Ubuntu/Debian Apache: Hide your server details on error pages

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.


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.


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.

BT DevCon 3: Paradigms of Programming Retrospective

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.

The Exercise

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.

The Results

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.

Thoughts for future workshops

There are a few things I would like to try or would suggest trying in the future if this session is run again:

  • One defining issue with our session was that, whilst Steve and Michael’s original session had 3 hours at SPA2010, we attempted to fit it into a 1.5 hour slot. This meant that the summary was compressed but otherwise it worked well. I would suggest in future at least 2 hours was given (10 minute intro, 4×20 minute iterations, 20+ minutes for discussion and summary)
  • Bolstering the documentation on the paradigms with more examples, especially the functional handout, to alleviate some of the trouble with understanding the paradigms.
  • We had some issues with the 4 teams having ~15 members per team. Due to a lack of space we could not split it into 8 teams of ~7 each, but I think this size would have been far better for getting everyone involved.
  • I would really like to try the session with a 5th iteration, where each item in the list needs to be manipulated. This will negate some of the perceived advantages towards the non-functional paradigms and give each team a chance to see what had been done with (or to) their original work.
  • Change the rule-based paradigm for constraint-based and see how easily the problem is solved.

Resources & Examples

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!

Android Essential Apps

Android WavingI’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:

1: DoubleTwist

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.

2: Barcode Scanner

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!

3: Opera Mini

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.

4: RingDroid

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…

5: Last.fm

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!

Var Args in Bash: Sub-arrays using array expansion modifiers

On a recent adventure into Bash scripting, I recently wanted a function which took 2 parameters (host and port) and could be modified by any number of optional parameters.

There’s a lot of ways to do this with putting arrays or shifts, but there is also a reasonably elegant way to do it. In this example I’m using cURL, which requires hostname and port number but in some cases I may want to append other options.

function varArgExample(){
    local host=$1
    local port=$2
    curl http://$host:$port "${@:3}"

The magic is the “${@:3}” variable expansion at the end. It uses the well know ${@} variable, the array of all arguments passed, but it adds the little known option to say only use the array from element 3 onwards.

If only 2 varables are passed in, “${@:3}” expands out to “” (nothing, just an empty string) without any problems, acting much like varArgs in Java 6.

Should you want to stop at a certain element in the array you can also add a second option. For example,

echo "${@:2:5}"

would expand out to the values of $2, $3 and $4. Obviously, you can also start using integer variables to control the expansion and start getting into some really complicated behaviours too.

start=3; end=6
echo "${@:$start:$end}"

MeeGo: My new netbook OS

My trusty Acer Aspire One has yet again  become the test bed for a new Linux distribution I want to try and this time it’s the turn of “MeeGo”, a project especially made for netbooks and smartphones that is getting a fair bit of buzz around itself.

MeeGo is focused on online content and despite some installation issues (a few notes on that below) it is a nice experience. A lot of online functionality, such as IM, twitter and email, is built into tabs on  the main UI and definitely makes me use my netbook more as it was intended- as a quick, lightly powered way of viewing online content, instead of the full Ubuntu install I’ve previously tried to use for coding and reading.

Whilst the online integration is very slick, MeeGo is currently a little light on the services it does this with. All of the main IM services are available (MeeGo uses Empathy for IM) and email is taken for granted, MeeGo only really supports Twitter and Last.fm in any especially meaningful way. I’m sure this will expand, though it may be a long wait with MeeGo subscribing to the model of putting out new versions every 6 months.

One thing that seems mostly finished already is the UI design. MeeGo certainly has a strong identity: it is colourful and cartoony but not over-the-top. I really like the design- playful but functional and relatively minimal. The main UI is based on a customisable row of icons which open tabs into the integration functions, such as a slick settings tab, application menu and a number of tabs for using online services.

The “main” (well, first) tab is the MyZone homepage which aggregates online events from Twitter and Last.fm into a wall of what you’re friends are up to and displays this along with your calendar appointments, tasks, email notifications and quck launch icons for your favourite apps. However, straying off the main tabs into software you may have installed (like Skype), or even the default media client, see you dropped off the crisp and slick design and into a plain, grey application window. This could (and probably will) be solved with some nicer looking frames but for now it just looks a bit ugly, especially in contrast to how nice everything else looks.

All in all, I really quite like MeeGo and I won’t be rushing back to Ubuntu netbook remix any time soon; not because Ubuntu NBR is bad (far from it!) but more because MeeGo is a bit faster and really provides the features best suited to the device in a useful way. It’s worth trying if you have a slightly neglected netbook and I’m sure the next couple of versions will see it really come into its own, especially as more and more device manufacturers (including Nokia, so far behind in the device OS stakes that its not even funny) are announcing MeeGo as the OS for their next waves of devices.

Installation Notes

If I’ve (hopefully) inspired you to give MeeGo a try, here are a couple of things I got caught up on:

  1. The MeeGo netbook binary image comes as a .img file, as opposed to .iso which must be copied byte-wise to a USB stick. I usually use the awesome unetbootin to make bootable USB sticks but it is not capable of doing this with an img file…despite not explicitly warning you of this and even appearing to succeed. To make a working bootable usb stick from the img file, use either dd on Linux or Win32diskimager on Windows.
  2. There is a known issue with setting DNS servers in MeeGo on some hardware. This meant I could connect to WiFi networks but the OS had no idea where to go for DNS stuff, so it constantly timed out when trying to view pages and sign in to accounts. A fix is incomming, but in the mean time you can use the terminal to add the DNS server address to /etc/resolv.conf manually. There is a useful thread on the MeeGo forums here.
  3. A must for any mobile device I wield is the ability to use Skype. Again, the MeeGo forum has a quick tutorial for anyone not used to installing software via Yum.