A lesson in archiving software systems

Posted by .

Prompted by various situations lining up, I spent some time last night dusting off my old CedarRapidsOnline.net web service and trying to make it run again. Before shelving the source code a couple of years ago, I had taken time to document it, so it should be easy to get it running again. Let’s see… I need Python, PostgreSQL, and the Python packages PyGreSQL and CherryPy. Sounds good.

But wait, what version of Python? Does it matter? What version of PostgreSQL? Does it matter? What version of PyGreSQL and CherryPy?

And oops, it seems PyGreSQL doesn’t build properly on my Mac, and there’s no precompiled binary available from the developer.

After some poking around, I finally got all of the individual pieces in place, I think, but then the whole system doesn’t work! I must still not have something right, but I’m not sure what.

Grr. I think I’ll just update it all to use Python3 and newer versions of the other tools, rewriting from scratch anything that I need to.

Lesson learned: document not only the tools used to build the software system, but the versions of the tools, and, if at all possible, make an archive of the tools themselves in case you can’t download them again later…

Native Applications or Web Applications?

Posted by .

One of the things I’ve been contemplating most from my recent trip to MIT is the hypothetical decision of, for any given software application, should I write a native application that runs directly on the phone or PC, or should I write a web application? Our instructor, an accomplished software developer, pointed out that the web applications he built nineteen years ago are still running just fine, while he doubts that any native mobile phone applications written today will even be usable, much less running, nineteen years from now. And on top of that, it’s usually much more complicated to write a native application than to write a web application that does more or less the same thing.

After investing a fair bit of time into learning iPhone development, that hurt a little to hear! But further consideration leads me to the same conclusion. For all of the hours I poured into iPhone programming, I’m still pretty disgusted by it. I wince when I envision the drudgery involved in making even modest changes or additions to an iPhone application. But web applications have always felt pretty streamlined overall.

But what about making money? Isn’t it super easy to make money on the iPhone App Store?

I’ve recently been making some designs for a music education program that I planned to develop as an iPhone application. Yesterday, a friend showed me her new iPad, and asked what I thought about running GarageBand on it for basic music tracking. I said it’d be hard to go wrong with that option, as it only costs five dollars.

I seriously doubt that my planned music education app would have 10% of the overall functionality as GarageBand, so maybe I could offer a good value on the iPhone App Store if I just gave it away for free!

At least with web applications, you can justify time and resources spent hosting and maintaining the application, and charge money accordingly. Big companies might think it’s a good idea to build iPhone applications just so their marketing departments can say that they have one, but for an individual software engineer, maybe it’s not only more technically pleasant to write web software, but potentially more profitable…

2012 Trip to Boston and MIT

Posted by .

I got back home yesterday from taking an intense three-day programming class at MIT. As usual, the Boston area is a delight to visit, and MIT is a fascinating place to hang out (at least if you’re into science and engineering).

The weather was delightfully unseasonably warm, making the mile-long trek from the hotel to the classroom quite reasonably pleasant.

New BP Interface Software

Posted by .

Stopping for gas at the area BP station this evening, I was pleasantly surprised to see that they have updated the software behind their self-service gas pump interfaces: when you press “Yes” it instantly accepts a “Yes”, and when you press “No” it instantly accepts a “No”. Very nice.

In the past, when declining the offer to purchase a car wash, I found myself pressing “No” repeatedly several dozen times before the system finally registered by response, but on the rare occasions I did want to get a car wash, it managed to accept my “Yes” response immediately…