Thursday 14 July 2016

Tailoring Code



Over time, even with the best of intentions, code bases will tend toward entropy if constant effort isn’t made to improve and maintain them. Even revisiting your own code which has sat untouched for years, after your learning and knowledge has expanded, will look worse than you remember leaving it!

Recently I had a suit made to measure, and while the tailor is able to get it fitting pretty near right on the first attempt, he will always need you to try the suit on so he can work out what adjustments to make. The suit you try on is stitched properly, the alterations are made by carefully unpicking the seams being careful not to damage the material. The fabric is repinned and the new seam stitched in.

The same goes for an approach to refactoring code, the seams are the structure of code, the fabric being the logic. In order to change the structure, we must use techniques which leave the logic intact. We build the logic while not worrying too much about the structure of the code, and then refactor to form the exact shape. Just like the tailor we can iterate over this process several times until the final product has been crafted.


The tailor doesn’t worry about the first few iterations being time wasted as it helps him fit the suit to an individual body. Equally refactoring as we learn more about a problem space and find how we structure the code over time, helps us to create a codebase which is malleable and can evolve over time. As the codebase grows, alterations can be made to support the changing nature of the system, and the constant unpicking and restitching prevents devolution towards the mess seen in so many code bases where this has been neglected. 

Tailoring Code



Over time, even with the best of intentions, code bases will tend toward entropy if constant effort isn’t made to improve and maintain them. Even revisiting your own code which has sat untouched for years, after your learning and knowledge has expanded, will look worse than you remember leaving it!

Recently I had a suit made to measure, and while the tailor is able to get it fitting pretty near right on the first attempt, he will always need you to try the suit on so he can work out what adjustments to make. The suit you try on is stitched properly, the alterations are made by carefully unpicking the seams being careful not to damage the material. The fabric is repinned and the new seam stitched in.

The same goes for an approach to refactoring code, the seams are the structure of code, the fabric being the logic. In order to change the structure, we must use techniques which leave the logic intact. We build the logic while not worrying too much about the structure of the code, and then refactor to form the exact shape. Just like the tailor we can iterate over this process several times until the final product has been crafted.

The tailor doesn’t worry about the first few iterations being time wasted as it helps him fit the suit to an individual body. Equally refactoring as we learn more about a problem space and find how we structure the code over time, helps us to create a codebase which is malleable and can evolve over time. As the codebase grows, alterations can be made to support the changing nature of the system, and the constant unpicking and restitching prevents devolution towards the mess seen in so many code bases where this has been neglected. 

Wednesday 4 December 2013

NancyFx - Testing modules requiring authentication

I've recently been using NancyFx to build a pretty simple API. It's a great little framework, lightweight and super extensible. It's also been designed with testing in mind.

I developed a good chunk of the API without implementing any authentication mechanism. Later on I protected certain Nancy Modules by using Nancy's RequiresAuthentication() method which caused the unit tests around the controllers to begin failing. What I needed was to tell Nancy there was an authenticated user present.

Using Nancy's Browser() with the configurable bootstrapper, I loaded the module I needed to test:


But how to tell Nancy there is an authenticated user? Well all Nancy does is check if an instance of IUserIdentity with a UserName is present on the Context (authentication plugins set this!). We can get access to the context at the beginning of the request using the configurable bootstrapper, so modifying our Browser set up to the following is all we need to do, ta da, Nancy believes a user has been authenticated.


Wednesday 26 June 2013

Rails 4 Asset Pipeline Gotcha

Last night, I upgraded a site to rails 4. The site is a pretty basic rails app, so the upgrade path wasn't too painful, pretty much all I had to change was to do with the new mass assignment security - whitelisting of form params and the controller rather than the use of attr_accessible on the model.

The upgrade went smoothly until I pushed to heroku, the app built and ran successfully, however, a javascript plugin I was using wouldn't load in production. The javascript plugin is CKEditor, which has a number of javascript and css files which are loaded by including a script tag to just one root javascript file.

When using rails 3, I had placed the ckeditor folder in 'vendor/assets/javascripts' and forced precompilation of the folder's entire contents by adding config.assets.precompile += [ 'ckeditor/*'] to production.rb. This worked fine, as the asset pipeline compiled 2 copies of each file, one with an added hash in the file name and a version with the unaltered original filename.


In Rails 4 this no longer works, the asset pipeline no longer compiles 2 copies of the file, it only compiles the 1 copy adding the hash to the filename or not dependent on the config.assets.digest option. Now I don't want to disable the fingerprinting of my javascript and css, I want the caching benefits this gives me. The solution was therefore to disable the precompilation of the CKEditor files, and move the CKEditor folder to the 'public/assets/' folder.

Try where possible to include 3rd party javascript and css in the asset precompilation, however for those plugins such as CKEditor which will not work with fingerprinted file names, this technique offers a get out of jail card, but remember, these files have the potential to get stuck in caches and as the filename doesn't change when you deploy a new version of the plugin in may take a while for all clients to get the latest version!



Thursday 23 May 2013

Rails, Fast Tests and Architecture

For a while now I have been flirting with Ruby and Ruby on Rails. Very early on, I learned the hard way to stick to the 'Rails way', especially when you don't yet understand the technology. I have however, often found myself fighting both rails and what has appeared to be the 'standard' way of doing things in the Rails community.

While the Ruby / Rails community have been writing tests, and lots of them, the .net community has been catching up. In that time though, writing tests in .net, I've concentrated on the speed they run, we all want fast feedback right? Lets push those slow running full stack tests away from the unit tests so we don't need to run them all the time, and while we're at it lets minimise how many there are, lets just make sure the whole thing hangs together, lets not test every permutation through the UI while hitting the DB. Starting out with Rails, this was one of my first pain points, the lack of isolation in the test suite.

For a while I wondered why every test I wrote needs to spin up the entire stack, it's so slow. Putting all my domain logic on the ActiveRecord bound models, my model tests are slow as they go to the database all the time. But this seems to have been where to put your logic for quite a while, after all, we want 'fat models and thin controllers'. Does this really mean though that the entire model should be in one class?

Lets think about Rails another way, what if all 'model' means is 'the application'. What if the 'Rails Application' isn't the application at all? Maybe it's just a presentation adapter. Well maybe not, there's ActiveRecord too! So maybe Rails is two things, a presentation adapter and a persistence adapter.

I thought I was either going mad, or inventing a problem. I'm not experienced with the framework, maybe I'm missing something. Why don't these 'Rails guys' care about this stuff, is everything I know about OO going out the window? So I put down Rails, continued playing with Ruby, and kept building stuff in .net. And then I picked up Rails again and discovered that people have been thinking about this stuff. I discovered Corey Haines Fast Rails Tests talk. Uncle Bob's been fighting the corner and I recently came across his talk Architecture The Lost Years, and recently, Avdi Grimm's been writing a book Objects on Rails which you have to read.

So where does this leave us? When should we worry about the architecture, and when will all this stuff help, might it be a hinderance? I'll write about this in a future post (hopefully not too far in the future!)