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!
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:
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.
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.
The popular continuous build tool Hudson has a few options for those looking to backup their setups. Most people will suggest one of 2 plugins, either the SCM Sync which pushes config changes into Subversion with a log message, or the Backup Plugin which can be configured to wrap up your main config, build job configs, histories and artefacts. I wanted something that blended these 2- a way of pushing all the config and history for my jobs into Subversion.
I began to look into the source to contribute my own plugin and came across a Team Lazer Beez blog post where they have used a described a Hudson job which runs commands in the shell. It adds newly created jobs to Subversion, removes deleted ones and checks in any other changes to your config files. There were a couple of issues I had with it as it stood- mainly that it couldn’t cope with job names containing spaces, so I edited it a bit.
# Add any new conf files, jobs, users, and content.
svn add --parents *.xml jobs/* users/* userContent/* fingerprints/*
# Add the names of plugins so that we know what plugins we have.
ls -1 plugins > plugins.list
svn add -q plugins.list
# Ignore things in the root we don't care about.
echo -e "war\nlog\n*.log\n*.tmp\n*.old\n*.bak\n*.jar\n*.json" > myignores
svn propset svn:ignore -F myignores . && rm myignores
# Ignore things in jobs/* we don't care about.
echo -e "builds\nlast*\nnext*\n*.txt\n*.log\nworkspace*\ncobertura\njavadoc\nhtmlreports\nncover\ndoclinks" > myignores
svn propset svn:ignore -F myignores jobs/* && rm myignores
# Remove anything from SVN that no longer exists in Hudson.
svn st |grep "\!" |awk '{printf "\""; for (i=2;i<=NF;i++) {printf "%s%s",sep, $i;sep=" "}; printf "\"\n"}' | xargs -r svn rm
# And finally, check in of course, showing status before and after for logging.
svn st && svn ci --non-interactive -m "automated commit of Hudson configuration" --username user --password xxxxxxxxx && svn st
It is working great as a job set to run ‘@midnight’, or with a manual triggering of it after a particularly rigorous config editing.
Hopefully this will prove useful to someone else.
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:
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 }
@Override
String toString(){ value }
String getKey() { name() }
}
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!
By default, a freshly installed Apache on Debian-based distros print the server name and apache version in the footer of every error pages.
We gain nothing from displaying this information; in fact we are only making it easier for someone to find a known exploit in our version, so we will turn this off.
To turn this off for all VirtualHosts we’ll set it in the main config file, usually found at /etc/apache2/apache2.conf. At the bottom of this file, add:
ServerSignature Off
If you are still using the default config (/etc/apache2/sites-available/default) you will need to remove the line from there. Also check any other config files you might have inherited from anything else running behind apache.
Updated:
Closer inspection shows that the default install has a file in conf.d called security. This is well worth reading as it has a basic secure config ready to be dropped in, including hiding the server details.
Updated even later:
A more complete list of good ways to secure your apache, check out this great post by Anson Cheung.
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.
This year at DevCon3, Anna Kennedy and I ran the ‘Paradigms of Programming’ session created by Steve Freeman and Michael Feathers for SPA2010. The session is focused upon expanding knowledge and awareness of different paradigms which can be programmed in instead of focusing on the languages used- a point Robert Floyd made in his 1978 Turing award acceptance article when he wrote:
“…advancement of the art of the individual programmer requires that he expand his repertory of paradigms”.
To get people thinking about the paradigms more, the majority of the session was spent getting everyone working with each of 4 selected paradigms of programming: Procedural, Object Oriented, Functional and Rule-based.
There were four tables set out and each one had been assigned one of the paradigms. The attendees split into 4 teams to sit around each table and were given the same problem to solve, writing pseudo-code in the style of that tables paradigm. After 15 minutes of working on a solution, each team picked one person who (in theory) understood their work to remain as the “maintainer”. The iteration ends with everyone else moving to the next table to begin working with the next paradigm.
The second iteration began with the teams first being briefed by their maintainer on the thoughts and design of the previous team. The original problem was extended to require more functionality and each team added this to the work they had inherited. At the end of this iteration a new maintainer was selected with the express rule that this could not be the person who had played the maintainer for this iteration, and the process started again.
As well as allowing a comparison between different paradigms implementations for the same problem, the exercise has some interesting features designed in by Michael Feathers and Steve Freeman. The most notable is that after the 2nd iteration each team is maintaining code where the original developers aren’t available. This helps to demonstrate the intrinsic ease of comprehension each program had. The tasks for iterations 3 and 4 also held some opportunities for reuse and could highlight the defects and merits of the design.
It was interesting to watch how the teams progressed whilst performing the tasks and the effects that this had on code verbosity, maintainability and the time it took to complete the tasks.
It was especially interesting to see a couple of the participants who are not software developers joining in. These people seemed to have a much easier time switching between paradigms and remarked on how they enjoyed trying the different styles and ideas.
In contrast, some of the developers who would occasionally muse “How would we do this in <favourite language>?” seemed to find it somewhat more difficult. This is a perfect example of what happens if we make one language and the act of programming synonymous in our minds: we hamper our ability to think of other solutions outside of our ‘main’ language. I do not think this is a problem so long as we are mindful of how to implement other paradigms in that language, which is the main point I feel this exercise makes very well.
Outside of this macro-people watching, it was very interesting to observe the common themes which each team followed when working on a particular paradigm. Here is a brief summary of what we saw:
The Object Oriented paradigm is certainly the one with which most of the attendees were familiar. This was reflected in the fact that whichever team was working on it, that table tended to complete the set task first.
The structure was easy to extend and reuse. It also made it easier to see the concepts of what the original designers had been thinking as they solved the initial requirements.
On the downside, the final code for the OO implementation was very long, partly down to the very-close-to-Java pseudo-code used and partly due to the relatively verbose code needed to add functionality in the later iterations.
The procedural paradigm was also familiar to our teams and as such it reflected many of the same benefits and realisations as OO. However, as the code grew phrases like “erm…this does some stuff” crept in more and more and pen-testing/debugging took more time as people struggled to follow the flow of execution and its resulting effects on the data structures being used.
Despite these drawbacks, the code didn’t get too big or become particularly unwieldy, though it was certainly the longest solution at the end.
This paradigm was relatively alien to most attendees. In general, it was agreed that this paradigm was pretty simple once you were able to get your head around how it worked. It was decided that this was probably the easiest paradigm to extend and it was very easy to implement this particular problem with this paradigm.
However, the discussion also raised the point that for a system or problem which required a larger number of rules, it might become unwieldy and almost impossible to debug as the composition of rules gets more complex.
This was largely considered to be the hardest paradigm to work with – mostly due to people’s unfamiliarity with the paradigm. It was particularly interesting to note that when each team arrived at this paradigm, they tried to rewrite the existing code and start all over again as very few people understood what was going on.
The discussion around this paradigm raised the point that it is perhaps harder to decompose a problem into manageable chunks when using the functional paradigm, though no one was sure if this is an inherent issue with the paradigm or whether it is just a side-effect of most participants being used to decomposing the problem into objects and items rather than events or functions. The difficulty I had in finding a clear and concise definition of functional programming online also reinforces our results, though I am unconvinced that it isn’t down to the same issues of the prevailing mindset decomposing problems to items/objects.
Another issue that this paradigm specifically faced during our session was that the syntax was very hard to understand.
So what did this exercise demonstrate?
The primary lesson to learn here is the reminder that we can solve most problems in a variety of different paradigms. Each paradigm is appropriate for different scenarios and, whilst some languages are certainly written with one paradigm in mind, we can write code in a style approximating different paradigms in any language. As Floyd suggested, we become better programmers by expanding our repertoires of paradigms.
We also demonstrated that it can be difficult to maintain code written by others in styles with which we are unfamiliar. Whilst this could easily be used as an argument to support the idea that we should not stray from the core paradigm of the language we are writing in, I believe that we should hold each other to a higher standard and expect a good programmer to be at least slightly familiar with these alternate paradigms. If we avoid using them because someone else may not understand them we can fool ourselves into missing better solutions and enter a vicious circle of neglecting the less used paradigms.
Hopefully it serves as a reminder that, whilst learning new languages, API’s and design patterns are important for us to be more productive, we may (and many of us have) narrow our fields of vision to only look at procedural and OO paradigms. There is a lot of value and many possibilities in other paradigms which do not get very much attention outside of academia.
There are a few things I would like to try or would suggest trying in the future if this session is run again:
The Steve’s original material, including some example implementations, can be found here, and the resources I modified can be found here.
We hope all those taking part enjoyed it and we would like to thank Steve Freeman and Michael Feathers for creating the session and allowing us to use the materials for it!
Thanks for visiting, the link from the newsletter isn’t working in some cases but the article referenced is this one: TDD at the System Scale.
I’ve finally made the jump from my tired iPhone to a nice shiny HTC Desire running Android 2.1. Initial impressions were that it was very promising but that Android had some way to go to get to the iPhones level of polish and function. I was very wrong… with just a few apps I’ve surpassed the experience of my iPhone is almost every way. Here’s are my essential apps for a new Android user:
DoubleTwist lives up to its tag-line of ”iTunes for Android” in the best possible way. It comes as both a very decent desktop client, which looks quite like iTunes, and the best media player I’ve seen on Android. It handles music well, syncs to any attached storage device and even imports your music library automatically if it detects iTunes or Windows Media Player on your pc. The killer feature though is its podcast support- the PC application is a great pod-catcher on its own, but the fact it syncs the podcasts and my position listened to means it gives the one feature that kept me using iTunes. It even rolls in Amazons MP3 store and a nice view into the Android Market Place just to seal the deal. I can’t recommend it highly enough, especially for users coming from the iPhone. The only possible downsides are that it currently doesn’t have linux client (yet) and soon it may become a paid app, though this second point is moot- DoubleTwist is easily worth paying for.
RedLaser made a huge splash on the iPhone by introducing the ability the look up products by scanning their barcodes. This was something of a fad which seems to have mostly passed and Barcode Scanner does the same thing on Android. However, it is useful for far more than that, thanks to the Android community using QR (2D) barcodes to share download links to applications- sites like Androlib and lifehacker frequently add them to posts about apps, as do humble techies like me. Point Barcode Scanner at these blocks and your phone will ask if you want to install it. Easy and simple, couldn’t ask for more!
Fantastic, fast and good looking mobile web browser, Opera Mini has a nice implementation of multiple tabs and a landing screen which acts as a speed dial to your favourite sites make getting where you want to go quick and easy. Almost definitely better than the stock browser your Android phone will ship with, certainly the default on my phone now, just as it was on the iPhone before.
Android ships with some pretty average ringtones and thanks to RingDroid its pretty easy to replace them with snippets of any MP3′s you have on your phone. The interface its intuitive and within a couple of minutes you’ll have some more personal ringtones. Please use this ability wisely, we’ve all got a ringtone that makes us cringe whenever we hear it…
An excellent portal into Last.fm, the official app is also capable of scrobbling (notifying last.fm) the tracks you play them directly on the phone, so no more errors which plague the iPhone implementation. Also great for getting recommendations and works with the DoubleTwist media player as well as the stock one.
Finally but by no means least, ASTRO lets you view your on-board storage and SD cards on the phone. This means you can actually find files you download while out and about but it also means that you can browse network shares. It was a glorious moment when I realised I could stream all of my photos and movies from my NAS box and PC’s straight to my phone! Very worth having for those occasions.
With these 6 apps I can honestly say I feel like I’m now using a device that is superior to the iPhone. Yes, there will be a couple of things the iPhone does better, but given the quality and volume beginning to populate the Android Marketplace, I think the iPhone will have to lean more and more on good marketing rather than better apps. These 6 apps really are the tip of the iceberg- I’m constantly trying and finding new cool things to play with. It’s great to see the Android marketplace is very alive and well, I’m certainly looking to dip my own toes into development very soon!
Software developer, dedicated to quality engineering practices and learning new techniques and languages.
7 years of development experience and 2 years experience of web design and Linux system administration.
Always interested in projects creating mobile applications, web-based services and new devices. Eager to learn and try new things!