The Data Asylum

Programming, Databases and People

Switching From Web to Desktop Application Development

Switching jobs and making a career change is a big challenge. New problem domains to learn, new working relationships to build, new brand of instant coffee to get used to. For a programmer one of the more interesting changes can be moving from working on web applications to desktop applications. Here are a few points that i've picked up having made the plunge a few months ago.

  • Control of environment. As a web programmer you have a lot of control of the environment your application runs in. Browser issues aside, once a HTTP request hits your servers you have complete control over what happens next. A desktop application has little control over where it is being run, what software is installed with it etc.

  • Managing performance. A desktop application performing poorly can be a nightmare to diagnose. The characteristics of the users machine and currently running processes are completly foreign. If your web app is running slowly you not only have the program available but intimate knowledge of the hardware and architecture it is running on. You can make tradeoffs on the servers that your users may not be willing to do for your desktop application.

  • 24/7 operations. Most web developers will not only have to create the application, but support it as well. These problems that occur on live systems are usually given high priority pushing more long term work to the back.

I had no idea how narrow my knowledge was. I'd be interested to hear your thoughts. Have you made the switch from web to desktop, or in the other direction?

Creating a Static Class Variable in Ruby

One of the patterns I (over)use in php is having a class with only static variables and static functions. To do this in ruby isn’t as straight forward as it could be, so here is how to do it.

class StaticKlass

    # ruby class variables are prefixed with '@@' .
    @@variable = nil

    # If you want to provide getters and setters you cant use the attr_accessor
    # keyword, you have to create them manually. By adding the class name to
    # the method definition, we are indicating that this is a method on the
    # class, not in instances of this class
    def StaticKlass.variable= (x)
        @@variable = x

    # the getter is defined to return the class variable when called
    def StaticKlass.variable
        return @@variable


My Widescreen Desktop

This is how I organize my widescreen desktop.

My Desktop, with the taskbar on the left hand side.

The main feature is moving the taskbar over to the left hand side. When editing code or reading a website I would rather have more space vertically. It is also easier to select a window when you have a lot open. The Quick Launch toolbar is more useful, because you can have a lot more shortcuts without taking away taskbar space.

WTF - Scheduled Reports

Working on scheduled reporting systems, you expect to see the same concepts. What format wiil we send the report in? How will it be delivered? I opened the “scheduled report” table to see how this particular system had been implemented. I couldn’t immediately find which column i was looking for. In fact the only one that looked like it might be useful was something called deliv_method.


Ok, so we’ve got a numeric list of delivery methods. Nothing too unusual about that. I just need to find the list either in the database or codebase. But where do we store the format of the report? I worked my way through the report scheduler code until i found this.

$delivMeth = ($row['DELIV_METHOD'] >> 8);
$myFormat = ($row['DELIV_METHOD'] & 0xFF);

Are those bitwise operators? And even a literal hexadecimal number? The only place i’ve ever seen a bitwise operator is when setting the error reporting level. I’ve looked at this a few times and am still not sure i correctly understand it.

The answer eventually revealed itself.

$a = array(
	0x0104 => 'Email HTML',
	0x0204 => 'Email HTML Attachment',
	0x0284 => 'Email HTML Zipped attach',
	0x0201 => 'Email PDF',
	0x0203 => 'Email TSV delim',
	0x0283 => 'Email TSV delim zipped',
	0x0203 => 'Email CSV delim',
	0x0283 => 'Email CSV delim zipped',
	0x0304 => 'FTP HTML',
	0x0301 => 'FTP PDF',
	0x0303 => 'FTP TSV delim',
	0x0303 => 'FTP CSV delim',

Pretty clever you have to admit! Unfortunately it can lead to same rather ugly code.

if ((($('#INPUT\\[DELIVERY_METHOD\\]').val() & 0xFF00) >> 8) != 0x03){

Why Hire a Senior PHP Programmer?

One of the first questions I ask when attending an interview is why are you hiring a senior PHP programmer? It is a question born out of cynicism. If everything is going well in your organization why change things by hiring someone? But also the question is 'Why do you need someone with lots of experience'. They are going to be more expensive so why are you spending the money?

In Joel Spolsky's book on hiring programmers, he states :-

The great software developers, indeed, the best in every field, are quite simply never on the market.

Sitting on the other side of the fence, I believe that the opposite is also true. The great software jobs are quite simply never on the market. There are many reasons to hire a senior programmer. Let us have a realistic look at them from the point of view of the jobseeker.

  • The business is growing and we have more paid projects then the current staff can handle.
    • This is the most common answer, and sometimes it's not rubbish. It's one of the better answers but the problem for the jobseeker is there is no real way to disprove it. Also you have to ask why do you need more than a mid-level or even low level programmer.
  • Our senior programmer quit, and we are filling in his position
    • Why did he quit? Is he moving cities to look after his sick aunt? Or did he just quit because he didn't like the job? It is once again hard for the jobseeker to verify this. Even if they gave you permission to speak to the ex-employee, would you believe it if he told you it was the greatest job on earth? Perhaps asking how long his tenure was may offer an insight.
  • We only hire experienced people
    • If everyone is senior who makes decisions? Who does the boring crap? (Seriously there are often a lot of repetitive tasks that are perfect for a junior to cut his teeth on, and would drive a senior person insane with boredom). Who am I going to mentor?
  • Our platform is a complete mess and we need senior people to decipher it
    • While this is a cynical view I believe that there are quite a few positions where a senior position is required because of this very reason. It will not be stated explicitly or even understood by the people hiring, and can be a real surprise for employees walking in to a new position. Trying to tell if this is the case before hand is tricky. The sad thing is that this type of challenge could be attractive to a senior person. Give a technical person the opportunity to make something better and they (should) grab it with both hands.

What are the other reasons to hire a senior programmer? Get it off your chest and leave a comment!

Help Eliminate Bad Code

The Bad Code Offsets project is an attempt to get programmers to put money into open source software. We may not be able to change the bad code we have written. Instead we can buy an offset that goes towards creating more good code.

Bad code lives on well past the time we inflicted those bad lines into the global code base. Applications continue to live their lives serving businesses, consumers and the global community at large. Bad code weakens the utility delivered by these applications causing business loss, user dissatisfaction, accidents, disasters and, in general, sucks limited resources towards responding to the after effects of bad code rather than toward the common good.

They have just made a $500 grant to the GPSd project, which aims to shield developers from the idiosyncracies of integrating each GPS device available.

How often do you use open source software. How often have you contributed, either by submitting code or donating money? My gut feeling is that at least 95% of developers haven't done either. The 10 USD I donated will be going to the Apache software foundation. The apache webserver has been at the base of nearly every project I've worked on and will be for a long time to come.

2 Points to Remember When Interviewing Developers

  • Sell your company. Tell a story. Where you have come from and where you are going. Why the position is so important to continuing that story. What technical challenges are the company facing. Keep it interesting and relevant to the position. You want everyone who comes for an interview to want to work for you. Even if the person is not right for the job, word of mouth amongst potential employees is a great tool for getting people through the door.
  • Qualify the applicant. Ask hard questions and let them prove their knowledge. Most of the enjoyment you can receive from a job is through co-workers. One of the concerns a job seekers will have is the quality of their future co-workers. By showing that you are screening out lazy, boring and unqualified people, the person will feel more comfortable about taking the job. Instead of wondering if the company will be good enough for them, they will start to wonder if they are good enough for the company. It also puts a level of expectation on the applicant which is a good place to start the work relationship.

grepWin - Grep for Windows

grep is an often used tool on linux. It’s job is very simple, to find a string (or regular expression) in a group of files.

grepWin is a gui version and is a lifesaver if you have to use windows as part of your development environment. The best bits are

  • Integrates with windows explorer. Search any folder by right clicking on it.
  • Results behave just like a windows explorer folder. Right click on the files to edit from the results panel.
  • Regular expression support. A feature compared to windows built in search.
  • Search and replace. The tool goes further than grep and will do a search and replace over many files.
grepWin Screenshot

How to Be a Programmer - Circa 2002

While looking through some old files I found this gem. It's an essay written seven years ago by Robert L. Read called "How To Be a Programmer: A Short, Comprehensive, and Personal Summary". It covers a what the writer feels are the most important skills to learn across beginner, intermediate and advanced skill levels.

I remember being heavily influenced by this as it appeared a short time after I first had a real job. seven years is a long time in technology and I was wondering if the advice in it held up. Here are a few excerpts.

2.9 How to Deal with Intermittent Bugs The intermittent bug has to obey the same laws of logic everything else does. What makes it hard is that it occurs only under unknown conditions. Try to record the circumstances under which it does occur, so that you can guess at what the variability really is. … Try, try, try to reproduce it. If you can't reproduce it, set a trap for it by building a logging system, a special one if you have to, that can log what you guess is what you need when it really occurs.

When I first read this many years ago I was relieved. It's not just me that has these problems. I've used this formula too many times to count.

6.7 How to Know When to Apply Fancy Computer Science There is a body of knowledge about algorithms, data structures, mathematics, and other gee-whiz stuff that most programmers know about but rarely use. In practice, this wonderful stuff is too complicated and generally unnecessary.

It's the biggest contradiction in our industry that a lot of importance is placed on solutions to complicated problems when most of the time simple solutions to simple problems are needed (and more desirable).

4.1 How to Stay Motivated It is a wonderful and surprising fact that programmers are highly motivated by the desire to create artifacts that are beautiful, useful, or nifty. … There's a lot of money to be made doing ugly, stupid, and boring stuff; but in the end fun will make the most money for the company.

I'm not sure where I stand on this one. As much as I'd like to believe that fun is always the way to go I'm not sure that it will always pay the bills.

Overall it is still a relevant and important essay for any programmer at any level.

Glue Code

Glue is what holds your application together. Code needs to talk to databases, Javascript is calling your PHP functions using Ajax. When two systems, or different parts of the same system need to talk to each other, you end up with glue. It (hopefully) doesn’t have any business logic. It’s used or copied by at least a few different parts of your system, perhaps even in different projects in the same organisation.

Glue code holds things together. The only problem is that glue is not your application. Unless you're developing a framework, operating system or perhaps something that needs plugins, glue is not your strength. There are always exceptions but if you are writing glue, especially the same glue for the 3rd or 4th time, then you're not directly working on the application you are building.

Having said that, your project won't survive without glue. So how do you keep everything together?

  • Recognise glue. The first step is to understand that you are now writing glue code and not working on business requirements. For example, say you are writing a script to process files that are uploaded to your server. Discovering the files is glue, the processing of then is specific to your application.
  • Standardise across your organisation. Glue may start out as a one off but as time moves on it will become apparent which pieces are worth time improving and which aren't.
  • Make it as simple to use as possible. It will need to be understood by a larger group of developers than your other code. Put that extra time into documentation and code beautification.
  • Make it as robust as possible. You don't want this getting in the way of your 'actual' work.
  • Use 3rd party glue. Someone has nearly always been before you. Wiring your PHP and JS together with AJAX? It's been done. Creating a DB access class? Been there, done that. If you think you can do better your probably wrong. You may write better code, but you probably won't document or test it as thoroughly as an open source project has already been.

In conclusion, you want to keep glue simple and straight forward. Recognise what is and isn't glue in your application. Share the glue you have with every one in your team, and if your brave, the outside world.

The idea of glue is described in Eric Raymond's excellent book The art of unix programming.