dan/blog

The MVC architecture and the many frameworks that implement it (Rails, Zend, Code Igniter etc) are designed to prevent you committing any number of coding sins.

Examples where the models contain almost none of the domain logic, the helpers contain 99% of the application and the controllers just try to keep up are hell to look at.

Knowing how to cleanup helpers really helps. This screencast shows how to move self-contained logic into separate classes and keep the helpers from hindering.

This podcast is from railscasts.com - well worth subscribing to for lots of rails tips.

Sometimes it’s useful to make AJAX calls go it a certain order. If the AJAX calls are sent in response to user actions, you might want to make sure that the responses happen in the same order. 

Unfortunately, AJAX is, by definition asyncronous.  

To get around this I wrote a single function through which all AJAX calls are made and all onComplete responses are run (we’re using prototype at the moment).

So write a function that accepts the AJAX calls:

AjaxQueue(
  // All your arguments go here
);

AjaxQueue pushes all the arguments onto a queue (first in, first out) and process it accordingly. If nothing else is on the queue, send the request else queue it.

Really simple history is a library of deep linking in AJAX – that is, linking to things that are a few clicks away in and AJAX app.

GWT does this for you, but it’s useful to have something like RSH for non-Java apps. 

Haven’t had time to play with this yet, but will do soon…

One thing that really riles some people is the lack of a good SLA for EC2. What this means is: Amazon say the EC2 servers will probably be there but won’t definitely be there, and this makes it harder to justify using EC2 for mission critical apps.

But Amazon aren’t the only people offering cloud computing:

• Mosso is a rapidly growing system, backed by Rackspace and offering Windows as well as Linux (which is all Amazon offer at time of writing).

EC2, Amazon’s exciting new cloud computing product, is going to have persistent storage.

So, now you can start X thousand instances of EC2 and they start up with all the HD data you need on them. This solves a problem that several people have ranted about… 

I spend a lot of time helping coders and companies get going using Subversion so here are my top tips for using subversion:

Use SVN. Trust SVN. Use SVN more. If you’re still making manual backups of your code before you make changes then you’re not using subversion. SVN tracks all changes and lets you revert them – so trust it and then use it. If you want to undo some changes to a file, just do:

# svn revert myfile.cpp

Ok – I do make manual backups sometimes if I’ve concerned I’m going to screw up my working copy.

Delete your sandbox every 2 days. Your sandbox is your working copy – it’s what you checkout from SVN and work on. Every 2 or 3 days, delete it and checkout from scratch again to make sure you’re really working with code that is in SVN. 

This is where most people go wrong – they checkout once and use that copy for months, but you should really do is think of the sandbox as dispensable so get into the habit of dispensing with it.

If you’re working on a web project and the directory name matters, just rename it and check out from scratch in its place so you have your old code:

# mv myproject myproject-backup
# svn co http://mysubversion/myproject/trunk myproject

Useful commit messages will help everyone. Something like “update CSS” is useless if the only file you checkin is a .css file. Something like “fix text alignment” is better or, if you run a bug tracker like Redmine you can include the bug number: “fixes #1234″.

Use branches as soon as something goes live. Make sure it is clear to everyone which branch is live and which is still in development. This will save hours of manually copying code from the live branch to development and vise versa.

Keep branches simple because they take time to get used to. The best advice I’ve seen is to make sure most work happens in one place – e.g. the trunk – and use branches for longer, complex work. A tool like GIT or SVK, which lets coders version their changes locally before committing back to you central SVN repository will also help.

What happens when things get cheap?

Servers are bought by the box (e.g. from Dell or HP) or by the month (e.g. from 1and1, Rackspace etc). Barriers to entry to the hosting business are high and the added value of the setup of the servers, the number of servers is tied, more or less, to the hosting company.

With EC2, everything from the machine downwards doesn’t matter anymore. What matters is the service you run on top of them. 

As barriers to entry fall, so the number of companies offering value-above-the-box services based on big server configurations will rise. Smaller companies can start doing things that only those companies with huge infrastructure could previously do.

This will probably take a few years to get used to – in fact, EC2 is already nearly 1 1/2 years old and running on the cloud isn’t the standard yet.

When one company or some small set of coders find the killer app though, every client will start wanting their site “in the cloud”.