Software Engineering on UberMongoose

A Concise Guide to Hiring Good Programmers

Mon, 03 Aug 2015 17:12:14 +0530

The best way to hire a good programmer is to be invested in his or her results. It’s like getting married. You want to be careful to choose the right kind of girl, the kind of girl that you’d want to spend the rest of your life with. Just like marriage, it can make your life as close to heaven or hell as it can get on earth. Here’s how I about it.

The pImpl Idiom – Hiding Private Implementation Details

Thu, 17 Jan 2013 16:16:31 +0530

One key principle behind the design of classes is that of the encapsulation of the implementation from the clients using the code. Here a client is any bit of source code that uses the classes that you write. C++ provides an imperfect implementation of this idea in the way it defines rules for classes. Consider the following class which is declared in event.hpp.

#include "system_clock.hpp"
 
class Event
{
 
private: 
    SystemClock mClock;
    std::string mMessage;
 
public:
    Event(std::string message);
    ~Event();    
};

The Event class models an event that can happen at some point in time. It uses “system_clock.hpp” which defiles a class called SystemClock to see what time it is. Notice that both the message and the current time as defined by the member variable mClock in Event is private. This should mean ideally that any changes to the variables in the private section of the class is not exposed to the client code and indeed to an extent it is. No client can create an instance of Event and then access it’s private members like so:

Sociable Programming

Mon, 10 Dec 2012 10:42:43 +0530

Programmers are not known to be social creatures. It’s an unfortunate reputation really, considering that programmers spend most of their lives writing their thoughts to each other - they should be right up there in the social landscape with Paris Hilton and Lady Gaga. The problem of course is that programmers never recognise the social aspect of their work. They think they write code for computers. Nothing could be further from the truth.

Step on that Code

Sun, 02 Dec 2012 16:09:10 +0530

In Sociable Code I mentioned that an often overlooked consideration when writing code is the strain that it puts on the programmers who end up reading it. Difficult to read code tends to mash the wetware and end up causing more bugs and longer resolution times. One way to reduce that effort is to write code that would make control flow explicit when being stepped through with a debugger. Take a look at this bit of code. I came across it during a foray into a rather well known programming site. I have endeavoured to anonymise the code but the key piece has not lost it’s form.