Freelance
Web Designer

We all have them – little coding tricks and snippets of knowledge that we’ve picked up over years of experimentation and evolution of our processes, that are now part of our regular routine and save us time, gnashing of teeth and allow us to work quickly and efficiently. Here’s some of mine – perhaps you know a few of these already – I’d be interested in hearing yours in the comments.

Disclaimer: Some of these points have a php bias. Sorry to you Rails devs or people building their awesome next-gen apps in Fortran etc (“MOM! a new user signed up and I’ve run out of punch-cards!!1”). Oh and to the first person who says “DUDE, like, all of these are SO OBVIOUS!!” – all I can say is congratulations! you win the internet.

 

1) SVN checkout as the production site

The n00b way of updating files on your web host would be to FTP in and drag and drop / delete stuff. Doing it like this will quickly get you into a mess with a large site with many files – there’s the potential to forget to upload certain files, accidentally overwriting things you shouldn’t etc. Some FTP apps have a “sync” button that tries to solve this, but I don’t trust them; you’re still overwriting files that you can never get back. That’s not a good policy to have with the valuable data on your production server.

I haven’t used FTP for about a year now. Now, all my interactions with the production server are simply ssh-ing in and typing “svn up”. I have a remote SVN repository on a totally separate server. On my local machine I have a checkout of the repository, and the same on the production server. Updating files and adding new functionality is as simple as me working locally, committing, then firing off a command on the production server to update all the edited files (I could even cron-job this if I wanted to, but it’s better to be in control in case you commit something borked by accident). This means all my edits are versioned, so I can roll back if I break something. It also means that setting up another machine to work locally from (e.g. my laptop, or a new team member) is as simple as checking out the repository to that machine and starting work.

This tip alone has made my workflow a hell of a lot faster, especially with regard to deployment of new functionality to an existing site. Also, since you’re interacting with the production server only through ssh, everything is encrypted, meaning it’s more secure than FTP.

Just make sure your .htaccess file is set up to prevent viewing of the .svn folders that will be part of the checkout on the production server.

James Ellis has a great write-up here although I don’t advocate the use of GUI tools for SVN, I tried that for a while and found it clunky – command line works best IMO.

2) CSS Reset

In all of my projects I include a CSS Reset, supplied by Yahoo!, in the main css file of the site. This normalises everything – it gets rid of unwanted styles that a browser might set arbitrarily (e.g. IE6 adds some arbitrary padding on form elements), to ensure that you’re always starting from ground zero on any browser whenever you start a new project. Some of you probably do a similar reset at the top of your CSS files like this:

* {
margin: 0;
padding: 0;
}

But the CSS Reset goes one step further by being more granular with its selectors (so you don’t rely on the individual browser’s interpretation of the * catch-all selector) and also getting rid of certain font styles, for example some browsers arbitrarily give the **strong** tag a bold font weight, but your project might not want this – it’s better to start from zero each time. Much cleaner, and will save you time down the line.

3) Separate Static and System Files

This is just one of those best-practice things that you should employ for your peace of mind and ease of maintainability. In all my projects I keep my system files (that is, executables such as php files) completely separate from my static files (such as css, js and image files). A typical file structure would be this:

Or even better, this:

Where you keep the system folder completely outside the document root meaning no one can attempt to mess with your system files via HTTP, looking for holes to HAXXORZ.

4) Drink a coffee and take a 15 minute nap

If you’re anything like me you probably work in cycles of going balls-to-the-walls with inspiration writing the best code of your life, to unproductive downtime of feeling unmotivated and looking at lolcat pics whilst saying “heh” periodically. The worst enemy of a productive mind is fatigue – I pretty much know that if I don’t get something “done” before sleeping when I’m in “the zone” (I’m making scare quote gestures as I type, which is impressive), I mess up my pace and the next day it’s unlikely I’ll pick up exactly where I left off. To prevent this I have a simple solution of drinking a cup of coffee and then taking a short nap. The nap is enough to give your body a rest, and by the time you wake up the caffeine will have started to do its work – once I shake off the nap, I’m good to go for another 3 or 4 hours.

5) Use underscores to control your file lists

Really quick tip – in your project you probably have template files (in MVC this is the “View”) and within those template files you probably have partial templates that you include in a bunch of different pages, for example a header template or footer template. I always stick an underscore at the start of these filenames so that they always appear at the top of any file lists (e.g. in my text editor), so _header.php and _footer.php – this way they don’t get lost in a long list. You could bundle them off into their own folder, but I prefer having these files quickly on hand in the main template folder. Plus, hierarchically-speaking that’s where they should be as they are part of the whole project, not part of a sub-section of the project.

6) Leave off the last ?> in php-only files

Shock horror, you don’t need to close your php tags in a php-only file. The reason you might not want to is because:

• It makes you look cool and dangerous to people who don’t know this tip. Kind of like the geek equivalent of smoking in front of your 10-year old cousin.
• It prevents accidental whitespace from being output by your php file
• If you add up the time you save by not typing those two characters in each file of every project you work on from now until you are dead, you’ll find that you’ll literally save valuable minutes of your life.

7) Wrap floats in a float, to clear!

If you work with css floats much you’ll eventually come across this problem:

2 floated elements inside a container. The container doesn’t expand to contain the floats. There are a lot of solutions to this, such as sticking in an element to clear the floats (bleh) before closing the container, using the :after pseudo-class to inject something to clear the floats, or setting a fixed height for the container, using a min-height workaround – the list goes on. The simple, all-conquering method of getting around this problem? Float the container too:

It will expand to fit the enclosed floats perfectly, whatever height they are. Thanks to Steve Smith of Ordered List for this tip – it changed my life. / on knees, not worthy, not worthy

Use jquery and the Form plugin for Ajax interactions

When using a javascript library, often to do an Ajax action we have to basically assemble a query string and then pass it to a function – the jquery example would be something like this:

$.ajax({
type: "POST",
url: "/ajax/kill_all_humans",
data: "id=" + my_id,
success: function(msg){
alert('ahhhh yeah');
}

Don’t re-invent the wheel! That example only has one parameter (“id”) – can you imagine doing an Ajax interaction that required 10 parameters? 20?

The way I do all almost all Ajax interactions now is by writing out an HTML form and doing pretty much sweet naff-all else. The equivalent of the above would be:

<form method="post" action="/ajax/kill_all_humans">
<input type="hidden" value="1" name="id" />
</form>

Then I simply use the excellent Form plugin for jquery which has the killer method ajaxForm(). I write out some simple javascript that tells the browser which forms on the page I want to submit via Ajax and the submit event is then handled by jquery. It simply sends all your form data as is written in the normal html form, asynchronously. And it works for multipart forms too! The benefits to this:

• You don’t have to change any of your javascript if you add a bunch of new stuff to the form. You simply declare the form as an Ajax form via ajaxForm() once, and then from that point jquery will handle whatever you throw at it.
• The form still has a valid action attribute which means it’s much easier to make the form degrade to handle a non-Ajax interaction (for people with javascript turned off or browsing on a mobile device etc).
• No inline javascript and minimal extra coding.

9) Controllers to handle input types

When using an MVC framework often we map areas on the site to their own controller, for example www.yongfookisawesome.com/members maps to /controllers/members.php which handles all the associated functionality for that part of the site (e.g. viewing a list of members, viewing an individual member page etc).

I use this convention for inputs too, so I often have an ajax.php controller that handles all Ajax interactions. To me, this makes a lot of sense and adds to the maintainability of the project – ajax functions tend to be quite compact, often simply taking an input, writing to the db and responding with a TRUE or FALSE or spitting back a json string. The last thing I want is for all these little functions like create_contact, delete_contact, send_message, add_comment, delete_comment to be scattered all over my application in a bunch of different files like contacts.php, mail.php, comments.php – I keep them all in the ajax controller so that I know exactly where those functions are based on the type of input they expect.

10) Install the Zend Framework

If you are a php developer building web applications, you probably use one of the popular php frameworks such as CodeIgniter, Symfony or CakePHP. Personally, I use CodeIgniter for all my projects. These frameworks all supply an excellent set of class files for dealing with most of the day-to-day functionality your app will need to cover. For everything else, you can use Zend. The Zend Framework is basically an extensive set of well-written classes that you install on your server, and can then pick and choose from at will when you find there’s something your php framework of choice doesn’t quite cover. Rather than googling for some proprietary library that you can retro-fit to your framework, or searching for an extension to your framework that supplies the required functionality or – gasp – coding something from scratch, you can simply pull Zend Framework functionality as needed. Between the classes included in your framework of choice and the Zend Framework, you’ll probably have 99.9% of all functionality you’ll ever need for your application and the only googling you’ll need to do to figure something out will be on the documentation for your framework and the documentation on the Zend Framework (which is extensive, and clearly laid out).