Revision control is a critical part of any significant development project. Having secure full time access to your repository from wherever you are can be important. In some environments, such as open source projects, it's absolutely crucial to the functioning of the development team.

To summarize, as memory goes too low, garbage collection could kick in, but it in turn needs memory to maintain a traversal stack … Quite a catch-22.

This final part of the series will step outside the domain of standard C and investigate a pattern for event-driven applications. The REACTOR pattern decouples different responsibilities and allows applications to demultiplex and dispatch events from potentially many clients.

Before I start, this is going to be fun. Understand? Fun. Not dull, but fun. I intend writing this in a banana suit with my feet in a bucket of warm rice pudding[1]. That's how much fun it's going to be!

J2SE 5.0 has been available for download since the end of 2004. This new release included many changes and enhancements to the Java platform such as speed and stability. Additionally, some changes were made to the Java language itself.

Last time we began a high-paced stroll through a gallery of collected programmer stereotypes. In this concluding article we'll finish the tour, and see what makes the best type of programmer. Brace yourself: here come more Code Monkeys...

In my previous article we learnt the important optimisation process, the steps that ensure any optimisation really is worthwhile. Being eager code monkeys, I can see that you're all desperate for practical code optimisation techniques.

So here they are - in this final part we'll investigate specific code techniques for optimisation. Just don't tell anyone that I showed you. To redress the theological balance, we'll also see how to avoid optimisation in the first place.

In the first part of this series, we looked at what it means to optimise code, and saw the cases for and against optimisation. In this article, we'll look at the process of optimisation. We'll see the correct, methodical approach that will lead to solid, worthwhile code optimisations.

“There is more to life than increasing its speed” - Mahatma Gandhi

We live in a fast food culture. Not only must our dinner arrive yesterday, our car should be fast, and our entertainment instant. Our code should also run like lightning. I want my result. And I want it now.

Ironically, writing fast programs takes a long time.

Optimisation is a spectre hanging over software development, as W.A. Wulf observed. “More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity”.

It’s a well-worn subject, with plenty of trite soundbites bounding around, and the same advice being served time and time again. But despite this, a lot of code is still not developed sensibly. Programmers get sidetracked by the lure of efficiency and write bad code in the name of performance.

In these articles we’ll address this. We’ll tread some familiar ground and wander well-worn paths, but look out for some new views on the way. Don’t worry – if the subject’s optimisation it shouldn’t take too long...

To err is human.

Finding fault.

Software architecture

Software evolution or software revolution

A passing comment

What's in a name?