Just recently, the HDD in my development server has started to become noisy and so I took the decision this morning to replace my development setup before it was forced upon me at an even more inconvenient moment.  I decided that I am not a big fan of using the electricity it takes to power two individual machines, plus it takes up quite a lot of space in my home office.  For this reason I decided to investigate virtualisation and whether or not I can run Ubuntu ‘within’ Windows 7 (my ‘host’ OS).  Whilst not comprehensive, this set of instructions will hopefully help someone out a bit if they’re ever looking to do something similar to this….

My main requirements (beyond all the usual ones for a development web server) were defined as follows:

1. I must be able to access the filesystem of the development machine through a fileshare of some kind (in the past I have used Samba) both on the host machine and on other machines on my LAN.
2. The websites I am developing must also be accessible by other machines on the LAN (by navigating to an IP address).

I ended up stumbling upon Oracle VM VirtualBox which seemed to enable me to do exactly what I wanted.

The steps I took were as follows:

1. Download and install Oracle VM VirtualBox – as I am a Windows 7 user I installed the Windows version.
2. I set up a virtual machine, following the excellent instructions provided by VirtualBox
3. I downloaded a disc image (.iso) of Ubuntu Server Edition 11.10
4. I then added the downloaded Ubuntu disk image (the .iso) to the storage devices so that I could boot with it on my virtual machine. For the virtual machine in question, I clicked on Settings then Storage. Under CD/DVD Device, next to Empty, I clicked the little folder icon and selected the Ubuntu .iso I had downloaded earlier.   This means that the virtual machine will start up, treating the .iso image as a genuine, burnt CD in a CD drive, and installation can be done from there.
5. I started the Virtual Machine and installed Ubuntu Server Edition – excellent instructions for setting up Ubuntu 11.10 as a dev. server are available all over the internet and are updated all the time, so consult google!  Generally from this point on, installation is as-per-any-other install…
6. Importantly, in order to satisfy my two requirements, I had to make a setting change for how the network behaves for this virtual machine: I changed it from NAT mode to ‘Bridge’ mode.  Right click the virtual server in VirtualBox, click “Settings”, then go to the “Network” tab and select “Bridged Adapter” in the “attached to:” drop down menu for Adapter 1.  I then configured the ubuntu network interfaces to use a fixed IP address in the same IP address range as the host machine (192.168.0.10 in my case) and was then able to access http://192.168.0.10 on all devices connected to my LAN.

Other useful links:

• Ubuntu Documentation – for 11.10 server edition
• Ethernet Device Configuration – for Ubuntu – helpful for setting up a static IP address
• Samba Fileshare documentation

Useful points (These generally revolve around little annoyances with the “out of the box” LAMP server that comes with Ubuntu 11.10 with a quick path to resolution).

1. mod_rewrite is not enabled by default. To enable, type “sudo a2enmod rewrite” on the command line, modify /etc/apache2/apache2.conf and change AllowOverride None to AllowOverride All in the /var/www/ directory section.  Then restart apache.  mod_rewrite will now be available.
2. curl is not installed by default.  To install, type “sudo apt-get install curl” and install, then “sudo apt-get install php5-curl” and install, then restart apache.
3. Some of the php.ini settings are ridiculous – this will be down to your own preferences, but my advice would be to do a phpinfo(); page and inspect every configuration option!
4. Virtual hosts can be set up by creating vhost.conf files in /etc/apache2/sites-available and then symlinking them in /etc/apache2/sites-enabled – remember to restart apache every time you add a vhost.

preg_match('/\\p{Han}/u', $description, $matches);
if(count($matches) > 0) {
// chinese characters exist in $description.
}

Unit Test my existing code

Unit Testing verifies that individual units of source code do what they were intended to do.  Quite simply, I would like to spend the time writing and running unit tests for existing code in our business – I am due to refactor a substantial part of our ecommerce software in terms of basket total calculations and discount implementations and feel that these are perfect areas to implement unit testing before the refactoring begins.   This way, the software can be verified to be working the way it should be today, and then verified to still be working the way it should be after the code has been refactored.

Practice Test Driven Development

My basic understanding of Test Driven Development is essentially the idea that you write test cases that define what you would like your function/method to achieve, and then write (preferably the minimum amount of) code to allow those test cases to pass.  It is very much a ‘test first’ principle – writing tests first and developing this way has many advantages:

• Coming up with the tests in the first place often requires investigative thinking in to the problem, which allows the developer to better understand the problem that needs to be solved.
• Requirements are therefore established firmly before code is written.
• It can be immediately determined whether the functionality is complete (when all tests pass, the code has fulfilled the specification)
• The tests have already been written, so if the code  is refactored at a point in the future, the process of testing that refactored code is short and simple.
• As tests tend to be concise and binary by nature, the code written to pass each test tends to also be concise and each method/function tends to have a single purpose.  This naturally reduces the chances of the occurence of spaghetti code and follows the programming rule that ‘everything should do only one thing’.

I’ve yet to actually develop this way, and over the following few months it is my aim to do so.

Attend a Conference/Developer Meets

This one is a bit of an easy aim, really.  I read a lot about conferences and developer meetups – mainly through Twitter  - but feel that actually being in the room where these people talk about the industry would be a better experience.  I’ve booked a ticket to attend the port80 mini web conference in Newport, South Wales and hope to rub shoulders with those in the industry with experience and advice that they are willing to share.  In addition to this I have pledged to attend at least some of the UnifiedDiff meets in Cardiff (UnifiedDiff is a monthly meet-up for anyone interested in software development) with a view to learning things from people with much more experience and knowledge than myself.

Put together a presentation about something in the industry

The UnifiedDiff meet tends to feature 3 talks covering any aspect of Software Development.   This has shown to me that people out there have real passion for what they do every day, and even more importantly, that people are prepared to hear about it! With my experience of working remotely for a small-medium sized Web Development firm, I think I’m going to start to write a presentation about the pros and cons of working as a remote developer, and how developers and project managers alike can work to make the process easier if this is something they wish to explore.  If I end up being confident enough that the presentation is of high enough quality, I might even ask if I can feature as a speaker at one of the UnifiedDiff meets.

Understand Git – and then start using it.

I am still a big Subversion fan and am yet to be convinced of the advantages of Git (in terms of justifying the time expense of a move from one to the other).  The problem is – every intelligent chap that I know and respect in this industry seems to sing the praises of Git on a near daily basis, and nearly everyone I speak to is looking to make a move to it.  So I need to research and understand what advantages Git offers over subversion, actually use it for a personal project or two so that I understand it, and reassess my feelings on it.

Hopefully, I will make the time to blog about and share my experiences on each of the above points – check back here over the coming 12 months to see how I’m getting on!

As developers, we are often rewarded with praise (or more) for turning new features around quickly.  If your company estimates that a particular feature will take eight hours to write, and you take only four, the company’s making a tidy profit, you can move to the next item in your schedule more quickly and everyone is happy.  This is all very well, so long as that feature has been written properly and in accordance with your company’s general approach; everything ranging from naming conventions right through to the organisation of the filesystem.  If it hasn’t been written properly, then you have incurred technical debt, and at a point in the future either you or another developer maintaining your code may need to spend more time writing a feature or changing your feature than anticipated.

This can cause all manner of problems.  When you come to develop on from your last feature, you might estimate that another bit of functionality will take 8 hours to write.  However, when trying to hook in to the existing feature, you discover your technical debt, and end up having to refactor the existing code to allow you to do what you wish.  This might take another 4 hours.  This might not seem to be a disaster; after all, you were 4 hours up on the first feature, and we’re just back where we should be now, right? Wrong! It is important to remember that managing our time isn’t  just about managing the absolute amount of time taken, but keeping to schedules.  The 4 hours it takes to sort out the mess in this second round of development delays the next item in your project schedule, which might result in a disappointed client.

In my opinion it would have been better to take the full scheduled 8 hours in the first round of development and avoid the unexpected hold-up during the second round of development.  The 4 hours in the first instance are less expensive than the 4 hours in the second, as they’ve less of an effect on surrounding projects & priorities.

The trouble is, at the time the new feature is written, it can be difficult for someone non-technical to tell the difference between it having been done quickly and it having been done properly.  In fact, from an end-user’s point of view, the system can look absolutely identical.   So, given two developers, one who can turn the feature around in 4 hours, and another who takes twice as long at 8 hours, which will the project manager or client be more happy with? My money would nearly always be on the 4 hour guy. But long term, the 8 hour guy is actually going to be less expensive to run, or will at least facilitate more accurate estimates and quotes on the same system in the future.  The problem is, as developers, we need to resist the temptation to be the 4 hour guy. The short term praise can be addictive and it’s understandable why it seems easier and more tempting to do things as quickly as possible and worry about the consequences later.

What I’m noticing is, in 2008 I WAS the 4 hour guy. I was turning around features faster than other people had in the past, and grew a reputation for being quicker.  While I was quicker at the time, now, 4 years on, when I’m revisiting those sites and starting to improve or extend them, I’m paying off my technical debt with ‘expensive’ rewriting and refactoring.  So now I’m in the position where I am expecting the implementation of a change request to take a given amount of time, but on loading up the project and seeing the way it was written in the first place, the implementation is taking much longer.  This extra development time is difficult to explain and to justify to those responsible for project scheduling, and is something that I’m going to really strive to avoid in the future, even if it does seem to take me slightly longer to develop new features than before.

It seems sensible to finish this post with one of the more famous quotes about computer programming. I’m sure you’ll have read it before…

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live

Trust me, it’s bad enough even if it’s YOU that ends up maintaining your code!

Tip: Have your own work space or room

In our house I am fortunate enough to have reserved the ‘box room’ bedroom for the sole purpose of serving as my office.  This gives me an opportunity to enter ‘a work environment’ and close the door on home (and vice versa at the end of each day).  This focuses the mind on work matters and keeps me from being distracted by the massive amount of DIY work that remains incomplete in our house at the moment.  I recall reading articles before I asked for this arrangement with regards to habit fields, and really am a believer in this concept.  I think I would find remote-working so much more difficult if I had to sit somewhere that also served as a relaxation area.

Tip: Set up your working environment properly

Set up your working environment as if you were in an office for a company.  By this, I mean everything; ranging from the bare bones of your work environment to your software setup.  Actually pay attention to health and safety regulations with regards to monitor and keyboard/mouse use; make sure your chair is correctly adjusted (and is adjustable at all! Don’t work on a dining chair!) – in my early days as a freelancer I used to sit on a non-adjustable chair for about 5 hours a day and ended up needing physiotherapy on my lower back as I was in utter agony.

Try not to compromise on your software setup either.  Install the same FTP client you use at work, and configure your IDE or text editor in the same way as your work, including indentation and layout settings; it’s amazing how a little effort to get the environment consistent can make your life so much easier.  My advice extends to, if possible, having a computer for work and a laptop for pleasure.  This further extends the separation of work time and play time; if this is financially not viable then a good compromise is to have two users on your desktop machine; one for work and one for personal use.  I’ll bet your bookmarks for work in your bookmarks toolbar are substantially different to the bookmarks for home in your home bookmarks toolbar!

Keep work and pleasure separate in your software environment too

Moving on from that point, I used to have all of my bookmarks for freelancing and general interests in one bookmarks toolbar folder, meaning BBC News was mixed up with the PHP Manual and a bookmark to my phpmyadmin directory.  This made it too easy to see the BBC news bookmark and check the news for 5 minutes.  5 minutes turns in to 10, in to 15, etc.  Now, I keep my bookmarks separate, by using different browsers. I use Mozilla Firefox for work; and Firefox only has my work bookmarks in it, and I use Google Chrome for pleasure; this has my personal bookmarks in it.  Largely I won’t even use my desktop PC for ‘play’ or ‘relaxation’ and try to reserve that stuff for my laptop.

Don’t get work done in your house when you’re supposed to be working

For the first two days of the remote working arrangement we had ongoing building work.  It is very difficult indeed to get good runs of concentration with the noise, and interaction with the tradesmen.  If you’re having any considerable work done to your house my advice would be, if possible, to go in office for that period.  It’s much quieter and you’ll be much more productive.

Communication

Assuming you are moving from an office environment, you will be used to being tapped on the shoulder and asked questions, and being asked for updates on the state of work on a fairly regular basis.  Though these distractions are often labelled unnecessary and irritating, they naturally lessen in frequency if you’re not in the office.  This doesn’t mean that you should make yourself completely impossible to contact!  I ensured I invested in an unlimited call plan on a home number so that I can call the office as frequently as needed to ask questions to which I need immediate answers, and so that the office have a reliable line on which they can contact me.  Thus far I have more than made good use of the phone line!

Your project manager will largely appreciate frequent, detailed updates of your progress.  There’s nothing worse than having a developer working for a solid few days with no good indication of where they are at with a project.  It’s good to say “all’s going well and we’re on time” and it’s responsible to inform if you’re having difficulties and look to be struggling to deliver for the target time.

Work Time

Something said fairly frequently to me is “oh so you can work whenever you want then”.  I’m not sure that this is entirely true, and my advice would always be to try to be at your desk between the hours that your office would normally be open (in my case 9am to 5pm).  This means:

• You are contactable via email and on the phone all day, should you be needed.
• You maintain a fairly normal working life and have similar spare time as other people (provided your friends work normal hours!)
• You are guaranteed to put in the required number of hours per week.

Quick advice for those who do freelance work alongside a full time job

• The hours of 9am – 5pm are strictly your company’s time.  Make your freelance clients aware of this. Break the rule for noone.  In my opinion, to freelance when you’re being paid to work by someone else is criminal!
• You will find it much more difficult to motivate yourself to freelance after having spent 8 hours each day working in your own house (I used to find working 12 hour days fairly easy if 8 hours were in-office and 4 hours at home).  My solution to this is to work in my office for work, and to move to the sofa on a laptop to freelance.  This does break slightly from my laptop == pleasure rule but at least gives me some separation in terms of the type of work I do!

Summary

Overall, it took me a week or two to get in to the swing of working remotely full-time, but I’ve got there now, and it feels good! I get distracted a lot less on an hour-by-hour basis and feel that I get more done in terms of pure development, and also the three segments to each working week really help me with maintaining my productivity at a high level right from Monday morning to Friday afternoon.  For any employee with the option of working remotely: give it a go, but only if you can separate work and home properly!

I thought “someone else must have had this problem”, and if they hadn’t, I was going to write a Firefox Add On to help maintain productivity by blocking distraction web sites. But, alas, someone has beaten me to it! I have found and installed the LeechBlock Firefox add on and it is fantastic. I’ve added my favourite sites to a list of sites to block at any time that isn’t a break time (so here, 9-11, 11.15-1, 1.30-3, 3.15-5) and it’s proven very effective.

On the command line interface, assuming you have wget installed, type:

wget -r ftp://USERNAME:PASSWORD@mysite.com/

Hit enter and wait while it retrieves everything for you.

I did it this way because I didn’t want to download 4gb of data to upload again, so ran this command direct from the ‘production’ server with its stupidly fast internet connection. Hours and hours saved!

In ‘the olden days’ when processes such as updating your Facebook status or posting a tweet were done through bog standard HTML forms posted by the browser to a new page request, it didn’t matter when the page I was posting to didn’t get posted to fully, or didn’t respond, because I could hit refresh (or press the submit button again or whatever) and the request would be resubmitted.

Some web developers (myself, at times, included) HATE impatient users who will press buttons twice or refresh the page because it’s taking too long. In a lot of apps this means that the action is applied however many times the button is pushed (e.g., two or three orders are placed instead of one). But the reality is, sometimes there is a genuine need to refresh or resubmit, because nothing is *ever* going to happen with the first request that was sent. This could be due to an internet connection problem or a server-side problem.

Now, more and more web sites seem to favour the “no new pageload is necessary” approach which, in itself, I do not have a problem with – at all. What I do have a problem is is when the developers choose to disable the submit button once I press it – permanently. Because if nothing happens for 2 or 3 seconds, I am pretty damn sure that that status update or tweet is never going to get posted. What I would like to do at this stage is to resubmit the request. But at this time, there is no easy way to do this:

• I have not requested the page in a traditional sense in the browser, so I can not push the ‘refresh’ button; that would reload the whole page and typically delete the tweet or status update that I have written.
• The submit button for the form is permanently disabled, so I can’t press it again to submit again.

Even if the JS implementation gracefully degrades (e.g. if I have no JS support I get the “old fashioned” style normal form), this situation occurs for people with JS enabled. Just because a user has JS enabled doesn’t mean that their web connection is faultless or that they won’t need to push that submit button twice!

I was trying to think of a way around this issue that doesn’t require scrapping the AJAX submission all together, and came up with only one potential solution, which is to disable the submit button but only for an elected period of time (say 2 or 3 seconds), so that if the request doesn’t get responded to in that time, the user is given an opportunity to re-submit.

Anyone else’s ideas of how to work around this problem would be gratefully received through the comments section; I don’t want to write software that frustrates people in the same way that this frustrates me!

The main reason for Javascript being used to progressively enhance the user experience rather than be a fundamental ‘requirement’ is cited as making the site accessible to as many people as possible. Importantly, many mobile devices don’t fully support Javascript (Smart Phones tend to, but I’m talking true mobile phones here) and screen readers certainly don’t support Javascript. Realistically, the percentage of visitors falling in to the ‘browsing on a mobile device’ or ‘using a screen reader’ will be low, and often low enough for a client (or yourself) to make the judgement “we’re not going to bother”. It is important to consider that there are advantages to graceful degradation other than making the site as accessible as possible:

Google, Bing, and A.N.Other search engines – search engine spiders are still fairly basic creatures. If your site navigation doesn’t load a new page but instead loads new content in using Ajax when you click the ‘About’ link, how are search engines going to find and index your ‘About’ page content if the site is not navigable without Javascript? It’s quite simple to make things like this degrade; if Javascript is disabled the link should go to index.php?page=about rather than nowhere. Importantly, many clients think that google is the most important visitor; if they’ve forced you to put lots of keywords at the bottom of the site despite your pleas for them not to then they wouldn’t be very pleased to find out that the search engines can’t get any further than your home page.

Application Design – Designing the application so that it works without Javascript and then adding Javascript afterwards often makes the system architecture much more understandable and ‘rigid’. In fact, if done correctly, this can speed up the Javascript implementation process. Looking back to our previous example, index.php?page=about will load a completely new version of the page with header, footer and all the bells and whistles. How about, if you click the ‘About’ link with javascript enabled, it will load index.php?page=about but through AJAX? Using HTTP_X_REQUESTED_WITH we can detect that it was requested through AJAX and serve just the ‘meaty’ bit of the page; ie the content that is changing, rather than the whole page. Does this really add much time to the development process? In my opinion, no it doesn’t!

Of course, the user experience will not be identical without javascript, but in my view it is still important to support users with no support for the language on their device, or even those that choose to browse without it. It is my view that you can treat support for when Javascript disabled in the same way as many designers treat support of Internet Explorer 6: The site should work, but it doesn’t necessarily have to be perfect. Sticking to this general guideline will not add huge amounts of time to the development time of a project, and if it does… you should take a look at how the system is designed, because it really shouldn’t.

Explaining and justifying your decisions

At the most very basic level, take this bit of code for example:

ksort($files);

To most PHP developers it is obvious that this bit of code sorts the $files array in key order. But it is not obvious to any PHP developer *why* I have done this. Adding a comment to say what I am doing and why would help speed up the recognition of what this code does; but more importantly, explain why this code is here.:


/**
* Sort the $files array in Key order. We want them displayed on the
* page in added order, and the $files array is not necessarily
* sorted in that order before this stage.
*/
ksort($files);


Using code comments as a tool: Autocompletion

There are other areas of an application where documentation can be even more useful. Modern Code Editors and IDEs will read what are called ‘docblocks‘ at the top of class, method or function definitions and add the information in the docblock in to your autocomplete prompts. So how do these docblocks work?

Docblocks are generally in this format (opened by /**, closed by */, with a * at the start of every line inbetween) and always apply to the next uncommented line of code. In this case, the line of code beginning with $page_posted_to = is documented by the docblock above.:


/**
* Determine if the page has been posted to with an action.
*/
$page_posted_to = (array_key_exists('action', $_POST) && !empty($_POST['action']));


Within docblocks you can contain ‘tags’. These ‘tags’ begin with an @ symbol and are often read or interpreted by documentation generation utilities or IDEs/Editors for autocompletion. A comprehensive list can be found on the Wikipedia page for Docblocks. Using these tags can encourage you to include information in your documentation that you might forget to include normally, ie the expected data type of function parameters.

At it’s most basic use, docblocks usually look something like this when describing a function or method:


/**
* This function adds two values together
* @param int $a The first value
* @param int $b The second value
* @return int The value of $a + $b
*/
function add_together($a, $b) {
return $a + $b;
}


As you can see, including these docblocks explains in plain english what the function does, what parameters it expects, and what it will return. This can save the next developer that reads your code tonnes of time and headaches, but most importantly of all, will make your code editor or IDE (if it supports autocompletion and docblock parsing) much more intelligent when it comes to helping you call your own methods or functions.