I'm actually talking about social causes. Specifically technology companies and how we can help alleviate the problems our communities might face.

Any sufficiently advanced technology is indistinguishable from magic. Arthur C Clarke

We live in a golden era of personal technological marvels. There are things we take for granted now, such as mobile touch screen phones, instant global communication and GPS mapping. These would all seem like voodoo of the highest order to a person even 30 or 40 years ago.

If you are fortunate enough to live in the '1st' world, chances are you have at your fingertips more information than you could digest in a lifetime. 99% of your questions can be answered with no great sweat.

Most of this is facilitated by technical workers, companies and agencies. They build the websites and applications that disseminate the information you are after. They also build the browsers and the operating systems that run on your machine. They built and designed the machines too.

Agencies

The role of your typical web agency is the one I'd like to focus on here though.

Web agencies make a lot of money from essentially, producing brand driven websites for companies without the technical skills in house to do it themselves.

Firstly, there is nothing wrong with making money, that's not the message here at all.

However, making money isn't the be all and end all of any professional activity. We all need money but we also need more than that. For Nomad the 'more' in question was a sense of community, equality and ownership. We've worked for other people, guided by their philosophies, and whilst we took a lot from those experiences we felt it was time to take control of our own careers. 

Having decided on this course of action we started to look into our options regarding how our company should be set up. One option we came across was a cooperative. This seemed to satisfy all our criteria for how we would want to run our company, namely:

• Equality of ownership
• No employees, just members
• Transparency
• An awareness of the local community, and our place in it

These and more are encapsulated by the guiding principles cooperatives manage themselves by, the Rochdale Principles.

Locally speaking...

The last item on that list above is 'an awareness of the local community, and our place in it' or to take the relevant Rochdale principle: Concern for community

Now this can manifest itself in many ways, but the main way we've chosen to pursue it is by donating our skills to those who have the need of them but lack the resources to hire us.

Agencies, and agency workers as a whole, spend a lot of time playing with the next big thing and new technology. We focus inwards into our community a hell of a lot - sometimes I feel to ours and others detriment. Whilst this is a natural and required state of being for us, I think we can all afford to face outwards a little more.

Going back to my earlier Arthur C Clarke quote, one of the reasons that we focus inwards is (I think) that because of the nature of what we do and the fact that not many people outside of our community can understand it, it's just plain easier to be understood when talking to others who do understand.

The march of technology carries with it the capacity for enacting huge social change. A few large scale examples:

• The Khan Academy - mass education, on a global scale
• 38 Degrees - organising and prompting action on large, national issues
• For better or worse (mainly worse), the riots of 2011 in the UK were organised via social media sites such as Twitter

However it's not really on this scale that most agencies operate, even if they would like to. Luckily in order to make a change you don't need to operate on this scale or come up with the next big idea.

Remember, what is simple and routine for us can be eye opening and out of reach for those without the technical skills to do it themselves.

Lend a hand.

Without naming names or subject area, Nomad recently took on some work pro bono for a support group. They needed somewhere online for story sharing, discussion and information dissemination - basically a CMS controlled website with a forum. This wasn't a difficult thing for us at all, but it was completely unachievable for our client who did not have access to anyone with the technical expertise to help them.

A small amount of effort on our part has, we'd like to think, made a huge difference to them.

A lot of web agencies do similar work and I would bet that most, if not all, have been approached with a similar need and carried out the work at their own cost. However I think we all can, and should, do more than that.

To paraphrase John Donne, "No company is an island". We exist as part of our communities both physical and virtual and we are part of a shared ecosystem. We've seen what happens when companies leech from that system without putting back in. We need to be aware of our responsibilities back towards that system and act in harmony and cooperation with it. Rather than just worrying about the bottom line constantly.

So what would I have companies do? Well, to start with, just thinking about the possible ways in which they can make a difference locally would be a good start. There are all sorts of charities that operate on a local level that lack the organisation and resources that the larger national charities have, but have the same technological requirements. It's not just about charities though, it's about anyone who you can help and improve things for. Be it a charity, knitting circle or playgroup.

Remember, it needn't be and often isn't about the grand (technical) gesture. Sometimes it's as simple as a little bit of education - such as spending a morning chatting with them about Twitter and how it can help keep their group connected and informed.

Beyond that though I think the key thing would be for companies to codify their community focus. To incorporate this aspect into their actual identity. So rather than being something that is done ad-hoc whenever they think of it or have the spare resource, it's simply a part of what they do and who they are. Something they actively seek to do - a core principle that guides them.

We've committed to the Rochdale principles, and through them, to our community. We are still working out the exact mechanisms by which we want to give back, but that hasn't stopped us from making a start on things. We've got more than a few irons in this particular fire and hope to expand on these as time goes on to help raise a bit of awareness.

Thanks for reading this far, and I hope this has given you some food for though about what you and your company could do. As ever, if you have any comments, please send them to us via the form below.

echo preg_replace('/&([a-zA-Z])[^;]+;/', '\\1', htmlentities('ÊËÄÁâçñöòï'));

A tutorial on advanced JavaScript by John Resig, the original author of jQuery.

The smart people at Raspberry Pi have produced a cheap, credit card sized computer.

Scalectrix style race track using quantum locking. I kept looking for the wires!

An interesting take on micro payments and flattery. I think it will need a large uptake to work but I'd like to see it happen.

A talk on OpenGL performance by Tim Omernick from ngmoco.

There was a contest after Full Frontal to write a blog post about the conference and be in with a chance to win a couple of tickets for next year's event. The deadline was the end of November so I may have missed that… Full Frontal had an interesting line up and venue – the ever good Duke of Yorks cinema in Brighton who provided free coffee and pastry treats throughout the day. Fruit was provided by Prem at Dharma Fly which is a nice touch for a conference of geeks. Prem also hosts the fortnightly AsyncJS meet up, which is worth checking out if you're ever in Brighton.

I'm not going to go into too much detail about every talk, there is a speaker line up and schedule available which outlines the talks, so I'll just go over the highlights for me.

CoffeeScript Design Decisions

by Jeremy Ashkenas

CoffeeScript is a language which can be "compiled" to JavaScript and is intended to hide JavaScript's warts. I've been aware of the language for some time but have never experimented with it as it seems like a bit of a novelty. I already know JavaScript, so why would I learn another language to write JavaScript for me?

Jeremy's talk really opened my eyes to what the language has to offer. It's heavily Ruby influenced with the same "everything is an expression" philosophy, meaning what would be a statement in most languages (e.g. if/else try/catch etc) would be an expression which returns a value in CoffeeScript. There are some very nice features, such as list comprehensions and splats, which would save a tonne of typing. Unfortunately, while I feel I now "get" CoffeeScript, I still don't think I'd use it. What I'd love to see is CoffeeScript used as an independent scripting language outside the browser à la Perl or Python.

Web Based Code Editors

There were two talks in this series, the first by Marijn Haverbeke who built CodeMirror, the second by Rik Arends the CTO of Cloud9 IDE.

Marijn talked about the technical difficulties of implementing a code editor in HTML and JavaScript and his various attempts moving from an IFRAME with designMode = "On" to the contentEditable attribute to finally faking it by building his own caret and text insertion methods. The talk went in to a lot of detail concerning the pitfalls and performance issues involved with creating this kind of system. I would honestly rather see something like CodeMirror built into a CMS than TinyMCE at the moment.

Rik showed us a demo of the recently released Cloud9 IDE. This is something else I've come across recently, but haven't really had a chance to delve too deeply into. As web developers we're pushing more and more types of software online in some form or another. Except for IDE's. We tell people the web / cloud (if you prefer) is the place that all software should live but we don't practice what we preach. Cloud9 are changing that! The editor itself looks pretty sweet plus they're now adding in git and github integration to complete the service.

Beyond the Page

by Glenn Jones

Glenn Jones is a developer based in Brighton and founder of Madgex, a provider of job boards. He showed us a combination of browser innovation and semantic web niceties with web intents included. He showed us a couple of demos, including dragging semantically marked up contact info between Chrome and Firefox. When the data packet lands on the second browser it automatically parsed the content and searched for related info about that contact. Very impressive and well worth checking out his Ident Engine.

All in all Full Frontal was a fantastic day.

I noticed with interest earlier this month the news that Berg (Design consultancy) have announced the impending availability of their Little Printer – a small newpaper printer for use in the home. It's going to be based on their Berg Cloud – a system for controlling (smart) products from the Internet.

This is just the latest in a line of products and ideas which are acting as vectors for making the Internet less about chunks of data, and more about how things interact. Where the paradigm was predominately computer and desk based, the advent of mobile technology has gotten people used to having the Internet with them all the time. You hardly hear anyone ask "Are you online?" anymore – the assumption being that everyone is.

What specifically interests me is the fact that everyday objects are becoming more aware. It used to be that the example trotted out at this stage would be a fridge that was "Internet aware" and could order milk before you run out. Whilst these undoubtably exist, they aren't really the level of object that is subtly leading the way. Things like the little printer won't even register as Internet aware for most people – they are just things that perform a function. The Internet is fast becoming less important in people's perception – the same as people don't think about the gas infrastructure or the sewer system. It's just a hidden layer of complexity that provides them services.

We've already seen this merging of the Internet with the everyday with QR codes, which are now used as hyperlinks between offline and online content.

Bruce Stirling, the author, coined the term Spime to describe an object that:

... can be tracked through space and time throughout the lifetime of the object Bruce Stirling

We aren't far off. Adidas have recently released a football shoe for amateur players called the Adizero which features their miCoach technology – which is an update on the Nike+ tracking chip, but the miCoach provides data on a wide range of metrics such as average speed, maximum speed, number of sprints, distance at high intensity levels, steps and stride all via its built in 3D accelerometer.

If you couple this movement towards ubiquitous Internet and more aware objects with the growing number of open source hobbyist electronics and manufacturering projects, such as Arduino and Makerbot, then we are moving towards a very exciting period.

Hopefully the coming year will see both an increase in the number of smart home products and an acceleration of pace of development of new and interesting ideas. Additionally, a bit of spare time so I can hack around with a few of these things wouldn't go amiss :)

function uniqueId(len) {
	var tokens = "abcdefghijklmnopqrstuvwxyz0123456789".split("");
	var id = "";

	for(var i = 0; i < len; i++)
		id += tokens[Math.floor(Math.random() * tokens.length)];

	return id;
}

Oh and it really needs to look the same in IE6. That's ok right?Your client

We've all been there, you've built a gorgeous website, using the latest CSS techniques, it looks perfect in Safari, Chrome, Opera, FireFox and Internet Explorer 9. You're awesome!

Then the client says, "It doesn't work on Sally's computer." You know what that means, you can sense it. You ask what browser Sally is using. IE6 wasn't agreed at the start. "But Sally has to sign it off and it doesn't work". So you fire up IE6, shaking fingers slowly punching in the url. You hit return.

You turn your face to the sky and yell obscenities at whatever deity you do or don't believe in and resign yourself to the headache of figuring out just how IE6 has broken your baby.

How do you avoid this issue? I'm going to give you a comprehensive run down on how to build in such a way that IE6 issues should be minimal.

Is IE6 really a requirement?

As a technical company, the sites we usually build come to us with a design completed and a brief written. While this makes processes easier for us, we prefer being involved in the planning of work. As a designer / developer who is involved at the start you can more easily manage client expectation and judge client needs.

You can take the approach of Andy Clarke. His universal stylesheet for IE6 is a great idea, if your client is happy with that. So far we haven't found a client who is.

The reality is, the only people really still using IE6 are corporations who had in-house apps built ten years ago. It would cost these companies lots and lots to get everything updated in terms of hardware updates, software licenses and man hours. It's a tough cost for them to justify when the system still works.

If your client has their own clients and they are of this corporate ilk, then it's probably best for your client that you do support IE6, on the other hand, if they run a blog about Guinea Pigs then chances are they don't need IE6.

As for us.

We put our browser support restrictions in our contract, it states that we will build for the latest generation of browsers and that that is all that is included in the quotation. If they want IE6 support it will be extra. Nine times out of ten, they do not ask for IE6 support.

Testing in IE6.

So how do you get your hands on IE6 to test? Chances are if your computer (or OS) is less than 5 years old it will not have shipped with IE6 on it (IE7 shipped in 2006). Well you could uninstall your current version of IE and install IE6 if you are on windows XP. But if that sounds like a good idea, you are probably ready to be carted off by those men in white coats.

You could test using a browser site such as the ones found in this search, however in my experience these are really slow and your site needs to be visible to them. If you are building on a local setup, you'll have to upload somewhere in order to see the results.

You could get one of the programs that are out there such as IETester. In my experience these programs are buggy, and inconsistant with what they display. I don't trust them to give accurate results, if you do, they are a good way to test all the versions of IE easily.

The way I test is to use a Virtual Machine (VM).

For those that don't know VM software allows you to run another operating system inside of your own. So I can run Windows XP in a window on my Windows 7 system.

These are available for all operating systems. At Nomad we have the following preferences.

• Windows : Microsoft Virtual PC
• Mac : Vmware Fusion
• Linux : Virtual box

Then you need a virtual hard drive to load into the virtual machine, luckily Microsoft provide this for us. (for windows at least – Google will more than likely provide resources for other OS's)

http://www.microsoft.com/download/en/details.aspx?id=11575

Now you can load your virtual HD into the VM software and test with IE6 to your heart's content.

Building for an easier IE6 experience.

There are plenty of ways to make the IE6 experience easier. I don't really like to use hacks in our CSS. Also we like to keep HTTP requests to a minimum where we can.

To this end I use this technique from Paul Irish to add a class to the HTML tag if the browser is an older version of IE than IE7.

<!--[if lt IE 7]> <html class="ie6" lang="en"> <![endif]-->

Then I prefix any styles that I need to overwrite at the bottom of my main stylesheet.

For example.

body p {
   color:#333;
   font-size:100%;
}

//All my other styles

.ie6 body p {
   color:red;
}

Embracing HTML5 is great and there are a couple of scripts / shivs out there that will make the experience almost the same in IE6.

The ones I include off the bat in every build are.

Remy Sharp's "shim" that makes IE6 recognise the new elements in HTML5. You could do this yourself by creating the elements in the DOM, but since Mr Sharp was kind enough to go to the trouble for us, why repeat his effort? (Thank you Remy!).

Then I like to add selectivizr. This allows you to use advanced CSS selectors such as :nth-of-type in the older wonkier versions of IE. It can be used with various libraries including jQuery, but the one that provides the most selector support is DOMAssistant. I don't mind including that for IE6 given the benefit of the wider array of available selectors and the cleanliness of the HTML it leads to. Plus we just saved an HTTP request with our css.

Here is the code snippet that I use to include all of this.

<!--[if lt IE 9]>
<script type="text/javascript" src="http://html5shim.googlecode.com/svn/trunk/html5.js""></script
><![endif]-->

<!--[if lte IE 8]>
<script type="text/javascript" src="/assets/js/DOMAssistantCompressed-2.8.js"></script>
<script type="text/javascript" src="/assets/js/selectivizr.min.js"></script>
<![endif]--> 

Additionally I usually use a reset stylesheet, or a normalise stylesheet and CSS PIE which lets IE6 handle some of the shiny css3 that we love.

Debugging.

So hopefully now you can build and test in IE6, what happens when you open it and something is still broken?

I would always recommend having IE6 open as you build and every now and then check it. At least check it once you have your structures built, it's usually here that I find IE falls down, on layout, not on actual styling.

Your first stop should be your HTML, IE6 does not handle a missed closing tag anywhere near as gracefully as modern browsers do. If your layout explodes and you have used the scripts above, I would almost guarantee that a missed closing tag is the cause.

Beyond that my testing process usually goes as follows if it's a layout issue.

• Note the styles that are applied to the element.
• Remove the Margin and Padding – Did this fix the break? If it did then add them back in and tweak the values and width to get the result you need.
• If it didn't, add different horrific background colours (MAGENTA!) to the container and any children to better see where the elements lie. Some people use borders, however if you are on a tight space build, the 2px of width added by the border can hide that a problem is fixed.
• Tweak layout and width of elements until fixed.

Building in IE6 doesn't have to be a huge pain anymore, while I don't believe we should be shouting about how easy IE6 is to support (because it isn't) I believe that if the client needs IE6 to be supported, then that's part of our job as professionals to do that. You can manage expectations by telling them it's a 10 year old browser that was never built to handle modern coding and charge extra for the additional effort.

Hopefully this post will be useful to you, if you have any stories of IE6 being a pain, or if you use any techniques to make developing in IE6 eaiser, please share in the comments.

This one is going to be short and sweet. We're going to create our first local Git repository (repo).

Fire up your Terminal and go to the directory you wish to use as your repo. In this case I've create a directory called 'my_project'.

cd ~/Sites/my_project

Now we're located in the directory we wish to use as our repo, lets go ahead and create it:

git init

And that's it, you should have recieved the following:

Initialized empty Git repository in /Users/macbook-pro/Sites/my_project/.git/

So, we now have our new empty repo. So lets add a few files to it. Firstly, create some files:

touch index.html
mkdir css
touch css/screen.css
mkdir js

We've created an index.html at the root of our repository, and a new directory for our stylesheets, with a single file in there called screen.css, we've also created an empty directory for any future javascript we may need to add.

Lets go ahead and add all of that to our repository:

git add *

We're using a wildcard (*) to add everything to the repo here, but you could have quite easily added each file individually. Lets run a status to see what we've got:

git status

Should return:

# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: css/screen.css
# new file: index.html
#


We can see what files are going to be committed. At this point we refer to the files as being 'staged', in that they'll be committed at our next commit. In Git, we stage, and then commit, as opposed to SVN's straight commit.

Also notice that there's no mention of our 'js' directory in the commit. This is because Git tracks files, and not directories. In this instance, if you want to include the empty directory into the commit, you could do this little trick:

touch js/.gitignore

This will create a Git Ignore file, informing Git of which files to ignore, and more importantly NOT ignore in this case. Open, up the .gitignore file with your favourite text editor, and enter the following:

!.gitignore

We're telling Git to NOT ignore it's own 'ignore' file in a roundabout way. So, now run another status check:

git status

# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached ..." to unstage)
#
# new file: css/screen.css
# new file: index.html
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# js/


And you'll see the empty directory has now been added to the repository (strictly speaking, it hasn't, but the ignore file has).

Before we commit we need to stage the 'js' directory and its contents:

git add js

Now all our files are staged, we can go ahead and commit:

git commit -m "Initial commit"

If you've used SVN before, you'll see how familiar this is. We use the '-m' flag to tell Git we'll be adding a message to the commit which will show in the repositories history log. Running this command should show the following:

[master (root-commit) 89a7059] Initial commit
1 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 css/screen.css
create mode 100644 index.html
create mode 100644 js/.gitignore


And there you have it, your first commit. If you run a status check again you can confirm everything has been added successfully:

git status

# On branch master nothing to commit (working directory clean)

Next instalment will explain how to set up a remote repository and link our local to our remote.

Everyone who uses the internet is familiar with spam and the problems it causes. Most people's familiarity is through its intrusion on email, but since running the Nomad site we've had to deal with a lot of comment spam. It goes in phases but we receive something like 10 to 20 spam comments per week all of which get flagged so don't appear on the site.

Our initial strategy was to delete spam comments as they appear. A notification email is sent whenever a comment is posted and while working I'm never too far away from a computer so spam comments wouldn't appear for too long on the site. Of course, having to delete spam comments quickly became tedious!

There are a number of common methods for blocking spam comments — forcing the user to register with the site, hiding comments until approved by a moderator, CAPTCHA images, etc. Whatever method I decided on I knew it had to require as little thought from the end user as possible. I don't want to stop the few legitimate comments I am getting in my effort to stop spam.

That cuts registration from my available options and, I would argue, CAPTCHA. While CAPTCHA is becoming more familiar to internet users and a lot of good work is being done by reCAPTCHA it's still an impediment to the commenter. This leaves comment moderation, but that feels too close to my current system.

After some research I came across honey pots as a security concept and found a lot of information in the article Stopping spambots with hashes and honeypots by Ned Batchelder. Using programming cunning to prevent spam is a bit more like it! I decided to try implementing the ideas outlined in the article one at a time, starting with a honey pot.

The honey pot idea is very simple: provide something enticing for the spambot but hide it from the user. Spambots vary in their sophistication but most operate by trying to fill relevant information into the form e.g. a field named 'email' will be filled with an email address. Hidden fields are left untouched as these often contain information vital to the form submission. The trick to the honey pot is that spambots will fill in all text fields.

With this in mind I created an additional text field in the comment form with the name of 'lastname'. It's randomly inserted into the form each time it is generated and removed from display by using CSS absolute positioning within the stylesheet. As far as a spambot is aware the field is there on the page — you can see it by viewing the source code — but doesn't appear to the end user. If the field is filled in when the form is submitted the comment is flagged as spam and not displayed on the site. I can then delete or allow the comment as I see fit. My only concern with this method is accessibility: screen readers will probably display the field. Currently the field is labelled 'Input not required' which I hope is enough to stop legitimate users from filling it in.

Over the past 3 months this technique has worked incredibly well: I've had a 100% success rate so far.

This article was originally posted at we-evolve.co.uk on 1st November 2009.

Nice little CSS3 hover effect for carousel buttons.

Responsive images without Javascript - not really very practical but an interesting hack none the less.

Nice tool for testing responsive sites - just don't look at ours, responsive build in the pipeline!

An excellent video on quantum locking. and some info on how it works.

Android device fragmentation.

Any Java related examples should be taken with a pinch of salt as I haven't done any in about 10 years and I'm sure the language has moved on since then.

Oh and I assume you know how to programme already, so no beginners stuff here.

Classes

(I'll skip quickly through this as you probably know it)

Classes are a template for creating objects. They define properties (values, variables) and methods (functions, actions).

In C#:

public class MyClass {
	public string MyProperty = "";

	// constructor
	public MyClass() {

	}

	// destructor
	public ~MyClass() {

	}

	public void MyMethod() {
		// ...
	}
}

And creating an instance of that class in original C# syntax:

MyObject o = new MyObject();

Since version 3 of C# you can do:

var o = new MyObject();

This is a syntactic nicety which cuts down on a bit of typing. In PHP this would be:

class MyClass {
	public $myProperty = "";

	# constructor
	public function __construct() {

	}

	# destructor
	public function __destruct() {

	}

	public function myMethod() {
		# ...
	}
}

$o = new MyClass();

Constructors and destructors are special methods which are called when an instance of the object is created or destroyed. The constructor is what you're calling when you do new MyObject(), desctructors are generally called behind the scenes rather than directly. So if you do:

var o = new MyObject();

o.MyMethod();
o = null;

The destructor will be called some time after the o = null part. In C# / .Net this is when the garbage collector kicks in, in PHP it's generally when the script finishes running.

Access Modifiers

The keywords public, protected and private can be assigned to methods, properties and classes.

Public

Anyone can call that method on the object (e.g. o.MyMethod() or $o->myMethod() in PHP).

Private

Only that instance of the class can call the method or access the property. It's completely inaccessible outside of itself.

Protected

That instance of the class can access the method or property, inheriting classes can access the method or property and other instances of that class can make use of the property or method.

e.g.

public class MyClass {
	// ... snip ...

	// the "MyClass o" part means only objects which are of the type MyClass
	// can be passed to this method
	public void MyMethod(MyClass o) {
		o.MyOtherMethod()
	}

	protected void MyOtherMethod(MyClass o) {
		// ...
		// could call o.MyOtherMethod here as they're both instances of MyClass
	}
}

Inheritance, Encapsulation and Composition

Classes can inherit from other classes, which means they get to use all public and protected methods of the parent class. Inheritance can go any number of levels deep, but it's generally a good idea to not go too deep as changes in a base class can have a knock on effect further down the inheritance chain.

One of the key concepts of OO programming is code-reuse and this is covered by inheritance and partially by encapsulation and composition.

A class has access to all public and protected methods and properties of its parent classes. So...

public class Controller {
	// in C# you have to declare the type of a property
	// i.e. the class it's going to be
	// in PHP you don't need to so this line would be "protected $model;"
	protected Model model;

	// ... snip ...

	private void ValidateModel() {
		// do something with model
	}

	// in C# you need to define the return type (class) of all methods
	// in PHP you don't need to so this line would be "protected function render()"
	protected string Render() {
		// generate template from view
		var view = new View();

		ValidateModel();

		return view.RenderTemplate(model);
	}
}

// the colon in C# signifies inheritance, in PHP / Java you would use the extends keyword
public class ArticleController: Controller {
	public string Index() {
		// create a new instance of the protected Model class
		model = new Model();

		// ... snip ... load up a list of articles and add stuff to model

		// call the protected Render method from the Controller class
		return Render();
	}
}

(in PHP the class declaration would be: class ArticleController extends controller {})

Usage would be:

var articles = new ArticleController();

articles.Index();

There are a few important things going on here.

The ArticleController class inherits from Controller and gets to use its protected Render method and its protected model property. It doesn't get direct access to the private method but that method is still called when the Render method is called.

A class should have one area of expertise and should only know about the minimum stuff it needs to know. It should expose as little of itself as possible. This is especially true of properties but also applies to methods. We wouldn't want external code to do something like:

articles.Model = new Model();

This could create all sorts of havoc with our class! This is known as encapsulation, and basically means keep yourself to yourself.

A class should have one area of expertise so in this example it would be wrong to add a ConnectToDatabase method to either Controller or ArticleController. It wouldn't be wrong for ArticleController to create an instance of a Database class and make use of that. This is known as composition. The idea being you compose one class from other classes, so you create more intricate functionality from smaller parts. You can see this within the Render method – Controller is making use of the RenderTemplate method of the View class.

The reason we build up class functionality from smaller classes is to allow reuse and to allow the code to be changed easily. If you need to render a template outside of the Controller class you can by creating your own instance of the View class. If the Controller handled the template rendering itself we'd be kind of stuck. If we want to allow a different template rendering we can create a specialised version of the view class and change Controller to allow a different View to be created. This would be simpler than rewriting the Controller class with a different type of rendering method or even many rendering methods.

The one area of expertise thing also applies to inheritance. A class should extend the functionality of its parent class. The ArticleController to Controller inheritance works because ArticleController is a more specialised version of Controller. It would be wrong for Controller to inherit from Database as a Controller isn't a specialised version of a Database.

The classic example of this is a car. You can have a Car class, which all have similar properties (number of wheels, number of doors) and there are many different types of car (instances) some of which are better (inheritance) than a basic car. But core parts of a car (e.g. engine) are built up using composition, because you wouldn't want to go to the trouble of building an engine and then find you can only use it one type of car.

Abstract Classes

Abstract classes (and interfaces) took me a while to get my head round but really come into their own when we start talking about polymorphism (up next!).

Abstract classes are classes which you can't create an instance of. They let you define a whole load of functionality that you know is going to be reused but not necessarily define all of it. The way I always think of it is with humans and animals. Humans are quite similar to apes and reasonably similar to dogs and cats. We all breathe in the same way but we walk and talk in a very different manner. So we all share a base class of Mammal but it doesn't make sense to create an instance of a Mammal (what the hell would that be?!?). So...

public abstract class Mammal {
	public void Breathe() {
		// do complicated stuff with lungs and ribs and whatnot
	}

	public void See() {

	}

	// let inheriting classes deal with these
	public abstract void Walk();

	public abstract void Talk();
}

It doesn't make sense to create an instance of a Mammal class but it does make sense to inherit from Mammal and create a Dog class or a Human class. You get all of the functionality of the Breathe method but are free to implement the Walk and Talk methods however you choose.

Inheriting classes must implement the abstract methods, unless they're also declared abstract. So you could create an abstract FourLeggedMammal class which implements Walk and then have Dog and Cat classes which implement Talk independently.

Again, the general rule of inheriting classes being specialised versions of their base classes applies.

Interfaces

Interfaces are a little different. An interface defines a contract that implementing classes must adhere to but doesn't define any functionality. Essentially they're just a list of method / property names. The other difference is you can implement multiple interfaces whereas in most OO languages you can only directly inherit from one parent class.

While an interface isn't related to a UI, a UI can be a good example of how an interface works. If you think of a cash machine they all provide roughly similar interfaces – somewhere to put your card, a keypad, and a money dispenser. No-one cares what happens behind the scenes (it could be monkeys pushing money through the slot or steam powered or maybe someone is behind their painting each note) as long they get their money.

A programming interface is the same – it says do this, I don't care how. The syntax for an interface in C# (identical in Java, almost identical in PHP) is:

public interface IDataReader {
	string Read(); // reads something from somewhere and returns it as a string.
}

It's a common (but not universal) practice to always start interface names with an I. In C# the syntax for implementing an interface is the same as for inheritance. In PHP / Java you use the implements keyword, which I find is a bit clearer, to be honest, especially when you're inheriting from something and implementing an interface at the same time. Compare:

class MyClass: BaseClass, ISomeInterface, IAnotherInterface {}
class MyClass extends BaseClass implements ISomeInterface, IAnotherInterface {}

I originally thought interfaces were a complete waste of time. Why would you go to the trouble of defining a whole load of method names with no functionality? Madness!

Strong vs Weak Typing

In PHP it's perfectly acceptable to do the following (although probably not a good practice):

$x = new MyObject();

# ... snip ...

$x = 6;

# ... snip ...

$x = "Hello";

This is because PHP is a weak (or loosely) typed language. A variable can have any type and is assigned a new type based on its current value. C# and Java are strongly (or strictly) typed. Once a value has been assigned to a variable it can change value but the type of the value must be the same. So the above code rewritten in C# would cause compile errors.

In Java to create an instance of an object you have to do:

MyObject x = new MyObject(); // notice this looks exactly like the original C# form

You declare the type of the object, then the variable name, then you call the constructor. C# introduced something called inferred type which means if the compiler can figure out the type it will. This saves on actual typing with the keys. It looks like:

var x = new MyObject();

You can still use the longer form in C# if you want and sometimes it can be useful to do so, e.g.

var x = this.MethodWhichReturnsSomeType();

Types also need to be declared when you're passing parameters to methods and as return types from methods. In C# when you do:

public bool MyMethod(string s)

You're saying the method must be passed a string and will always return a boolean value. If you had:

public void MyMethod(string s)

Then the method will never return a value.

In PHP you can't specify the return type and you don't have to specify the parameter type. In PHP5 you can specify the parameter type if you want, e.g.

public function myMethod(MyClass o)

You can't specify the parameter type if you want it to be a string, bool, array or number in PHP. It's for classes only.

The pros and cons of strong vs. loose typing is a whole long winded discussion in itself. Strong typing protects you against things like x = "6" when you mean x = 6 but sometimes it can feel like you're fighting against the type system.

Polymorphism

This is where it becomes a head fuck.

Polymorphism means any object can be treated as its own type (the class it's created from), or as the same type of any classes it inherits from, or as the same type as any interface it implements.

That's a horribly convoluted sentence but what it means is if you have a method which accepts a Controller instance as a parameter you could use an ArticleController (or a BlogPostController or a FormController etc.) in its place.

Going back to the Controller example and its Render method, lets tweak the class a little:

public class Controller {
	protected Model model;
	protected IView view;

	// ... snip ...

	protected string Render() {
		// view is now created somewhere else, probably in an inheriting class

		ValidateModel();

		return view.RenderTemplate(model);
	}
}

Where IView is the interface:

public interface IView {
	string RenderTemplate(Model model);
}

We may have an HTMLView class which implements IView or a PDFView which does the same. Both have radically different ways of rendering a template and radically different implementations of the RenderTemplate method. They probably also have way more methods than just RenderTemplate but as far as the Controller Render method is concerned it's dealing with an IView and it can only make use of the RenderTemplate method.

(this example is becoming a bit contrived as there's probably a lot of shared functionality between something which renders to HTML and something which renders to PDF, I'd probably have some sort of abstract base class which both HTMLView and PDFView inherit from...)

This also applies to inherited classes and abstract base classes. In our earlier Mammal example with the shared Breathe method and the abstract Walk and Talk methods, anywhere an instance of a Mammal is expected an instance of a Human, Ape, Cat, Dog or Sheep could be used.

Say, we had a method on another class which involved walking in some form:

public void DoWalk(Mammal mammal) {
	mammal.Walk();
}

We could pass anything which inherits from Mammal into that method and it would work fine. As far as that method is concerned it's got a Mammal, whether that mammal is a cat or dog or whatever.

What if we also had a Crab class which has a Walk method? I'm not sure what a Crab is but it's not a Mammal (some sort of bug?). We currently can't pass a Crab instance to the DoWalk method even though it's perfectly capable of walking. This is where interfaces are incredibly powerful. We could have an interface such as:

public interface ICritter {
	void Walk();
}

And change Mammal to implement this interface, which Crab can also implement. Now if we change our method to:

public void DoWalk(ICritter critter) {
	critter.Walk();
}

The method can now be passed a Crab or a Sheep instance and it will still work, even though they don't have a shared base class. It also means if we change the inheritance structure at some point (maybe Sheep aren't Mammals either) or add new classes (a Robot class) we can still pass them to the DoWalk method because they can all implement the ICritter interface without messing with their inheritance tree.

That's quite a sizable topic and it took me a while to properly understand the power behind it so if you have any questions, let me know.

Those really are the core concepts behind OO programming:

Inheritance, encapsulation and polymorphism.

Agencies

After education, which I dealt with in the previous post, it is my personal belief that the other thing that is wrong with our industry are the agencies themselves.

Specifically the main issues with them are they are too big, too bloated and about as maneuverable as a blimp in high winds.

Too big

Agencies come in all shapes and sizes, but the big boys are big. Some can be very big indeed. With size comes overhead - be it the nice big office space or the added layer of administration people to help run the company. A large company like this is still easily able to be successful (loads do it) but often an agency is built from humble beginnings, and the people running it aren't necessarily interested in the processes required at this larger stage in their development. You can't just keep hiring people, pretending you are still a small company with big aspirations - you need to change and modify your working practices to accomodate what you have become.

Failure to do this leads to...

Too bloated

The agency isn't small anymore, it's started employing more and more people - particularly in areas which are needed but aren't directly chargeable to a client. Additionally these people are just employees and pull a salary from you. Most are brilliant, some are good, and a few are... unmotivated and "jobbing it". They are all a cost, and whilst they help you day to day and you can't do without them, you also don't have the time to monitor them too closely. You don't have an appraisal process either, you grew too quickly, so you have no metrics for how individuals are doing in your agency.

People can't be expected to give you 100% every day, but how do you know they are giving even 70%? or 50%? What if you do notice that person A isn't really invested in ongoing collective success? How do you deal with that person?

What happens if they just aren't doing a good job? You haven't measured this, so you can't arbitrarily decide to get rid of them - they'll take you to a tribunal. How do you deal with this situation?

Not agile

Meanwhile, your production chain is longer. It's no longer a designer/developer talking to a client, it's a designer talking to a project manager, who together with account management are talking to your client. You are getting people to write specifications for quoting in order to ensure jobs are done correctly, but the client is changing their minds constantly - and they are a huge brand and potentially very lucrative, so you suck it up and ignore the proper workflow.

Meanwhile, because of your new size, you need bigger and bigger jobs to hit your targets - the flip side being that if all jobs are bigger, they will all have a bigger impact when they disappear or go wrong. Some inevitably will.

Sigh

It's a bleak picture, and admittedly the above is an anecdotal almalgamation of the worst stories I've heard, but it's also remarkably common. The bigger an agency gets, the longer the days and the greater the internal expectation. Staff will chop and change between agencies, and the new job for a while tricks them into thinking things are going to be different, but mainly they've just shifted the issue. The people at the top are still stressed, and everyone is overworked.

The alternative

The alternative, and I can see this already happening around us, is to fracture. More and more people are starting smaller, specialised agencies which act in a modular fashion. Coming together for the bigger projects as required. This has many benefits, from being plainly more flexible and agile to keeping costs down, to improved motivation in their workers.

For clients there is little that is problematic with this approach. They would have only been using a portion of a larger agency anyway. It's cheaper this way (of particular importance at the moment) and they have direct access to the people doing the actual work. This can only be beneficial, especially in the early stages of the project where a clear understanding of the goals is key. It's just as key to run projects properly, but the discussion and specification can go a lot smoother with a clear line of communication.

For the workers themselves, motivation isn't hard to come by. They are now stakeholders in the success of their own company. They can also target the type of work that interests them and they are calling the shots. A well motivated person is a person that will do their best work. They are also rounding out their skill set: they aren't just the designer anymore, they also have to go and talk to the clients, handle the finances, push for new business etc. It's not all lovely, but the stress that is there is stress they are in control of.

I can see more and more people moving towards this sort of structure as clients lose their fear at dealing with companies that have been traditionally seen as small fry. For ourselves at Nomad we've adopted this approach wholesale. We set up the company in such a way as to ensure that we never have employees. We want to remain small, focused and passionate about what we do. We tell our clients that we are a technical agency and we don't handle anything else. If they want design or SEO though, we know plenty of others like ourselves who we are happy to work with and recommend.

That's just my take on the subject, but it's my take from many years of being on the inside of the agencies, and a few now being on the outside. I wouldn't change my time on the inside, I made great friends and learnt from some very talented people. However now I'm on the outside, I know where I would prefer to be given the choice and I know how I want to approach working in our industry.

Throughout my career so far I have on several occasions worked contract roles with very large financial corporations. There are a lot of things that big corporations do wrong and that's not what I want to get into in this post. What I want to look at is the things I have learned and how they've effected me both as a freelancer and now that I am a representative of Nomad.

Pro's and Cons

Obviously the major selling point of contract work is the pay. The pay in web development roles can be incredible if you are willing to travel to where the work is. There is of course a major draw back in that effectively your contract can be ended at anytime.

Most contracts will run for a specifc amount of time, 3 / 6 / 12 months or longer but this is the duration of the terms of the contract. Every contract I have ever seen has a much shorter termination clause usually a month or a few weeks. This will usually apply to both the company and the contractor (thought it might not be the same for both) so make sure you read your contract carefully so you definately know where you stand. Another drawback that is rare but I certainly have experienced is envy from full time staff at a place I was working. I usually try very hard to keep the amount I am earning on contract quiet, however these things usually have a way of getting around and I have experienced snide quips from salaried staff (just once).

Pace of work

One of the most massive differences to me between the work I do for Nomad now (or when I was freelance) and working in an office with a corporation is the pace of work. If I want to change something on a client's site, I update SVN, open the files I need, make the changes, commit them back in and push to live. A fast change can be done in minutes. This is not the same in a corporate environment.

I've seen developers spot a change is needed, perhaps a typo in some image based text. In order to make that change, the developer has to edit the image, upload the new image to what is more or less likely to be a staging or development environment. Get sign off on the change (which we'll get into in a minute) from one or more "stakeholders" and then move the file to the live environment and recheck it and have it signed off again on the live site. Now this process can also only take a minute, in reality it won't.

The signoff process is where I personally believe a lot of corporations fall down, you'll know this already if you read my previous blog post (On trusting who you hire). Every additional management layer involved in the sign off process increases the time to get a change made exponentially. If someone in that process is tied up, in a long meeting or away for a day then the change can sit unresolved for a long time and what should be a 2 minute fix ends up taking a whole afternoon to be implemented.

This in my experience leads to a lot of down time while in a contract role. It's not unusual to finish a piece of work, drop it into the sign off process and have to wait on it. If there is no other work to do, or the rest of your work depends on the first piece being complete you're left twiddling your thumbs. It doesn't really make sense for you to just sit there, so in these situations I usually talk to my line manager to find out if there is anything else I can get working on. If there isn't I let them know that I am free to work and then open google reader and catch up on my reading. It's easy to feel bad in this situation but I think it's important not to sit and stagnate.

Meetings

Oh boy do corporations love their meetings. An obscene amount of time gets taken up from the average day with meetings that may not really require your attendance. I don't know about you but it takes me a while to settle into my work and get focussed. Going into meetings really disrupts the development flow and makes it much harder to stay on track with the job you are trying to do.

If I could tell corporations one single thing, it would be to cancel any meeting that is not critical. 8 people in a meeting for an hour is a day of wasted time!

Working outside of work

To everyone who works a full time job AND freelances in their spare time, I salute you. Getting home at the end of a long day that's been full of meetings and hold ups, and still having the energy and drive to code is really tough.

It makes you fat!

One contract I've worked had a canteen that provided lunch for free..... enough said there, has anyone seen my gym pass?

Conclusions

If you are willing to commit to working in an office for a few months at a time contract work is pleasant and very lucrative. There are downsides that's for sure but if you can find a good company that you enjoy working for it's a great thing to try.

image sourced from Chantry Edu

This month I attended the first UK based Expression Engine conference aptly called 'EEUK'. Held in Manchester town hall, and kindly organised by Ian Ebden from DesignKarma. Typically, Expression Engine conferences have always been held abroad, either in parts of Europe, or as EECI is this year, in America.

That leaves these conferences slightly out of reach for those of us in the UK who can't afford the time and cost to attend. So after Ian made an impromptu comment about hosting a UK based conference the Expression Engine community quickly held him to it. I think Ian initially intended the conference to be held in the back room of a pub somewhere - as he didn't expect many of the community to turn out. However, the conference quickly sold out and the Manchester Hall was decided as a venue.

I arrived at the venue early, and was greeted with a goody bag containing all kinds of niceties from the sponsors, like a t-shirt by Made by Hippo, a pen and a coaster. Then was given coffee and biscuits, which, was well needed to wake me out of my morning haze. Quickly people arrived, and was obvious to see plenty of folk already knew each other - either from Twitter, the Expression Engine forums, or having worked on projects together. One thing I will say about the Expression Engine community is, that although it's relatively small (compared to the likes of Wordpress), there's a real sense of connectivity. If you're interested in getting involved in the community over twitter, it's worth using the #eecms hashtag, as that's how a lot of people tend to follow along.

So, onto the speakers. The first up to speak was Joel Bradbury, and his talk '101 Ways to Skin a Cat : Design Patterns in EE'. This was a really good opener to the conference. Nothing too heavy for being so early in the morning, but enough little snippets of information to keep me interested. He showed off some research on the different types of naming conventions, plugins and template coding styles used by developers who work with Expression Engine. I was happy to see that the best practises being demonstrated was how we already work with Expression Engine at Nomad.

Next up was Leslie Flinger, and she spoke about using Expression Engine as a freelancer. This included how to find clients, manage your time and other things. Although her talk was very interesting - I felt it didn't really belong at the conference. Most of the attendees were already freelance or employed with established agencies - and I felt were there to learn something new, rather than consider a career change.

After a short break, and a bit more coffee and cake (conference hosts take note - always provide cake!) John Henry Donovan took the stage. John spoke at length about Faceted Navigation Techniques. For those unfamiliar with faceted navigation - it's essentially a technique for breaking up large amounts of content into smaller, more filtered results. However, this only really works on content that has a large amount of meta data associated with it. A good example of a site that uses faceted navigation is Amazon. They use the technique to filter search results down to finer grained detail. For example, you may search for the term 'Star Wars' - then be presented with everything from toys to DVD's. Faceted navigation, then lets you filter out what you don't want to see. You can see it in highlighted in this screen shot.

Although John's talk was very informative - again, there was no really practical, hands-on examples utilising Expression Engine. However, for a 30 minute slot, this could have easily caused him to overrun. So maybe one for a rainy afternoon to have a play with.

Stephen Lewis picked up the baton from John, and spoke at length about creating Expression Engine add-ons as a commercial venture. I think it's safe to say this was of interest to the majority of attendees, as most of them either used add-ons in their day to day development, were active add-on authors, or were interested to see how being an add-on developer could be profitable. I think a very interesting part of Stephen's talk was about how he writes the user documentation first (amongst sharp intakes of air in the room). He spoke about how this helps him define the scope and spec of the add-on he's building - which, if you think about it, is the right way around. Work out what you want it to do, how it's going to do it and then build it. Stephen also spoke about writing scripts to help you automate any process you find you're repetitively doing on a daily basis - however, I think most developers do this already. It's part of what drew us to being developers in the first place, right? However, one thing Stephen did show off was his basic add-on builder he developed. While Stephen said the code wasn't the best he'd ever written, and wouldn't open it up to the public, it did what it needed. In less than 2 minutes, he went from nothing to a functioning add-on on which he could continue development. Impressive.

Time for lunch.

Photo by EEUK

After stuffing myself on sandwiches and sausage rolls (the lunch provided was really lovely) - the infamous Lodewilk Schutte, or 'Low' as he's more commonly referred to, took the microphone. Low dropped HUGE knowledge bombs about the parsing order of Expression Engine. Something that has caught all developers out at least once. He went through in detail about how Expression Engine parses templates, plug-ins, modules, extensions, global variables, simple conditional, advanced conditionals, php... and more. By the end of it I think everyone was pretty much blown away. Low must have spent days in Expression Engine's parsing engine working this all out - and being kind enough to share it with the community makes him truly admirable. From all the speakers at the conference this was by far the best talk for me - this is what I think conferences should be all about - learning and exploring. If you're interested in learning a bit more about the parse order, see the following link. Low - Expression Engines Parse Order PDF.

For the next speaker I was hoping for something a bit less 'heavy' as I was suffering severe mind melt from Low's talk - however, next up was Carl Crawley, speaking about optimisation of Expression Engine installs. This is something we're very interested in at Nomad - and I personally keep an optimised copy of Expression Engine in a Git repository ready for a quick checkout and install, allowing us to hit the ground running on those 'urgent' briefs. Carl didn't disappoint, and I was glad to see that we were already doing most of the points Carl recommended such as:

• Disabling all modules/extensions/plugins by default, and only enabling the ones you need for your project.
• Keeping a library of reusable snippets of code.
• A set of basic html templates for common pages.

You can see Carl's notes here: Carl Crawley - Structuring your #eecms build

The final speaker was Erskine Design's very own Garrett Winder, and he spoke about Expression Engine and mobile sites. This is a very hot topic at the moment, and the debate rages between responsive design and dedicated mobile sites. Garrett went into a bit of technical detail on how to set up Expression Engine to handle a dedicated mobile site without letting it take over his entire talk. Kudos.

However, I think choosing between either approach depends on the context of the site/application, and can also include a mixture of the two approaches. I think there may be instances where it makes sense to serve a different front-end to a mobile device, however, that doesn't stop us from applying a responsive design to it, allowing us to cover a wide range of support for mobile devices. Although I fully admit there may not be time, budget or resource to create and maintain a mobile version of your site/application and applying only a responsive design is a happy medium between the two. Either way, Garrett's talk gave me plenty to think about. You can see his slides here: Garrett Winder - Going Mobile.

And that, as they say, was a wrap. Pixel & Tonic were paying sponsoring the post-conference drinks, however, I had to jump in the car and drive all the way back to Norfolk, so didn't get a chance to socialise. Next time maybe. Although according to Ian Ebden, there may not be a next time - as the conference was incredibly time consuming to organise. I can understand that, although I think there'll be others who'll get involved to make EEUK '12 a possibility.

A big thanks to Ian, and all the speakers and organisers for their time, energy and enthusiasm to organise EEUK.

A JavaScript port of the Box2D physics engine. That's an actual physics engine running inside a canvas tag!

A brilliant animated story using parallax scrolling.

iTunes coverflow implemented in JavaScript.

And on a more practical note, a very good HTML reference including new HTML 5 tags, attributes and usage guide.

To achieve this we'll use a publish / subscribe approach to broadcast changes in the model. A lot of frameworks (e.g. Dojo, AmplifyJS, Backbone.js) provide similar functionality but we'll build it from scratch to see how it's done.

We'll start with an event class which has two core methods:

nomad.Event = function() {
	var events = {};

	this.publish = function(event) {
		if(!events[event])
			return false;

		var evt = events[event];
		var args = _.rest(arguments);

		for(var i = 0, len = evt.length; i < len; i++) {
			evt[i].apply(null, args);
		}

		return true;
	};

	this.subscribe = function(event, callback) {
		if(!events[event])
			events[event] = [];

		events[event].push(callback);
	};

	// ...
};

All that's really happening here is we're storing a hash of event names with an array of callback functions. You'll notice we're using the convenient rest method provided by Underscore.js. This returns everything apart from the first element of the array. It also works with the JavaScript arguments object which operates in a similar manner to an array without providing the standard array methods.

Separate instances of Event won't conflict with each other so a global instance can be created to provide observer functionality throughout your application UI, in a similar manner to dojo.publish, or local instances can be created within other objects to provide observer functionality within that object. Our model class will instantiate its own Event object to handle events unique to itself.

As our model is based around a table of data and is really a collection of models we'll call it a list and use it in a similar manner to an array. We'll need methods for appending, removing items, iteration and sorting. For ease of use we'll also allow an array of objects to be passed to the list constructor.

nomad.mvc.List = function(list) {
	var events = new nomad.Event();
	var data = [];

	// ...

	this.append = function(model) {
		// ...
	};
	this.remove = function(index) {
		// ...
	};
	this.sort = function(property, inverse) {
		// ...
	};
	this.each = function(callback) {
		// ...
	};

	// initialise the supplied array
	if(list && _.isArray(list)) {
		for(var i = 0, len = list.length; i < len i++) {
			this.append(list[i]);
		}
	}
};

We'll need some events for our view to hook into: ideally one for each action that can be performed plus a general "I've changed" event.

nomad.mvc.List = function(list) {
	// ...

	this.onsort = function(callback) {
		return events.subscribe("onsort", callback);
	};

	// ...
};

These are just wrappers around the event object instance, which has been kept private to prevent it from being changed or accessed directly by any calling code (encapsulation+composition). For our sort method we'll allow a property name to be passed to it and an optional sort ascending parameter.

nomad.mvc.List = function(list) {
	// ...
	this.sort = function(property, inverse) {
		inverse = inverse ? -1 : 1;

		data.sort(function(a, b) {
			a = a[property];
			b = b[property];

			return inverse * (a == b ? 0 : (a < b ? -1 : 1));
		});

		events.publish("onchange", this);
		events.publish("onsort", this);
	};

	// ...
};

This will cover 99% of the sorting our table will ever do and all of the functionality required for this example.

When it comes to loading data into our List we have a few options depending on our web app. We could have the server write out the data as JavaScript objects when it writes out the HTML for the table; we could parse the table and use the rows and cells to build our data structure; or we could retrieve it via Ajax.

Once our data is loaded we'll need to register our onsort event handler with our list model and add click event handlers to the heading cells in the table.

(We'll cheat here and use a little bit of jQuery)

var sorting = "Name";

$("th").click(function() {
	var text = $(this).text();

	list.sort(text, sorting == text);

	sorting = sorting == text ? null : text;
});

We're storing the text of the last sorted column so we can invert the sort if the heading is clicked again.

Our onsort event handler is quite straight forward.

var list = new nomad.mvc.List();

list.onsort(function() {
	var tbody = $("tbody").empty();

	list.each(function(model) {
		var tr = $("<tr />");
		var name = $("<td />").text(model.get("Name"));

		tr.append(name);
		tbody.append(tr);
	});
});

All we're doing here is clearing out the table rows and rebuilding them by looping over the data in the list model. This means our rendering code (view) has no understanding of what is happening to the model. As far as it's aware the model has changed and needs to be redrawn, it doesn't know why, nor does it need to. We could even use the same function for the onappend and onremove events if we wanted to and the table would still render perfectly.

The other advantage to this approach is multiple views can be hooked into one model, so we could display our data in a list or a form and have it update as simply as our table.

There are quite a few JavaScript frameworks which take this approach to UI development or you can have a look at the extended example code at MVC JavaScript Examples.

More often than not when working on a project, a client would phone an account manager and ask for a change to what was agreed upon. This is perfectly reasonable. After this point however the process needs to be managed carefully. The potential change needs to be evaluated, costed and confirmed with the client. Any implications need to be explored and delivery times shifted as required.

The reality however is that often the cost is absorbed by the agency, for fear of upsetting the client. The pressure is pushed down the chain to the developer, who finds themselves with more work, less time, and no extra reward. You could just as easily swap out "developer" for "designer" here. It happens to all staff.

This fear manifests itself in a number of ways. Sometimes it's squeezed developers, other times it's quoting too low to win the prestigious client and doing a job for less than you should. Occasionally it's farming out the work to cheaper, less adept sub-contractors (you generally get what you pay for) to maximise margins.

So what are we afraid of?

We've all got bills to pay, mortgages, credit cards etc and families to support. We'll quite happily suck up a lot of rubbish in order to take the stress of modern living off our shoulders. Security in your workplace is a wonderful thing, and the best way to guarantee that is to make sure you work as hard as possible - make yourself invaluable.

Once you start accepting this though, either at an individual level or on a wider company level, it sets expectations. It's human nature - we like patterns of behaviour. If you always work late, then pretty soon it's expected of you. Maybe not consciously - but when you go home early (i.e. after 7.5 hours rather than your usual 10) it will stand out as odd.

Now before I go much further I'm not saying you shouldn't work hard and that you shouldn't try to please your clients/customers. I believe very strongly in always doing your best in any given situation. Clients should be treated well and fairly. Changes are a fact of any project, you'll never avoid them and often they are completely legitimate and required.

However being a happy developer and having happy clients aren't mutually exclusive.

So what is broken?

In my opinion there are two things that are broken, one easier to fix than the other. The first is education, the second is Agencies themselves. I'll give my thoughts on the education aspect below, the Agencies side of things will be in part two of this blog post.

Education

This one is the easy one. The trick here is simple. Be consistent, be up front about your processes, be willing to stand firm but also be willing to compromise and above all be honest.

Educate your clients when they first start working with you as to what your process is and make sure you stick to it. Make sure they know where they stand and always are up to date on progress.

Once you've agreed on a specification with a client, expect the changes. It's not the client's fault. They are under as many external pressures as you, just make sure you react appropriately. Minor changes and your capability for dealing with them should be built into your quotes, the way you work should be flexible enough to accommodate this. Major changes should be evaluated and any changes in cost and timings communicated back to the client. Bend like a reed in the wind grasshopper! (but make sure your roots are deep).

Work with the client not just for them. If there is a major development issue with the changes requested, talk to them honestly about it. They'll realise that there are cost implications in what they are asking. 99% of clients when approached this way are completely reasonable.

Saying all this though there is always that 1% who will try and take advantage. Who will ask for a 3 page website and expect a social media web app. Or claim their expectations were completely different from what was delivered, regardless of all the supporting information to the contrary. They don't trust your judgement, they question your every move and motive. You are the expert, but they want to give all the advice.

The solution here is simple. Get rid of them. Fire them. Nicely of course, but if they are being that unprofessional there they will never be worth the hassle. Success is measured in more then just invoices. Your time and stress levels are incredibly important too.

Coming up

I've decided to split this post into two. Otherwise it would be a huge wall of text, also I feel there are a lot of talking points and I'd rather have any discussion focused on one thing at a time. As ever, leave comments below, email us, or get us on twitter.

Like so many of the blog post topics that spring into my head, this post is inspired from a conversation that I observed on Twitter.

A designer was upset about the way in which a client had subsequently treated a site that they had provided. This got me to thinking, doesn't the client trust that this designer is a professional?  I think this is a problem that everyone working in the web industry has faced at some point or other and while it can grate that your perfect site is being mauled I think it's wise to think through why this could be.

It could be that the client doesn't trust that you know what you are doing. That you have analysed the requirements and elegantly solved the problems. Sucks right? It might be that you (or they) didn't really understand the requirements of the project and then rather than continue making amends to it through you they've decided to cut thier losses and do it "in house". In the particular case I observed this didnt seem to be the case as it was not a freelancer but someone from a well respected and moderately large agency.

Well this might just be that the client is particularly .... irritating... perhaps they didnt really want a full design service and would've been happy with a bit of artwork and that's all (but you should've known that).  Whatever the reason for their post launch tinkering, unfortunately your name is against that work and now it's more an example of how not to code than best standards and practice. Undoubtedly you shouted about it when it launched as you were so excited, so this could potentially be damaging for your reputation. I think it's worthwhile asking for feedback in these situations, though I wouldn't recommend charging to their offices and demanding to know why they've put clip art as the background, but a calmly constructed email asking why they made certain choices and asking if you can help is likely to be better recieved.

So how do you build this trust? How do you instill in the client a sense of professionalism, not just in the way that you work but in the knowledge that you have.

Have plenty of testimonials and case studies of your work available to see. If a client see's that you have worked with a lot of people and are proven,  then they are more likely to defer to your expertise than bullishly assume that they know best - that's not to say that you shouldn't listen to them though.

Talk with the client about the work you've done before. If you have had a successful project that was similar to the clients requirements, tell them about it, talk about the goals that you needed to achieve and how you did it. Experience goes a long long way in an industry that doesn't have any qualification to measure you by. (Brad Koehler W.E.B).

If you can make the client understand that you do in fact know what you are talking about from the start then you can hopefully avoid a client recklessly making modifications to your baby.

Trusting who you hire isn't just an issue facing businesses and their clients, having previously worked at agencies and to a lesser extent contracted with larger companies, I have found that in my experience there is often (though not always) a lack of trust in contract staff and in some cases even in direct employees. Whether it be needing to get permission to access the files that you need to do your work or needing 75 different levels of sign off to actually make that 2 minute text change in the footer.

Companies, Agencies, if you are listening, trust the people you hire. You set out the requirements for the position and they met them, you picked them above the rest for the role you've given them. I know you need to protect yourselves to some extent, but don't stifle the great people you've hired, it's not good for them or for you.

We'd love to see some discussion on how you build initial trust with new clients, reply in the comments!

If you'd like to influence a future blog post you can follow me on twitter @koehlerbear or @NomadCoop

Thanks for reading

Alternatively, here's a couple of quick links for users on OS X and Windows to install Git 1.7.4:

• OS X - 32-bit: Download
• OS X - 64-bit: Download
• Windows: Download

Installing on OS X:

Download either the 32 or 64 bit package to suit your system. Once downloaded, double click the downloaded .dmg file to mount the disk image. Then double click the .pkg file to begin installation:

Install step 1 - click 'continue'.

Install step 2 - click 'install', and enter your password (You'll need an administrator account).

Install step 3 - click 'close'.

All done. Git is a installed as a binary file on your system, so there is no application icon to be found. To check it has installed properly, start up Terminal (found in Applications > Utilities) and type the following:

git --version

Then press 'enter', you should see something similar to the following:

git version 1.7.4.1

Congratulations, Git has been successfully installed and is ready to go...

Installing on Windows:

Download the file from the link shown above. Once downloaded, double click the downloaded file to begin installation:

Install step 1 - click 'next'.

Install step 2 - click 'next' to accept the license.

Install step 3 - here you can select where to install Git to, normally the default path is fine. So you can go ahead and click 'next', otherwise set the install location first.

Install step 4 - here you can choose what to install, again, the default options are fine, so click 'next'.

Install step 5 - click 'next'.

Install step 6 - here we want to tell Git that we'll use Git in it's own Bash shell so it doesn't conflict with other applications. Make sure 'Use Git Bash only' is selected and click 'next'.

Install step 7 - here we have options for file line endings. The first option is the recommended setting, so we'll stick with that and click 'next'.

Install step 8 - and we're all done, click 'finish'.

The windows installer installs 2 application icons. 'Git Bash' and 'Git GUI'. Double click the 'Git Bash' icon and a command line application will start. Once loaded, type the following to check Git installed properly:

git --version

Then press 'enter', you should see something similar to the following:

git version 1.7.4.msysgit.0

Congratulations, Git has been successfully installed and is ready to go...

So there you have it, Git is now installed and ready to rock. In the next article we'll set up our first Git repository and commit a few files. Cool huh? From here on we'll be working with the command line (Terminal for OS X, or Git Bash for Windows), not because it's geeky, but because I believe in learning how stuff works under the hood before using a GUI to make life a bit easier/quicker.

In the meantime, if you want to have a look at GUI's available for Git, here's a quick list of some available:

GUI's on OS X

• GitX
• Gitti
• Gitbox
• Tower
• SmartGit

GUI's on Windows

• TortoiseGit
• Git Extensions

• Some good advice on working smarter, not harder.
• A 2D platformer which allows you to control time - Braid. It's one of the subtlest games we've ever played. On one level it's a basic Mario-esque rescue the princess type thing, but there's real depth to the story which includes themes of obsession.
• Powerful photos of a volcanic eruption in Chile.
• Interesting tech art from Kinetica 2011.
• Some good information on proper URL design.
• Riak - a nosql database with replication built in from the ground up. I'm looking forward to playing with this.