Obviously, you will grade your quality of experience with these suppliers largely in terms of the reliability of service that they provide. But these days most reasonable suppliers offer very similar levels of reliability, so what becomes more and more important is the quality of their customer service. All services will encounter a problem every now and then; the true mark of a great company is how they address those problems, how quickly they respond to your support requests and questions.

After dealing with literally hundreds of companies with stunningly crap customer support, when I find one where the people are helpful, quick to respond and knowledgeable about what they do, I hang onto them pretty tight and recommend them to as many people as possible. So I thought I would recommend a couple of companies that I have dealt with a lot recently and have found to provide both excellent reliability and fantastic customer support.

Wired Tree (Hosting)

Wired Tree offer managed VPS as well as dedicated servers, with cPanel/WHM at reasonable prices. I host all my personal sites with them, and we use them at work now for all our clients’ hosting, and they have performed excellently in terms of speed and uptime. More importantly, their customer service has really been second to none - support requests are generally answered within 15 to 30 minutes, and they are knowledgeable, honest and exceedingly helpful. Highly recommended, check them out at wiredtree.com.

Campaign Monitor (Email broadcasts)

These guys are great! They provide a really nice, easy to use online email broadcast tool, which does it’s job very well. They also are quick to respond to support tickets and information requests, and are eager to help and quick to look into any problems that I have encountered (mostly my fault!). After using an number of other email broadcast tool suppliers over the years I can honestly say that none have even come close to the level of service that these guys offer. You can sign up for an account at campaignmonitor.com for free to check out the tool.

Any one got any other great companies they can recommend?

It basically allows you to paginate any collection of elements on the page, adding very simple prev / next links (as well as a ‘page’ counter if required) to allow navigation.

I often use this to paginate a list of news articles, or as a very simple way to throw together a little ’slideshow’ (by paginating through images with the ‘perpage’ setting set to 1).

It can paginate pretty much any collection of elements (of mixed types if required), including images, divs, elements in an unordered list etc (ordered list li’s don’t work well - try it and see why!).

Once again, I’ve kinda rushed it up there so if you spot any bugs or mistakes in the documentation etc, just drop a comment below and I will look at it asap.

Check the plugin out here.

In contrast, I have just started learning a bit about iPhone app development. Primarily because I want another challenge, something a little different; and partly because I am really excited about the potential that the platform holds, and I would rather be in there making things happen then watching from the sidelines. So I have started getting stuck into a bit of Objective-C, and to be honest it is something of a shock! Coming from a PHP/JavaScript background, the language seems incredibly rigid - no more getting away with being sloppy about return value types! Actually, to start with the whole thing seemed incredibly anal, but I am slowly starting to see the advantages of doing things this way.

In fact, even though I have only just started looking at it, I am starting to understand how PHP is really a kind of facilitation layer plastered over the underlying core programming language - which makes things easier for sure, but lacks the fundamental power that scripting in C can give you. Of course PHP is really optimised for web tasks, and Objective-C in turn for mobile and desktop applications, so their intention is very different and they undoubtably each fulfill their roles very satisfactorily. But I can’t help the feeling that I have suddenly had a veil lifted from my eyes and can now see that I have been programming in Fisher-Price, child-friendly languages up until now.

I mean this as no disrespect to the people who code in PHP/JavaScript etc - I do so everyday and very much enjoy it. It’s just that within those languages you are very much shielded from a lot of the more ’serious’, lower-level programming issues (such as memory management and threading) that you have to deal with in languages such as Objective-C. This is a fact that I was aware of but never really understood until I started investigating iPhone development.

So I am realising how much I have to learn, all over again, but I am really quite excited about it all. Who knows where it will lead - 5 years ago I was doing a Master’s degree in Oceanography and would never have though I would be programming for the web in 5 years time! I certainly wouldn’t be sad if I was earning a living writing Mac/iPhone applications in a few years time. But perhaps I’m getting ahead of myself…

Opera also ran the pages indexed by MAMA through the W3C’s validation tools to see how many conform with standards. The results show that only 4.13 percent are valid.

Ahhh how I love statistics, especially headline grabbing ones like this. It’s a shame they can’t measure the ‘as close to validating as to not make the blindest bit of difference to anything or anyone’ percentage - I think it would be a lot higher, and more representative of the general state of the web today.

As it is I think this particular stat might just get Jeff Croft all wound up again.

It’s amazing how a week away from the computer can open you eyes and re-align your perspective. It really highlighted to me how alive I feel when I spend a lot of time outside doing physical exercise - especially adrenaline sports such as windsurfing and surfing - and how 14 hours a day in front of a screen just sucks the life out of me. I’m sure I’m not the only one who feels like this! With the day to day pressure of earning money and with the routine of ‘normal’ life it is just so easy to forget what is really important to you.

So whilst the break has done me a world of good, in a funny way it has also made me feel less satisfied with my life as it is at the moment. That’s not at all a bad thing: I really think it’s important to keep looking at where you are and what you are doing, and asking yourself if it is in keeping with your ideas and dreams. Don’t get me wrong - I love what I do, but given the choice I would much rather be spending more time outside and in the water that I get to at the moment.

I guess what I am saying is that if you have the opportunity, get away from the computer, go outside, get refreshed. It sounds obvious, but it is actually surprisingly hard to do sometimes when everything else seems so pressing. I know I’ll be trying to do it more.

Anyway, I’m back in the fold now, in front of the computer, so normal service on all fronts should be resumed soon.

Our site design process generally goes a little something like this: After the initial scoping phase is completed, a sitemap is drawn up (or a supplied one is checked and amended as necessary). Then typically a wireframe gets put together, featuring all the appropriate navigation items plus any other components of importance. This is then shown to the client, and on signoff is then passed to the designers for them to build upon to create the final design. Pretty standard methodology.

So what’s the problem with this method? Well, the main issue is that the wireframe itself is not drawn up by the designers. This is for good reason - our designers (and this is very often the case elsewhere too), whilst very talented at what they do, are not dyed in the wool web designers; whilst they can certainly produce a lovely looking site, they don’t have the depth of understanding about information architecture, usability and accessibility etc to on their own produce a site that works as nicely as it looks.

So mostly the wireframe gets put together by the project manager, who is more experienced with IA, usability concepts, etc - but is not a designer. And herein lies the problem. A wireframe of a site often depicts a simple layout - width, number of columns, content areas, header areas and so on. This initial wireframe may not be at all show the intended layout for the final site - more just a quick schematic to ensure that all the relevant parts will be accounted for and so that the client has something tangible to engage with and to comment on. But however much you tell the client that this is NOT necessarily how their site will be laid out, they will always expect the final design to roughly resemble the wireframe. It’s just the way it is. And no matter how many times you tell the designers not to be constrained by the layout on the wireframe, inevitably this layout will be hard to shake out of their heads, and nine times out of ten the end design will end up being somewhat restricted by this.

There are many ways around this issue, some of which we are now starting to explore. But our experiences at VGroup have taught me that good, effective wireframing is really not easy; it is a delicate balance to get the correct level of detail in them, to present them at the correct time in the site design process, and to ensure that all the relevant parties have just enough input in the process so that the wireframes provide a springboard for the creative process and not a cage around it.

I am going to try and do a bit more thinking and reading about the wireframing process over the next couple of months, and I’ll be sure to post up anything useful I come across. And if anyone has any top tips or recommendations for books/articles then please leave a comment or drop me an email!

Apparently, Apple has now started labeling their rejection letters with Non-Disclosure (NDA) warnings:
THE INFORMATION CONTAINED IN THIS MESSAGE IS UNDER NON-DISCLOSURE— MacRumours

Apple is really, really pushing the limits of peoples’ tolerance with this now. I love your products Steve & co, but you need to get a grip on this before it becomes a deal-breaking issue.

It’s hard to imagine pushing the limits of object oriented PHP so far that your web servers choke, but the truth is those limits are reached faster than you think. — Ryan Campbell

I’ve run into this problem a number of times myself, and always with regards to the example Ryan provides - a script that exports a large database table to a CSV. I didn’t realise that it was the object instantiation that was sucking up all the memory - although perhaps this seems obvious in retrospect.

Whitespace, whitespace, whitespace

Probably the single most important thing you can do to increase the legibility of your code is to inject a good dose of whitespace into it. Dense, cramped up code is hard to scan and hard to extract information from quickly. Correctly indenting your code, together with liberal use of spaces and new lines results in a much clearer easier to scan and understand script. If you are writing JavaScript or CSS, don’t cut back on whitespace to save you a Kb or two in filesize - instead space everything out nicely and then run it through a compressor when you are ready to go live with it all, keeping the uncompressed version for later editing. Have a peek at the CodeIgniter framework source code for a great example of well formatted code with plenty of whitespace.

Make it self-documenting

Good code doesn’t need pages of comments to tell you what it is doing. Careful choice of variable and function names can go a very long way to making your code speak for itself. Stay away from non-standard abbreviations and generic names (like ‘value’ of ’set_value’) where possible, and try to make sure all of your function names are really representative of what the function actually does, and variable names describe accurately their contents. The CodeBetter site has a good post on self documenting code = check it out for loads of good tips.

Create a set of conventions, and stick to them

Nothing is harder to get your head round than code that doesn’t follow a cohesive set of conventions. It is really, really important that you develop a set of conventions (or adopt ones from somewhere else) for all the code that you write, and then stick to them religiously. The actual conventions don’t even matter as much as the sticking to them; what you are aiming for is uniform, consistent code standards across and within projects. This goes for naming of functions, variables, file names - everything, even the amount of whitespace. Write down your conventions if you need to share it across teams - Zend’s ‘coding standard guide‘ for their Zend Framework is a great example of a comprehensive manual of coding and naming conventions. Obviously for your own personal projects it is unlikely you would take it this far; but however far you go it will make it much easier for people who have looked at one piece of your code to pick up another and immediately feel at home.

Comment enough, but not too much

Comments in code are often invaluable for providing information as to the purpose of a particular line, function or other segment of code. In an ideal world the code itself would be entirely self-documenting (see above) - however in reality this is rarely (if ever) achieved, and a few helpfully placed and concise comments can work wonders. But keep the comments short and sweet! A 30 line comment, unless absolutely necessary, will actually hinder understanding of the code, as it adds to the visual ‘noise’ in the script and most people are highly unlikely to actually read it all! Besides, if a function (or anything else) needs 30 lines of comments to explain what it does it is very likely that the real problem is in the clarity of the code itself.

Don’t get too fancy

Whilst it is tempting to condense a 10 line ‘if’ statement into one line by stringing it together into a triple-nested ternary operator expression, this does not necessarily help with the general maintainability or readability of your code! It might get you top geek marks from the most hardcore of programmers, but generally it is not bad thing to split up complex statements to make it clearer to those charged with understanding your code.

Write better code, and less of it

Okay, so maybe this isn’t so easy to implement. But the amount of code you write, together with the quality of it go a long way to making it easy to understand (or not!). Stick to the DRY (Don’t Repeat Yourself) principle, and look at every piece of code you write to see how you can improve it and cut down on the number of lines it takes achieve your aim. Shorter, more concise code that fulfills the same role will generally be easier to understand than a long, rambling, poorly written script, as long as it doesn’t break any of the principles outline above.

So these are a just few things that you can do to improve your code’s maintainability, and make it easy for others (or even yourself!) to pick up the code later on down the line and easily make sense of it. No-one is perfect, and I certainly deviate from these guidelines form time to time. But following these general principles will go a long way to making your code accessible to others.

The vast majority of developers will, at some point in their career, use code written by a third party. This might be code written by a co-worker, a little snippet from a repository such as Snipplr, or a comprehensive language framework such as CodeIgniter or jQuery.

Now if you have actually ever had to go beyond just using any code written by others, and instead had to delve into the guts of the code itself, you will probably have seen a mix of code quality. Poorly written code can be a nightmare to understand. Well written code, on the other hand, can make it feel like you are reading prose; you can instantly get a feel for what is happening. Typically, well established code libraries will tend to have clear, easily readable code, whereas your co-worker might be turning out code that looks like it is written in Klingon.

So what does your code look like? How easy would it be for other people to pick up your code and figure out what it is doing?

Even if you are working on your own, writing code intended just for yourself, it is important to have a strict coding standard that you work to. You never know in the future who will have to look at your code and figure it out. And even if that person in the future is you, it is amazing how quickly you forget what a particular function or class does. The extra time taken to carefully craft and comment your code so it is easy to pick up again after a break will be paid back a hundredfold when you don’t have to hunt through file after file tying to figure out what your mind was thinking when you wrote it.

If you are writing code explicitly intended for others to use, then the case for clear, expressive code is even more pressing. It is your obligation to ensure that the code is as readable and easy to understand as possible; doing so will benefit you as well as your users, helping to cut down on requests for help or clarification. Good code speaks for itself and needs little documentation.

So how do you make your code easy for others to follow? In the Part 2 of this series I will go into detail on how you can make your code expressive, easy to read and simple for another developer to pick up and understand.