No version control

This is a pretty bad one! I’m glad I learned to use SVN at an early age…

Always use version control in your projects. Be it Git, SVN or even CVS, as long as you use something. It’ll help you avoid a thousand problems!

Here’s some of my posts about Git.

No plan

It may feel like just having a general idea (eg. “Hey, let’s make a forum!”) is alright, but it isn’t.

With no plan or roadmap, your project may easily derail into more and more new features, never actually getting anything finished.

Always try to create some kind of a plan that includes the features you want. Make it a Word document, or even better, put it in a tool like Trac or JIRA where you can easily track what you are working on. Not only will this give you a clearer image of what needs to be done, it can be useful to see what you have already accomplished so far.

No schedule

You may have a plan, but do you have a schedule?

Scheduling is as important as having a plan in the first place. Without a schedule, the project may easily keep going endlessly, with very little progress as nobody cares as there are no deadlines.

I have to admit that even now there’s a project I’m working on, without a proper schedule, which has been going on way longer than it should. I plan to fix that, though!

No release strategy

What’s a release strategy? This may not be the correct term, as I just made this up, but I think it’s quite descriptive: It includes how often you want to do releases and the steps involved in making a release.

The most basic requirement is to have a build/deployment script. A single command you, or anyone in your team, can run to completely build and deploy your application. This is important because a minor mistake can cause problems.

How often have you forgot to upload a file to the server when deploying? I bet the number is bigger than zero. Now think how many steps there is even in a simple deployment.. Sending files, setting up the database, maybe installing a default user…

How often you do releases can be important too. For example, in Scrum you develop in sprints and in the end of each sprint is a natural point to make a release with the features chosen for the sprint.

Tools such as Ant can be used to create build and deployment scripts.

Developmestruction

Not having a separate development and production environment is a recipe for disaster, especially if your application is being used in the real world at the same time as development is happening.

I’m a guilty of doing this, but luckily the applications weren’t being used by more than a handful of internal users.

Always perform development on separate machine(s) than the actual production deployment. This ensures the production system should stay relatively intact (unless your deployment screws up or you introduce more bugs).

Additionally, having a staging environment can be a good idea. This should usually be on similar hardware and software as production, as this will allow you to test-drive your code on a realistic setup before pushing it to production.

Not using Test Driven Development

This may not be the most critical problem, but I think it’s important nevertheless.

By having a good test-suite, you can ensure you don’t introduce regressions and that your code works at least as well as your tests were written.

For some reading on testing, check out unit testing essentials and How to make your code testable in this blog.

Post your tips/mistakes in the comments

If you have any tips/mistakes of your own, please share them in the comments. I’m still learning too, so they would be great additions to this list.

In this post, I’ll go through the most common ones, and suggest some approaches to avoiding them. Suggest your own errors and tips in the comments!

Boolean logic errors

This was the most commonly encountered problem. I have also made mistakes with boolean logic more than enough times.

Boolean logic errors usually manifest in if-else statements, as they are the main pieces of code where you may run into complex statements to determine what to execute.

There are various ways to avoid these, ranging from utilizing OOP better to splitting up conditions to multiple statements:

• Split conditionals into multiple statements: As this tip’s name says, split your complex conditionals over multiple statements. Not only will they be more readable, they can convey the meaning much better.

  if(!($user->level == 1 && in_array($bannedUsers, $user->id) || 
    $page->name == 'index') {
    ...
  }
   
  //vs
   
  $isMainPage = $page->name == 'index';
  $notBanned = !in_array($bannedUsers, $user->id);
  $loggedIn = $user->level == 1;
  if(($loggedIn && $notBanned) || $isMainPage) {
    ...
  }

  I had a better example in mind from some recent code I modified, but I forgot it. However, this kind of made-up looking example still demonstrates the point – as you can see, the condition is much cleaner and it’s quite obvious what the requirements for the if-clause passing are.

  In fact, while writing the above example, I almost made a logic mistake.

• Utilize OOP and polymorphism better: Often an if-else may be used to determine some course of action. In many cases, this could simply be abstracted into a class, and the concrete implementation of it would determine the course of action, without the calling code needing to use if-elses.

  There’s a great Google Tech Talk about Inheritance and polymorphism which shares a great deal of information on how to avoid conditionals completely.

Typos or unintentional omissions

Typos and omissions are some of the most common issues people told me about. Typos should be quite obvious: Misspelled variable names, function names and such. Unintentional omissions may be a little less clear at first – By omissions, I mean things like forgetting to remove debug statements, forgetting to upload a file or other things like that.

I’ve grouped these two mistakes under the same headline, as they belong in the same category: Mistakes caused by not paying enough attention, or in other words, being sloppy. Another cause is plain and simple forgetfulness.

While these two aren’t always very fatal mistakes, they can be problematic and annoying. For example if you check in code with typos or omissions to source-control and your coworkers get broken code.

How to avoid typos?

• Use a programmer’s editor or an IDE. They will often support code-completion and are often able to highlight misspelled names
• Write slower: While this sounds really obvious, you might not really need to type that fast. While I personally take some pride in being a fast typist, sometimes it’s just difficult to write things correctly when you’re simultaneously thinking about things like implementation details or how to name your variables etc.
• Become a better typist: The opposite to the above, by becoming a better typist you can write faster and make less mistakes. While learning to be a fast writer may not rank very high on your to-do list, there are ways to make it quite fun. A good example is Typing of the dead
• Get a better keyboard: Your keyboard may not be bad per-se, but perhaps you’d be more comfortable typing with a different one? I’ve noticed some changes in my correctness after getting a Logitech Wave keyboard to replace my aging Microsoft Multimedia Keyboard

A reader also suggested learning to use the dvorak keyboard layout instead of qwerty. If you have the patience to suddenly become the world’s slowest typist for a while when learning the new layout, this may be a fun and useful skill.

A spelling corrector may also be a good thing to have at hand.

What about omissions?

• Read through diffs: Before commiting code to source control or creating a build, you can save your and everyone else’s time by going through the diffs for your changes. Not only will this let you spot any accidental omissions, you may actually spot a genuine bug while at it. Even better, you might want to get someone else to review the code with you
• In general, version control tools like svn and git are good for avoiding omission-like mistakes. They can display you a list of modified files, unversioned files and other such things, which can help you find the errors.

Debugging mistakes

While not strictly a programming mistake, these are very much related.

Debugging mistakes can be so many things that I’m not going to go into all specific details. However, there is one common occurence: Wrong debug methodology.

How do you know your debug methodology is wrong?

You constantly go deep into code to figure out some problem, and it turns out it was something really simple, such as a missing file.

The old IT support mantra comes to mind:

- Is it plugged in
- Is it powered on
(repeat for each peripheral)

While this appears in various tech support jokes and such, this is a valid methodology: By ruling out the mistakes that are easiest to detect, you can save a lot of time if it was one of them.

Quite recently, I worked on some code that needed to be built to run. I could debug it from the IDE without building, and for some reason the code worked perfectly well in the IDE but not with the build.

I probably spent an hour or more, looking into various internals of things that seemed to be causing the issue. In the end, it turned out the build script was broken: A new directory I had added wasn’t included in the build, breaking the application.

If I had checked the relatively easy to test issue of having all directories in the build, I could have saved much time.

If you have a bug that seems elusive, check the obvious things before spending a lot of time debugging it. It may end up saving you much time and nerves.

JavaScript closure misunderstandings

While the other problems aren’t language specific, this one was also common enough to include in the list.

JavaScript closures can be very confusing if you aren’t used to them. I used to get confused by them all the time.

The typical mistake looks like this:

var obj = {
  prop: 10,
 
  myFunc: function() {
    alert(this.prop);
  },
 
  otherFunc: function() {
    setTimeout(this.myFunc, 100);
  }
};
 
obj.otherFunc(); //does not alert 10 correctly!

While the problem here is obvious to JavaScript veterans, it’s not so easy for beginners – even if they’re experienced in programming otherwise!

The fix to above is to wrap the timeout call:

var self = this;
setTimeout(function() {
  self.myFunc();
}, 100);

I won’t go into more details here, but there’s plenty of material on JS closures on the web.

What did I miss?

Out of the dozen or so mails, these are the most common ones. I was hoping to list at least 10, but due to lack of participation I couldn’t.

Do you have a common problem you encounter when programming? Do share it, or your other tips , in the comments!

I’ve had time to play with it for a while now, and while it’s a pretty cool concept, is it actually useful for anything, or will it be?

Wave terminology

To understand Wave better, you need to know about what the terminology used means. A wave is kind of like a thread in a forum, except anyone can modify it (no read-only mode at the moment). Waves consist of blips, which are single entries in the wave by users or robots. By default, waves are private. However, you can invite other users or robots to participate in your wave, or make it public.

A robot is an artificial Wave-client. When a human user uses the browser as the client, a robot is just a programmed client running on a server. Kind of like an IRC bot.
Robots can do everything a human wave user can – they can post blips, edit them, etc.

Waves can also include gadgets. They are similar to iGoogle gadgets, for example it could be a chess board or a map. Gadget state is synced to all participants of a wave, so you could play a game of chess with your friend on wave (after they make it so that you can’t move the opponent’s pieces, but let’s not get stuck on the small details )

Here’s a screenshot from Wave with wave and blip indicated:

(click for bigger image)

Robots and gadgets

I think a big part of Wave is robots and gadgets, because they allow anyone to extend the functionality provided by the “base”.

The sharp eyed might have noticed some robots in the above screenshot: Calcbot, Rssybot, Graphy, Tweety, Wikify and Wave Live Messenger.

• Calcbot is essentially a calculator. The screenshot above includes a blip from calcbot, displaying its usage instructions.
• Rssybot allows you to embed any RSS feed into any wave, making it a feed-reader replacement, as you could store your favorite RSS feeds as waves into a folder
• Graphy draws graphs. There’s a small graph showing in the screenshot as well.
• Tweety allows you to use twitter through Wave. It seemed to work rather well, with one exception: It did not update new tweets from your timeline. However, it would seem this is merely because the person who wrote it has not implemented it yet
• Wikify allows you to easily embed links to wikipedia into waves
• Wave Live Messenger, as you might guess from the name, allows you to chat with your Windows Live Messenger buddies through a wave. It worked, but it is rather rudimentary at this point, and a bit buggy

These are just some bots I tried. There’s a lot more, like a bot which converts text into pirate speec (yarrrr!), and as said, anyone can write their own bots. Hopefully someone will write a bot which implements libpurple and allows you to use the most popular instant messengers via wave. That would be very cool, and as Wave Live Messenger demonstrates, very much possible.

I have not tried many gadgets, mostly because I couldn’t find any definite source for good Wave-compatible gadgets. However, there are several ones that Wave shows by default, such as the chessboard visible in the screenshot, a Google Maps gadget where you can place markers for anyone to see, a “Who’s coming?” gadget etc.

You could also think of embedding youtube videos into waves as being a gadget. Yep, just paste a link from YouTube and Wave will display a little icon which you can use to turn it into an embedded video, which also works quite nicely.

User interface

The user interface is pretty similar to Gmail or other mail clients. However, it’s possible to customize it nicely, for example you can resize each column, or hide them. You can also minimize a wave into the area on top, which could be useful if you have a wave where you chat with your friends – similar to having an IM window or an IRC channel open.

The UI also shows various hints when you move the cursor around. Hovering over a blip will display some buttons you can use to interact with it, such as reply to or edit the wave.

In general, it’s very responsive, which makes it nice to use.

Stability and usability

A concern from some is that this a very ambitious project that’s might not work out.

The good news is that it works just fine. Not in Opera (stop being lazy bums, Google!), though, but I’ve used it in Firefox 3 and Chrome where it works quite well. There have been some days with a lot of downtime or slowness, but that’s probably because it’s not quite there yet.

Sometimes the Wave updates also seem to break the robots, but once again this is probably due to the fact that the API is not 100% stable yet either.

Wave is a viable email/IM replacement and more

This sums up my opinion of Wave: It is very much a viable email and IM replacement.

You can think of various other uses too: A forum, a personal/group wiki… Facebook replacement… It’s a very viable IM and Twitter client too, as the robots show – just needs some more polish.

However, right now it’s not very useful. This is because it’s not very likely that anyone you know is using it (unless you work at Google). At the moment it’s also a bit difficult to “moderate” a wave – you can’t lock or make it read-only, so every participant can edit everything. I hear things to limit editability are coming later, but even with them it may require some rules and restraint from the participants to make it easier to follow a conversation.

I think what Wave can be largely rests on the users: It depends on what kind of robots and gadgets people write. Without them, it still will be a good alternative for email and IM and perhaps some other uses, but with them it can be much more, and even the email/IM stuff will be much better.