Original article

As I’m in the very early stages of setting up a freelance web development business, I wanted to give a very quick shout out to Stuff & Nonsense for their fantastic Contract Killer – an open-source contract for web designers and developers.

Not only does provide the beginnings of a very well written (in plain English) contract for you to modify as required, but it also goes into a lot of detail to explain why the different parts of the contract exist. I think my favorite part is its clarification on browser testing, specifically:

Browser testing no longer means attempting to make a website look the same in browsers of different capabilities or on devices with different size screens. It does mean ensuring that a person’s experience of a design should be appropriate to the capabilities of a browser or device.

Although I have access to wonderful resources such as the fantastic Design is a Job book by Mike Monteiro (if you get a chance, watch his Fuck you. Pay Me. lecture), and The Web Design Business Kit published by SitePoint, they both fall short in comparison to what Contract Killer provides regarding this very important legal document (seriously, watch Fuck You. Pay Me.)

Update (26th January 2013)

It’s taken me 28 revisions, and a week of editing, but I’m happy to share with you the Lime Blast edition of Contract Killer 3.

I’m not currently 100% happy with it, mostly because I don’t know anything about British contract law (and as such, I’m a little bit nervous about actually using it), but I’m hoping what I’ve ended up with is going to be suitable for my needs.

What you may not know is that I’m also the co-founder of a gaming clan/guild called Fight Club Monkey.

Fight Club Monkey?

What started as a semi-serious attempt at competing in an Urban Terror gaming league with some friends, resulted in us all realising that we’re were not actually very good at the game, and that we had far more fun messing about than trying to win.

(Most of our clan nights ended with the in-game gravity on the server being turned down, allowing us to pretend as if we were shooting terrorists on the moon.)

Although the clan lasted for a couple of years, and we ventured into new games as they were released, eventually it become less and less important as we grew up, got jobs and/or went to university.

Since late last year, however, FCM has made a return, not as a clan or guild per se, but rather as a group of friends who like to get together to play games once in a while.

Getting to the point

I mention all of this simply as a preface to the announcement that on Friday I relaunched the Fight Club Monkey website based on a fantastic WordPress theme called Responsive by ThemeID.

I’m often quite fussy about the themes I use in my WordPress projects – most of the time I prefer to build a theme using something like Roots Theme (although, not so much now it’s gone Bootstrap exclusive) or the newly discovered _s base theme.

On this occasion, however, I had limited time to work on the project, so was more interested in finding something that worked out the box, which I could then expand using child themes. Being responsive was never crucial to the project, but would have been a nice perk.

During my research I came across themes such as Hybridside and Revova, both of which I think were attractive options, but Responsive blew them both out of the water with its functionality.

What makes it good then?

Responsive theme

We’re moving into an age where more and more people are using mobile and tablet devices to access the web, and any sites that don’t keep up with the changing face of technology will get left behind.

There are some features that don’t work quite as well responsivly as I would like (such as the very top and very bottom navigation bars being far too small on phones), but these issues should fixable with a few CSS tweaks.

Child theme support

Unlike some free themes I’ve used in the past, the development and improvement of Responsive seems quite active (just a day after launching the site I saw there was a theme update waiting for me), so by having good child theme support, you’re free to go in and make your own customisations and enhancements, while retaining the ability to easily upgrade to the latest release.

Theme options

Baked into the theme are a number of settings which can be controlled within the WordPress administration area. These include being able to set-up links to popular social networking sites (such as Twitter, Facebook and even Pinterest & Instagram), adding your Google/Bing/Yahoo webmaster verification strings, as well as whatever statical tracking code you use, and an area for a small amount of custom CSS.

Also impressive is the easy way in which you can customise the elements which exist on the homepage, with the main call to action area being controlled via its own interface, and the three areas below that being widgetized (is that even a word?) allowing you to put in whatever widgets you want.

The theme also supports ten page templates, allowing you quite a lot of flexibility in how you want to display your content of your site.

Conclusion

All in all, I’m very impressed by the Responsive theme. It has ticked all the boxes I needed for the FCM site, and am looking forward to using its child theme support to enhance it further. Visit the Responsive theme website.

But what if you’re not working on an open source project? Sure, you can buy access to private repositories from GitHub - but if you have a team of five or less, I’m here to tell you to put your wallet away.

Bitbucket for teh win

Allow me to introduce you to Bitbucket, which started life as Mercurial’s answer to GitHub, and served as a hub for the Mercurial community. I used the Bitbucket service, for a time, during my Mercurial days at Propeller, as they offered private repositories for free.

I remember at the time that this caused me much dilemma, as I knew the de-facto industry standard was becoming Git, and was keen on switching away from Mercurial for this reason, but could not afford GitHub.

This all changed on the 3rd October 2011 when Bitbucket announced support for Git.

Is it any good?

Bitbucket works in much the same way as GitHub does, and so far as I can tell, supports mostly all the same features. For example, each repository supports a wiki and issue tracking system, full history of past commits, support for pull requests, integration with a large number of services, and proably a whole ton of other git-based goodies that I’ve not even begun to explore.

They also support submodules hosted at in other locations (such as GitHub), a feature that I take full advantage of on almost all of my own projects (even WordPress ones), so you don’t need to worry about losing this feature.

Keen on taking business from their rivals, BitBucket also supports the ability to import repositories directory from GitHub, Google Code, Subversion, et al. meaning that switching to BitBucket is an easy process.

(And no, as my old work colleague Sheepy asked me, it doesn’t do anything funny like ‘covert the repositories into mercurial then back into git’.)

Value for money

Bitbucket makes its money by charging for the maximum number of people that can access each repository, rather than on the number of repositories you own. This means, for example, if you’re in a small web design firm with a large throughput, (such as Ghost Design) it could work out more cost effective than the competition, without any loss of functionality.

So, If you’re not yet using any form of remote repository for your private projects, then give Bitbucket a go., Whereas if you’re already using GitHub, a couple of quick sums will tell you if you’re better off with BitBucket, and with no more than a few minutes importing your existing repositories, you’ll be up and running before you know it.

Full discolsure

I did win a t-shirt from Bitbucket as part of their spooning promotion, but it takes a lot more than a free t-shirt to buy me. I’ve posted this message because I believe that Bitbucket offer a good service, and I want to give credit where credit is due.

*watches as tumble-weed bounces across the void*

…one of the main reasons I got a dedicated server was because of Git, and all the wonderful things that it is able to do for you.

The problem I quickly discovered was that all of my (and my employer’s) customers used shared hosting, which meant being limited to FTP for uploading changes to their websites.

This meant that when it came to deploying my changes to the server, I still had to find and upload each of the changed files manually (or think “sod it” and upload them all, to make sure I didn’t miss any).

And, if I’m honest, this became quite repetitive and boring… So what should you do if you want to automatically deploy from Git via FTP?

git-ftp to the rescue

git-ftp is a free and open source Bash script that allows you to push files in a Git repository via FTP to a remote server. But rather than upload all the files each time you push, git-ftp is intelligent enough to only upload (or delete) files that have changed since the last push.

It also has additional features such as configuration of an ignore file, which will prevent any specified files from uploading, and the ability to perform dry-runs, which simulates the upload facility, to make sure that nothing will go wrong before you do push for real.

Installing git-ftp was so simple that even I (a Neanderthal when it comes to most things Linux) was able to do it without issue, and once a repository is configured with the correct FTP settings:

$ git config git-ftp.user daniel
$ git config git-ftp.url ftp.example.com
$ git config git-ftp.password s3xyAnd1Kn0wIt

and an initial git-ftp initiation process is completed, pushing the most recent changes is a simple as:

$ git ftp push

Alternatives

To help avoid confusion, I figured it would be important to point out that there is another project hosted on github which has the same name, and does the same thing, as the aforementioned git-ftp, but is written in Python rather than Bash. As I’ve not used it, I cannot comment on it, but if Python is your thing, then you might be interested in trying that instead.

Alternatively, if you don’t mind spending a bit of money, it might be worth taking a look at Beanstalk. This is designed to be an all-in-one solution alternative to github for repository hosting, with the additional benefit of automatic FTP deployment, and third-party service integration, etc…. I gave their free plan a try, and the service they offer seems to work well…

Conclusion

…but personally, seeing as a price-tag of free is very attractive, I’m quite happy combining git-ftp and Bitbucket (more on this in a future post), and in fact do so for 12 (and counting) projects.

Much like the other CSS preprocessors, CSS Crush offers a range of features designed to make your life easier. Although these including functions that let you do things like manipulate the opacity of a colour value, or generate a data uri from a relative file path, I’m going to talk about some of the other features that I have experience with.

Vendor prefixing

The first, and possibly most important of these, is vendor prefixing. There has been a lot of talk in recent months about non-webkit browsers adopting the -webkit prefix, which has been spurred on by the fact that, to be honest, vendor prefixes are a pain in the arse.

CSS Crush helps solve issues like this by automatically adding all relevant prefixes to the properties that support them, meaning that this:

div { background: #fff linear-gradient( left, red, white ) no-repeat; }

will automatically be converted into this:

div {
    background: #fff -webkit-linear-gradient( left, red, white ) no-repeat;
    background: #fff -moz-linear-gradient( left, red, white ) no-repeat;
    background: #fff -ms-linear-gradient( left, red, white ) no-repeat;
    background: #fff -o-linear-gradient( left, red, white ) no-repeat;
    background: #fff linear-gradient( left, red, white ) no-repeat;
}

This is something that (so far as I’m aware) none of the other CSS preprocessors offer out of the box – although some creative use of mixins does offer something similar – but by using CSS Crush as a git submodule, you’ll always have access to the latest prefixes available.

Variables

Another helpful feature is that of being able to define and use variables. This allows for uniformity across all your stylesheets, meaning you can define variables such as:

@define
{
	/* fonts */
	title: "Times New Roman", Georgia, serif;
	body: Verdana, Arial, Helvetica, sans-serif;

	/* colours */
	primary-rgb: 89,168,15;
	primary: rgb($(primary-rgb));
	primary-text: #FFFFFF;

	secondary-rgb: 158,213,76;
	secondary: rgb($(secondary-rgb));
	secondary-text: #FFFFFF;

	background-rgb: 240,242,221;
	background: rgb($(background-rgb));
	background-text: #222222;
}

then if you need to change a value at a later date, rather than having to do a find/replace, and risk missing some, you simply update the value is one place, and CSS Crush does the rest for you.

Direct @import and minification

One of the things I found particularly useful was the ability to use @import to manage different CSS files for responsive sites. A practical example of this would be something like:

@import url( "mobile.css" ); /* Mobile first */
@import url( "tablet.css" ) screen and (min-width: 768px); /* Tablet and higher */
@import url( "desktop.css" ) screen and (min-width: 992px); /* desktop and higher */

which not only imports the files directly into a single stylesheet, would also put the correct @media tags around the imported code, and then performs minification on it all.

Implementing CSS Crush in WordPress

I’m actually using CSS Crush in my limeBase WordPress starter theme, so that could be a good way for you to get started, but if you wanted to create your own implementation, it couldn’t be simpler:

1. Download/clone the files into your theme folder in a folder called cssCrush
2. in your functions.php file, add the following line

   require_once 'cssCrush/CssCrush.php';

3. in your header.php, replace your existing stylesheet <link>code with

   <?php echo CssCrush::tag( TEMPLATEPATH.DIRECTORY_SEPARATOR.'style.css' ); ?>

Upon viewing your page, CSS Crush will create two new files: .csscrush and style.crush.css, and output the relevant <link> code linking to the new style.crush.css file.

If, before further page views, the original style.css gets updated, CSS Crush will detect the change, and generate a new crushed file for you, otherwise it will continue to serve the cached file.

Conclusion

If you’re already happily using LESS or SASS, then I’m not sure there is much that CSS Crush can offer you. If, however, you’re more interested in a simple way of automatically adding vendor prefixes and performing minification on your CSS, then you can’t go far wrong with CSS Crush.