The Humble Geek

Stuff I write.

Thirty Ways a Software Grows

The following recount is rather generic in nature so I do not have to worry about stepping on any toes, but it is all true.

yeah

Everyone has a workplace story to tell and I've finally gotten around to writing about my own. I have had a rare opportunity to write and maintain software for a company that has plenty of history. The company I, still, work for has been around almost as long as Microsoft to give you a point of reference.

In The Beginning In traditional fashion of the time, which still holds true today, the company started by buying the rights to a software that someone else wrote. The country of origin: Canada. I do not know much about the company or who were the original authors besides a few names I've seen in copyrights, so unfortunately I do not have any juicy stories to tell about them. They wrote to Minix, which surprisingly still exists today. The data was stored in ISAM databases (Google it), which unfortunately still exists today. The program displayed via a terminal-based text screen with support for input fields and displaying different types of screen layouts, which, also unfortunately, still exists today. The only saving grace was that it was written in the C language.

Abraham Lincoln The company originated in a log cabin, now turned historical landmark. I heard the winters were cold, and the summers were hot. The size of the cabin is about the size of a traditional living room with two whole stories. There was also the shift from Minix to UNIX and DOS operating systems to keep up with growing demand.

Enterprise Split Eventually the software became outdated, in a sense, for the customer base the company wished to sell to. Enterprises wanted a more robust and fully featured software. The solution? Rewrite! The company moved to a different city, but left behind the original software - to live in its own filth.

Dungeon Upkeep Keeping the software maintained to a point people could still use it was the job of a fellow I only met once when I was being interviewed (for an unrelated position!) so I can't tell you any juicy stories about them either. However, I can tell you the software essence remained the same. They continued to use the original UNIX compiler and coding techniques. These techniques include typedefs to normal C keywords and functions. Numerous programs that simply copy & paste code from other programs. Global pointers ruled the entire source code base from top to bottom. Return values were rarely checked. Instead of calling the standard rename or delete functions, system calls were made to the operating system's shell tools. The source control system involved cloning the main source directory per release - some of which I did not find when I took over. Take this scenario for instance: One customer was given a compiled program on Monday but changes would be made to the same program and given to a different customer on Tuesday. Every customer had a unique compiled version of the software. Let that settle in your mind for a moment.

Change of Hands A friend of mine, who has moved on to greener pastures, took over a few years ago. He began a very important and rigorous job of evolving the software into a state that a guy off the street could come in and program to. The code went from 1980s leftovers to 1990s l33tsauce. It was now source controlled in CVS and macros were removed. Some of the copied code were moved into libraries that were compiled against. A small set back to the improvements happened when another programmer was hired and began transforming perfectly good code into obfuscated and over coded code. String pointers were turned into "static const char *const variable;" nightmares. Functions were rewritten to be twice as long and contained bugs that I had to find and fix for about a year.

Modern Tools After I took over we released a major version. This version was the first version where all of the software was released in one update. It was all source controlled, and I implemented a sane update system that insured customers would all be on the same software level. Lately we've moved the code into git and I have been loving every minute of it. The software is slowly emerging from its colorful past.

Over the Rainbow GUI, SQL, Cross-platform. These three words are the embodiment of the future of the company. If I get a chance to finish the project, it should provide the company and its customers with a fresh breath of life.

SSDs Speed Up Anything and Everything

Computer storage technology was running out of innovation a couple of years ago until the next step, in many steps to come, arrived: the Solid State Drive. Quick summary: Traditional hard drives are spinning discs of a magnetic substance that hold all your precious junk. An SSD is a collection of flash memory modules similar to those found in SD cards for your handheld camera. The end result is RAM-like performance without the con of losing everything when you turn off the power. It's hard to grasp this concept until you've seen the difference first hand.

First up I decided to install Fedora 12 x86_64 and perform a package update. This involves hundreds of packages ranging in all shapes and sizes. On a traditional hard drive I would be dreading the thought of performing this operation as it would most likely take about 15 minutes of my precious time. My mind can now rest at ease with the speed of an SSD:

 

The target device my SSD was going into was the Sony Playstation 3 as I noticed the multitasking introduced in previous updates caused excessive hard drive usage, most likely by usage of lots of swap space. It's slightly visible in the video below that the performance delta between boot times is different:

 

In other important news, my Grand Theft Auto 4 boot times were reduced by 20 seconds to 1 minute 37 seconds. A new GTA4 patch reduced that by another 4 seconds. I can also tell that there is some intentional latency programmed into the multi-tasking option. Was the $200 upgrade worth it? Yes ma'am!

Problem: Taking out the trash takes a long time to do.
Solution: Install an SSD!

Same Team, Same Game

I'm repeating myself here, but it is a new year after all. The Dallas Mavericks have proven to be very reliable at starting strong and finishing flat on their face. Their record is a mask to their ugly underside. Heck even the humble owner knows they suck - at least that's a step in the right direction.

Win one, lose one. If they can win against teams above .5 and lose against the lower .5 teams then they might make the playoffs. Dirk can barely play full games and the rest of the team cannot maintain any sense of consistancy. I hope a smart, talented, and young player replaces the late Hemp Howard. Maybe this year can be saved. Maybe.

Developing Openly on Proprietary Land

My programming adventures continue. Nokia's experiment into Linux with Maemo is very alluring and since I've applied myself into a few Linux projects, I felt it would be worth looking into what Nokia has put together.

The Maemo SDK runs under Scratchbox, a virtual environment created in part by Nokia. The Scratchbox toolkit can run under any Linux distribution, and it requires it. If you wish to run the SDK under Windows, your only option is to use a virtual machine. Once your SDK is running, it is nearly identical to a running Maemo device. In order to use the SDK, basic knowledge of Linux goes a long way, but since Maemo is derived from Debian there are some distribution specific programs. I've been using Red Hat based distributions for years, so it took some time to get used to using dpkg and apt-get to handle packages. After a few months of using my N900, creating and handling packages takes less work under an RPM system, but it's adequate.

Since Maemo is Linux, any Linux application has a chance of life. This makes building new applications or porting existing Linux applications a walk in the park. You can literally compile any Linux program for ARM and run it, however, the necessary screen space and physical size of a N900 can make it difficult to use a large application such as Open Office, which has dozens of menus and toolbars. This is where Maemo ports come in. A finger-friendly UI can be designed and added, even sent to the upstream authors, and makes the app you port usable everyday on your device.

I started with building a brand new application. A stopwatch seemed like an easy first project. I noticed several stopwatch applications already existed, however they were written in Python or were not maintained in a long time. The Maemo Garage is a center for Maemo projects, so I created my own project page and began work. I decided to write in C, the native language of many Linux core libraries, and use GTK for the UI, a cross-platform, and the native toolkit for Maemo 5. During the programming process, I learned the Hildon additions to GTK made by Nokia, and the dbus methods to activate and listen for accelerator changes to allow my applications to turn into portrait mode when the user turns their N900. Here's the first incarnation: Stopish 0.9.0

Other programming projects are endless. I wanted to look at fixing a few usability issues. One was the RSS reader, which used a slider that was too thin for a finger. I submitted a patch to Nokia and it will be included in the next major firmware update. The second was the lack of FLAC tags in the media player. I now enjoy FLAC as my music format of choice, and it's possible to use since the Maemo media player uses gstreamer for media codecs and tracker for tags. In order to add FLAC tags, I had to extend the tracker program to be able to read them. Someone had already created such a plugin for vorbis, and so using it as a template, I made one for FLAC.

There are two Maemo repositories for projects, Maemo Devel and Maemo Extras. Finalized applications live in Maemo Extras, while developers can play with new applications in Maemo Devel Adding my projects to Maemo's repositories was a breeze. Just create a Maemo account and request upload access. I can use scp (SSH CoPy) to send my source code to the Maemo build server and it will package my projects and makes them available on the Maemo Devel repository. From this repository a developer can choose to promote it to Maemo Extras. During this promotion, other Maemo users vote on the application and if enough positive votes are made the project is automatically pushed into Maemo Extras.

Although most of Maemo is open source and source provided through gitorious, there's still a lot left closed - such as the phone, contact, and media player. Nokia's plans include more open source goodness in Maemo 6. The future of Maemo definitely looks bright even if they are forcing Qt down everyone's collective throats.

New Face, Same Blood

Hi there. You may remember me from such blogs as The Humble Geek. Due to a recent Blogger change, I've had to set up shop using server-side software. I looked at three different projects and ended up with Dotclear. I'll break down my selection pro/con list:

  • Wordpress

The big man in town. Unfortunately it uses MySQL for a backend and my server is PostgreSQL territory. Poor security is another minus. A Wordpress blog has probably been defaced by the time you've read this sentence.

  • blosxom

I saw this recommended as an alternative to Wordpress. It's Perl based and writes to flat files. Not very flexible for my taste.

  • Dotclear

Written in PHP, supporting PostgreSQL, themeable, plugable, and more. I couldn't ask for anything better. I have customized my own theme and added some plugins. The built-in functionality also allows me to add the Geek Tip as a widget. I don't have to manually edit the template as I had to with Blogger.

I may write about my Maemo programming shenanigans next, but don't hold your breath.

- page 1 of 9