Experience Internet Blog

Using Git to Manage an ExpressionEngine Website : A Typical Git Workflow

Stephen Lewis — 2009-10-12T09:30:06+00:00

This is the last in a series of posts about using git to manage an ExpressionEngine website. If you’re new here, you may want to start at the beginning.

Summer has turned to Autumn, that duplicitous charlatan Masuga has attempted to steal my thunder, and yet somehow we’ve managed to stumble our way to the final installment in this series.

This is the point at which all your hard work and inexhaustible patience pays off.

The previous post concluded with a brief overview of a typical Git workflow, and the promise of a more detailed description of the day-to-day usage of Git in the next installment. Ever a man of my word, that’s exactly what this article is all about.

The scenario

Your client is the proud owner of a fairly large, busy website, requiring lots of minor ongoing updates and improvements. He also plans to launch a big new product (the Widget-o-matic) a few months hence, an event which requires a number of significant changes to the site.

The prospect of building a major new website feature, whilst simultaneously making regular updates to the existing site, would terrify a lesser man. But not you dear reader, for you have Git at your elbow, and such things no longer hold any fear.

The solution

Something that Git does very well — indeed continually brags about — is branches. A branch is a separate line of development that shares a common ancestor with the other branches within your project.

In this case, your default branch (master) will be used to manage the current (live) website, and a new widget branch will be used to manage the development work for the new Widget-o-matic section.

The workflow

Working with Git is very simple, and really only involves a handful of commands. Here’s how the above solution translates into Gitspeak.

Create the `widget` branch

First up, create the new widget branch in your local repository.

$> git checkout -b widget

This simultaneously creates a new branch named widget, and makes the widget branch active. If you prefer to do things one at a time, you can instead enter.

$> git branch widget
$> git checkout widget

Let’s see what we’ve got so far.

$> git branch -a
  master
* widget
  origin/HEAD
  origin/master

In an attempt to keep this post a manageable length, I’m not going to get into a discussion of the origin/HEAD and origin/master branches right now. Suffice to say that you should never attempt to work with them directly; they are tracking branches, whose sole purpose is to track the branches in your remote repository.

Which leads us neatly into the next step: creating the remote repository widget branch. The simplest way to do this is as follows.

$> git push origin widget

Git is smart enough to realise that the widget branch doesn’t currently exist in your remote repository, and creates it for you. You can confirm that everything is hunky-dory by listing all of your branches again.

$> git branch -a
  master
* widget
  origin/HEAD
  origin/master
  origin/widget

You could get on with building the Widget-o-matic right now, but ideally you’d be able to push and pull from both the master and widget branches without the need to specify the remote repository branch every time.

Running the git remote show origin command displays lots of useful information about your remote repository.

$> git remote show origin
* remote origin
  URL: ssh://shell_username@account_name.dreamhosters.com:git-repos/example_website
  Remote branch merged with 'git pull' while on branch master
    master
  Tracked remote branches
    master
    widget

As you can see, there’s no mention of what happens when you do a git pull whilst on the widget branch. You can rectify this by updating the .git/config file, either manually (through a text editor), or via the command line.

Before you do that, let’s take a look at what your config file looks like now.

$> cat .git/config
# Some information removed for clarity
[remote "origin"]
  url = ssh://shell_username@account_name.dreamhosters.com:git-repos/example_website
  fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
  remote = origin
  merge = refs/heads/master

The first block (in the above example, you’ll likely have some other information at the top of your config file) defines the remote repository that you’re tracking.

It gives it the short name origin, and then specifies the URL that should be associated with this short name. This saves you typing it in every time you want to perform a push or pull. I’ll skip over the fetch line in the interests of brevity.

The second block includes some important information about the master branch. Firstly, that it’s tracking the remote repository with the short name origin. Secondly, that performing a git pull whilst on the local master branch will merge the remote master branch (identified by refs/heads/master).

Again, we’re at risk delving deep into the bowels of Git here, which is not the intention with this series. The important point is that you need to create an information block in your .git/config file for the widget branch.

There are two ways of doing this: via the command line, and editing the config file manually. I’ll run through the former, and then show you the resultant changes to your config file.

$> git config branch.widget.remote 'origin'
$> git config branch.widget.merge 'refs/heads/widget'
$> cat .git/config
# Some information removed for clarity
[remote "origin"]
  url = ssh://shell_username@account_name.dreamhosters.com:git-repos/example_website
  fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
  remote = origin
  merge = refs/heads/master
[branch "widget"]
  remote = origin
  merge = refs/heads/widget

All being well, your config file will contain a new configuration block for the widget branch. Running git remote show origin again will confirm that your local widget branch is now tracking your remote widget branch.

$> git remote show origin
* remote origin
  URL: ssh://shell_username@account_name.dreamhosters.com:git-repos/example_website
  Remote branch merged with 'git pull' while on branch master
    master
  Remote branch merged with 'git pull' while on branch widget
    widget
  Tracked remote branches
    master
    widget

All is right in the world. Onwards!

Build the Widget-o-matic

Before you can work on the Widget-o-matic, you need to ensure that you’re working on the widget branch.

When you ran the git branch command a few moments ago, you may have noticed an asterisk next to the widget branch. This asterisk tells you which branch you’re currently working on. To work on a different branch, simply run git checkout.

$> git checkout master
$> git checkout widget

Now that you have your ducks in a row, it’s time to crack on with creating the Widget-o-matic. Create a readme file, with a description of exciting new feature, and add it to your local repository.

$> echo The Widget-o-matic is an automatic widget. >> widget_readme.txt
$> git add widget_readme.txt
$> git commit -m "Added widget readme file."

Running git status will inform you that you’re one commit ahead of origin/widget, so go ahead and push your changes to the remote repository.

$> git push

Thanks to your earlier config fiddling, you don’t need to specify the local or remote branches. Nice.

Finally, confirm that your new file is present in your working directory.

$> ls
example_file.txt    # Created in the previous installment
widget_readme.txt

Now for the exciting part. No, really.

Update the live site

Your hypothetical client now wants you to make a few changes to the live site. Not a problem. First, checkout the master branch.

$> git checkout master

Before continuing, list the files in the current directory again, and notice that widget_readme.txt has disappeared.

$> ls
example_file.txt

Git automatically updates the files and directory structure of your working copy, to reflect the currently-active branch. Told you it was exciting.

Create a new file in the master branch, and commit it as before.

$> echo Coming soon, the Widget-o-matic! >> latest_news.txt
$> git add latest_news.txt
$> git commit -m "Created latest news file."
$> git push

Once again, you’ll notice that git push automatically sends your updates to the appropriate remote repository branch.

The only problem is, the news on your widget branch is now out-of-date. Again, Git has the answer.

$> git rebase master widget

This writes any outstanding master commits to the widget branch, bringing it up to date with any changes made to the live site. It also switches you to the widget branch, so run a quick ls to confirm that latest_news.txt is present.

$> ls
example_file.txt
latest_news.txt
widget_readme.txt

Perfect.

Launch the Widget-o-matic

The time has come to launch the Widget-o-matic. To do so, you need to merge the changes on the widget branch into the master branch, and push them to the remote repository.

Before doing that, confirm that you don’t have any uncommitted changes in either the widget or master branches (git status will tell you what you need to know).

Once everything is current, you can proceed with the merge.

$> git checkout master
$> git merge widget
$> ls
example_file.txt
latest_news.txt
widget_readme.txt

Awesomeness. git push your changes to the remote repository, and you’re done.

Housekeeping

Now that the Widget-o-matic is launched, and part of the master branch, it makes sense to delete the obsolete widget branch. The simplest way to do this is by first deleting the remote branch, as follows.

$> git push origin :widget

Perhaps a little counter-intuitive at face value, but it has the desired effect. You can confirm that the remote branch has been deleted by running git branch -a.

$> git branch -a
* master
  widget
  origin/HEAD
  origin/master

Now that the remote branch has been deleted, you can delete your local widget branch.

$> git branch -d widget
$> git branch -a
* master
  origin/HEAD
  origin/master

Doing so also cleans up your config file.

$> cat .git/config
# Some information removed for clarity
[remote "origin"]
  url = ssh://shell_username@account_name.dreamhosters.com:git-repos/example_website
  fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
  remote = origin
  merge = refs/heads/master

Neat.

Conclusion

Those of you that skipped to the end, I understand completely, but your ingratitude makes me weep. Those of you that read this far, well done, and seek help.

The conscientious amongst you should now have a reasonable understanding of how to setup your Git working environment, how to create your local and remote Git repositories, and how to work with Git on a day-to-day basis.

There’s an awful lot to Git that I’ve deliberately shied away from covering in this series. If you have any questions or comments, I encourage you to join the discussion on the ExpressionEngine forums. Hopefully we can all learn something from each other.

Using Git to Manage an ExpressionEngine website : Creating Your Website

Stephen Lewis — 2009-07-17T21:27:10+00:00

This is the third in a series of posts about using Git to manage an ExpressionEngine website. If you’re new here, you may want to start at the beginning.

If you’ve been following along with parts one and two, you’ll now have Git installed on your local machine, a remote “repository” server (hosted by DreamHost, in the example provided), and a remote “live” server (hosted by MediaTemple, in the example provided).

This installment details the process of setting up your ExpressionEngine site as a Git repository. Note that in the following examples $> denotes the bash prompt, and should not be entered.

Step 1. Create your local Git repository

Open the Terminal, navigate to the directory where you’d like to create your new website, and enter the following:

$> mkdir example_website
$> cd example_website
$> git init

The creation of the new directory could just as easily have been accomplished via the Finder, it’s the last command that interests us. With that line you’ve created a new Git repository for your website.

Let’s have a quick nose around to see what just happened:

$> ls -a
.    ..    .git

Unlike Subversion, Git won’t pollute every directory on your website with hidden folders. Instead, everything is housed within a single .git directory, in the root of your working directory.

One of the many advantages to this arrangement is that it makes the process of updating EE a whole lot easier; no more accidentally deleting a bunch of hidden .svn folders, and screwing up your site’s version control.

Step 2. Ignore unwanted files

By default, Git will track every file or directory that finds its way into your working directory. You can control this behaviour by setting up “ignore” rules.

There are a number of different ways of setting up ignore rules, and the most appropriate choice typically depends on whether you always want to ignore particular files, or only wish to ignore them for a specific project.

For the purposes of this walkthrough, we’ll just use a simple .gitignore file, with a single rule telling Git to ignore .DS_Store files:

$> echo '.DS_Store' > .gitignore

Step 3. Create your remote Git repository

Open a new Terminal tab, and ssh into your DreamHost repository (the following command assumes you set up shell shortcuts, as described at the end of part two):

$> ssh dh

I keep all my Git repositories in a general git-repos directory, so let’s set that up:

$> mkdir git-repos
$> cd git-repos
$> mkdir example_website
$> cd example_website

You now have an example_website directory, ready to accommodate your new remote Git repository. This time though, you need to initialise a “bare” repository.

$> git --bare init

Git typically assumes you’ll be using a repository as your working directory. As such, a standard repository contains all of your project files, along with the aforementioned .git directory, which contains the bare repository files.

A remote repository isn’t interested in your working files, it just needs to know what’s changed, in order to keep track of everything. This is what “bare” means to Git — just the repository itself.

Step 4. Link your local repository to the remote repository

Switch back to your local repository Terminal tab, and enter the following (assuming you’re using DreamHost for you remote repository):

$> git remote add origin ssh://shell_username@account_name.dreamhosters.com/~/git-repos/example_website

This automatically adds some code to your local .git/config file, linking your local repository to your remote repository.

Step 5. Create your “live” Git repository

The “live” site should be a working copy of your remote Git repository. The file paths in the following instructions are specific to MediaTemple’s (dv) server — adapt them as required for your preferred host.

Open another tab in the Terminal, ssh into your live server, and navigate to the main website directory (not the HTTP documents directory):

$> ssh mt
$> cd /var/www/vhosts/example_website/

Clone your remote repository:

$> git clone ssh://shell_username@account_name.dreamhosters.com/~/git-repos/example_website

This creates a new directory, example_website, which become the main httpdocs directory for your website:

$> mv httpdocs httpdocs_old
$> mv example_website httpdocs

Step 6. Get your feet wet

The next installment will contain a more detail description of my Git / EE workflow. In the meantime, here’s something to whet your appetite.

The commands below perform the following actions, which will be typical of your day-to-day workflow:

Create a new file in your local working directory.
Add the file to your local Git repository.
Commit the file to your local Git repository, with a brief description of the work carried out.
Push the changes to the remote Git repository.
Pull the changes from the remote Git repository to the live site.

In your “local” tab, enter the following:

$> touch 'example_file.txt'
$> git status
# Untracked files:
.gitignore
example_file.txt
$> git commit -a -m "Created .gitignore file, and example_file.txt"
$> git push

Switch to your “live” tab, and pull the changes from the remote repository, to your live server:

$> git pull

Next time

Next time out I’ll be providing a proper explanation of the above workflow, with some more detailed examples of the everyday practicalities of using Git.

Iconic Interiors Shortlisted for “Top 10 Sites of 2008” Interactive Media Award

Stephen Lewis — 2009-06-11T11:59:43+00:00

A few months back, IconicInteriors.com — a site we designed and built — received a “Best in Class” Interactive Media Award. You may remember me bragging shamelessly about it.

Well, it turns out that the IMA judges liked the Iconic site so much that it’s on their “Top 10 sites of 2008” shortlist.

Now if we can just beat BMW, Porsche, Maserati (twice), Volkwagen, Amnesty International, the Worldwide Fund for Nature, the Smithsonian, and MSN, it’s in the bag.

Ah.

Using Git to Manage an ExpressionEngine website : Setting Everything Up

Stephen Lewis — 2009-06-09T17:52:38+00:00

This is the second in a series of posts about using Git to manage an ExpressionEngine website. If you’re new here, you may want to start at the beginning.

The first installment in this series was little more than an introduction. Now it’s time to get your hands dirty, setting up Git, and laying the groundwork for your day-to-day development tasks.

Before you get to the nitty-gritty, it’s worth taking a moment to review what exactly you’re working towards.

What you’re working towards

The setup described below is pretty simple, but can be easily expanded to accommodate more developers, or more “staging” servers.

Dealing, as it does, with the ins-and-outs of setting up your development environment, this will be the most implementation-specific article in this series. If you’re using a different operating system, or a different hosting company, you’ll most likely need to adapt a few of the step-by-step instructions accordingly.

At this stage, it’s also worth stating the obvious; that these instructions are presented as-is, without warranty or guarantee. We’re all grown-up boys and girls, and whilst these instructions worked (and continue to work) just fine for me, if you accidentally delete the internet whilst following them, it’s not my fault.

Caveats dispensed with, here’s what you’ll be setting up:

The local development environment is where all of the work gets done on a day-to-day basis. Each developer has his own local Git repository, enabling him to commit changes into source control quickly and easily, even when he’s offline. He can then periodically push whatever local changes he’s made to the “origin” repository.
The “origin” repository lives on a remote (DreamHost) server. Every other Git repository pushes and pulls to and from this repository.
The live site (and / or staging site) is another Git repository, living on a MediaTemple (dv) server. Updating the live site is simply a case of SSHing into the server, and pulling the latest code from the origin repository. A more seamless alternative would be to use Capistrano.

Laying the foundations

Before you can start pushing and pulling your code about the place, you need to get everything set up.

Step 1. Install Git on your local development machine

Provided you’re on a Mac, the first step is easy — you can either install Git via MacPorts, or download the Git OS X installer.

If you’re feeling particularly adventurous, there’s always the option to compile and install Git manually, but unless you have very specific requirements, it’s probably not worth the effort.

Windows users may find this useful.

Step 2. Install Git on DreamHost

In a piece of tremendous good fortune, it appears that DH now installs Git as standard on new hosting accounts. To confirm that you’re all set up and ready to go, SSH into your DH account, and run the following commands:

[server]$ which git
/usr/bin/git
[server]$ git --version
git version 1.5.6.5

If you’re one of the unlucky few not to have Git installed, the official DreamHost Wiki has detailed instructions for installing Git.

Step 3. Install Git on MediaTemple

After the effortless ease with which you glided through steps 1 and 2, you may be thinking now is a good time to kick back with a self-congratulatory cup of tea.

Not so fast.

Installing Git on a MediaTemple (dv) server actually requires a (little) bit of effort, and whilst the MT knowledgebase article is a good starter for 10, it doesn’t work quite as advertised.

MediaTemple recommends using Yum to manage the installation of software on your (dv) server, but unfortunately the knowledgebase guide to installing Yum falls a bit short, neglecting to mention a number of Yum’s dependencies.

This leads to lots of errors message, typically followed by loud and sustained cursing. Not to worry, you can benefit from my bitter experience by following the Yum installation instructions below:

Install the developer tools via your AccountCenter.
Log into your (dv) server using SSH:
ssh root@mydomain.com
Install Yum’s dependency files:
- rpm -Uvh http://mirror.centos.org/centos/5.2/os/i386/CentOS/python-iniparse-0.2.3-4.el5.noarch.rpm
- rpm -Uvh http://mirror.centos.org/centos/5.2/os/i386/CentOS/yum-metadata-parser-1.1.2-2.el5.i386.rpm
- rpm -Uvh http://mirror.centos.org/centos/5.2/os/i386/CentOS/python-elementtree-1.2.6-5.i386.rpm
- rpm -Uvh http://mirror.centos.org/centos/5.2/os/i386/CentOS/python-sqlite-1.1.7-1.2.1.i386.rpm
- rpm -Uvh http://mirror.centos.org/centos/5.2/os/i386/CentOS/rpm-python-4.4.2-48.el5.i386.rpm
- rpm -Uvh http://mirror.centos.org/centos/5.2/os/i386/CentOS/m2crypto-0.16-6.el5.2.i386.rpm
- rpm -Uvh http://mirror.centos.org/centos/5.2/os/i386/CentOS/python-urlgrabber-3.1.0-2.noarch.rpm
Install Yum:
rpm -Uvh http://mirror.centos.org/centos/5.2/os/i386/CentOS/yum-3.2.8-9.el5.centos.1.noarch.rpm

Once that’s done, you can return to MT’s standard Git installation instructions:

Install EPEL:
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm
And finally, install Git:
yum install git

Making life easy for yourself

At this point, you should have everything setup and ready to go. If you’ve had enough for one day, feel free to go and have that cup of tea now.

If you’re still bursting with Terminal energy, there are a couple of additional things you can do that will make your life at the command line at lot simpler.

Easier SSH

As you’re going to be doing a lot of SSHing between servers, it’s worth spending a few minutes setting up some SSH keys. Otherwise you’ll spend your life mistyping passwords in the Terminal.

Here’s how to setup an SSH key on your local development machine. Do this for each remote server that you want to access via SSH (DreamHost and MediaTemple, in this setup).

Open the Terminal. At the prompt, type:
ssh-keygen
Specify the file as ~/.ssh/key_name, where key_name is the name you wish to assign to this SSH key.
Enter a passphrase.
Copy the public key to your remote server:
scp ~/.ssh/key_name.pub username@remoteserver.com:./key_name.pub
Secure shell into the remote server using ssh username@remoteserver.com. You’ll still need to enter your password at this point.
At the prompt, type ls -l, to list all the files and directories in the current folder. If the .ssh directory already exists, cd .ssh into it, and skip to step 12.
Create the .ssh directory:
mkdir .ssh
Change the directory properties:
chmod 700 .ssh
Move to the .ssh directory:
cd .ssh
Create a new file:
touch authorized_keys
Change the file permissions:
chmod 600 authorized_keys
Add your public SSH key to the “authorized keys” file:
cat ../key_name.pub >> authorized_keys
Remove your public SSH key file:
rm ../key_name.pub
Exit the remote server:
exit
On your local machine enter:
ssh-add ~/.ssh/key_name

With that out the way, you can now log into your DreamHost or MediaTemple server using ssh username@remoteserver.com, without entering a password.

It’s also worth taking the time to set up an SSH key on MediaTemple, so you can easily log into your DreamHost server from your MediaTemple server. Here’s how to do that:

Log into your MediaTemple server as root:
ssh root@remoteserver.com
Follow the instructions above, substituting the file path in step 3 with:
/root/.ssh/key_name
Add the code from this MediaTemple knowledgebase article to your ~/.bash_profile file.

Even easier SSH

You can shave even more keystrokes off your day by adding SSH “aliases” to your config file. You can then log into your remote server by typing (for example) ssh dh, instead of the much less catchy ssh username@remoteserver.dreamhosters.com.

To achieve this state of keyboard Zen, add the following block of code to your ~/.ssh/config file, for each server you’re connecting to.

Host shortname
User username
HostName remoteserver.com
# You probably won't need to specify the port, so just omit the following line
Port 2222

Next time

After a suitable recovery period, the next installment will deal with the task of setting up your ExpressionEngine site as a Git repository. In the meantime, please join the discussion.

Using Git to Manage an ExpressionEngine website : Starting the Conversation

Stephen Lewis — 2009-06-02T17:03:48+00:00

Git has rapidly established itself as the version-control system of choice for ExpressionEngine add-on developers, and various EE developers (myself included) have also Tweeted about using Git to manage entire ExpressionEngine sites.

However, there’s only so much you can say in 140 characters, and I’ve yet to see a proper discussion about best practises for managing an ExpressionEngine site with Git.

This series of posts is my attempt to fill that gap, by documenting how I use Git to manage ExpressionEngine websites. My goal is to start a conversation on this topic, from which we can all (myself included) benefit.

With this in mind, I’ve started a thread on the ExpressionEngine forums, rather than opening comments for this (and subsequent) posts. This will hopefully encourage greater participation in the conversation, and will also serve as a useful resource for EE developers in the future.

What to expect

The information contained in the upcoming posts will be very specific to my current setup.

It will discuss how to install and use Git with the services I use (DreamHost to host the Git repository, and MediaTemple’s DV service for the live site), my standard workflow for setting up a new site in Git, and how I manage day-to-day site updates.

If you’re looking for a more general discussion about what Git is, or advice on how to install it on hosting company X’s servers, you won’t find it in the posts. You may, however, find the information you need in the ensuing conversations on the EE forums, so please don’t hesitate to ask the question.

In conclusion

It’s worth restating that my primary reason for writing these posts is to get the EE community talking, and sharing their knowledge. I freely admit to not knowing everything there is to know about Git, but I have — largely through trial and error — found something that works well for me and my business.

My hope is that these posts will help the complete novice get started, whilst also filling in the gaps in my own knowledge.

So please, head on over to the ExpressionEngine forums, and help me get the conversation started.

Labgruppen.com Bags an “Outstanding Achievement” Interactive Media Award

Stephen Lewis — 2009-05-12T13:12:34+00:00

You can tell work is busy when you bag an Interactive Media Award, and don’t get ‘round to mentioning it to anyone for a month.

Which is a roundabout way of announcing that Labgruppen.com — a site we designed, built, and continue to maintain — has received an “Outstanding Achievement” IMA.

It’s not our first IMA, but in many ways I’m more chuffed with it than the “Best in Class” award we got for IconicInteriors.com, at the end of last year.

For a start, Iconic was only a few months old when it received the award, whereas the Lab.gruppen site had been live for nearly a year by the time the IMA judges paid a visit.

As anyone who has developed a large content-managed website knows, a lot can go wrong in a year — especially on a site with thousands of members, and multiple administrators. The fact that Labgruppen.com still scored 98% in the cross-browser compatibility category is a testament both to the ExpressionEngine CMS, and the content authors at Lab.gruppen.

The other reason for being particularly pleased with this award is that Lab.gruppen is pretty much the perfect client.

We work with them week-in, week-out to incrementally improve their sites, ironing out niggling problems, and responding to user feedback. The to-do list is never-ending, but that’s OK; it means we’re learning, evolving, and improving, based on actual usage. That’s pretty exciting, and very uncommon.

An ongoing approach is the best (probably only) way to build a rich, usable site, with an enthusiastic user-base, and it’s a genuine pleasure to be involved with a client who understands this.

The other side-effect of this ongoing commitment is that you become strangely attached to the site in question.

Labgruppen.com certainly isn’t perfect, and I could rattle off a list of at least half-a-dozen things that bug me about it, or that I would do differently with the benefit of hindsight. It works well, though — very well in fact — and my fingerprints are all over every graphic, and every line of code.

Despite the fact that customer feedback and site stats had long-ago shown Labgruppen.com to be a success, it’s still nice to have it confirmed by a group of people with no involvement — or indeed interest — in the site.

Call me shallow and needy, but a bit of validation is nice once in a while.

The Lack of Enterprise Show

Stephen Lewis — 2009-05-07T17:23:48+00:00

The Enterprise Show’s promotional literature.

A few weeks ago I wandered into The Enterprise Show, and local initiative to encourage more people to go into business for themselves.

The advertising for this event was aimed squarely at the latent entrepreneur, with posters asking “ever dreamed of starting your own business?”, cartoon thought-bubble and all.

The tone was deliberately inspiring, implying that The Enterprise Show was the place to go for practical, hit-the-ground running advice.

The reality was sadly different. After surrendering all my personal details, I was afforded access to a soul-destroying event focusing entirely on the tedious legal and accounting minutae involved in running a business.

Granted, getting your legal and accounting ducks in a row is a necessary part of running a business, but it’s hardly the inspirational fillip that the marketing promised.

Living on borrowed time

Within two minutes of entering, the helpful “what is the health of your business” questionnaire had informed me that my fledgling enterprise was doomed to failure, unless I took immediate steps to develop a comprehensive business plan, and contact my bank about overdraft facilities.

Just for the record, I’ve been running this business for 3 years, never borrowed a penny, and am busier now than I’ve ever been.

Catering to the minority

The whole experience of attending The Enterprise Show was very much in-line with my previous encounters with the local Business Link branch (the Business Link website, on the other hand, is very useful).

In the Humberside region, if your business operates in an arena thick with red-tape — importing, exporting, or trading hazardous materials, for example — there’s a wealth of helpful information and advice available via Business Link.

The problem is, most entrepreneurs in this area aren’t international peddlers of kryptonite, they’re people hoping to start a small local business, providing a simple but valuable service or product to their customers.

Informing these budding CEOs that they can’t possibly succeed without a 40-page business plan spilling-over with financial projections and market research isn’t the best way to encourage fresh thinking, innovation, and growth in the local economy.

Keeping it simple

In the early days of my business, I wasted far too much time worrying about the legal and accounting side of things. With the benefit of hindsight, here’s what I consider to be the necessary steps to starting a simple service-based business similar to mine:

Evaluate the validity of your idea. No need for a massive business plan or comprehensive market research, just be honest with yourself. We all know deep-down if our idea is crap, the important thing is to admit it to yourself before you waste too much time or money on it.
Start small, so you can learn as you go (that’s part of the fun anyway), and don’t risk everything on an unproven idea (see point 1).
Find a solicitor via the Law Society website. Most will provide you with a free initial consultation, so take a couple of hours to meet with a few local firms, pick one that you feel comfortable working with, and give him some money to prepare your terms and conditions.
Find an accountant via the Institute of Chartered Accountants website, and sort out the best legal structure for your business. Once again, initial consultations are typically free, so you can shop around a bit to find a firm you’re happy doing business with.
Start doing the things that you got into business to do, and hopefully start making some money.

If things go well, there may well come a time when you need to worry about the bigger stuff. That time is not now.

Atebits’ Common-Sense Approach to Licensing

Stephen Lewis — 2009-04-22T00:04:13+00:00

Along with what seems like the entire Mac Twitterverse, I’ve just shelled out a few quid for Tweetie, the new Mac Twitter client from Atebits.

It would seem that Atebits’ talent for simplifying complex interactions extends way beyond the user interface, to the traditionally murky waters of software licenses.

They take a refreshingly common-sense approach, as explained in the confirmation email:

The rules are simple, you can use that license key for all your Twitter accounts on as many computers as you (personally) own. Unless you own like 1,000 computers in which case that’s just crazy.

If you don’t have a crazy number of computers, but you do you have any questions or just want to say hi, send an email to support@atebits.com.

The language is friendly and mature, treating the recipient (who just bought the app, let’s not forget) like a reasonable human being, and makes a refreshing change to swathes of “we know you’re just itching to steal our software” legalese.

An Alternative Approach to Password Confirmation

Stephen Lewis — 2009-04-16T12:00:03+00:00

I read an interesting article over at the Viget Labs website this morning, about the annoyances associated with the traditional “Password / Confirm Password” fields on sign-up forms.

The author, Kevin Vigneault, proposed several alternatives, one of which (the “Show Password” checkbox) is used in a number of Mac OS X applications. This got me thinking about a possible solution not mentioned by Kevin, which is the standard way the iPhone handles password input.

For those of you not familiar with the idea, the iPhone displays the last character entered for a couple of seconds, before it reverts to being the standard password “bullet”.

I’ve quickly knocked up a JavaScript-driven equivalent (below), using unobtrusive JavaScript to enhance a standard password / password confirm form. The password fields are hidden, and a standard text field is created on-the-fly, with a “keyup” event listener.

I haven’t tackled the task of writing the password back to the hidden fields, as this is more a proof of concept.

In keeping with the original article, it’s worth mentioning the pros and cons of this method:

Pros: visual confirmation of the information entered is provided, without displaying the full password.

Cons: “keyboard-starers” may never see the visual feedback.

If you have any comments or suggestions I’d love to hear them.

Kicking the Business Book Habit

Stephen Lewis — 2009-04-11T20:29:47+00:00

Until fairly recently, I was an avid reader of small-business books. The E-Myth Revisited, Duct Tape Marketing, The Four Hour Work Week, you name it — if it was about the process of running and growing a small business, it was required reading.

Now, I actively avoid reading such books.

It certainly wasn’t that I ran out of reading material — there’s a ridiculous backlog of them sitting on my bookshelves, waiting for their chance to educate me how best to run my business. Rather, I came to realise that I was reading instead of doing.

Reading about doing results in a very misplaced sense of progress. Reading 200 pages detailing exactly how to attract a never-ending stream of eager clients to your door can easily result in the assumption that this is pretty much a done-deal; all you have to do now is implement the recommendations, and you’ll be sorted.

For me at least, the “this has worked for thousands of small businesses” tone of most small-business books effectively trivialised the most important element — the doing.

By constantly devouring small-business books, I was forever postponing the implementation of the brilliant ideas contained within. I’d start of course, but would inevitably get distracted by the next book offering its own recommendations, which had worked wonders for thousands of small businesses.

Going cold turkey

When I finally acknowledged the blindingly obvious fact that I was involved in an elaborate cycle of procrastination, I did something “radical”; I put all the small-business books away (with the exception of 37signals’ “Getting Real”), tried my best to stop worrying about the future of my business, and went back to just doing what I enjoy.

No more attempts to create a predictable funnel of new business, no more educating my target market on the value of the services I offer. Just designing and coding for fun, because I’m a geek and that’s what I like doing.

This was towards the tail end of last year, just as the economy was going through the floor, and anybody with any sense was ramping up their marketing efforts. Not surprisingly, we had a couple of very quiet months.

Resisting temptation

Instead of rushing back to the books though, I continued doing what I love. I tidied up a few ExpressionEngine add-ons that I’d developed for internal use, and released them to the community for free. I also became more involved in the ExpressionEngine forums, simply because I had a bit more time on my hands.

This wasn’t part of a big marketing plan. There was no attempt to establish my expertise within a particular niche, or build a marketing list by offering something of value for free. It was just the natural thing to do.

And then something rather wonderful happened.

Other ExpressionEngine developers started downloading and using the add-ons I’d developed. They started leaving nice comments on the EE forums and Tweeting about them. Some pretty big companies (in my little world) even started plugging them.

I was, frankly, rather chuffed. There was still bugger all work coming in, but I didn’t even care at that point. It was just nice to get some positive feedback from my peers, and feel like I was contributing something — however small — to a product and community that I genuinely like.

And then, after a couple of months, something even more wonderful happened.

People started contacting me directly, offering me ExpressionEngine-specific jobs — everything from small custom add-ons, right through to full EE-driven websites — all on the back of the free add-ons I’d written and released for fun.

A few months on, and the majority of new work coming through the door can still be traced back to those add-ons. The best part is that I’m being paid to do something that I was doing for pleasure anyway.

So those business books are staying on the shelf. I’m going to continue doing what I enjoy, and see where it takes me, and my business. I recommend you do the same.

Experience Internet Blog

Using Git to Manage an ExpressionEngine Website : A Typical Git Workflow

The scenario

The solution

The workflow

Create the widget branch

Build the Widget-o-matic

Update the live site

Launch the Widget-o-matic

Housekeeping

Conclusion

Using Git to Manage an ExpressionEngine website : Creating Your Website

Step 1. Create your local Git repository

Step 2. Ignore unwanted files

Step 3. Create your remote Git repository

Step 4. Link your local repository to the remote repository

Step 5. Create your “live” Git repository

Step 6. Get your feet wet

Next time

Iconic Interiors Shortlisted for “Top 10 Sites of 2008” Interactive Media Award

Using Git to Manage an ExpressionEngine website : Setting Everything Up

What you’re working towards

Laying the foundations

Step 1. Install Git on your local development machine

Step 2. Install Git on DreamHost

Step 3. Install Git on MediaTemple

Making life easy for yourself

Easier SSH

Even easier SSH

Next time

Using Git to Manage an ExpressionEngine website : Starting the Conversation

What to expect

In conclusion

Labgruppen.com Bags an “Outstanding Achievement” Interactive Media Award

The Lack of Enterprise Show

Living on borrowed time

Catering to the minority

Keeping it simple

Atebits’ Common-Sense Approach to Licensing

An Alternative Approach to Password Confirmation

Kicking the Business Book Habit

Going cold turkey

Resisting temptation

Create the `widget` branch