Sometimes I go to a bootcamp style gym and theprescribedworkout is something insane like 100 pullups, 200 pushup and 300 squats. On the surface this seems impossible. On a good day I can do perhaps 20 pullups in a row which is only 20% of the number needed here. During the workout, which took me a little over an hour last time the muscle rich coaches yell platitudes like something from a Simpsons episode. One of the favorite chants is “Chip away at it, chip away”.

With ripped hands and believing that I would never again be able to inhale like a normal person again I have very little interest in hearing the chants. (My favorite one of the last week was “burpies should be your rest, they’re easy”) However the chip away comment I find to be pretty applicable to software development. On any project of any size and of any age there is going to be a great deal of technical debt. Trying to pay down technical debt all at once is impossible. You’ll never convince management that all new development needs to stop so that you can make invisible improvements to the code base. Instead you should make as small a changes as possible while you’re doing other development.

My rule is that if I’ve opened a file, even if I’m just reading code, then I need to make an improvement. It could be as simple as removing unused using statements or changing a stringconcatenationto a string.format. These don’t seem like they’re going to do much to pay down your technical debt but their effects arecumulative. Eventually you run out of trivial changes to make in your files and you start making slightly larger changes. These slightly larger changes add up to larger changes. Before you know it your code base has been improved.

I followed this idea at a job once. When I started it took us 2 months to do a realease of our software. We identified the biggest pain point and automated it. Then we repeated this process until we actually ran out of things to automate. It took a couple of years but we got builds down so that they were running every night and producing full release packages. I automated myself out of a job. At least I would have if we didn’t end up responsible for two dozen additional products. If we hadn’t worked away at it wewouldhave been working 90 hour weeks just to stay on top of things.

Paying down technical debt is like paying a mortgage. If you just pay a little bit more each week then your debt will be paid down much sooner.

Chip away at it.

In my mind one of the most abused bits of functionality in ASP.net MVC is the routing engine. I don’t think this is a problem unique to ASP.net MVC as other MVC frameworks like Rails also make heavy use of routing.

In a nutshell routing allows you to map the URL(or URI if you want to beentirelycorrect) to a file or action on the server. For instance if you look at the URL for this post

http://blog.simontimms.com/2013/03/04/why-you-shouldnt-be-bothering-with-routes

You can see that there is some information buit into it. I don’t know the internals of wordpress but you can be pretty much assured that there isn’t actually a file on disk calledwhy-you-shouldnt-be-bothering-with-routes in the directory/2013/03/04/. Instead this URL is used by a routing engine to passappropriateparameters to a script which looks up information in a database. The combination of the domain and the name of the blog is probably sufficient to identify the record in the database. The date information in there is just a hint to readers so they know when the blog was written.

The only thing is: its wrong. I’m writing this blog on the 9th of March and it is scheduled to be published on the 13th. The reason that date is there is that I created a draft on the 4th. That I created a draft on the 4th isimmaterial. I have some drafts from 9 months ago. Heck, I have a half written rant about an architectural failure at Backblaze which is so out of date that it will likely never be published. The draft date is not important in the least.Fortunatelynobody looks at the URL to gather this information.

URLs are not meant to convey useful information to people, they’re there as instructions to computers. From time to time it is useful to have a friendly URL that people can remember but this is typically only for allowing them to type it in from a piece of paper. URLshorteningservices are fantastic for that.

Embedding information in the URL might look nice but it has very limited utility. In the .net world routing is provided by System.Web.Routing and this is typically configured in the startup of an MVC application. I have seen a number of MVC applications which have dozens, even hundreds of routes defined. Even Phil Haacked has contributed to the madness by providing a route debugger. Stop the madness! Use the default routes!

Having complex routes makes it very difficult to figure out which controller it is that is causing you trouble. It is also a boat load of extra code you need to test and understand. The fact that a route debugger is necessary should be a big hint that your logic is too complicated. The default route is sufficient for 99% of the requests coming to your site.

The only legitimate uses I can think of for routing requests are:

1. You need to do some optimization for search engines. Apparently google place some emphasis on the structure of a URL. It is difficult to tell because google keep pretty quiet about how they do page ranking. Optimizing for search engines is a prettysleazybusiness anyway so you’re likely better of not even trying.

2. Mapping old URLs. This is a really good call. It sucks when there is a change to the underlying engine behind a website and now none of your links work. By setting up a mapping you can avoid a lot of 404s in your error logs.

If these two reasons don’t match your use case then don’t even bother adding custom routes. It will save you headaches in the future.

It seems like I’m writing a lot of fizzbizz examples at the moment. It is kind of fun experimenting with different languages. There are always different constructs for looping and recursing. I’m also super happy that there are a lot of languages to get through before I have to write it in prolog. I have prettytraumaticmemories of prolog from university. Today’s language is shell script.

Of course shell script isn’t just one language, it depends on which shell you’re using. When I worked a lot with unix derivatives I mostly worked with bash scripting. Unless it was aparticularlyold or odd OS in which case we would end up on plain sh. There are a bunch of other shells out there and I can remember a time when both csh and ksh were also popular. I can also remember when druids sacrificed goats. Is there a link between ksh’s stupidarcanesyntax and goat slaughter? I can’t proveconclusivelythat there is but there are no dead goats here and no ksh syntax either. Draw your own conclusions.

I thought I would try using zsh style scripting for fizz bizz. Zsh is a newer shell which has many of the features of bash and also borrows from other shells. Now I say “newer” but it still dates to 1990.

The script starts with a sha-bang which instructs the program loader that to run the script it should execute /bin/zsh which is where zsh lives on my machine. It might be better to replace it with #!/usr/bin/env zsh which instructs the program loader to launch env which searches for zsh. This allows for searching of the path for zsh. There is an increased security risk with doing so as an alternate zsh might be selected. However this risk is probably worth it for increased portability.

I was hoping that it was possible to putmathematicalexpressions in the case statements but that’s not possible. Instead I took advantage of case statements here and the fact that we can take the remainder modulo 6 to do most of the fizz bizz heavy lifting. On line 3 there is a bit of a syntactic oddity. Zsh is not really designed for doing a lot of math so arithmetic operations need to live inside double parenthesis.

Gosh, I can’t wait for the next interview where I’m asked about fizz bizz. I am going to kill that question.

If you read this blog with any sort of frequency you’ll know that I’m somewhere in the range of 15-18% about typescript. In my travels the other day I created a new web project on a machine without typescript installed(go on, ask me how many computers I have at home). When I went to add typescript to the project it didn’t compile and I squinted my third hardest squint. Digging around on the web I found that one might need to add a target to the .csproj file. The examples I found all pointed to the typescript found in C:\program files.

I hate that.

Doing so means that you have to install typescript, in the default location, for the compile to work. That’s too much friction for setting up the project on a new machine. Instead I copied the contents of that directory into a tools directory in my project and checked it in. Now when people compile it they won’t even notice that it is building their typescript for them and the friction for a new developer is 0.

The target? Well just paste this into your .csproj file right before the

I put typescript in a tools/typescript directory at the same level as my .sln file. All good to go.

A while back I blogged about how I thought having a FizzBizz like problem on a job interview was a good idea. In that post I mentioned that coming up with novel ways to do fizz bizz should be fun for more senior developers. I though perhaps it might be fun to try out this F# language I’ve been hearing so much about as of late. So I poped over to the Try F# site where they have a nifty online F# interpretor. A bit of paying resulted in

F# is a functional language which has really good support for lists or arrays. Here I used the | operator which is a forward-chaining operator to pass the results from one function to the next. It is reminiscent of shell scripting (incidentally doing fizz bizz in shell scripting would also be fun). As part of F# there is a concept called a filter which acts in sort of the same way as a switch statement. It allows you to match the elements of a list and perform different actions depending on the match. That’s what you see on lines 3-6.

Being pretty new at this F# stuff I went hunting for other people’s solutions online. No better way to learn a language than to see how other people use it. That’s why github is so awesome. Well it is one of the reasons. I found a swell answer on StackOverflow inTomas Petricek“˜s answer. The gist of it seems to be that this is a functional language and we should be attempting to use it functionally. To do that we can declare an active pattern and slot that in instead of the individual modulo checks. This allows us to remove the where from the filter

So there is an F# version of FizzBizz.

There are two schools of thought behind how to construct methods. The first says that your method has one entry point so it should have one exit point. A method like that would look like

With this it is easy to see where the value is returned to the caller. Other than that there is not much good about the structure of the code. There are a lot of brackets and you have to read the whole function to figure out what it is doing. As I understand it this particular structure of code is a throwback to the days of structured coding and was used to avoid the dreaded GOTO. The other method of designing a method is to return early. If we rebuild that last method it would look like

Here we can see that there are a bunch of places which return. As we read through it is easy to see where we return. There is no need to read the entire function as we trace through it. At the top is a guard clause which will return right away if the parameters to the function are incorrect.

Now to be fair I took returning early to an extreme in this example. Everywhere I could retur early I did. If I were to come across this function in a code review it would be questioned. I would probably rewrite it to use a number of functions, something like

It is still a bit messy but that is probably more a function of a poor API for the imaginary client I created.

So the conclusion is that single entry-single entry is an outdated concept which makes code difficult to read. At the same time leaning heavily of return early createsmessycode too. Mixing the two and makingintelligentdecisions on a per method basis is the optimal strategy.

Irritatingly frequently I encounter a request which basically boils down to “I have this amazingly complicated excel spreadsheet I’m using to stop the company from going bankrupt, can you make yourapplicationproduce it?”. So I bravely dive into it and find 96 tabs and graphs and the what not. I am terrified that so much of the business world relies on spreadsheets of this sort but my nightmarish fears are not the subject of this blog. Well not today.

I make use of theabsolutelyfantastic excel library EPPlus. In today’s nightmare I was to create a databar. This is a special sort of conditional formatting which basically creates a bar inside a cell.

The length of the bar is calculated based on the range between the largest and smallest values in the range. Aren’t they pretty?

The latest version of EPPlus adds support for conditional formatting and you too can create these sorts of spreadsheets programatically.

Basically all you do is select the range you want and assign the conditional formatting of type databar to it. As far as I can tell there is no support yet for solid fill bars.

Ten years ago when I wrote JavaScript I only ever had one function and the function was always called validate. The only function for which I used JavaScript was validating for entry. Somewhere along the line JavaScript became awesome and it was possible to build large applications using JavaScript. I personally think the watershed moment was when gmail burst onto the scene. I understand that the first version of gmail waswrittenin Java using aframeworkcalled GWT which transcompiles to JavaScript. However, the point remains that it is possible to build complex applications using JavaScript.

In object oriented languages code is arranged into functions, these functions are grouped together into classes and the classes are placed into namespaces. This hierarchical approach allows for thearrangementof large quantities of code into a logical structure. For the most part this method of arranging code has gone unchallenged for decades(with the exception of AOP, but that’s a whole other post). JavaScript was never envisioned as a language for building large applications so it lacks first class support both classes and namespaces. Just as with Perl it is possible to simulate objects using arrays and even namespaces.Unfortunately,the syntax is prettyarcane.

Typescript to the rescue!

First classes. The syntax is pretty easy

This short snipped of code shows off a lot of different features of the classes. First we see a class level property in the description. Next there is a constructor fo the class. You’ll notice that the propertypublicationDate is prefaced by the keyword public. This is a great little shortcut which turnspublicationDate into a public property on the class. It is the same as if we had created a property like description then assigned a value to it in the constructor. Finally we see the use of the this keyword to denote that we are accessing a class level variable.

Now if we wanted to move this class into a namespace we would use the module directive

Modules can be described in any number of files and the JavaScript engine will combine them together for you.

The beauty part of TypeScript and other languages which compile to JavaScript is that if you decide to abandon the technology and switch back to JavaScript then the exit cost iseffectivelyzero. TypeScript produces this, very readable, JavaScript from our module and class

I have been using typescript which is the newishMicrosoft language which compiles to JavaScript in a lot of my blog posts lately. It occurred to me that I haven’t actually written anything about typescript by itself. I’m really a big fan of many of the things typescript does so let’s dive right in.

The first thing to know is that typescript needs to be compiled by the typescript transcompiler. There are a number of ways to get the compiler. You can install it as part of a node.js install using npm, the node package manager. You can download the visual studio plugin or you can compile it from source. Compile it from source? What is this, linux? Actually the compiler is written in typescript. I guess that this is a pretty common thing to do when you build a compiler: build a minimal compiler and then use that to build a more fully featured compiler. It boggles my mind, to be perfectly honest.

Anyway, I installed the npm version because I’m doing most of my web development using the Sublime text editor. The command line is very easy, you can pretty much get away with knowing

./tsc blah.ts

This will produce a javascript file called blah.js. I recommend that you keep the default of naming the javascript files after the type script files, it will help you keep your sanity. If you really want to rename the output you can do it with the out flag

./tsc blah.ts -out thisisabadidea.js

There are a number of other flags you can use including a bunch of undocumented flags you’ll only find by reading the source. The most useful flag is -w which watches the .ts file and recompiles it when there are changes. This is useful if you’re developing you code and don’t want to have to keep dropping to the command line to recompile and then refresh in the browser.

The first thing about the typescript language itself you need to know is thatit has a hybrid type system. Typically javascript performs type checking only at runtime, by default this is the same thing that typescript does but typescript allows you to perform some type checking by annotating your variables with a type. To do this the syntax is to add : type to a variable declaration. These can be used in functions and in declarations. For instance:

If we change the call to this function to

Then try to compile it typescript will throw an error

Supplied parameters do not match any signature of call target

This is obviously a very simple example but I have found that typescript quickly pulls out silly typing errors which normally I would have to check with unit tests.

Tomorrow we’ll look into some more features of typescript.

Yesterday I showed creating a force directed graph with a dataset taken from wikipedia. As it stood it was pretty nifty but it needed some interaction. We’re going to add some very basic interaction. To do this we’ll use the data- attribute we added when building the graph. These attributes were added as part of HTML5 to allow attaching data to DOM elements. Any attributes which are prefixed with data- are ignored by the browser unless you specifically query for them.

I started by adding a set of buttons to the page, one for each show.

Then I added a simple jQuery function to hook up these buttons and filter the graph

First I reset the graph to is original color, then I select a collection of elements using the data-productions element. This is a stunningly inefficient way to select elements but we have a pretty small set of data with which we’re working so I’m not overly concerned about the efficiency. It could be improved by using a css class instead of a data-attribute as these selectors have been optimized.

The final product is up athttp://bl.ocks.org/stimms/5069532

There are a bunch of other fun customizations we could do to this visualization. Some of my ideas are:

• Improve the display of name labels during hover
• Highlight linksbetweenpeople when you hover over a node
• Show the number of collaborations when somebody hovers over a link

That’s the best part of visualization: there is always some crazy new idea to try out. The trick is to know when to stop and what you can take away without ruining the message.