Managing code quality

It’s fair to say that the quality of your code has a direct correlation to the success of your product.   Products crafted to a high quality using proven techniques and industry accepted standards have a better chance of succeeding.  This applies to any field; be it. car production, joinery and  most certainly software development. Read more


Bug tracking system – A must feature

It’s an open question, “What makes a good bug tracking system good?”, and one’s answer may well depend on your software life-cycle’s requirements. In this post I’ll outline one of the ‘must have’ features I recommend. This recommendation comes from my experience from working in both an open source and business driven development environment. Continue reading “Bug tracking system – A must feature”

5 laws all software development we should all know

Dreaming in code book and laws of software developmentI’ve just finished reading this book, “Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software”. As the title suggests the book is about software development and project management. The author follows the life of real software project, fronted by the Lotus-1-2-3 legend Mitch Kapor. I would recommend this book to any software developer. If you have been involved at any level with a software project you will relate to the problems the team face, and you’ll get great amusement and pleasure to know that your software project is not the only one that takes longer than expected, or, suffers from feature creep, or, has an ever increasing list of bugs that needs your attention!

The content of the book covers various aspects of software development and general computing.  As the author interviews the team they touch up-on and refer to several laws of computing.  These law are so, so true!  Thus, though I’d share the best.

  1. Linus’s law, “Given enough eyeballs, all bugs are shallow”.
  2. Murphy’s law, “Anything that can go wrong, will go wrong”.
  3. Brooks’ law, “Adding manpower to a late software project makes it later”.
  4. Moore’s law, “The power of computers per unit cost doubles every 24 month.”
  5. Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

Is your JavaScript code top quality?

How do you measure code quality? This question is harder than you think to answer! The topic of code quality is quite young. In fact the topic of writing code is young in comparison to other crafts; such as carpentry or engineering. We therefore struggle to agree what is good or bad code. And, more often than not we disagree about trivial points such as whether braces should start at the end of the line or, on the next line. Although these points are fun to debate they mute the real point and should be hidden in the religious wars drawer with the vi vs. emacs argument!

Programmers within any team have quite different opinions on what makes code quality. One major point they generally agree on is that when writing quality code you must ensure the team agrees to a coding standard. Ensuring every line of code has a consistent implementation is paramount. Let’s look at an example.

Inconsistent code

function dr() {
	c = d.getElementById('x');
	  t = c.getContext('2d');
		b = c.height / 80; db();
		p = new Image(); p.src = 'pieces.png'; p.onload = dps;
          c.addEventListener('click', bc, false); }
	else{ alert("Canvas not supported!"); 

Consistent code

function draw()
	// Main entry point got the HTML5 chess board example
	canvas = document.getElementById('chess');

	// Canvas supported?
		ctx = canvas.getContext('2d');

		// Calculdate the precise block size
		BLOCK_SIZE = canvas.height / NUMBER_OF_ROWS;
		// Draw the background

		// Draw pieces
		pieces = new Image();
		pieces.src = 'pieces.png';
		pieces.onload = drawPieces;

		canvas.addEventListener('click', board_click, false);
		alert("Canvas not supported!");
The two examples above perform the same function and the code is exactly the same, except for naming and layout. They are equal in speed and performance and result. However, from a code quality perspective these are world’s apart.

Assuming we all agree that quality matters, how do we enforce it? Introducing JSLint. JSLint is a JavaScript code quality tool. The tool is written by Douglas Crockford: a member of the JavaScript royal family. JSLint takes a JavaScript source and scans it. If it finds a problem, it returns a message describing the problem and an approximate location within the source. The problem is not necessarily a syntax error, although it often is. JSLint looks at some style conventions as well as structural problems. It does not prove that your program is correct. It just provides another set of eyes to help spot problems.

Using JSLint

JavaScript can be copied-and-pasted directly into JSLint.

On pasting your code into JSLint simply press the “JSLint” button to submit. The site will then analyse your code and present the results:

Some of the rules applied can be tweaked to match your preference:

jslint online code quality options

On minor annoyance with using the on-line tool is that it can be time consuming. It is more than likely that you’ll go though several iterations of copy-paste-analyse cycle before your code conforms to the rule-set. Thankfully the tool can be used with IDEs such as Aptana.

Integrating JSLint with Aptana

Aptana is an open source IDE which lets you develop and test your entire web application within a single environment. It fully supports JavaScript; however, by default JSLint validation included but not enabled. To enable JSLint first select the option “Window->Preferences” e.g.

Enabling jslint in Aptana

Within the window that appears select the option “Aptana Studio->Validation” from the left-hand list. Then select the “JavaScript” option from the menu on the left within the ‘Validation’ section e.g.:

Code quality with Aptana

To enable JSLint simply click the ticks within the “Build” and “Reconcile” column within the validator’s list. Confirm by pressing the OK button. The IDE will then begin to report feedback from JSLint. Lines which are flagged as warnings by JSLint are decorated with a warning symbol on the left hand margin of Aptana e.g.

Aptana code quality results

The rule-set can be tweaked using the same settings as the on-line tool. Modification of settings is applied by including a formatted comment block at the top of the JavaScript file e.g.

Code quality option within Aptana with JSLint

Further information on JSLint can be found on the official site JSLint. Please note that JSLint’s official tag line is: Warning: JSLint will hurt your feelings! Did it?

Human Readable XML

Extensible Markup Language (XML) defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. It conforms to the standard produced by the W3C (World Wide Web Consortium). However, according to all known laws of computing a machine does not care how the XML documents are formatted; contrary to this humans do!
More often than not you may see XML documents that are well-formed (readable by a machine); but, unreadable to a human. Take the following example:
<breakfast_menu><food><name>Belgian Waffles</name><price>$5.95</price><description>two of our famous Belgian Waffles with plenty of real maple syrup</description>
<calories>650</calories></food><food><name>Strawberry Belgian Waffles</name><price>$7.95</price><description>light Belgian waffles covered with strawberries and whipped cream</description><calories>900</calories></food><food><name>Berry-Berry Belgian Waffles</name><price>$8.95</price><description>light Belgian waffles covered with an assortment of fresh berries and whipped cream</description><calories>900</calories></food><food><name>French Toast</name><price>$4.50</price><description>thick slices made from our homemade sourdough bread</description><calories>600</calories>
</food><food><name>Homestyle Breakfast</name><price>$6.95</price><description>two eggs, bacon or sausage, toast, and our ever-popular hash browns</description><calories>950</calories></food></breakfast_menu>
And the same data formatted:
		<name>Belgian Waffles</name>
		<description>two of our famous Belgian Waffles with plenty of real maple syrup</description>
		<name>Strawberry Belgian Waffles</name>
		<description>light Belgian waffles covered with strawberries and whipped cream</description>
		<name>Berry-Berry Belgian Waffles</name>
		<description>light Belgian waffles covered with an assortment of fresh berries and whipped cream</description>
		<name>French Toast</name>
		<description>thick slices made from our homemade sourdough bread</description>
		<name>Homestyle Breakfast</name>
		<description>two eggs, bacon or sausage, toast, and our ever-popular hash browns</description>
The two are worlds apart as far a human readability goes! But, both are equally valid. In fact, the first example includes less characters; thus, the argument for removing formatting characters, such as tabs and carriage returns is a feasible one. For example, imagine if you are transmitting XML data over an expensive communication medium. When I say expensive I mean in both dollar cost and delivery speed. If each character costs 1$ and the number of messages sent per year is over a million, then you would save a few million dollars by removing non-essential characters. This means software vendors may intentionally use unformatted XML data; thus, decreasing the readability for the occasional human who wants to read it. This raises the question, can we easily format unformatted XML?

Introducing the xmllint program. The xmllint program parses one or more XML files, specified on the command line. It prints various types of output, depending upon the options selected. It is useful for detecting errors both in XML code and in the XML parser itself. It can also format XML using the –format option. An example of how to do this follows:
xmllint --format foo.xml
This example reads the content of the file ‘fool.xml’. It then formats the contents and outputs to the terminal. Brilliant! For more information about the xmllint program take a look >here

Getting involved with the Fedora project – Part 5

This is the final part of  “Getting involved with Fedora”.  Parts one to four covered the steps required to install Fedora into a virtualization system running on Windows 7.  Part four also explained how to register an account with Fedora’s bug-tracking system.  In this post one intends on testing the Fedora system with the hope of finding a defect in one of its software packages.

What to Test?

One of the hardest parts of testing a huge system such as Fedora is being focused.  In my experience it’s best to focus your attention on one software package at a time.  The more you tinker with the same package the more knowledge you gain about that package.  As knowledge is power I would expect your bug finding skills to benefit from knowing the inner workings of any given package.

In order to test a package it is essential to understand the expected behaviour.  This normally means understanding the inputs and outputs.  Take for example the user and groups management utility system-config-users.  This software package aims to provide system administrators with an interface for creating and maintaining users and groups.  Therefore, if we can make it fail its goal we’ve found a bug!

Finding a bug?

I’ve already found a few bugs with the system-config-users utility.  Here are the steps I performed to uncover one such bug:

Start system-config-users by selecting the GNOME menu option Application->Other->User and Groups:

Bug finding Fedora

Fedora will start the utility; however, as the utility requires escalated privileges to run you will be prompted for the root user’s password:

Bug finding Fedora

After submitting the credentials the utility will start:

Bug finding Fedora

From the Edit menu select the Preferences option:

Bug finding Fedora

Then from within the Preference screen un-tick the “Hide system users and groups” check-box and press Close.  This will reveal the system users e.g.

Bug finding Fedora

Select the ‘root’ user and press the “Properties” button.  This is will open a window that displays the root user’s details:

Bug finding Fedora

Remove the content of the home directory and press OK.  Then close the utility.  Once closed re-launch the utility:

Bug finding Fedora

Whoops, it didn’t start?  Why not?  Because we remove the home directory of root which I believe should be mandatory; thus, we’ve broken the system.   Let’s prove this by starting a console and trying to log on as the root users:

Bug finding Fedora

Oh dear!  I cannot log on as root.  System-config-user has allowed be to omit the home directory; therefore, huge parts of the system are now broken.

Bug finding Fedora

We can now log this as a bug!  One useful piece of information you’ll need is the version of the software at fault.  This can be obtained by running the YUM command “yum list installed system-config-user” – see sample above.  I actually logged this particular fault while ago and it can be viewed here  I’m not going to explain the details of logging a software bug because this information is covered in the on-line Bugzilla user guide.
That concludes this series.  I hope it’s beneficial to some and allows you to get involved.  All feedback welcome!

Getting involved with the Fedora project – Part 4

This is part four of a series of posts which explains how to get involved with the Fedora project.  In the previous three posts (1, 2 and 3) one has explained how to install and configure Oracle’s VirtualBox software and how to install Fedora as a virtual machine.  In this post one will explain how to register an account with Fedora’s bug-tracking system.  This will allow us to feedback our findings when we start testing.

Redhat’s Bugzilla!

Red Hat Bugzilla is a bug-tracking system and is used to submit and review defects that have been found in Red Hat distributions.  This includes Fedora because it is a Redhat sponsored company.  In fact, Fedora acts as an experimental arm that complements Redhat’s enterprise grade operating system.  The goal of the bug-tracking system is to allow you to submit a defect which has  not been reported yet. Defects will go directly to the engineer responsible for the component you filed the defect against. Engineers have many responsibilities and will get to your defect in due time; thus, don’t expect an instance response – unless you find a super-critical bug.

Registering an account

The bug-tracking system Fedora uses can be found here  The system is publicly available; however, participation requires registration.  As our intention is to test the system and log as many bugs as we can find, we’ll need to register an account.  Registration is free.  To register browse to the following URL

Creating a new account at bugzilla

During the registration process you will choose a username and password.  This can be used to log on to you personal Bugzilla account e.g.

Once logged on to Bugzilla you will be presented with the welcome page:

Bugzilla welcome page

Among other things you can log a new defect, view your existing bugs, or, search for an existing bug.  One link that should not be ignored is the “Red Hat Bugzilla User’s Guide“.  This will provide you with the necessary knowledge required to maintain you Bugzilla account.
We are almost ready to find our first bug!  One final stage is required.  The Fedora operating system contains thousands of software packages.  Each package is updated on a regular basis.  This may be new features being added, or, bugs being fixed.  Therefore, it is wise to ensure we are testing the latest version of each software package; otherwise, we could be wasting our time by finding bugs that have already been fixed.

Updating Fedora

Before testing any part of Fedora we should periodically ensure that we are using the latest software.  Thankfully, Fedora provides an update manage to do this task. This update manager is called YUM.  To force YUM to perform a check follow the steps below:

Updating Fedora

From the GNOME menu select the “Terminal” option from the Application->System Tools menu.  This will load a console which will allow us to invoke YUM.

Updating Fedora

Within the terminal type the following commands: first log in as the root user “su – root”.  Input the password for root and then invoke YUM “yum update”.  The first time you ask YUM to update your Fedora system it may well need to apply several software packages; thus, this may take some time.

Updating Fedora

Once YUM has evaluated the list of updates confirm you want to apply these changes by typing “Y” and pressing return.

Updating Fedora

YUM will then download and install the latest packages.  Again, this will take some time.  On completion we may need to reboot if the kernel package was updated.  If so, reboot.  Once rebooted you are ready to test and find bugs!  In part five I’ll explain the basics of bug finding.

Getting involved with the Fedora project – Part 3

In part one and two of this series one explained how to download and install Oracle’s VirtualBox software, I then covered the steps required for downloading the latest Fedora operating system.  And, finally I explained the steps needed to set-up VirtualBox in preparation for installing Fedora.  In this post I’ll continue the series by showing how to install Fedora into the newly created virtual machine.

Installing Fedora into VirtualBox

Installing Fedora is pretty simple.  Fedora provides a multi-step wizard approach. Within this post I’ll cover each step and explain the actions to choose during each stage.  Before we can install Fedora we first need to start the virtual machine.  Remember, we downloaded the Fedora Live CD which when started will load Fedora into memory.  Therefore, we’ll be able to use Fedora in its ‘live’ mode; but, it is not  installed.  Therefore, I will explain how to permanently install Fedora from within the ‘live’ mode.

Powering on the Virtual Machine

If the VirtualBox GUI is not running it can be started by selecting the “Oracle VM VirtualBox” option from your Windows start menu.

Starting VirtualBox

The main VirtualBox window will  show the configured virtual machines within the list on the left.  The panel on the right should also display a summary of the selected virtual machine.  The virtual machine we created in part two should be present:

Virtual machine wizard complete

Select the virtual machine we created in part two from the list on the left  and power it on by clicking the Start button on the toolbar shown below:

Powering on a virtual machine

On clicking the Start button VirtualBox will open a new window and it will attempt to start our virtual machine.  To orientate readers who are new to virtualization this is akin to powering on a physical machine.  The first image to appear within the new window should be:

VirtualBox BVIOS screen

The above screen will flash past within seconds.  The next screen should be Fedora 16’s CD/DVD boot menu.  This is being loaded because we inserted the Fedora CD image into our virtual machine’s CD/DVD drive in part two.

Fedora 16 Live CD boot menu

If the above screen does not display please refer to part two and ensure the Fedora CD/DVD image was correctly inserted into the virtual machine’s CD/DVD drive.  If all is well after a few seconds the live instance of Fedora will start to load:

Fedora Live CD starting

This screen will display the loading progress of the Fedora 16’s Live CD.  Depending on the speed of you host PC this may take a few minutes.  Once complete the Fedora operating system should be ready to go!

Fedora Live CD started

The default user interface for Fedora 16 is GNOME 3.  This requires a rather powerful graphics card; thus, in VirtualBox initially you’ll get a warning about graphics.  Don’t worry about this – simply close the warning.  If you are interested in how this can be fixed (not essential) then look here.  As stated before the live CD is not installed within the virtual machine: it is just running in memory.  Although, you can test Fedora perfectly within the ‘live’ mode it can be restrictive.  For example, adding software is not permanent.  Therefore,we need to install Fedora onto the virtual machine.

Starting Fedora’s installation wizard

Within the ‘live’ mode you can choose to permanently install Fedora.   The option to start this is located under the GNOME menu:

Fedora live to disk

Select the option “Install to Hard Drive” from the Application->System tools menu.  The following screen will be displayed:

The set-up wizard is several steps long and some of the steps are personal choice; for example, the above step allows me to choose my keyboard.  Therefore, select the keyboard that suites you and press the Next button.

The step (shown above) allows you to choose the installation type.  We are using a local disk so ensure the “Basic storage device” option is selected and press Next.

If prompted confirm you are happy to erase any data.  As we are virtual we are not going to loose anything!

Again the above step is a personal choice.  Input a hostname and press Next:

Choose you geographical location and press Next:

Input the root password and press Next:

The above step refers to the partition preservation/erase screen.  In this case we are not installing Fedora alongside any other operating system such as Windows; therefore, leave the default and press Next:

After pressing Next on the penultimate step the set-up wizard will start the installation of Fedora.  This will take several minutes; therefore, I suggest you break for a refreshment, or, just wait 🙂

Eventually the installation wizard will confirm the completion.  Before rebooting please ensure you remove the virtual CD/DVD from the drive.  This can be done from VirtualBox’s menu by choosing the men option Devices->CD/DVD Devices->Remove disk from virtual device.  Once removed hit reboot.

Although Fedora 16 is installed there are some final configuration screens to complete.  After reboot the first of these screens is:

The screen above is simply a welcome screen, so click Next:

Click Next on the license information:

Ensure the date and time are correct and click Next:

The user details are personal choice.  Enter the required details and click Next:

The is the penultimate screen which you can simply press Next:

The installation and configuration is now complete.  Fedora is now fully installed into our virtual machine.  In the next step we’ll complete the last phase of our preparation prior to testing which is registering an account on Fedora’s bug tracking system.  This will permit us to log any bugs we find.

Getting involved with the Fedora project – Part 2

In part one of this series one explained how to download and install Oracle’s VirtualBox software.  Part two (this post) focuses on downloading the latest Fedora operating system and then explains the steps needed to set-up VirtualBox in preparation for installing Fedora.

Downloading Fedora

Installing Fedora is pretty simple; however, you will first need to get a copy of Fedora.  In my experience the easiest way to get a copy of Fedora is to download the latest version directly from the Fedora website.   At the time of writing this post the latest version was Fedora 16 and the download page can be found at the following URL

The page should look similar to this:

Downloading Fedora

Hit the big blue download button.  This action will trigger your browser to download Fedora Linux operating system’s Desktop Edition ISO.  The ISO format is support by VirtualBox, so no physical CD/DVD is required.  The size of the download is about 650Mb so it may take sometime to complete.  If your Internet connection is too slow to obtain the download within a reasonable time there are alternative ways of obtaining a copy such as buying one of the many Linux magazines from you local shop, or, you could even convince a friend to download it on their supper fast connection.

Creating a virtual machine in VirtualBox

The main interface for VirtualBox is a nice user-friendly GUI.  It can be started by selecting the “Oracle VM VirtualBox” option from your Windows start menu.

Starting VirtualBox

It also worth noting the Oracle provide a full user manual in both CHM and PDF format.  I’ve not read it, but, I am sure it is worth a read. Once start VirtualBox should resemble the following:

Installing Fedora in VirtualBox

There is nothing exciting to report here; the main window provides the more menu and toolbar seen on most Windows applications.  Below that, the left of the screen has an empty list which will contain your virtual PCs once your created one or more and on the right is a nice welcome message.  We will dive straight in and create our virtual machine for our Fedora Linux image.  These steps are akin to purchasing the individual components of a physical machine e.g. how much memory do you want, what type and size of disks etc. Start the virtual machine wizard by clicking the New button on the menu.  The following screen will be displayed:

VirtualBox Welcome page

Press Next to process onto the Next step:

Assign the name and os type in VirtualBox

The step above allows you to choose a name for you virtual machine and choose the type and version of operating system you intend to install.  The name of the machine is used to name the machine and should aim to be fairly description. For example, do not call it “Fedora” if you intend on install future releases e.g. Fedora 17.  In this example I’ve called it “Fedora 16” and chosen the Linux operating system and the “Fedora” version.  Press Next once you have made the selection:

Choosing Memory in VirtualBox

The step above allows us to choose the amount of memory out virtual machine should have.  The memory available should be at least 768Mb as per the minimum specification recommended by the Fedora team.  If you host machine can spare more I would assigned at least 1GB.  After choosing the desired amount click the Next button:

The next step within the wizard allows you to set-up the size and type of your virtual machine’s hard disk.  Ensure the “Create new hard disk” option is selected and press the Next button:


The step above allows you to choose the format of your virtual hard disk.  Each virtual hard disk is actually stored as a file (albeit a large file) on your host machine.  The file format is only important if you wish to use you virtual disk with other leading virtualisation software such as VMWare – a compatibility feature.  In this instance we’ll stick with the default and simply press Next.

Fixed or Dynamic disk option

The option available in the step above allows you to choose either a fixed or dynamically allocated disk.  This basically means do you want VirtualBox to reserve the space needed for the entire virtual hard disk upfront (fixed), or, would you like VirtualBox to take the space when needed (dynamically).  Allocating the disk-space during the initial set-up is probably best as the virtual machine does not have to wait for the disk to be dynamically sized when more space is needed!  However, I am going to leave the default and press Next:

Choosing disk-space

The step above allows you to size your virtual disk and choose the location that it will be store on your PC.  The complete collection of package available within Fedora Linux can occupy over 9 GB of disk space, so if you are intending on installing everything choose at least 10GB.  Once you’ve selected the right choice press Next.

Disk selection summary

The disk creation wizard will then display a summary of the options you have selected.  Double check these match what you entered and press the Create button if you are happy:

Virtual machine summary

The virtual machine wizard will now display the summary of the options you have applied to the machine e.g. the memory, operating system type.  Again, check these match what you entered and press the Create button if you are happy:

Virtual machine wizard complete

The virtual machine creation wizard will then perform the actions we’ve asked it to do.  Once complete you will be returned to the main VirtualBox window which will now show the newly created virtual machine within the list on the left.  The panel on the right should also display a summary of the virtual machine.  We can now start the virtual machine and install Fedora.  Before powering on the virtual machine we first need to insert a CD into the virtual machines CD/DVD drive.  Under the summary options click the word “Storage”.  This will open the storage settings window:

Virtual machine setting window

The storage settings window allows you to put a CD/DVD into you newly created virtual machine.  The storage tree will list the virtual IDE and SATA controllers.  Under the IDE controller is an icon of a CD.  This is the CD/DVD drive that will be connected to your virtual machine.  Click this icon and the attributes for the virtual device will be displayed on the right hand panel.  If you are new to virtualisation you may find this confusing.  In simplest terms this window allows you to insert CD/DVD into you virtual machines drive – just as you would with a physical drive in your PC.
To insert the CD into the virtual drive click the CD icon next to the CD/DVD drive drop-down list.  This should show a list that is similar to the following:

VirtualBox inserting a CD

From the menu select the “Choose a virtual CD/DVD disk file”.  The result of selecting this option will allow you to choose a virtual CD/DVD disk file to insert into your virtual machine’s CD/DVD drive.  Browse to the Fedora ISO file we downloaded earlier and press OK e.g.

Back at the storage setting windows the details of the loaded ISO will be displayed:

Fedora ISO loaded into VirtualBox

We have now successfully inserted our virtual CD (downloaded Fedora image).  Press the OK button which will close the window.  The virtual machine is now ready to power on!
In part three we will power on the virtual machine and install Fedora.