I had the opportunity (or misfortune!) to visit an organisation recently whose computer systems are somewhat shambolic. They understand that their systems are not in a good shape, but as this is not their core business, spending money on it is really not what they want to be doing. In fact, it wasn’t a business at all, it was a charity.

This is a real dilemma for such an organisation. Vast sums of money tend to be hard to come by for most charities, and explaining to donators that you spent their cash on an IT system probably doesn’t look great either! But boy, do they need a new system.

The current system is essentially an old school Access database and nothing much else. This would not be a problem if it actually worked OK, but it doesn’t. The system was created around 10 years ago and no longer fits the “business” model. Sure, you eventually get what you need from it, but everything takes around 10 clicks, it doesn’t work with the latest MS Office, forms take 30s to 1 minute to load, the output frequently has to be adapted manually and frustration with the system is high.

Understandably, they are frightened of change though. Not change induced by moving away from their old system, but change as in how much change will they get from £10k to get a new system developed. Nothing I would suspect.

This is not good. But hey, we programmers need to eat, so we can’t expect to do stuff like this for nothing, right?. Maybe charities just need to get real with this situation. You either pay up and get the system you need, or you don’t have a system at all. Screw the inefficiencies created by the absence of such systems and also to the people who are affected. This is just the world that we live in. Eat or be eaten. I mean who wants to sit and develop software and not get paid for it?

Mmmmmm, well loads of people. We must be one of the only industries that give away our time for nothing, and for no reason other that we love doing it so much. So maybe instead of wasting our time developing another new open source web framework in whatever language, it might just be a great idea to develop the software for these charities. Sure, it ain’t going to be as exciting, but it may be much more rewarding.

Has this been done before? I dunno. I can’t find much after a quick search. However, if it has been attempted, I certainly don’t know about it and I suspect neither do lots of other developers. If someone has heard of something similar please leave a comment with the details.

The undertaking of such a task would by no means be plain sailing. It would require lots of input from the staff at charities and their volunteers – because as the software developers we ultimately need to know what to develop. This is achievable though, right? And in the era of open communication afforded to us by the internet, there may never have been a better time. If open source projects can work, then I see no reason why this idea should not be possible, it just needs momentum.

Programmers at times can take themselves, and their abilities, a little too seriously. The fact is that programming, in general, is just not that difficult. Sure, there are parts of it that are tricky but, at the risk of over generalising, the capabilities required by your run of the mill programmer are not that high. Are you sure I hear you say?

Well plucking figures right out the air I’d say that around 90% of applications involve a simple CRUD model. So what we are essentially doing is gathering data, processing data, and writing this data to the database. Two-thirds of this process is pretty simple, i.e. gathering the data and writing it to the database, this leaves the possibilities for hardness in the processing data phase.

Again in most situations the processing of data is pretty simple with no complex db manipulation or algorithmic mind games. Consider your typical web application for example. The processing of data is minimal, with little to no algorithmic work involved at all – I mean with Twitter there is literally nothing to do. Google on the other hand has lots to do: it has to make those search results shine. This is not to say that developing Twitter is simple, as the scaling issues will make your head hurt. However, scaling problems are only going to affect a very very small number of sites out there, but due to their ubiquity they are the ones we hear most about.

If all this programming nonsense is so easy then surely it’s difficult to make bad software?

Nope. The fact is that the only people who care what the code looks like are other developers. The code underneath could be shitter than an incredibly shitty shit and the end user wouldn’t know. As long as it carries out the task that they require the software to do, in a reasonably efficient and user friendly way, no one really cares. Oh apart from other developers.

Obviously nice structured code, that is easy to understand, free of bugs, and a maintenance dream is a good building block. However, it is by no means a guarantee that you are on to a winner. Marketing, user experience and coolness are all equally important, actually, they are probably much more important. I obviously can’t say for sure but I would imagine there are plenty of successful software products that are badly written but tick these boxes – maybe even most successful products, as they are free from the burden of the studious programmer.

So, essentially what I’m trying to say is that despite programming not being that difficult there are many other more important factors that contribute to the success of a software product. Many software products do their job, but the one that will be successful is the one that does it well.

All this is not to say that programming well is not important. On the contrary, it’s important to other developers who you work with and that is not to be underestimated. This is a topic for discussion another time though!

Finally, for those non-programmers out there, don’t start shouting “If it’s so simple why does it take so long”? Well just because something is easy it does mean there are not lots of easy things to do. I mean, hammering a nail into a piece of wood is pretty simple, right? But if I asked you to hammer 10 million nails into a bit of wood it would take you a long time. Remember this marketers and project managers.

We are all well aware of the dangers of strong coupling: for me, the most dangerous being the increased maintenance costs in such a system. Much has been discussed about coupling and measures such as dependency injection are used to help control it.

However, as far as a Google search leads me to believe, but I didn’t search too hard, not much has been said about the strong coupling that can exist between HTML, CSS, and JavaScript files. Maybe I’m doing something wrong, or at least something different, from others but many times in recent weeks I have found that the dependencies between these files can be rather tight and restrictive.

To understand what I’m talking about, let’s take a look at an example. Consider the following snippets of an HTML, CSS, and JavaScript files respectively:

    
Header
    

#main_wrapper {
    color: #FFFFFF
}

$('#main_wrapper').attr('color', '#000000'); 

As you can see the id is referenced in at least three different places. Well so what?

The problem, as I see it, comes from the fact that it is more than likely these files will be maintained by different people. For example, a designer is likely to maintain the HTML and CSS files and a developer the JavaScript file. In the days before JavaScript proliferation, this maybe wasn’t such a problem. However, with the rise of jQuery and its awesomeness the landscape has changed a little.

In fact, jQuery actually compounds the problem, as we have all become accustomed to seeing JavaScript code littered with things like $('#main_wrapper'), i.e. CSS selectors are referenced throughout the code base. What this means is that when the designer changes the structure of the HTML file, or the class names and ids, it can have unexpected side effects.

The easy (part) solution to all this is that when you create ids and classes you never change/remove them or their container – or at least you never change them without searching globally rather than just locally. I’m not sure how restrictive this is though, maybe those with far more experience of this than I do can offer up some more constructive thoughts? Are designers are just not used to such constraints? I dunno?

To me it just seems like a hassle having to keep track of selectors, ids, and classes in so many different places. It seems to go against the spirit of good programmer where we try to localised any side effects when changes are made. With the above way of working this doesn’t seem possible – and combined with the divided level of responsibility between designers and developers, I imagine this causes an increase in the number of bugs and also in the cost of maintenance.

Maybe others don’t see this as an issue at all? Maybe I’m doing designers around the world a disservice? You decide.

At the moment I can’t offer up any better solutions, as I have not really thought about it too much yet. When I do though, I’ll be sure to report back 😀

We’ve all had it drilled down our throats that development should be completed in short-sharp iterations. “Release early and release often” – no agile developer gets up in the morning without repeating this mantra to themselves before they reach the sink. However, surely it’s important to realise the difference between “Release early and release often” and “Release utter shit early and release utter shit often”.

Who really wants to use an application/toolkit/library that has so many bugs in it that the user experience is dreadful? Surely users would rather wait a few more weeks for something that is, in a sense, polished? I mean we’re not talking Microsoft Vista style release cycles here, but quality control consisting of a little more than running a set of unit tests would be nice.

So what has prompted this minor rant? Well Firebug unfortunately. I hate to criticise it because it’s free but the bugs I find in it are getting worse and worse. The most recent one being that the continue button no longer works in the latest release (1.4.0b10). Sigh. However, open source or not, my feeling is that if you choose to do something then do it properly or not at all.

Anyway. Regardless of the product, it surely makes more sense to sacrifice your release schedule a little for some real testing and bug fixing? For commercial products a bad user experience is going to make a sale difficult both now and in the future. Being first to market is one thing, but it’s far from being the only (or even main) contributing factor to a products success – Google and Facebook being good examples of this.

So is it possible just to have a little common sense about all this and maybe restate the mantra as “Release quality early, release quality often”. It can’t be that hard, right?

I’m sorry, I’m sorry, but I object to the use of the word geek. I’d always imagined that a geek was someone who was obsessive about computer programming. Lately though I’ve seen people use it in a way that is beginning to annoying me – it’s used to describe someone who simply uses the latest and greatest software or gadgets. This was brought to a head when I clicked a link in a tweet (thanks Colin!) which sent me to an article called “Top 10 Ways to Provoke a Geek Argument“.

I mean, I like to think I’m a geek, sad, but true. However, if the things mentioned in that article are likely to incite an argument in a geek, then I ain’t a geek. True geeks laughs in the face of such insults. So bearing all this in mind I say a real geek is someone who takes offense when:

1. someone states that programming is just a day job;
2. someone tells you they work in IT/computing and they can’t program – this often comes in the form of a third-person telling you their friend works in IT just like you!
3. someone tells you that the technology used doesn’t matter;
4. someone’s role call of programming languages does not extend to at least 4 and they don’t know at least one dynamic language – real brownie points go to those who know a functional language;
5. someone shifts a conversation about programming to something else – oh yes, including girls, well maybe not!
6. a developer tells you they don’t have broadband at home;
7. someone states that Agile development is essentially the same as the Waterfall model;
8. someone becomes a “developer” during a one year Masters conversion course – in particular sociology and arts students;
9. a “developer” tells you they want to be a manager;
10. people don’t think they’re a geek.

There you go, if you don’t agree with these then you ain’t a geek! However, you are at least one tenth of one! 😀

A while back I was impressed to see the Yahoo Media Player, which can be used to stream mp3s on a website. It appeared on the face of it to be a JavaScript only browser media player, which seemed not only impressive, but impossible. As it turned out, the media player actually used flash underneath the hood by making a series of API calls without the need for the typical flash UI.

Being suitably impressed I decided to write my own – I wanted several distinct features like a playlist and a custom look. I then found an astonishing good JavaScript API that interfaced to the audio features in Flash. This library was called SoundManager2, check it out, it’s great. SoundManager does provide some neat demo applications, but nothing that matched my needs – incidentally the demos may be far better now as I wrote this code almost a year ago.

So what was I looking to achieve with this:

1. I wanted to queue tracks in a playlist;
2. The order of the playlist must be dynamic, i.e. you can drag and drop the tracks to change their order;
3. Adding the media player to a website is as easy as adding a div with a specific id attribute;
4. Adding items to a playlist must be as simple as including an anchor tag with a specific CSS class;
5. The colours, dimensions, and images should be easily overridable but also have sensible defaults;
6. The path to the library should be configurable in some manner.

So what did this turn out like? Well you can see it in action on www.feellikefalling.com. I encourage you to check it out to see things like the play list drag and drop etc in action. Update: I have embedded the player here so that you don’t need to navigate away if you don’t want to.

So if you want to include this on your website how to you do it? It’s pretty easy – you don’t need to be a web developer! First you need to download all the required files by clicking the big button above or here, extract the files, and then upload the these files to your web server. The HTML required to embed the player is minimal and is show below:

 
  
      Feel Like Falling - 
      Can't Rock With The Kids
  
  
      Feel Like Falling -
      Purple T
  

To include the website media player in the page you simply add a div element with id myplayer. Then to add an mp3 to the playlist you create an anchor (a) tag with class myplayer_mp3. To include a tooltip for the song you simply add a title attribute to the a element. So what we are doing is creating a playlist from a series of urls specified in the a tags, it’s as simple as that.

In order to get all this to work you need to include the following in your document header:

Instead of explaining all of the above I suggest you just take a look at the inline comments. There is also a sample HTML file in the downloadable zip containing full working example – apart from the actual mp3 sound files.

You can also customise the player visually with relative ease. The colour scheme can be changed by simply overriding the default CSS styles for the player. For example, consider the following screenshot:

Here the volume bars, the play timer, the currently playing song background, and main background colour have all been changed. The code below shows the CSS elements that had to be changed/created to achieve this.

div#myplayer { background-color: #696969; height: 25em; }

#myplayer_playlist_container { height: 20em; }

div#myplayer_playing_timer { background-color: #6D0D33; }

div.myplayer_strip_skin_on { background-color: #6D0D33; }

#myplayer_playlist li { background-color: #929292; color: #FFFFFF; }

a.myplayer_mp3 { color: #000000;	}

#myplayer_playlist li.ui-selected { background-color: #6D0D33; }

#myplayer_playlist li.ui-selected a { color: #FFFFFF; }

Hopefully the method of skinning the player, as shown above, is straightforward to understand, it’s just basic CSS. Obviously just about anything can be customised through the use of CSS, and I suggest taking a look at the generated HTML to identify the appropriate ids and classes – you can use firebug HTML explorer with Firefox (or the equivalent in IE, Chrome, Safari, etc). In fact, the HTML generated can also be modified easily – take a look at the myplayer_snippets.js to do this. Be aware though that some of the elements generated are essential to the working of the application though.

For those more artistically inclined than me feel free to give it a sweeping new skin – in the colours of the site I linked to so that I can get the benefits 😉

It goes without saying there will be bugs! If you find any, either leave a comment or better still email me – my address can be found in the about section of this site.

So feel free to add the webpage media player to your site! Enjoy.

Until recently I had a rather nescient attitude to the needs of users who have barely seen a computer never mind used one. It’s easy for developers to forget about these people. However they exist, and with the rise of the internet as the dominant carrier of information, I would presume that now more than ever the new computer user is finding their way online.

Most developers have had the “keep it simple” mantra for UI development drilled into them over the years, both in an academic and commercial setting. However, having spent some time educating a few older family members (who fall into the computer newbie category described above) on the ways of the internet, I’m of the impression that it’s not just simplicity that is required but moreover consistency.

For example. A simple hyperlink like this one which seems innocuous to the average user, can cause trouble. Why? Well, when “teaching” people to use the internet it’s helpful if you can define some simple rules. One of these rules might be “Things you can click on will be underlined”. Rules like this give a surprising amount of comfort to an inexperienced computer user. However, until actually watching a family member struggle when links are not underlined I would not have known/believed the problem existed. To them the link above just looks like a piece of coloured text, which they don’t associate with the simple rule. A similar situation occurs when links are in the form of an image, where unless it looks like a button then they are unlikely to click it.

However, many sites don’t underline hyperlinks, so an alternative rule may be “When you move your mouse over a piece of text and it turns into a little hand, then you can click it”. That is as long as someone has not change the default cursor – thank you for this feature Internet Explorer! This rule is not ideal though as means you have to trawl the entire page to find links.

If you plan to really confuse a new user then you can always do the following: fail to underline the text, have it the same colour as the rest of the text, and instead of using an anchor tag, use any tag you like and just assign an onclick handler to the element in javascript. That way you get no cursor that changes to the familar hand as well. Awesome.

The above problem really does exist and I have seen it on many websites even those undertaken by well known web agencies.

This is not the only area of inconsistency, there are many others. In fact, another problem that seemed to cause increased stress levels is time/date input – for example a flight search engine. Most sites that require this functionality tend to provide some sort of calendar widget. Therefore, you can show someone how to input a date by asking them to first click on the calendar image, now click the appropriate button to navigate to the required month, then click on the required day to select. However, every calendar widget is slightly different which is just the start of the confusion. The real problem is reserved for those sites that do not have a calendar widget to select the date. The user then looks everywhere trying to find this calendar button to click, and finally is left pondering the date format to enter manually – if they even get this far. Surely it must be to the benefit of everyone if we agree on a standard calendar widget that can be skinned in some way? Just a thought.

I’m sure there are many other areas where this sort of confusion can occur – I can only begin to imagine the problems with Flash sites! Hence the next time you are designing a webpage that is intended for public consumption it’s probably worth bearing this in mind.

I love frameworks. You love frameworks. We ALL love frameworks. As web developers we just can’t get enough of these things. They’re everywhere: from Rails, to MS MVC, to CakePHP, to Django, and so on. I’m so obssessed with frameworks that I spend more time thinking about what one to use than actually using it. But this is not the only problem, as after choosing one, your problems can really start.

On a project that I have been intermitently working on for a little while now I chose to use CakePHP. The reason for this choice? Well first, I had a pretty good knowledge of PHP as I wrote my own little PHP framework when web frameworks were a mere twingle in their daddies eyes. Second, PHP is widely supported on shared hosting – though Ruby is catching up (that said, I’ve experienced some horrors with Ruby hosting). The widespread availability of PHP also means that PHP hosting tends to be cheaper.

Anyway, this is all beside the point. My real issue is with the size and complexity of these frameworks. Just the other day I was looking to do something as simple as validate an input that was supplied as an HTML POST parameter. Pretty simple right? Well it ended up taking me a disproportionate amount of time to do this task.

The first port of call was to find out if the framework itself supported this, which to my delight CakePHP (1.2) delivered on. Now it was down to the trawl/skim through the documentation trying to figure out how to actually do it. I found what I presumed done the task – basically I was required to add the appropriate validation rules to my model. Thus I added the following:

 array('rule' => alphaNumeric,
                                           'required' => false,
                                           'message' => 'Alpha numerics only'));
}
?>

Then in my controller I simply called the validate method:

if(!$this->Section->validates()) {
    parent::handleAJAXError($this->Section->validationErrors);
    return;
}

What happened? NOTHING! I passed data that should have failed and it passed. SHIT! I then decided to check to see that the rules were getting parsed so changed the required key in the rules to true, and passed nothing in. Now it worked – it asked me to specify the parameter. My logic was therefore it can see the data and the rules are getting parsed so what the hell is happening!

By this point I had spent quite some time trying to figure this all out. To be honest, I could have written the validation code quicker. So that’s what I decided to do. Yes I reinvented the wheel, it took me around 5 mins, dwarfing the hours I had spent trying to get the stupid library validation code to work. Not only that, much of the supposed benefits offered by using the built in validation code was of no use to me – it wasn’t built around AJAX requests. So what is the moral of this story?

Well it’s read the documentation better, don’t run the most stupid tests, and don’t charge-in thinking you know how everything works! WHAT I hear you say?!

If only I had taken more care when reading, eh the first paragraph, in the documentation I would have observed this:

First, set the data to the model:

$this->ModelName->set( $this->data );

Whoops I never done this. Basically I wasn’t EVER passing in any data to validate, which makes my shocking test of changing the required to true to convince myself the rules and data were being parsed an absolute joke. Rushing in to write my hand crafted code is as bad as the other old chestnut of complaining “there is a bug in the compiler” – c’mon we have all said it 😉 The only thing I can credit myself with here is that after a recent 4 week holiday I was stubborn enough to not give up and go back an look at it. Therefore, if there is anything to learn from this experience it’s that before starting something make sure you have taken the time to either read the documentation or listen to those trying to guide you. Oh and have a certain amount of stubbornness about you – not too much though.

I’ve been having some real problems with FireBug recently – essentially it has made itself utterly useless. Why? Well when I set a breakpoint within FireBug and that breakpoint is reached, the code window does not scroll to the breakpoint. I then have to drag the scroll bar down to the breakpoint, then when I press F10 to perform a step over, the code window resets itself to the top. As you can imagine this get rather annoying after a while, especially with large JavaScript files.

As a result of these misgivings I have found myself using the IE8 developer tools – which are actually quite good, though FireBug, when working, is better.

Luckily the project that I’m working on is not exactly critical, though the quicker I get finished it the better. However, if I was working on something that was going to generate me $$$$$$, I’d hope to god that I wouldn’t have to waste so much time with the debugger. With this in mind, and with the mindset of “You are a dumb ass if you fail to utilise open-source software” prevalent in our industry, it raises the question as to the limits of open-source software.

If the software that you are developing is largely based on open-source/free software, and this software sells for hundreds of thousands do you really want to be using libraries that have no real service-level agreement? For example, let’s assume that your software sells for $200,000. Then it’s safe to say that your customers will be expecting some pretty good service for that kind of money. Suppose a bug is found in some third-party open-source library that is used in your product. So you have two options: 1) you ask the community to fix the bug or 2) you fix the bug yourself. Are any of these really a satisfactory solution? I don’t think so.

Consider option 1. Suppose that the project stagnates or your bug is just not an issue for the community, then it may take some time to get this bug fixed (or they may not fix it at all). But you need this bug fixed yesterday! People tell you “Oh there is always someone in the community willing to help”. Nonsense. There are no guarantees and this is exactly what a professional organisation needs. A bank, telecom company, utilities company and so on are not going to give a shit that you can’t get it fixed soon, they will just move their business elsewhere. This is the reality of the situation, and if you are moving a core part of your business out to open-source software and charging a small fortune for your software, I’m pretty sure this is going to come back and bite you. Open-source software proponents can scream until they are blue in the face that this will not happen, but it might, and that’s all that matters.

So if option 1 cannot save you then your left with option 2. Well first, it’s easy to say that you just get the source and edit it yourself, but the fact of the matter is that it takes quite some time to be comfortable with a large code base. In particular, to be comfortable with the fact that making changes in one place doesn’t cause problems elsewhere. OK, unit tests help, but there are no guarantees. Maybe you could be involved in the maintanence of the open-source software on a regular basis to ensure that your team has built up a familiarity with the code. Maybe even developing new features etc. That sounds like a great idea. Until your competitor comes along and uses all these lovely features that you have so kindly developed for them! Then how much of a fool do you look.

The fact of the matter is that if you write the code, then you have more control over it, and this eliminates any dependencies you may have on outside parties. The more you charge for your software, the tighter your service level agreements are, and the more third-party libraries define the uniqueness of your product, the more important this becomes.

This is not to say that we should all go out and write our own compilers, IDEs, and various other things. It’s just a matter about being sensible about what you use.