A day at the farm

December 4th, 2013

It might not be where you’d expect to find web developers, but High Mead Farm was our destination last week for a spot of volunteering. High Mead is an amazing place  – a working farm community project which provides engaging and useful work along with animal therapy for those with learning and physical disabilities. Tucked away just up the road from us you could be forgiven for not knowing it’s there – but the benefits it provides to its service users was plain to see from the moment we arrived.


So, all togged up for the bracing November weather, we arrived at the farm to see what we could do to help out. The day started with a quick tour of the animal residents – the ferrets, geese, ducks, goats, rare breed pigs and miniature ponies – and an overview of how the farm got started and what the nice folks there are achieving.


Then, having got to grips with who lives where (and donned some extra layers of warm socks and some very attractive woolly hats), it was off to work. We started with digging the poisonous Ragwort out of the ponies’ field, then we dug some veggie beds in the poly-tunnels, and made a new raised planting area.  Then we topped the day off with taking the goats for a walk, then setting fire to the massive bonfire –  before all gathering around it to get warm again.


Thanks to Mark and Will and all at High Mead for making us feel so welcome – it was a really enjoyable experience and good for us all to do some “real work” for a change! To find out more about High Mead Farm, visit their website.



Git Workflow, Deployment and Hooks

June 17th, 2013

Git Deployment

We use a simple post-receive git hook to make a production ready repository that we can push to from our local machines. We’ve also setup SSH keys on the servers we deploy to so we don’t need to enter passwords.


Git Hooks


The most important hook that allows us to add the application repository on the server as a remote on our local machines

cd ..
unset GIT_DIR
env -i git reset --hard
git checkout -f


~$ git remote add production user@server:/var/www/some-application.com



Our post update hooks run Laravel’s built in migrations and Composer’s update function so our packages stay up to date.

cd /path/to/laravel
echo "----------"
echo "Running PRODUCTION migrations..."
/usr/bin/php artisan migrate --env=production
echo "----------"
echo " "
echo "**********"
echo "Running Composer Update"
unset GIT_DIR;
/usr/bin/php /path/to/composer update
echo "**********"

Which gives us the output of php artisan migrate and composer update in our local shell when we push to a remote repository.

We’re recruiting – calling PHP developers in Dorset!

June 4th, 2013

Join the team  – we’re on the hunt for an experienced PHP developer to help shape our dev team.

We’re looking for an in-depth knowledge of PHP, MySQL etc, along with  experience with MVC coding, OOP, GIT and server administration. Full information available here:  PHP developer role Dorset.

Ubuntu server 12 stuck at the grub boot menu waiting for key press

May 17th, 2013

Our local headless VirtualBox server (Ubuntu 12.04.2 LTS) fails to boot some mornings, waiting for a key-press. It appears that grub is configured, out of the box, to halt, if there are prior boot failures. Here’s the fix to ignore the boot failures as we always need this box to boot:-

Edit default grub config:

$> vim /etc/default/grub

Add the line:


Finally update grub:

$> update-grub

A big thanks to slm, Andrea Barcellona and ServerFault

CASE Expressions, for complex Order Bys in SQL

February 22nd, 2013

So here’s the problem I was having:

I wanted to order a set of data by Date End, with ‘date_end’ a datetime column in our database.
However, the data could also be 00-00-0000 00:00:00 – which represents ‘Present’, where there is no end date.

Heres some data as an example:

id date_start date_end
A 2010-02-01 00:00:00 2011-02-01 00:00:00
B 2011-02-01 00:00:00 2012-02-01 00:00:00
C 2013-02-01 00:00:00 0000-00-00 00:00:00
D 2009-02-01 00:00:00 2010-02-01 00:00:00
E 2008-02-01 00:00:00 2009-02-01 00:00:00

A standard SQL query with “ORDER BY date_end DESC” would return:

id date_start date_end
B 2011-02-01 00:00:00 2012-02-01 00:00:00
A 2010-02-01 00:00:00 2011-02-01 00:00:00
D 2009-02-01 00:00:00 2010-02-01 00:00:00
E 2008-02-01 00:00:00 2009-02-01 00:00:00
C 2013-02-01 00:00:00 0000-00-00 00:00:00

To get the Present one at the top, we can use the Case expression.

“CASE date_end WHEN 00-00-00 00:00:00 THEN 1 ELSE 2 END”

So CASE date_end is the column we have selected. WHEN selects the value we are looking for, and then THEN and ELSE assign values to the rows based on whether they match the value we are looking for. So we can visualise the result as something like this:

id date_start date_end case
A 2010-02-01 00:00:00 2011-02-01 00:00:00 2
B 2011-02-01 00:00:00 2012-02-01 00:00:00 2
C 2013-02-01 00:00:00 0000-00-00 00:00:00 1
D 2009-02-01 00:00:00 2010-02-01 00:00:00 2
E 2008-02-01 00:00:00 2009-02-01 00:00:00 2

So now we can order by our case statement, and then by date_end as a secondary clause.

“ORDER BY CASE date_end WHEN 00-00-00 00:00:00 THEN 1 ELSE 2 END, date_end DESC”

Which gives us our dates ordered by date with most recent (present) first:

id date_start date_end
C 2013-02-01 00:00:00 0000-00-00 00:00:00
B 2011-02-01 00:00:00 2012-02-01 00:00:00
A 2010-02-01 00:00:00 2011-02-01 00:00:00
D 2009-02-01 00:00:00 2010-02-01 00:00:00
E 2008-02-01 00:00:00 2009-02-01 00:00:00

Finally, as we are using Laravel as our PHP Framework, we can use Laravel’s Fluent Query Builder alongside a Raw Query.

->order_by(DB::raw(‘case date_end when 0 then 1 else 2 end’))
->order_by(‘date_end’, ‘desc’);

Sublime Text 2 Packages we love

February 6th, 2013

Here at Freshleaf Towers, we’ve grown to love Sublime Text 2. No, love may not be strong enough – we adore it. One of the main reasons we covet it is down to its extendability with plugins.

First off, you’re going to need the Package Control Manager. It’s free, and requires a quick copy and paste to install into Sublime. Once that’s on, then installing more Packages is a breeze.

Once it’s installed, go to Preferences -> Package Control. A menu will appear, allowing you to show your installed packages, uninstall, find, or install a new package. From then, installing a package is only a short search away.

Here’s our favourite packages. All of them are free aside from the SFTP Plugin.

SFTP Plugin

Much like Sublime 2 itself, this is free with an annoying message, but $16 for a user license. If you work with FTP, then it’s invaluable and well worth the cost.


Previously known as Zen Coding, Emmet is my best friend. It makes writing HTML super easy. It uses short CSS-style values to generate all the HTML you need in very little typing.

It has a learning curve, but once you get used to it you’ll never look back. Writing HTML is now effortless and I make far fewer errors. It also covers CSS, although I don’t use it as much. It also covers calculations (useful for CSS, type 50+5 and hit CTRL+SHIFT+Y and it’ll perform the action), number incrementing, Lorem Ipsum generation, and much more that I haven’t even learnt yet. Get it for the HTML Abbreviation, stay for the extras.

Try it now. Open a new blank HTML file, type html:5 and hit tab. Magic. Then try ul.nav>li*4>a inside body and hit tab. Looks like you just made a navigation, in no time at all. Have fun. Check out the docs for more.


Assists with highlighting { } brackets, etc. Useful for Javascript and PHP.


Helps with using .blade.php templates in Laravel.

CSS Media Queries

If you find yourself doing lots of responsive CSS and find typing out common Media Queries tiring, this is for you.


Helps with making PHP easier to read.


If you’re like me and enjoy a good gimmick, this plugin is for you. As the sun goes down the theme changes to a darker theme for legibility.

Color Highlighter

This plugin highlights CSS colours as their respective colours, both HEX and RGB.

Find Function Definition

Missing a quick way to find your functions from Netbeans? This’ll solve that. With this, you can right click on a function, and find it. It’ll take a few seconds to run through your project, and throw you back at the function. Most useful in PHP.


The real joy of Sublime is finding a workflow and packages that work for you. Stay tuned, and in the next few days I’ll go through my favourite tweaks and shortcuts to make your workflow in Sublime truly sublime.

Undo-ing ‘git reset hard’

February 4th, 2013

Chances are, you’re here because like me, you ran git reset --hard HEAD on your last hour or two’s worth of work. If you’re lucky then hopefully you ran git add . or added your files to the staging area. Providing a git clean (git gc) hasn’t been run, there may be light at the end of the tunnel!

$> git add .

Lots of lovely work added to your commit – then you decide, for whatever reason, to not commit. In my case probably down to lack of coffee or that I suddenly decided to slip back to the SVN way of things ; ).

$> git pull origin master

From this pull I got merge problems (obviously due to the lack of a commit). Then cleverly I decided to run:

$> git reset --hard HEAD

Oops! Panic – I’ve just reset my last two hours’ worth of development!


A quick search revealed this stackoverflow post and then a look in the git fsck man page shows that we’re going to need:-

Consider any object recorded in the index also as a head node
for an unreachability trace.


Do not consider commits that are referenced only by an entry in a
reflog to be reachable. This option is meant only to search for
commits that used to be in a ref, but now aren’t, but are
still in that corresponding reflog.


Write dangling objects into .git/lost-found/commit/ or
.git/lost-found/other/, depending on type. If the object
is a blob, the contents are written into the file, rather
than its object name.

$> git fsck –cache –no-reflogs –lost-found

Checking object directories: 100% (256/256), done.
Checking objects: 100% (571/571), done.
dangling tree 9f43ffdc200878fefaab63b7c15c58f1da73ba5d
dangling blob 837052b45a69934c822e832d5d01f81bb7cde437
dangling blob b1d0f0ceb214ba28f16826103d2a85ed6f90838b
dangling blob da70731ebc23a477994cf65dd51f951b5546cedd
dangling blob 09312824523012ba5ea0aab54093eb8df567ffc4
dangling tree 25f11f2af6addf4e6c4004481b34f5017cbc052e
dangling blob cc3a137f831e26e091265cdce3c6f7d224cf8961


$> ls -l .git/lost-found/other/
-rw-r--r-- 1 alex alex 2230 Feb 4 13:44 09312824523012ba5ea0aab54093eb8df567ffc4
-rw-r--r-- 1 alex alex 41 Feb 4 13:44 25f11f2af6addf4e6c4004481b34f5017cbc052e
-rw-r--r-- 1 alex alex 1714 Feb 4 13:44 837052b45a69934c822e832d5d01f81bb7cde437
-rw-r--r-- 1 alex alex 41 Feb 4 13:44 9f43ffdc200878fefaab63b7c15c58f1da73ba5d
-rw-r--r-- 1 alex alex 17281 Feb 4 13:44 b1d0f0ceb214ba28f16826103d2a85ed6f90838b
-rw-r--r-- 1 alex alex 20586 Feb 4 13:44 cc3a137f831e26e091265cdce3c6f7d224cf8961
-rw-r--r-- 1 alex alex 20855 Feb 4 13:44 da70731ebc23a477994cf65dd51f951b5546cedd


Now you should have reasonable success in identifying which file is which and you can diff them to check that these are indeed your changes.

Good luck! And don’t do it again.

Tips for creating a website development specification

August 16th, 2012

For anyone who’s worked in the website, software or application development industry for more than five minutes, I don’t need to explain the need for a really good specification.  It ensures that all parties – both developers and clients – are fully aware of what will be delivered, and it gives you something to refer back to when additional functionality is requested, to prevent scope creep within the project.

We’ve all seen projects where the slow but inevitable process of adding features to satisfy each new idea or new stakeholder causes the whole thing to flounder in a mass of mismatched expectations – developers work harder only to result in lower client satisfaction. No-one wins.

Essentially, good planning, and the ability to write a solid, specific and clear specification is often the key difference between a successful development project and an unsuccessful one. But good specifications are tough to write, so how do you get one that works?

  1. Keep costs fluid until the spec is complete.
    All costs are estimates until the specification is finalised. They have to be. The very process of writing the spec finalises the development requirements, and until those requirements are finalised, the cost cannot be fixed.  A builder won’t issue a quote until he’s seen the architect’s drawings, you can’t issue a final quote until you have your spec.
  2. Understand what kind of specification you’re trying to write.
    Typically in development projects there are two types of specification – functional and technical.  And there are two different types for a reason – they fulfil two separate roles, so understanding which one you’re producing and keeping them separate is critical. A functional spec tells you what, but not how. It lists user features, sometimes known as stories, to outline what the user will be able to do on or with the website or application (“user will be able to view outstanding orders”). A functional spec, or a partial one, is sometimes produced by clients as part of the briefing process.  A technical spec, on the other hand, outlines how the features will be delivered, and should cover everything from the coding language, platform and system architecture to sitemap, wireframes and URL.
  3. Information gathering first
    A lot of larger development projects will involve a huge amount of information gathering before a specification can be finalised – be it reviews of existing solutions,  briefings, brainstorming with stakeholders, research and focus groups, or usability studies.  Some will just require a list of required user features to be written up into a functional spec and then translated into a technical spec. In either case, ensure you’ve gathered all the input before you start trying to create the spec – otherwise it’s a movable feast from the word go.
  4. Be consistent in outlining basic requirements
    Writing specs is time-consuming because they are typically so bespoke, but you can make things easier by ensuring you’ve got the basics in a template. This not only gives you a starting point but ensures that the basics don’t get missed. Examples of this are the combinations of platform and browser support undertaken, hosting requirements or expectations, accessibility compliance  etc.
  5. Be specific & measurable – don’t ignore uncertainty!
    Specification. The clue is in the name. If it’s not specific, it’s not doing its job. Be specific when documenting everything. If a deliverable cannot be quantified into a set of numbers, or a defined goal, then refine it until it can be – and this may mean breaking down large chunks of development into smaller bite size chunks until they can be realistically documented. There absolutely will be the temptation to gloss over things, thinking “we’ll sort that out later” or “there’s a couple of ways we can handle that, let’s see how it goes”. But those are traps for the unwary which will almost certainly catch you out at a later date. If something can’t be made specific, go back to your client and ask questions as to how they’re expecting it to work, or back to your developers and ask how they’d recommend delivering it, or both, and discuss until you have a specific answer.
  6. Work through the user journey using flowcharts and wireframes
    For most website development projects, a specification is not complete until you’ve documented the various key user journeys with a flowchart (or series of flowcharts), starting with the homepage and running through all the key processes identifying the key pages or stages of user interaction. Once the key pages/stages and their relationship to each other have been defined, you can also produce very basic wireframes for each key page/stage, blocking out not how the page will be laid out, necessarily (that’s a design decision), but certainly what’s on the page and how it relates to other pages.
  7. Consider risks & mitigations, assumptions & dependencies
    These may not go into the specification document but should be written into your development plan alongside your spec.  As you look at each stage of what needs to be delivered, consider and document the risks, how you can mitigate the risks, the assumptions upon which your spec rests, and any dependencies. So, your client has said that they will be setting up a brand new hosting environment for the project to an agreed specification by the end of this month. Your project specification assumes and depends on that server environment being available on time and being as per the agreed spec. The risks are that it is delivered late, or that the hosting environment is not as expected. You might mitigate around these elements by requiring that the client to deliver the hosting platform two weeks before you expect to need it, so that both timescales and platform shortfalls can be addressed.   Learning to recognise dependencies, assumptions and risk factors is an essential skill… brainstorm these with the team and ensure you’ve planned for them as far as possible.
  8. Use plain English
    Yes, your specification is a technical document, but it’s also the document that outlines the agreement between you and the client as to what you’re going to deliver. You need your client to understand what’s in the document, and sign off against it – so baffling them with technical language is not going to get you any closer to a good clear understanding on both sides of what’s being delivered.
  9. Have someone CHECK your SPEC for specificity and certainty
    Whether your spec document is authored by the project manager or the lead developer or a combination of the two, the key thing is to have it checked by someone else once it’s finished (and before it goes to the client!). Someone who hasn’t been involved in writing the spec should check it, actively looking for holes, unanswered questions, and undocumented assumptions. Anywhere where there is uncertainty, resulting in questions such as “will it do this?” and “how will that work” must be flagged and reviewed. For the spec to be fit for purpose on final check, you must be able to use it to create a solid agreement as to what is being delivered within the project cost, and to prevent scope creep. Can your spec do that?
  10. Document change requests!
    Once your spec is complete and signed off, everyone needs to be clear on what happens when, inevitably, someone wants to change something.   Be clear in the spec that change requests will be documented, analysed, and costed – and implications on timescales and delivery discussed.
  11. Remember to look for lessons learned
    It’s an old management training adage – but if you keep doing the same things, you’re going to get the same results. So, after each project, take time to review your planning and delivery. Did it come in on budget? Did the specification do its job? What lessons were learned?

Rafts! Bridges! It’s a team building day.

August 13th, 2012

On Wednesday we took a trip outside of the office for a team building day. Squinting in the bright Dorset morning (we don’t get out much), we travelled down the Jurassic Coast to Brenscombe Outdoor Centre, in the shadow of Corfe Castle.

After a much-needed breather for tea and coffee, we got underway with the team building activities, which progressed from simply getting the team through a hoop, hitting numbered cones, and then on to crossing a rickety bridge over a raging river below. The last part was imaginary, but we were sure to take it moderately seriously.

The culmination of the previous challenges came when we drove down to the sea in a van full of barrels and wooden poles. Yep, we were about to make rafts. Now we might be kick-ass web developers and designers, but shipwrights we are most definitely not.

And we took to the sea with our rafts! We sailed them majestically, if your definition of majestic involves lots of splashing about. No one fell in though, no matter how shaky one of the boats looked…

The day was a fantastic and fun experience, one that really helped us gel better as a team and understand people’s way of working. It helped us better understand new channels of communications and the challenges in bringing someone new onto a project and communicating needs to them over barriers.

And it finally proved that back-end developers can’t build a boat properly.

Better passwords that you can actually remember

July 20th, 2012

The protection of data is key to the internet. Here at Freshleaf we have put a great deal of time into making our password protected areas as secure as possible using the most up-to-date and trusted techniques. However we can only do so much… in the end it’s all down to the quality of a user’s password that determines the security of their information.

I’ll try and avoid getting stuck into the really technical side of password security here. What I will do however is share some quick tips on how to improve your password security…

Over the years in a bid to get their users to make better passwords, many sites have forced you to create a password with at least one capital letter, special character and/or number. This is done in an attempt to make computers take a lot longer to guess your password. Having capital letters doubles the number of possible combinations of letters, and adding numbers and special characters increases the number of possibilities further. However not all passwords are not easy to remember, as humourously illustrated by this xkcd.com illustration:

Top Tip #1: don’t use “correcthorsebatterystaple” as your password.
Almost everyone who has read that comic now has that password stuck firmly in their heads.

xkcd shows that there’s also a lot of maths you can do to calculate the ‘entropy’ of your current password which I may cover in another post later on. There are also plenty of fun online tools that can tell you how many hours/days/months/years it may take a computer to figure your password out.

Top Tip #2: Try not use a password that you have typed into a password security calculator or any other password generation site.
Any of those sites could just be there to collect passwords, and all it takes is one of them and your password is compromised.

So how do we make a password that is both secure, and memorable?

As the comic suggests, a long password can be more secure than a short password with numbers and characters stuck in-between and also more memorable. One definite is that a longer password is a more secure password, and multiple word passwords are better than single word. So really we are now making passphrases instead of passwords.

Unfortunately from here on some of the suggestions I have are not always possible, as some websites force you to put numbers and special characters in. Some also limit the max length of your password to something small like 10.

Top Tip #3: Sites that specify the length of your password are less secure.
This is because if a hacker knows that passwords can only be between 6-8 characters for example, it instantly reduces the number of possibilities (entropy) their program will need to attempt.

With that in mind, providing you’re not forced to build your password in a specific way, heres are some examples of ways you can make a memorable password.
These are only examples, I am not suggesting you use any of the ideas below as your password security is your responsibility not mine. However they might give you some ideas.

A common one is to add numbers or dates, but this is getting a little too common
Example: iliketomakepasswords1890

Add 10 dots to the end of all your passwords:
Example: iliketomakepasswords……….

Put brackets around your password:
Example: [passwordsarereallyfun]

Add emoticons:
Example: :=)thisismyfavouritepassword:=)

A common misconception is that a computer guessing passwords can guess part of a password. Unless there is a particuarly sophisticated method I am unaware of, this isn’t true. Each attempt at guessing a password is validated on the entire password. Websites don’t come back and tell you that part of your password is correct, or tell you that the last two characters are wrong like a slot machine. So even if your password was joebloggsapple and the guess was joebloggspear, the computer would have no idea that it was close to getting it correct.

So now you have a password that is hopefully easier to remember and yet secure. Or is it?

Regardless of how much entropy your password has and how many years it may take a computer to guess, your use of the password is just as important if not more so. A password that has 100 bits of entropy can be less secure than a password with 8 bits of entropy if poorly managed.

There are people on the web who make money from collecting username/email and password combinations and sell them on. All it takes is those details to be recorded somewhere once by someone untrustworthy and that’s it, you’re on a list. Once your details are on a list, someone can buy your password and hack your account.

There’s not always a lot you can do about this. Looking for certificated sites or secure connections to sites can help stop your password being intercepted in data transfer which is key to online banking for example. But even if the site you are signing up to has those, how can you really be sure? The answer is you can’t, not completely. You could be signing up to, as in the recent case with LinkedIn, a site that was used by millions that hadn’t secured their passwords enough and all those passwords were leaked on a list.

This is particuarly a common occurance on old sites that have been long forgotten about, like that image uploader that you used once and haven’t been back to since. If you used your usual password on that and the same on your Paypal, then you could be at risk.

If you assume that one day your password will be compromised, this will allow you to take steps to limit the damage.

Top Tip #4: Never use the same password for different sites.
But nobody wants to remember hundreds of different passwords. We all know this is a bad idea but how many of us actually use a separate password for each site?

Heres some tips on how you can use the same password, but make it different for each site: (again, these are just tom spark ideas, don’t necessarily use these)

Add the name of the site into your passwords
Example1: facebookjoebloggslikestoshop
Example2: linkedinjoebloggslikestoshop
Example3: twitterjoebloggslikestoshop

Now an argument against this is that a real person looking at your password could look at it and work out what you were doing here but a computer wouldn’t. Using a site’s name isn’t particularly clever, so heres another example:

Add the main colour of the site into your passwords
Example1 (last fm): joebloggslovesthecolourred
Example2 (facebook): joebloggslovesthecolourdarkblue
Example3 (twitter): joebloggslovesthecolourskyblue

If you were to tell someone the pattern you use, they would still need the common bit (e.g. joebloggslovesthecolour) of your password to know the full password.

There’s lots you can do so have fun and make your own pattern.

Top Tip #5: Ultimately, the best way to be secure is to use long passwords, but also be original or atleast be different
invent your own method, that way you are not remembering passwords, just a pattern.

I hope this has helped give some ideas on how to make creating passwords and remembering them on the internet less of a headache.