Monthly Archives: April 2014

•

I knocked over this long standing member of my reading list this week, a staple of the programming, if not entire comp sci. industries reading list, and I can see why.

If you were putting off reading this like I was, I suggest diving in. It is much more relevant that you would think that a book written in the 70's about coding in the 60's, as the author put it, would actually be.

I also recommend getting the anniversary edition, published 1995, as it has a great retrospective on the entire 1975 edition, including many of the predictions in the No Silver Bullet essay, and the author has responded to many criticisms on statements he made in his 1975 edition.

While this is sure to just be another in a long serious of posts on this book over the last 40 years, I will only go into two points. What stuck with me, and of course, my 2 cents on the No Silver Bullet theory.

The statement that moving a program, from a 'garage app' program, to a commercial program woulds increase dev time by a factor of three struck home with me. Along with the sister theory that an app, to a app that integrates into a systems also requires are factor of three in effort. This culminated in the sum of the two theories that a consumer facing system integrating app equates to an increase of a factor of 9, and related to my experience with writing my very simple console app for slack.

A dirty app to raise an REST message via a console would be maybe 2 hours, (less if you have raised the scaffolding a few times before). Integrating that into both Jenkins, by reading the /api/json responses (append /api/json or /api/xml into any URL, very impressive.), and integrating into Visual SVN by reading the Env. Vars in the hselle that calls my console app and passing them into SVN look to full out the JSON responses did propel development time quite easily towards the 6 hour mark.

After all the pieces were getting along, my desire to look into best practice for console apps pointed me towards the Apache Commons CLI and the .Net CLI Implementation.

Then into Costura/Fody, and packaging it into a single exe.

After that, there was fair bit of refactoring, which I admit is due to my wanting to move it from a one trick pony console app, to something I wouldn't be ashamed of should my colleagues wish to dig around under the hood and extend it. As a result, should I have planned to it to be extensible initially, the refactor wouldn't have been required.

Though, back to the factor of 9 rule, I soon realised I had spend closer to 2 working days on this little console app, and it is still geared towards internal use in our team, than something I would want to distribute with the intention to maintain, my motivation was towards best practices, and a chance to do delve considerably deeper than I typically did with my console apps.

There have been a number of internal software projects I have come across, and internal staff often bring up that we could package it and turn it into a revenue stream. I think is some cases a factor of 3 to put that internal app you use in house, to something you would comfortable putting on the app or play store under you name is pretty conservative.

As for my thoughts on No Silver Bullet, the idea that there would be no single development in a 10 year period would increase productivity by an order of magnitude (factor of 10), is something I agree with. That being said, I believe that development package management, such as nuget, npm, bowser may warrant a brief mention, though more likely a foot note should there ever be a 2015 anniversary edition.

Package management alone does not met the silver bullet criteria of course, in that its only a slight automation over the previous common practice of having your personal repository of packages, or adding the most recent repository into your own projects. Also developers in the 60's if not 40's knew all to well, if not more that their modern counterparts, to not try and re-invent the wheel. I see the change has been in the overall accessibility of packages in general, along with one click integration, which is already taken for granted in how easily we can increase our output by standing on the shoulders of giants, and turn a empty project file into a highly extended framework and customised stack in literal seconds.

I am sure when I revisit The Mythical Man Month later in my career, when its pushing past its 1/2 century since iniltial publishing, there will still be much more than not, which still holds true.

 

•

After Integrating Visual SVN & Jira with Slack, I decided to replace the existing bat file calling a python script with something a bit more extensible.

I also wanted to change Slack's SVN integration to a custom one that would point to the revision on our Fisheye server, which would show the changes made and link to Jira when we added the  ticket <ProjectName-Ticket#> in the Commit Notes, which Fisheye does out of the box

.Net REST Console App

I decided to build a console app that call the slack incoming webhooks API. It needed to:

  • Accept a channel name, title & API Token
  • Accept a SVN Projectname & revision number to call SVNlook & get author & log details. (When fired by SVN Server)
  • Accept a Jenkins name to hit up the Jenkins JSON API for build details
  • Parse success/fail messages and convert them to the Slack notification color names (good, warning & danger)
  • Create a JSON Object
  • Post the JSON object to the slack API
  • A verbose option for debugging
  • Manually enter message text, and author to integrate with other apps down the line.

.Net Apache Common CLI

As there is quite a large set of parameters, I made use of the .Net port of the Apache Commons CLI libraries by Akutz. This handles all aspects of console arguments, while adhering to best practices and existing expectation when passing argument to a cone application.

An example of the init & usage syntax is below.

options.AddOption("a", "apiToken", true, "API token.");
...
get
{
  if (_apiToken == null && Globals.CMD.HasOption('a'))
  {
     _apiToken = CMD.GetOptionValue('a');
  }
  return _apiToken;
}

This is a huge help in argument management, and also handled the help messages.

There was very little documention on .Net CLI, though using the Apache usage documentation was fine, just remeber to capitalise the method name i nthe .ent vesrion, for example option.AddOption instead  of option.addOption, option.HasOption instead of option.hasOption and so on.

And one last catch, the Apache DefaultParser was called the BasicParser in the .Net port.

BasicParser parser = new BasicParser();
CommandLine commandLine = parser.Parse(options, args);

RestSharp

Restsharp likely needs no instruction has a library for simple Rest messaging.

I found it very easy to use, apart from one hitch that had me stumped for much longer than I would like to admit.

The following code (I thought) added the query string with the API token for slacker to the url.

 var request = new RestRequest(resource, Method.POST);
request.AddParameter("token", "CfkRAp1041vYQVb");

However, doing so, and then trying to add any details to body via request.AddBody resulted in it not being added, nor raising an error attempting to do so.

request.RequestFormat = DataFormat.Json;
request.AddBody(json); //Ignored if AddParameter was previously called

Opening up Wireshark showed that the query string was being added to the body.

After a bit of head scratching I found that AddParameter took a third argument,

request.AddParameter("token", "CfkRAp1041vYQVb", ParameterType.QueryString);

SVN versioning

As I planned to use this exe on various production servers, automated SVN versioning was the next logical step.

I utilised Avi Turner's SVN versioning script on stackoverflow to update the $WCREV$ tag I inserted into the AssemblyFileVersion in AssemblyInfo.cs and rev.subwcrev-template used to track the currently checked out & built version.

 Costura.Fody

Finally, I though I would try my hand at weaving assemblies into the .exe for a single file deployment.

I settled on Costura.Fody as many had said that it Just Works™

After adding both Fody and Costura.Fody via the VS2013 package manager, I assumed the various build xml files automatically would need to be tweaked. Though, when I hit build, I realised that I didn't need to touch them at all, and ended up with a exe file where every assembly set to copy local, in this case RestSharp, was embedded into the exe.