I thoroughly enjoyed the day, which got under way with an opening by Alan and the host for the day, Christian Heilmann.  The presentations were all of an extremely high standard, and I took something away from each of them.  Perhaps however because of my preference for getting my hands dirty with PHP and tinkering with Linux gubbins I found some of the talks a little high-level and abstract.  That should nevertheless detract from the outstanding talks and the wonderful day I had.  I do believe though that I may have got more out of the day were I more of a freelance front-end developer.  I’m impatiently waiting for next year’s conference, which can’t come soon enough!

With an overarching theme of back-to-basics, Steve Marshall kicked things off with a very interesting discussion about keeping things as simple as they need to be.  From getting lead astray by cognitive biases to avoiding over complicating and thinking too far ahead Steve hammered home the point that if we don’t take that next step, we’ll get nowhere fast.

Steve was followed by Rachel Andrew who discussed choosing the right CMS.  Everyone has their own set of favourite applications, and this applies equally to web applications.  However, when developing a stand-alone CMS, or deploying one as part of a larger system, it pays to choose the right tool for the job.  Sometimes a simple solution is what is required, other times something more ‘enterprise’ will be required.  Ultimately though, the choice should enable the user to publish their content without hindering them.  The content should be front-and-centre, with the CMS seamlessly facilitating publication of great content.

The next talk before lunch was given by Glasgow developer Jack Osbourne, one of the contributors to HTML5 Doctor.  Jack offered a whistle-stop tour through the key new elements defined by the HTML5 specification, given as a novel ‘live’ presentation where each element was demoed in place as part of the HTML5 rendered slides.

After lunch, the wonderfully entertaining Remy Sharp kicked the afternoon off with a presentation that by his own admission, was a little out of his comfort zone.  Rather than what one might expect from Remy; a rather technical discussion about JavaScript and it’s proper application, he shared his personal workflow for fulfilling specifications.  It wasn’t what I had expected but I really enjoyed it!  It’s always interesting to see how other people work, and to learn from those who are clearly successful!

Next up was Mike Rundle; clearly a passionate designer/developer particularly with respect to all things Apple!  Mike’s presentation elaborated on why the Mac design works so well.  He explored Apple’s use of real world textures and their use application of consistent light sources to create a consistent, polished interface.  Not usually my cup of tea; I’ve never really been the creative type.  An interested talk nonetheless.

The final presentation of the day came courtesy of James Edwards who discussed the issue of whether the use of AJAX had become any more ‘accessible’ over the last five years. The conclusion was a resounding ‘meh’. However, some problems can be mitigated by employing the WAI-ARIA spec to aid those viewing the web using technologies other than the traditional web browser. What followed was a slightly tangential discussion of using ARIA attributes to customise web forms to make them more useful for those experiencing the web through less traditional methods. Quite a technical discussion on a subject that isn’t well understood by most.  An excellent talk!

In summary, although not a particular creative type I found this conference enjoyable and informative and commend Alan and his minions who made it all possible.  If there were some slightly more technically oriented topics in future, that would be a big plus for me.  A massive thank you to the speakers who took the time to head north of the border.  I’m genuinely excited by the future of The Highland Fling and look forward to next year’s conference.

I work predominantly with Linux and use Virtual Box as my V12n application of choice.  Later versions of Virtual Box support VPC’s VHD disk image format.  This means it’s possible to run these VPC images under VirtualBox, but it involves downloading and extracting files from the win32 executables; downloading drivers for the ethernet adapter and other time consuming steps that I’d rather not repeat every time my IE VM expires.  I’m a programmer, therefore I’m lazy and don’t like doing things more than once; I’d rather script something to do it for me.  In keeping with this virtue, I’ve written msie2vbox to automate this stuff for me.  It’s on Github with a GPLv3 license.  There’s some outstanding todo items but it does the job for me, and I thought it might be of use to others.

I’m often jumping on and off of a number of different servers where I use a variety of programs such as Gnu Screen and Vim.  If I tweak ~/.vimrc for example, I have to remember to copy the changed file to all of the other servers I use, which is a pain.  I could request that home directories be auto-mounted using autofs, but this solution is something I can implement myself in isolation without effecting any other users.  The idea is to store configuration files in SVN so that when I make a change on one server, I can push that change to SVN and pull the change down to any other server I happen to be on.  The approach I’m taking here is to have a local working copy in my home directory, and to have configuration files symlinked into that working copy.  This could be made more flexible by having different configurations stored in a separate branch and switching branches depending on your needs.

I’m sure there are better ways to do this, such as having the entire home directory in subversion, and automatically updated on login.  Perhaps you could use SVN externals to provide a modular approach to managing your configuration.  The great thing about SVN, and more generally Linux is that there are plenty of different ways to achieve your goal.

Before I go on, I’ve made a few assumptions based on my server configuration – Ubuntu 10.04 with Apache 2.2.14 and Subversion already installed.  The first thing we need to do is enable SVN over HTTP.

sudo apt-get install libapache2-svn

Once installed, we need to configure the module in /etc/apache2/mods-enabled/dav_svn.conf

DAV svn
SVNParentPath /var/lib/svn
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/dav_svn.passwd
Require valid-user

This configuration will allow you to refer to your repositories via e.g. http://example.com/svn, where the actual location of your repositories on the filesystem is /var/lib/svn.  We’re also using basic authentication here, so we’ll need to add a valid user.

sudo htpasswd -c /etc/apache2/dav_svn.passwd username

Next, we need to create our SVN directory and create a first repository

sudo mkdir -p /var/lib/svn
sudo svnadmin create /var/lib/svn/homedir
sudo chown -R :www-data /var/lib/svn
sudo chmod 700 /var/lib/svn
sudo chmod -R 755 /var/lib/svn/homedir

Now, on a server that has a good baseline set of configuration files, we can check out a working copy

svn co http://example.com/svn/homedir .

Add some configuration files

cp ~/.bashrc ~/.vimrc ~/.vimrc ~/homedir
cd ~/homedir
svn st | awk '/\?/ {print $2}' | xargs svn add
svn commit -m "Initial Commit"

We can now symlink our files to those in the working copy

ln -sf ~/homedir/.bashrc ~/.bashrc
ln -sf ~/homedir/.vimrc ~/.vimrc
ln -sf ~/homedir/.screenrc ~/.screenrc

If we do this on all the servers we use, we can make a change in one place, commit it to SVN, and then update our working copy somewhere else to get the most up-to-date version of the files.  As I said before, I’m sure this can be enhanced and tweaked to be more efficient, but this serves my needs for now.

Strace showed that subversion reads from /dev/random as part of the commit, and that’s where the problem seemed to be happening.  After doing some research, I discovered that /dev/random generates random numbers using the so-called entropy pool.  This entropy pool is just random bits of noise generated from things such as mouse movements, time between keystrokes and so on.  For whatever reason, on the client server, this entropy pool was empty!  Using /dev/random is cryptographically more random than using /dev/urandom; and /dev/random blocks when the entropy pool is empty, whereas /dev/urandom is non-blocking.  Moving /dev/random to /dev/random.old and linking /dev/urandom to /dev/random solved the problem.  There may be a better solution to this, and depending on your cryptographic requirements it might be better to find an alternative, but this did the trick for me.  One svn commit later and all was well.