Category: General

Merging a single commit using Git

Posted by – January 14, 2010

Today, I came across the need for a function that would make most source control mechanism’s cry.  Essentially I needed some work that was due to go into production in a few weeks, to go today, which meant I somehow had to grab some code that was deep down in my bleeding edge branch out into the limelight of the live server.

In Subversion, this would be pain, but luckily I’m using Git.

Out of the box, git comes with a very useful command cherry-pick.  Essentially what this does is take one single commit, and then merges just those changes into the other branch.  This is different to a regular merge in that it doesn’t pull ALL changes, so it’s much more precise.

git cherry-pick -n [The commit's SHA-1 Hash]

(Note that the -n option should be used when you don’t want Git to automatically commit the change into the new branch, but you should make sure your new commit message references the old commit for sanities sake).

Remember though, your newly merged into branch might not be working perfectly now, as you may now have unsatisfied dependencies, so test, test test!

BrowserCMS Gotcha – missing cms/application.js

Posted by – January 14, 2010

I came across an issue today whilst putting together a site using the BrowserCMS content management system for Rails (and if you need a CMS, look no further).

Essentially I was ending up with a situation whereby when I was trying to remove an item from a container I was getting the following error:

No action responded to show. Actions: cms_connectable_path,  cms_index_path_for, 
cms_index_url_for, cms_new_path_for,  cms_new_url_for, cms_toolbar, container, 
container_has_block?, create,  current_page, destroy, edit_cms_connectable_path, 
handle_access_denied,  handle_server_error, move_down, move_to_bottom, 
move_to_top, move_up,  new, page_title, render_breadcrumbs, and render_portlet

After a little digging, I discovered that this is not a rails bug, or a BrowserCMS issue, but a missing Javascript file that needs to be in all of your templates (as well as the cms_toolbar) cms/application.js.  This file attaches all the required js functions to the BCMS buttons, and thus turns the necessary GETs into POSTs etc etc etc.

However, you don’t want this included all the time, but only when you’re logged in as an adminstrator or someone who requires the use of those buttons.  Therefore, the following code is required in each of your templates:

< %= able_to? :edit_content, :publish_content, :administrate do
     javascript_include_tag ["cms/application"], :cache => true
 end %>

This will ensure that everything hooks up as it needs to, and only when it needs to.

Cloning a remote branch using Git

Posted by – January 11, 2010

This is here more as a future note to myself, but hopefully someone out there will find this useful.

Essentially, imagine this:  You have a remote repository (say, on GitHub), and that repo has many branches.  You clone the repo and end up with the master branch in your local dev environment.  Now what happens if you want to use one of the other branches in the repo?

Well, initially, you’d think you would create the branch locally, and pull the differences down:

git branch production
git checkout production
git pull origin production

but what if master is ahead of production (a likely scenario)?  In this case this won’t work as your local production branch will now contain the changes in the master branch – as that’s where you originated production from on your machine.

What you need to do is:

git checkout -b <local_name_for_branch> <remote_source>/<remote_branch>
e.g
git checkout -b production origin/production
What this does is create a tracking branch.  Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type git push, Git automatically knows which server and branch to push to. Also, running git pull while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch.

Measuring your SEO services

Posted by – December 23, 2009

Following on from last weeks post about how SEO people should be trying to perform, I had a thought about something that appears to be common across nearly all SEO companies I have worked with in the past, and how wrong it is.

Picture this, you have a website, and an SEO monkey putting some stuff together for you on a monthly basis to report how well you’re doing.  From my experience, most companies seem to want to issue you with some form of keyword rankings report…

Oh, lookie here sir, we’ve now got you to the number one spot on Google for the term “web design company horsham bob mitchell cheap”!  We’re going to make you millionaires!”

Hang on a second there chummie.  This is all very well if I have all of my customers searching for terms that are very specific to my business, but they aren’t, they’re searching for all sorts of things.

In fact, as a website owner, I do not give a fuck what my users are searching for, I only care that they are coming to my site, and doing things which generate me income/profile/whatever the point of having the website in the first place is.

SEO people should be reporting on their work with analytics and conversion rates, not how great you are at appearing on terms that no-one gives a toss about.

Search engine optimisation is not a black art that’s only doable by some sort of SEO wizard – it’s a measurable level of marketing that will return you measurable results.

Why Search Engine Optimizers have the wrong idea…

Posted by – December 14, 2009

These days, it’s impossible to move more than about 20 feet before you get someone trying to sell you some search engine optimisation services of some kind or another.  Funnily enough they do this via direct selling rather letting you find them on Google, but generally speaking they make the same promises:

  1. They’ll get you to the fabled number one slot on Google
  2. They’ll double your traffic

However, they never tend to promise the one thing that you, as a website owner, really want … return on investment.

For instance, let’s say you’re paying a SEO “Expert” to help with your site.  What would you like to see?  10 million hits a day?  The number 1 slot on Google?  More income?

Exactly, whilst traffic is nice from a vanity point of view, it ultimately costs you money in bandwidth and beefier servers.  Only sales conversions generate you true income and I believe this is how all SEO experts should be measured.

Which would you prefer:  10,000 customers who never buy anything, or five who do?

Over time I would like to see SEO Experts moving to charging on a results based model, i.e. the more money you make you via your website, the more they get paid.  If they don’t increase your ROI (i.e do their work properly), they don’t get paid – simple.

How to choose your next web development technology

Posted by – December 10, 2009

Back when I started out in web development it was simple.  You built websites with HTML, used a very light sprinkling of JavaScript, used CSS if you were doing something cutting-edge, and wrote your backend in Perl.

These days, it a whole load more difficult.  There’s a very wide array technologies available, both backend and front, for all sorts of uses, all competing with each other.  These include browser plugins, compiled languages, statics languages, scripting engines, graphics tools and more.  Flash, Silverlight, HTML5, Rails, .NET, PHP, Canvas, SVG amongst others are all vying for your attention.

So, how do you choose what you want to build your next application in?

Well, chances are you’re already skilled in something, and that’s probably your first choice, but being a web developer means you have a tendency to want to build stuff that’s cutting edge (bleeding edge maybe), something that will attract attention, and something that will show how 733t you are.

Stop.

Unless you’re burning your own money instead of a clients, what you need is something that meets four simple criteria – tried, tested, proven and reliable.

Developers need to remember that at the end of the day, what they are doing has a cost be it time-based or otherwise.  If you’re a client, you want to know that what you’re paying for is going to work, and going to work well.  If it doesn’t, clients get grumpy.

Users don’t want rich

Posted by – September 30, 2009

For many years now, software developers around the world have been releasing quicker and more capable software on an almost constant basis. Each year, we tend so see new releases of existing products that make the products better in every apparent way, shape and form, and we, the computing public, lap it up.

For instance, Microsoft Word is currently at it’s 11th(-ish) version and still going strong as one of, if not the, most successful word processing packages of all time.  Each year or two Microsoft bring out a new and improved version that adds more features and more capabilities to the average person’s arsenal.

Now, for a moment, have a think about the last time you used Word.  Assuming you’re not one of the 10% of people who “power-use” Word, see if you can name five features of Word that you use on a regular basis.

Formatting?  Tables?  Printing?  er….. Word Count?

Let’s for a moment consider Word, with each and every standard toolbar open:

word

There’s a lot there, and there’s a whole load of stuff in there that you’ve never even seen before. Now, think back to the last time you upgraded your installation of Word.  What was the reasoning behind it?  What was the reason that you (may of) reached into your pocket and forked out for the funky new Office installer?

Well, let’s take Word 2008 – the headline features there were the Ribbon UI, and support for Office XML formats… and that’s about it.  Which of those features made you upgrade? Word probably has more functionality than you need… in fact, waaay more functionality than you’ll ever need.  So, why don’t you just use WordPad which comes free and is pre-installed on Windows?  Or TextEdit on the Mac?

Now cast your mind across to the web applications that we, as developers, are creating every day for our clients, be it on a bespoke purely custom basis, or as a product that we roll out to a customer base.  I dare say, that somewhere in your company is a man who works in what some would call ‘Marketing’.  This person wants to sell the product out to as many people as possible, and he also wants all of the current user base to upgrade on a regular basis.  Therefore, you most likely have an army of developers creating new features here and there, and making the existing features more capable in every way you can in order to persuade the customer that WhizzBang Enterprises Widget-o-matic 2009 is the best-est thing since last years version (which is now obviously outdated, insecure, and prone to crashing).

Why do we, as software shops, do this?  Why do we insist on making our software more complex, and more difficult to use for our customers?

bob

Put yourselves in the shoes of your user (let’s call him Bob).  First of all, be aware that Bob is nothing like you.  Bob doesn’t use computers for the fun of it, he uses computers to get something else done, so that he can go home on time and get back to work on his new garden terrace.  Bob doesn’t really get computers, he doesn’t really get the web that much.  Sure he uses Facebook, and emails his chums, and even has his own website (which incidentally is just his twitter stream), but Bob’s interested in other things – Bob just wants to get his shit done and go home.

So, whats the major difference between you and Bob?  Well for starters, for Bob, his computer, and the software on it is a tool – nothing more, nothing less.  He uses his tools to write his documents, send them out to his clients, and ensure that he gets paid at the end of the day.  To Bob his computer is identical to the bag he uses to carry his lunch to work, a tool to achieve a task.

So, thinking about tasks – what do most people want?  Well, it’s simple really.  Simplicity.  People just want to go in, get exactly what they want done with the minimum of fuss, and move on.  Even us developers do it.  We don’t sit down in the morning and think “I’m going to sit down for the next eight hours and write some Ruby…”, we think “I’m going to sit down for the next eight hours, and get this project finished and out the door”.  Our tools are an ends to a means.

So, coming back to our software, why do we make it so complex? Why are we so obsessed with feature richness and whiz bang interactions – the vast majority of people couldn’t care less, they just want to get their work done with the minimum of fuss.

Let’s take a look at richness in applications (the aforementioned whiz-bang element). Recently, there has been a huge movement by Adobe and Microsoft to get developers into using rich platform technologies such as Flash and Silverlight.  Whilst this is all very well, have a quick think about how many applications you use on a day-to-day basis you would consider to be rich (and buzzword bingo favourite “an immersive experience”).  Personally, there’s only one (Balsamiq Mockups if you want to know).  For most, it’s a twitter client.

So, what does this say?  Well for me it’s a sign that while we developers love to see the demo apps that are coming out and what some people are knocking out, but at the end of the day it’s ultimately simplicity and straightforward-ness that we prefer – we just want to get our work done.

In essence, I guess we might be guilty of three things – one, overestimating the users motivation and involvement in using the wonderful creation that you’ve just put out there. Secondly, of overcomplicating what we’re making the users use purely for the marketing aspect, rather than making a genuniely good product, and thirdly, for not really eating our own dog food and actually using this rich applications that we keep telling everyone they need.

Overally, we, as developers, need to keep it focused and keep it simple.  Distractions are aplenty, and we developers are incredilby suspectible to them all which makes us more prone to not keeping it simple…

How a puncture changed Top Gear forever

Posted by – September 15, 2009

Earlier today I was watching some of the near-constant Top Gear re-runs that are shown here in the UK on Satellite channel Dave. Whilst watching I couldn’t help noticing how different Top Gear was back then versus the last couple of seasons that have been airing on BBC 2.

So, I started to have a think about the causes behind the change from the old skool Top Gear of five years ago to the current mainstream Top Gear we have today.

hammondBBC1701_468x256For those who don’t know Top Gear (the current guise, not the really old style) was largely road tests of premium cars, associated with the odd challenge/race/larking about. These days the focus is very much more on the larking about and scripted mainstream entertainment.

From what I can work out a single event changed everything for the Top Gear production team and that was presenter Richard Hammonds stacking of the Vampire Jet Car.  From what I can work out, the accident took place towards the end of the filming of the next series of Top Gear.  Hammonds resulting condition caused the production team to want to delay the series until he returned – if he returned at all.  In the meantime, Top Gear was receiving a massive amount of media attention as a result of the crash and was pretty much every where you looked.

When Hammond was up and about again and ready to get back into the show BBC2 had to reallocate a slot for the series to fit in to – but only a six week slot was available as opposed to the previously booked 10 week slot.  This meant that the production team had to cull four whole weeks of content – and being funded by the licence payers, this meant that they culled the cheapest four weeks of production – i.e regular road tests etc.  What was left was six weeks of challenges/races/larking about.

When this series aired, the content, coupled with the massive public interest in Hammonds health, the series was a massive ratings hit – taking 8 million viewers for one episode alone, a BBC2 best ever.  From then on, the TG team realised that they were no longer having to cater for the motoring nuts out there, but the mainstream populace had no real interest in boring road tests and stats.

Roll on three years, and Top Gear is a very different animal to what it used to be, and in most ways for the better (admittedly a little scripted though).  Overall though, it would appear that that small puncture in September 2006 was a good thing…

Brawn GP comes to the iPhone

Posted by – September 10, 2009

Yesterdays F1 post reminded me of a post that I’ve been meaning to write for a long time (although now it’s a little out of date).

A while back, Brawn GP, F1’s fledgling, and championship leading, team have released a game for the iPhone, which, as expected. is a neat little F1 simulation.  When it was initially released, there was only one track available, the home “London” track, but now there’s three more with more on the way.

What’s more interesting about this isn’t the F1 aspect so much, nor the game, but how the iPhone/iPod Touch platform enables companies like this to crack out small games and push them out to a wide audience relatively quickly.  When you consider that the team has only really existed since March of this year, and that they are releasing a 3D racing sim three months later, it’s a pretty impressive feat.

What the means for the future is very interesting.  Assuming that the console manufacturers recognise that there is a large amount of money to make from thr App Store model, as Apple are currently demonstrating, this might lead to a massive movement towards small time development shops/individuals developing lots and lots of small, very inexpensive games.  It’s almost back to the old days where you could go out and buy a game for your C64 for 99p on a cassette tape.

This will hopefully remove us from the current games publishers vice like grip of charging us £50 for a single game, which can only be a good thing.  Admittedly we don’t want to stop getting the mega-budget hollywood-esque games, but we do want more choice for less money.

So, Microsoft,  Sony and Nintendo – take note of the iPhone and pull your f’in finger out.

There’s some dirty goings on at Renault F1

Posted by – September 9, 2009

I’m changing the subject of this blog a little for this post, as I think this is quite an intriguing subject, and one that the wider audience may well find interesting too.

bed9fc775c995507f14de2743b64160aEssentially, this post relates to Renault F1’s alleged conduct at last years Singapore Grand Prix (which they won, and was also sponsored by Renault’s key sponsor ING).

For those that don’t know, the inaugural F1 night race featured a safety car period at about third distance which involved Renault’s No 2 driver Nelson Piquet Jnr.  ”Conincidentally”, this crash occurred just after the No 1 driver Fernando Alonso’s out of the ordinary early pit stop.  The ensuing events meant that Alonso was able to build up a large lead, and then finally get Renault’s first win of the 2008 season.

Now, fast forward a year – Nelson Piquet has been sacked for not performing, and it’s widely known that the split was not the most amicable.  Piquet was well documented in his view of his manager, Flavio Briatore:

“I always believed that having a manager was being a part of a team and having a partner. A manager is supposed to encourage you, support you, and provide you with opportunities. In my case it was the opposite – Flavio Briatore was my executioner.”

So, it’s no surprise that new evidence happens to have come to light about an apparent bit of dirty dealings last year in Singapore.  At first we weren’t sure if this was from Piquet or not, but the timing kind of gave it away.

From what I understand, a meeting took place prior to the race between Piquet, Briatore, and Pat Symonds, the Renault F1 director of engineering.  In this meeting, Piquet, who doubted he would retain his race seat with the team, was asked if he would deliberately crash in order to help out Alonso.  Piquet obviously would have agreed as he would have been able to keep his race seat in an F1 car.

It would seem that more detailed information has also come out, Piquet having been later asked to crash on lap 13 or 14, at turn 17, once Alonso had made his stop.  This would have been the ideal time and place, due to the lack of cranes that could remove the car, therefore forcing the desired safety car period.

Of course, Briatore and Symonds both deny this, stating that the meeting did take place, but Piquet was the originator of the idea.

Another piece of evidence in the case is that of the car telemetry.  Normally when a car starts to oversteer, the driver will lift off briefly to catch the slide – however, in this case, Piquet kept his foot planted, a particularly unnatural thing for a driver to do.

So, overall, combine this evidence, and it looks like all the fingers are pointing at Renault as being a bunch of cheats, and much more so than the McLaren/Ferrari case of 2007, due to the fact that people’s safety was at risk.

Later this month, and coincidentally the week before the 2009 Singapore Grand Prix, there is a hearing due at the World Motor Sport Council where we will find out more, and see what kind of punishment will be handed out if they are found guilty.

Personally, if they are guilty, I think they should be taken to the f’in cleaners.

More information can be found here.