Outsourcing blog parts

It seems to be very modern to outsource thse days, and I’m trying to keep up. A while back I switched my RSS feeds from WordPress Build-in services to FeedBurner. It was a win-win. Has a lot less load and feedburner does a lot of work to make sure the Feeds are in top-notch shape.

Yesterday another little change happended. All the website commenting were outsourced to Disqus. The signup procedure was a breze and they had a nice plugin available for wordpress making the switch a 5 second job. So far it seems to work well and once again the server hosting the website should have a smaller load in the future.

Code exit strategy – 3 tips

It seems many developers get stuck in the same systems maintaining the same code for years and years. While it may be a common phenomenon there are a few things you can do as a developer to avoid being trapped in your own code forever.

First make things readable.

While your brain may be wired to a system of only using single character variable and function names or naming global variables after your cats, no one else will get the system. Try to make all names as logical as you possible can. Making it easy to read the code – not only as syntax but also in the names used in classes, functions and other objects in your source, improves the likelihood that someone else can figure out what’s going on and inherit the code someday.

Second make the code do what it supposed to.

Sure it may be cool making the system a generic all-purpose Swiss army knife of software, but preparing the code for all sorts of functions with aren’t used and aren’t needed, it only cause confusion of the next developer trying to move your code forward. Objects and class hierarchies may be suitable in some cases, but sometimes it’s more wrapping and declarations than actual code – and you’re probably on a wrong path.

Third provide in-line documentation.

Documentation are like a ghosts – it probably doesn’t exist. Making pages of documentation is probably a neat way to spend time if your on billable hours, but if you’re a regular developer, documentation is – at best a necessary evil. Do try to provide brief relevant comments, when something complicated or “not too obvious” happens in the code. Don’t place small novels in the source, but short precise guidelines.

While the above tips doesn’t guarantee your freedom to move on to new exciting projects, it surely improves the odds dramatically when you code is inheritable and accessible by another developer.

Looking forward – looking back

There are some fundamental differences in how Microsoft and Apple does things. If you haven’t been aware of them before switching from a Windows based computer to a Mac, you’ll probably notice some of them pretty fast.

One of the first things I discovered is that things are more “binary” in the Mac world. If you have an external device it either works with the Mac or it doesn’t. There isn’t that middle ground from the windows world where it almost works, but not quite – or worse it works in even week numbers but not when the sun shine.

Another thing I fear I’ll discover after the next Apple World Wide Developer Conference is their will to leave things behind. Microsoft has an impressive – maybe even amazing – record of backwards compatibility. Almost no matter how they move forward, they never really break anything backwards. Apple on the other hand is pretty hard on legacy – if you can’t keep up, you’re left behind. They were among the first to drop the disk drive, and they been much more efficient in moving their user base to the current version of their OSX (not quite like Microsoft, which seem to have a hard time getting their users on to Vista).
I’m afraid they’ll announce that the next version of OS X – the 10.6 – is Intel-only – leaving my PowerG5 behind. It doesn’t feel like an old nor slow machine, but once Apple decided it’s too old – it really doesn’t matter – and I better start saving some cash for a new Mac.