Web Development Supported by C++

I've just been working on an update for the Spring of Hope website. They are a charity that work with disabled children in Uganda, Africa.

I'd originally written the website in vanilla HTML and simply uploaded it, but I had to rethink my strategy after the charity's owner wanted to add a few pages to the site.

Simply adding a few new pages would have meant changing every existing page to link with the new pages - something that I didn't want to keep having to do. Instead I've written a small C++ application that loads the basic text required on each page, applies a standard header and footer to it, builds a menu, and outputs the HTML page.

A couple of hours work to make future updates simple.

Unintentional Leadership

I was flying back from Philadelphia and just before take off I looked across to see a tall chap asking the the air hostess for a seat with more leg room. She told him there were none left.

Once the seat belt sign went out, a fella got up from his extra-legroom seat and went over to the tall chap to ask him if he wanted to swap. Of course the tall chap agreed, and the exchange happened.

I know this generous fella was a team leader as I'd seen him and his new team on the shuttle bus on the way out. They were heading out for a training session.

His team weren't sat next to him on the plane, but they were close enough to realise that their new boss would give up his precious extra-legroom seat for a stranger in need.

If he would do that for a complete stranger, what would he do for one of his colleagues, one of his team mates?

Now that's leadership, unintentional leadership.

5 rules of variable naming.

When I was at uni some 10 years back now, I remember one of my lecturers telling me not to make variable names too long because you would get "pain in your fingers".

Well, rule #1 goes against that advice:

1. Make your variable names long and descriptive
Visual Studio has IntelliSense, Eclipse has its own code completion, and I'm sure whatever IDE you're using can finish your variable names off for you, too. Using long names prevents the ambiguity of short or cryptic names.

2. Put units in your variable names
If you are writing an engineering application you are going to be using variables with units. Embed the unit name in the variable, for example, distanceInMM.

3. If you are using Camel Case, don't capitalise commonly hyphened, or combined words.
Let me explain.

Callback is normally spelt as one word. So, pretty please, don't call your variable callBack.

4. Never, ever use the variable name temp. The only perfectly valid exception to this rule, is when you're writing a swap function.

5. int i is perfectly valid in a small loop. I've met programmers who would crucify me for saying this, but when your loop is half a dozen lines of code long or less, int i is perfectly valid as a loop counter. It's so widely used, it's almost expected.

Coding is dead, long live unit testing.

There are IDEs that can generate unit tests for your class once you've written the basic class stub. Or, they'll generate your class stub for you from the unit test code.

But a unit test suite should be written to cover all of the requirements in the requirements specification. It should be the contract of what is being developed.

So, if you've gone to all this effort to create a fully specified unit test suite, why should you then double your effort to write some more code to fulfil these requirements?

Couldn't something do this for you?

Like, a genetic software generation algorithm?

Life ROI

I enjoy DIY.

I'm not one for fitting a new central heating system or building a new conservatory, but I will paint a wall or two. I do it not only because it's rewarding but because I'm hoping it'll add some value to my new house.

But is it the best Return On Investment for my time?

Would it be more cost effective for me to spend my time reading a programming or management book and negotiating a pay rise for my additional knowledge whilst, at the same time, paying a professional decorator to paint my walls?

I'm still unsure how to measure the value gained from reading a book. Or, for that matter, how to measure the pride from knowing that the house is looking better because of me.

Further hat tipping

Richard Dare has already written several excellent articles on game design, I eagerly await his first blog post.

Welcome to the world wide weblog Trickster!

OSA

May I just tip my hat to the work of Andy Budd on the Operation South America website, he's come up with a great design and made some fantastic use of flash.

What a cool robot.

We've just found out that the robot we've been working on is a MacRobert award finalist.

I'd love to win it, but there's some really tough competition.

Brake Lights: A Usability Study

Have you ever been navigating through the front end menus of a PS2 game and gone off to get a cup of tea only to come back and think, "Which menu item did I have selected?"

No?

That's because console developers have to adhere to strict standards, know as TCRs and TRCs, that describe in precise detail how a front end menu should behave.

For example, Sony state that the selected menu option - which could be an icon or a word - must be coloured differently to the rest of the menu. But if there are only two menu items on the first menu you encounter, how do you know which colour is the selected colour and which is the unselected?

So a colour change alone isn't enough. Because Sony et al know this they also state that there must have some sort of animation of the selected item - some sort of distinguishing feature.

So what has this got to do with car brake lights?

On old cars, the brake lights sometimes share the same housing as the rear lights. The problem with this is the rear lights just look a bit brighter when the brakes are applied. If you happen to look away just before the brakes are applied, then when you look back again it's often difficult to tell that the car is slowing.

Or, to put it another way, there is no distinguishing feature to show that the brakes are applied.

So, in 1998 the EU stated that all cars must have a centre brake light. A distinguishing feature that allows other drivers to instantly see that the brakes are applied. (Incidentally, the EU took a whole 12 years to catch up with the America!)

Make your distinguishing features blatantly obvious and your users will thank you for it.

Mobile broadband

I want a fully blown, always on, pay-per-month, unlimited usage mobile broadband.

I want a device, much like a mobile phone, that acts as a mobile broadband server and a mobile wifi router.

I want to sit in my car with this mobile device in my pocket and for my internet car-radio to serve music through it. I want to listen again to Zane Lowe on my way to work in the morning.

I want my in-car GPRS system to auto-detect the mobile internet server and to tell the world that I'm not moving very quickly, that I'm stuck in traffic. Or to divert me off the M25 when the GPRS' traffic information server tells me that there are plenty of others parked up on it.

I want to sit in the park, open my laptop and instantly be able to access the internet through this device.

And I want this for £15 a month without the worry of data limits.

Is all this too much to ask?

How is refactoring like throwing out the rubbish?

In these green days, you no longer just throw out your rubbish. You rinse, separate, sort and then throw.

A process, not dissimilar to refactoring.

Some code goes into your grey, household waste bin. This is the stuff that was written before the scope of the project was finalised. It has normally been written quickly, doesn't always fit the spec, and is often bug-ridden. It can't be recycled. Just bin it.

But hopefully most of your code will end up in the blue bin. This is the stuff that can be re-used - sometimes with no changes - but usually needing a bit of washing and sorting.

You can help the process by building modular code with good clean interfaces early on in development.

In this green age, filling your blue bin and recycling old code as much as possible is essential. And this can be helped by building modular code - with good, clean interfaces - early on in the development.

Has my article been read?

So you've written a website with pages of search-engine-friendly text and you know how many unique visitors you are getting from your weblogs. But how much of your perfectly crafted prose is actually being read?

You could argue that with the weblogs of a site containing many small pages linked together you would have that information. But whenever I navigate to an article that has half a dozen pages, I know it certainly frustrates me.

So if you are writing long pages (ie, with more text that can fit on the screen in one viewing) you are going to need a way of working out whether people have actually bothered to read all that you are writing.

And once again, Ajax comes to the rescue.

Using javascript it's possible to figure out the position of the scroll bar. And using Ajax it's easy to tell the server about this position.

You could even write some server-side code to distinguish between a quick browse down the page and a full-on page read.

Engineering Problems on Large Software Projects

Size matters.

If you are on a large software project, you are going to face a bunch of problems that you just won't see on small developments.

And by large projects I mean multi-programmer developments based on a library of modules written over a number of years.

I said, "based on a library of modules". If you don't make your code strictly modular, you've already failed. That isn't always easy, especially when it's the day before a deadline and it's far quicker to bodge in a fix.

Given that you have a bunch of modules, with different versions of them used over several products or versions of the product; maintaining a formal build process is essential. Builds should be numbered or labelled and it should be trivial to reproduce any previous build from you version control system (you do have a version control system, don't you?)

Some formal structure to record who has what build is also needed.

Code re-use generates code as structural patterns are needed to ensure your new module can communicate with the existing functionality.

And with all this extra interfacing code, finding the guts of a particular function or class becomes a real issue. Although Google intranet search tools can certainly help here.

If you've only ever hacked together 2-day projects in your bedroom, these issues will be alien to you. Anyone who's worked in a real software house should be familiar with most if not all of them.

The new SI units

"Have you heard? The smiths won the lottery last week and the house they're looking to buy has a garden the size of 2 football pitches!"

But a football pitch can vary in size from 4,050m² to 10,800m².

And new mp3 players are often quoted as being able to store a certain number of songs, for example the 1Gb iPod shuffle can store 240.

But is this 240 average 3½ minute radio edits?

Or 240 20-minute drum and bass epics?

Or does it even matter?

Using a commonly known "thing" means far more to the average user than an exact figure. Approximating information is a good thing.

If you're only presenting information with 1 or maybe 2 significant figures, do you really care how accurate the unit is?

Company Culture

We hear about company culture all the time, but until you've worked in a few companies it's hard to understand how two software development houses can feel so different to work at.

The Team

A team based company will normally separate groups off into their own little rooms or sections of the open plan office. There is likely to be a hierarchical structure to each team with a one or two Chiefs and then many Indians.

Games companies typically tend to have this structure as game building is very much a large team activity, especially with the modern consoles and large budgets that accompany them.

The Consultancy

Consulting companies tend to treat staff as experts in their field. The company understands that if their staff can't solve a problem, they'll find someone who can.

In this type of company you'll be given freedom to work and you'll be treated like an adult. But you may be left to just get on with it.

This type of company would tend to employ someone with experience rather than a fresh graduate and the office is likely to be fully open plan.

The Start-up

Small, agile, and with time to market a priority, start-ups can be fun, energetic and hectic. If you're lucky enough to have an office you'll be sharing it with just a handful of others, some of whom may have experience but all of whom will be passionate about what they do.

Expect to roll out core software on Monday.
Explain it to your client on Tuesday.
Fix a bug in it on Wednesday.
Deploy a fixed version late Thursday evening.
And spend Friday afternoon in the pub with the directors celebrating a great week.

Don't be surprised if you get asked to help build the company website or install a company-wide version control system as the company will be too small to have a dedicated expert in that field.

Working code is worth its weight in gold.

Write your tests.
Write your code.
Update your diagrams.
Done.

See the mention of copious reams of documentation here?
No?
That's because there really is no need to write them.
Why?
Because there is no point in spending hours of programmer time trying to write a document that will never be read.

Class diagrams are useful to quickly illustrate the architecture to newcomers but that's all the additional documentation you should need to explain how things work.

If your code is written well - i.e. well laid out classes with suitably short, well-named functions that do just one thing - the tests and the working code will be sufficient to easily explain what it does and how it does it.

It should be like looking up the word "dictionary" in a dictionary. It's functional - in giving the definition - and it also explains what it is.

How to find a career you love

I while back I posted that to be successful you should be in a job you love.

And it's good to see that Steven Covey (of The 7 Habits of Highly Effective People fame) agrees with me!

He says:

Discovering your dream job involves asking yourself these basic questions over time :
(1) What do you really love to do?
(2) What do you do well?
(3) What should you do so that you tap into your true voice?
(4) What does the world need?

So far, his blog is definitely worth a read.

C++ Programming Tips

Inserting into a sorted std::vector

MyVec.push_back(MyInt)
if (MyVec.size() > 1)
{
  std::inplace_merge(
    MyVec.begin(), 
    MyVec.begin() + (MyVec.size() - 2), 
    MyVec.End());
}

This won't be the fastest way of performing an insert, but it will probably be the smallest amount of code. For the fastest way, look at finding with a binary search, then inserting.

Disclaimer: If you are going to be inserting many things into the middle of a vector, you probably shouldn't be using a vector. A list would be more suited.

Constructor variable initialisation order

This is a subtle C++ism that I forgot about and caught me out today.

When initialising items in a constructor's initialisation list, the order of initialisation is dependant on the order the variables appear in the class definition, not the initialisation list.

An example will help:

class MyClass
{
  MyClass();

  int a;
  int b;
  int c;
};

MyClass::MyClass() :
  b(0), c(0), a(0)
{
}

In the above example, a, will be initialised first followed by b, then c.

The Superstar Premium

An interesting article appeared today on the BBC website about the Superstar Premium. It basically says that the superstars are getting richer because of nu-media allowing them to be a global phenomenon. Instantly.

The Superstar Premium idea also applies to products such as music and video games.

For example video games fall into two categories, triple-A games and the rest. The AAA games go on to sell millions worldwide, whilst the rest - although costing virtually the same amount to make - can sell just a few thousand.

Even though the Premiership footballers and the triple-A games aren't thousands of times better than the rest, they earn tens or hundreds of times more. Why? Because they are better.

And when you are excellent, being just a couple of percent better - to make you the best - makes you so much more valuable. After all, who wants to finish second? And if you can sell your brand of "the best" product to a worldwide audience you're going to make a considerable amount of money.

AJAX Breaks my Back Button.

My last post about whether programmers should be allowed to wear headphones sparked a fair bit of debate, both in the comments and on the dzone website.

So, today I'm going to continue the controversy by talking about the problems with AJAX.

Now, don't get me wrong, I'm a massive fan of the potential of AJAX.

But it breaks the browsers back button.

This might not sound like such a big deal, but there are millions of web users who like to surf through links randomly, aimlessly wandering their way through cyberspace. To them, the back button is their piece of string in the dark cave of the internet.

Without it, the internet doesn't work as a link stack any more.

AJAX is essential for the future of the web, but developers should make it their priority to try to fix the problems that is produces.