Big Software in Little Pieces

I recently gave a talk at FESuffolk about Service Oriented Architecture and the general principles of writing big software in small pieces.

The video has been posted over here on the FESuffolk site if you’re interested.


Where does the Web go from here?

The web is a bit of an awkward teenager right now. Browsers full of plugins have been replaced with browsers running immense client-side JavaScript apps.

This is a big step in the right direction but the heavy use of JavaScript comes with its own problems. We spend vast amounts of effort have to be spent on browser dependent hacks for everything from audio to accelerometers. Lots of time and energy is put into solving similar problems over and over and very little reliable parity between browsers.

There are at least two options open to deal with this.

The first is simply to carry on; keep on hacking and shimming and poly-filling the gaps between the browsers we want and the ones we have, perpetuating the cat-and-mouse game of browser support for JS libraries, leaving support as an ‘n*m’ problem.

The second option, as Lyza Gardener put it at Over The Air 2013, is to “save the web by doing as little as possible”; we try to avoid the workarounds and wait for the standards and browsers to catch up. The web gets better as standards arrive and the complexity is pushed into the browsers and it is just an ‘n’ sized problem of dealing with the differences between browsers.

All we have to do is stop adding to the mess and try to resist the pressures and habits which lead us here in the first place, and this might be as hard as it sounds if we consider the context of things right now.

The internet has gone through major changes in the last decade, transforming from a desktop centric screen on the end of a paltry 56K connection into a vast array of laptops, smartphones and tablets devouring broadband and 4G. This has opened up so many possibilities but it has also created hundreds of new combinations of browser, screen and connection speed to cater for. On top of that, devices give us all kinds of new sensors to play with but each device offers a different combination or interface. The ‘m’ in our ‘m*n’ problem just became a much higher number.

All of this change is just beginning to settle down (at least until Google Glass-like devices or the Internet of Things become widely adopted and change the landscape again) and we are making the tools to provide excellent experiences on all these new forms of the internet; practices like responsive design are helping us close the gap between what is possible and what we’ve actually done. There is still an unimaginable amount of ideas to explore but, perhaps for a brief time, we have a chance to catch our breath a bit.

That means that now is the right time to start focusing on standards. We need to work on standardising APIs for real-time content, accelerometers, ambient light sensors and all the other neat inputs we suddenly have access to in a modern smartphone or tablet. Once we have the standards, the browsers can work on conforming to it and we’re back to just the ‘n’ sized problem of supporting each browser.

The earlier we start, the sooner we have all these capabilities easily and reliably accessible through browsers; We finally have a chance to help the web settle into a healthier, standardised form, ready for whatever comes next.

Beautiful Code (IPRUG Jan 2013)

On Tuesday January 13th I gave my talk “Beautiful Code” at IPRUG. Thanks to everyone who came and made it a really enjoyable night!

The slides are now available on Google docs; I’ve retyped the code examples so they might look a little different but the content is the same.

A lot of the ideas and examples were taken from the excellent talk, “Confident Code” by Avdi Grimm and the following talks were very influential:

All of these show some really nice examples of refactoring and lay down principles to guide us towards clean, well structured and ultimately more beautiful code.

I hope you find some of this useful and it helps you to make your code more beautiful!

Fixing Command-T for Vim in Ubuntu 12.04

The Command-T Vim plugin gives you a TextMate style “Fuzzy search” for files in the current directory tree. Basically, you can hit a button and start typing the bits of the file name you remember and Command-T will show you a set of search results.

On my first attempt to build and use Command-T it caused a seg-fault whenever I activated it. This is because Vim in the Ubuntu apt repo was built with the ancient ruby 1.8.7-p352, and Command-T only works when run under the same version which Vim was built with. If you install vim (or gvim/vim-gnome) from the package repos but get ruby from somewhere else, you’ll need to do the following:

  1. Get a copy of Command-T by following the readme. I use pathogen to load my vim plugins, so I cloned the Command-T git repo in my .vim/bundle folder.
  2. Navigate into the folder Command-T extracted or cloned to.
  3. Run `ruby –version`
    1. If you get the answer “1.8.7-p352”, congrats, go to 3 (argh, I used a goto!)
    2. If not, try setting your ruby to the system default.
      1. rvm users should run `rvm use system`,
      2. rbenv users can use `rbenv local system`.
    3. If you don’t see version 1.8.7-p352 now, we’ll install it. rvm users run `rvm install 1.8.7-p352`, wait for the compile to finish and then run `rvm use 1.8.7-p352`
  4. Now that’s sorted, lets build Command-T. First, cd into “ruby/command-t/”
  5. Run `ruby extconf.rb && make` to actually do the build
  6. Congrats, it should be built and working. Hit “<leader>t” in Vim and you should get the search box. Type in the name of your file and see if it completes!

I hope this helps, if not you can try loading my vim config and see if the Command-T I have built there works for you.

Composability is Crucial

In all technical work, I find there is an often overlooked principal which delivers a huge amount of value: Composablity.

In OO programming, this is represented by the core ideas of “loose coupling” and “highly-cohesion”. These principles drive us towards creating objects which can be reused and transposed easily- basically, we aim to make our objects composable in different circumstances.

In scripting and the whole-program level, composabily takes many forms. Adding lots of import/export options to your software enable users to involve it in their work more easily, but things really get interesting when you look at composability taken seriously.

One of the driving ideas for Unix/Linux was that of “small, sharp tools”, programs which do one job, very well. The result is almost magical: once you have learned a handful of the hundreds of commands, you can start piping the output of one into another. Suddenly you have a sort of “data manipulation Lego”- once you find the piece you are looking for, you can add it on to your others and quickly get some advanced behaviour.

Whatever I am building, I keep thinking about how my choices will affect it’s composability and found it a very useful tool. Hopefully it’s an idea that might help others too!

Edit: Sandi Metz gave a great talk which highlights the use of composition/collaboration to avoid an “Omega problems” and keep your projects fun to work on.

Grails: populate a g:select from an enum

As easy as it is to hard-code a list into a selection drop down box in grails, it is a pretty big violation of the Don’t Repeat Yourself principle and is best avoided. I struggled to find an answer for a neat way to do this, so here is how I recommend doing it:

Step 1: Define an enum

If you’re using the domain layer you can obviously put your enum in you domain objects and refer to them there in the later steps but for this example I’ll assume you don’t have or can’t change your domain layer.

In src/groovy/myPackage we’ll create a new enum with some values and the pretty standard enum methods.

package com.adamwhittingham.grails.examples.SearchableField:

public enum SearchableField {
    USERNAME(“Username”), FIRSTNAME(“First Name”),SURNAME(“Display Name”),EMAIL("Email")

    final String value
    SearchableField(String value){ this.value = value }

    String toString(){ value }
    String getKey() { name() }

Step 2: Import it and use it in the GSP

In our GSP, the first thing we need is to know about the enum.

<%! import com.adamwhittingham.grails.examples.SearchableField %>

With that done we can now get to defining the using the enum

<g:select name=”searchBy” from”${SearchableField.values()}” value=”${SearchableField}” optionKey=”key”/>

And that’s it, you can now use the enum in your controllers and views without needing to edit a hard coded lists. Much better!

Lesson Learnt: The business is not my Enemy

Thanks to a conversation with my manager and mentor (not to mention technical genius) Neil Winton, I’ve finally truly learnt a valuable lesson. A lesson which I’ve heard people talk about at conferences and read books which espouse its fundamental importance, but until now I didn’t really get it.

The business is not my Enemy.

I work in a large company (100K+ people) and software developers are the minority by a couple of orders of magnitude. More than once I’ve muttered phrases along the lines of “it’s a miracle that anyone technically competent still works here”. I’ve seen (and had) brilliant ideas with well written implementations and great potential get killed off or completely passed by. Projects have been given to cheaper and less competent companies, only to come back buggy, untested, lacking automation and a whole host of other bad traits.

Seeing this happen repeatedly (and rapidly), the company feels more and more incompetent, ignorant of technical quality and driven purely by cost. Great strategy from the top seems to get diffused into a mist of poor implementations and wasteful deals with ill-matched vendors.

More examples soon stack up and the frustration and annoyance really kick in. Your team looks more like a beacon of hope and quality in a wasteland of poorly written projects. It becomes the fault of “the business” for pushing developers into dull management positions, forcing implementations using product X (which they recently spent millions on) and giving work to lower-quality contracts.

For me, this week the epiphany came: It’s a business– it’s function is to make money for the shareholders. Whatever helps that goal is rewarded.

This is not to say that it’s actions were always right or justified, it just means that someone rational thought it was the right thing to do– they did not understand the implications of their decisions.

If two people offer you a “Free-timed Cylomatic system”, one wants £500K and the other wants only £300K, which do you pick? With no real idea what the thing is or how it is made how do you value it? Both promise to deliver  in the same amount of time but obviously the second offer is 40% cheaper! You can save the company money and helping to reach your targets- maybe you’ll be rewarded with a nice bonus! Oh yes, one SharePoint instance does sound cheaper than running all this separate wikis and intranet pages, maybe even more money can be saved there! Awesome!

In “The Passionate Programmer”, Chad Fowler gives a lot of very useful tips for a creating a successful career but the one I feel most of us (techies) overlook is the idea of grabbing an intro to business admin book and really grappling with the way our companies are run. How are we actually making money and how does my project contribute to it? Once a decent percentage of technical people can answer these questions, our profession can begin to engage with the rest of the business in far more productive way. We are in a profession which doesn’t really line up with anything that people outside of it can identify with, yet we rely on them to make decisions about it.

I’m not saying all programmers need an MBA or should become “business managers”; simply that we need to learn the language in which to talk to the people with the money and power to decide.

I’m advocating educating yourself on a minimum of business theory. Enough that you can understand the next meeting where someone shows you lots of PowerPoint slides with graphs and spending figures on without your eyes glazing over. If we want the business to stop making such terrible technical decisions we need to reach out to the people making them and help them to understand what the real repercussions are.

I know that none of this is new but I am going to try and learn a little. The master carpenter knows how to read his balance sheet, I believe the software craftsman should be no different.