Archive for programming

Working with Orientation Changes on the iPhone

// May 1st, 2009 // 6 Comments » // auto-rotation, code, iphone, iphone sdk, orientation changes, programming, sample code, viewcontroller

Update: It looks like Apple has change the way shouldAutoRotateToInterfaceOrientation works in iPhone SDK 3.0. Here is my updated post on how to do this differently.

One of the features with which I had to get fairly intimate with on the iPhone over the last couple of months was working with orientation changes. At first my code was completely incorrect and it wasn’t immediately obvious to me how to get my application to reorient itself properly. This was mainly due to the structure of my code. In this post I am going to explain a simple, memory efficient way of working with UIViewController and interface orientation changes.

1. The Basics

Before we get into the nitty gritty let’s first have a recap of how interface orientation changes work and how you should respond to them. Firstly, if you want your view to auto-rotate you need to override the method shouldAutorotateToInterfaceOrientation: and return YES. If you want to only allow auto-rotation under a certain condition you can put the test for this condition in this method too.

This is pretty much the most basic thing you need to do to allow for auto-rotation but there are additional methods you can override that can be very useful. These methods are

• willRotateToInterfaceOrientation

• didRotateFromInterfaceOrientation

• willAnimateFirstHalfOfRotationToInterfaceOrientation

• willAnimateSecondHalfOfRotationFromInterfaceOrientation

The first 2 methods are very useful for doing pre- and post-processing of your rotation. You could perhaps initialize a view controller or add some views to your current view in the willRotateToInterfaceOrientation. The second 2 are pretty much self explanatory. If you want to perform additional operations during that particular phase of the rotation you can implement them too.

Another very useful code example for when working with view controller orientations is:

    //do some processing…
}else if(UIInterfaceOrientationIsPortrait(interfaceOrientation)){
    //do different processing…}
else if(UIDeviceOrientationIsValidInterfaceOrientation(interfaceOrientation)){
    //do something

Most programmers aren’t aware of these macros and they do cut down and simplify code.

2. Loading & Unloading View Controllers

To save on memory usage you can load and unload view controllers as your interface orientation changes. I found this incredibly useful as my application required a fair amount of memory. It basically works on the principle that the application’s delegate class will manage the changing of the view controllers.

In you application delegate you can add the following method:

- (void) switchViewControllers:(UIViewController *)controller{
if(self.viewController != nil){
    [viewController.view removeFromSuperview];
    self.viewController = controller;
    [window addSubview:self.viewController.view];

Make sure you have a viewController property on the application delegate of course.

When switchViewControllers is called, your currently visible view is removed from its superview and the new view controller and its associated view are added.

The next step is to add this piece of code inside your view controllers that you want to switch out during auto rotation:

- (BOOL)shouldAutorotateToInterfaceOrientation:
                (UIInterfaceOrientation)interfaceOrientation {
    CustomUIViewController *customUIViewController = 
                [[CustomUIViewController alloc] init];
    MyAppDelegate *appDelegate = 
        (MyAppDelegate *)[[UIApplication sharedApplication] delegate];
    appDelegate switchViewControllers: customUIViewController];
    [customUIViewController release];

Where CustomUIViewController is your own view controller you want to switch to.

3. Pitfalls

This approach has worked very well for me but I did have an issue where I was using 3 view controllers. Let’s call them A, B and C. A switched to B and vice-versa when the phone’s orientation changed. C was loaded by B and was viewable in landscape and portrait orientations. The problem came in where if you changed C’s orientation and then the user navigated back to B where B had a different orientation, you would effectively not be notified of an orientation change. If you subsequently changed B’s orientation to load A, you would find A would load in the wrong orientation. Oops, bug…

After trolling a number forums I discovered there used to be an undocumented call in the SDK called changeOrientation: but for some or other reason Apple removed this method.

So how did I solve this? Well all I did was put this piece of code in A so that it would manually reorient itself from portrait to landscape:

- (void)viewDidAppear:(BOOL)animated {
        [UIView beginAnimations:@”View Flip” context:nil];
        [UIView setAnimationDuration:0.5f];
        [UIView setAnimationCurve:UIViewAnimationCurveEaseInOut];
        self.view.transform = CGAffineTransformIdentity;
        self.view.transform = 
            CGAffineTransformMakeRotation(MPI * (90) / 180.0);
        self.view.bounds = CGRectMake(0.0f, 0.0f, 480.0f, 320.0f); = CGPointMake(160.0f, 240.0f);
        [UIView commitAnimations];

Conversely you can use this piece of code to reorient from landscape to portrait if your “A” view controller needs to be in portrait mode:

- (void)viewDidAppear:(BOOL)animated {
        [UIView beginAnimations:@”View Flip” context:nil];
        [UIView setAnimationDuration:0.5f];
        [UIView setAnimationCurve:UIViewAnimationCurveEaseInOut];
        self.view.transform = CGAffineTransformIdentity;
        self.view.transform = 
            CGAffineTransformMakeRotation(MPI * (90) / 180.0);
        self.view.bounds = CGRectMake(0.0f, 0.0f, 320.0f, 480.0f);
        [UIView commitAnimations];

So far this method of loading and unloading view controllers on orientation changes has proved to be very memory efficient and not too performance intensive either. Let me know in the comments if it works for you or if you have any ideas about this method of managing view controllers and orientation changes.

Programming Lessons: iPhone Style

// April 10th, 2009 // No Comments » // 42 restaurants, application, iphone, iphone sdk, objective-c, programming, xcode

I have been really busy, as many of you have noticed, the last few months juggling my job at ChessCube and building an iPhone application. I have even gone so far as to only work for ChessCube part-time in order to make time to build my application.

The application I have busy building is called 42 Restaurants and it was a concept my girlfriend, Margarét, and I came up with one day while sitting in a sushi restaurant. It goes along the lines of producing a really beautiful iPhone application that showcases recipes from some of the best restaurants in the world. You can read more on the 42 Restaurants website here.

The concept started out simple. My knowledge at the time of the iPhone SDK was very basic and we didn’t want to be too ambitious. The main features would be amazing pictures, simple functionality and great recipes; all the while providing good marketing for the restaurants involved.

Now that we are nearing the end of developing the application, I can let everyone in on some tips to hopefully help their progress with their own application.

1. Read, Read, Read

The main thing that stood me in good stead for learning the SDK was reading. I read everything, from the Apple developer documentation to blogs and online tutorials. The two books that really helped me the most were - The iPhone Developers Cookbook By Erica Sadun and Cocoa Programming for Mac OS X by Aaron Hillegass. The best thing about these two books is that the former teaches you how to build and use components in the SDK without needing to worry about things like code structure and development tools. The latter teaches you the fundamentals of Cocoa programming – even though it contains no coverage of the iPhone SDK.

Understanding the basics is key to using the iPhone SDK.

2. Get To Know XCode

Coming from a development environment from Eclipse, XCode seems at first very different and at times a bit clunky. Now that I have figured out how to use a large portion of it, I can honestly say that I love it. Its simple, fast and it isn’t intrusive while you are coding. One tip which I think most Eclipse & Netbeans programmers will appreciate is to change the Layout Mode. Go to XCode->Preferences->General and change the Layout to All-In-One. All your XCode windows will then be grouped into one place and the interface will alter itself depending on whether your are debugging or coding.

Another important thing to do is download all the SDK documentation to XCode. Take a look at this great blog post to see how to do it without having to use XCode’s built-in documentation downloading mechanisms.

3. Understand How Interface Builder Works

From reading numerous forums on the topic, programmers seem to find it difficult to understand Interface Builder (IB). I was one of them. My distrust of WYSIWYG interface tools led me to building all my view code manually. This, as you can imagine, took me forever until I spent some time trying to understand IB. Now, I pretty much build all my components in IB.

The main concept I had difficulty grasping with IB was what piece of code fitted with what. Each XIB file has two parts, a File’s Owner and a View. The File’s Owner is a class that inherits from UIViewController and the View can be any class that inherits from UIView.

If you want to initialize a XIB file all you need to do is instantiate your view controller with the method initWithNibNamed and then add the view of that view controller as a subview of whatever view you are currently displaying. If you want to do any post instantiation initialization, such as setting text for a UILabel or applying an image to a UIImageView then you override the method viewDidLoad in your view controller.

Don’t forget of course to wire up your IBOutlets and your IBActions in your File’s Owner to your View and to set your File’s Owner to be the custom view controller that you have created in XCode. Otherwise, your view will load and nothing will happen.

4. Don’t Do Cut-and-Paste Coding

This seems to be the number one problem in the development community. There are too many programmers that try to code by searching the Internet looking for solutions to their particular problem. Cutting some sample code from a blog or forum post. Pasting it into their project only to find A) it doesn’t work, B) it is full of bugs or C) badly written.

Understand the principles of what you are trying to do before you go on the web to find a solution. Often you will save time writing the component/algorithm from the ground up and even if you don’t, you will have learnt a lot in the process. The next time you have to build something similar you can use that knowledge.

5. Don’t Be Scared to Rewrite Code

My application was about 80% complete when I realized I was coding around my solution. The architecture that I had designed was firstly, very inefficient memory-wise and secondly, limiting me in terms of the functionality I needed to add. When I started the project I had a very basic understanding of Objective-C and the iPhone SDK, and my solution thus far had evolved into a big, code beast. So I spent 2 days rewriting the core of the application. I lost 2 days but I gained a whole bunch of functionality, improved memory usage and reduced my code base considerably.

6. Lessons

42 Restaurants will hopefully get into the App Store at the end of April. Although the idea seemed simple to start off with, it has grown into a fully fledged recipe application. The sheer amount of design work that Margarét has put into it, makes it in my mind, a masterpiece. Each individual recipe has been custom designed and the application is looking amazing because of it. We both wanted to the application first and foremost to blow the user away with how great it looks and I think we are there.

I hope the code-work on my part will live up to the task. Keep watching this blog and the 42 Restaurants website for news on the launch. We are also on the threshold of starting a round of user testing, so if you have an iPhone and would like to check what we have built so far, post a comment and I will add you to my list of testers.

iPhone XML Management

// November 27th, 2008 // No Comments » // iphone, java, JTidy, libxml2, NSXMLParser, objective-c, programming, screen scraping, XML

Learning how to program in Objective-C and for the iPhone can be really frustrating sometimes. Although I am coming to grips with the language and its frameworks, I am finding certain seemingly simple tasks a bit of a chore.

For instance, as one of my own projects to help me learn Cocoa Touch, I am trying to do some parsing of HTML off of a website – screenscraping. To handle any kind of XML processing there are, to my knowledge, only two libraries/utilities you can use. One is the dreaded libxml2 and the other is NSXMLParser.

Firstly, libxml2. What a nightmare! Albeit that it is reported to be very memory efficient and fast, it is written in C, has the most confusing documentation on the planet – and to top it all off, the classes are named according to a different set of coding standards from the ones I am used to. This makes all sample code, that I could find, very difficult to read.

What I did find however, was a couple of utility classes written by Marcus Zarra that makes XPath querying with libxml2 a bit easier. But not easy enough.

Which brought me to NSXMLParser. If you are going to use NSXMLParser to screenscrape you are asking for spaghetti code. NSXMLParser is a SAX-style parser. In other words, while parsing through an XML document it fires events on the start of an element, when it finds characters on an element and at the end of an element. This works very well if you know what the XML is going to look like but it is not ideal when working with HTML.

In the end, after fiddling for a few hours and many curse words I got my code to work with NSXMLParser. Even though it looked like a dog’s breakfast and would probably break the moment an extra tag was added to the HTML.

There is one other thing, however, that you can do, create a proxy for all the data that you send to the phone. This serves two purposes. The first, is that you can use Java running on a web server to fetch, clean and extract the data from the website you are trying to scrape. I used a combination of JTidy and XPath to extract the data I needed from the relevant pages and convert it to objects which I can now serve to the iPhone. This gives an incredible amount of flexibility and allows for a marked improvement in performance as the phone does not need to load large documents into memory in the background.

The other major benefit of using a proxy server is that if you offload processing to an external server, and you make your iPhone application as dumb as possible you won’t need to update and resubmit your iPhone application to Apple, within reason of course. You can even resize images on the server and cache responses.

My application now uses NSXMLParser to work with simple XML files and I have a lot of control. Moral of the story, don’t try and do everything on the phone.

So what’s next? Well I am going to finish my server-side code. Rewrite my iPhone application so that it works with the simpler XML from the server. Once all this is done I can start working on the more fun parts of my application, such as using the media frameworks for the iPhone namely the camera, video and audio.

iPhone Developer Program Accepted

// October 19th, 2008 // 5 Comments » // emulator, iphone, iphone developer program, iphone sdk, programming, simulator

Woohoo! I just got accepted into the iPhone Developer Program after applying 3 weeks ago. In that time the price of the membership jumped R250 due to currency fluctuations, which can be viewed as a good or a bad thing depending on when I can get my application released into the store. If I can get it done before the rand strengthens against the dollar I will make the money back fairly quickly.

In any case, I can now test my iPhone application on a real-world iPhone rather than using the iPhone SDK simulator. This has a few advantages. Firstly, the simulator is exactly what it says it is; it is just a simulator not to be confused with an emulator. Therefore, all the apps that I test on it have access to my MacBook Pro’s 4gigs of memory and powerful CPU which is much larger than what I have available on the iPhone. This is not the best testing environment as not having the ability to test my applications on a real-world device would mean I would have no clue how fast the application would run.

Another limitation of the simulator is that I am unable to test additional hardware elements of the phone, such as the accelerometer, the GPS and the multi-touch interface. (Note: You can test multi-touch on the simulator by holding the Option-key while dragging your mouse around but its not very easy to use.)

I will be releasing a tutorial shortly on how to get your applications to run on your iPhone using the provisioning certificates that Apple provides once you have been accepted into the iPhone Developer Program.

Objective-C: Tips for a Java Programmer

// October 12th, 2008 // 7 Comments » // instruments, iphone, iphone sdk, java, java objective-c comparison, key-value coding, learning, objective-c, programming, xcode

I have been learning Objective-C part-time. Partly to learn something new and different but also partly out of curiosity. As a Java programmer, I initially thought it would be a doddle but as soon as I looked at the code I realised it was going to take a bit of getting used to. After going through Apple’s excellent, yet verbose, guide: The Objective-C 2.0 Programming Language – I started to get used to the syntax. Its not that hard, especially if you come from a C or Java background. Here are some of the differences and some of the highlights I have encountered so far.

1. Methods, Functions, Messaging

The most difficult thing to get used to initially is the syntax for calling methods, or as its called in Objective-C: messaging. In Java calling a method on an object looks like this:

Car car = new Car();, 100);

This piece of code creates an instance of type car and then tells it drive 10 kilometres at 100 kilometres and hour. If we were to write the same thing in Objective-C it would look something like this:

Car car = [[Car alloc] init];
[car drive:10 speed:100];

Whoaaa! Hold on a minute. That is completely different from Java and C. Well, don’t panic. If you have ever programmed with C or C++ you will probably understand the first bit – Car *car. We are creating a pointer to a place in memory that holds a car. The part after the equals is a little more confusing. The designers of Objective-C have dropped the dot-notation completely for messaging objects. The piece of code [Car alloc] can be rewritten in Java as Car.alloc(). In Objective-C, this is the way to allocate a piece of memory for your instance. It is also the way you call methods on instances.

The closest equivalent to a constructor that I can find in Objective-C is the init message call. All objects have an init method – inherited from the base object NSObject (in Java this would be equivalent to Object). You can override the init method in your classes to add initialisation code.

So the first line in our example now makes sense, but what about the second line? Objective-C uses the concept of named arguments. This may seem redundant or a little verbose, but once you get used to it, it does make it easier to read. This syntax scheme is an adaptation of the way you would message objects in Smalltalk. So we are basically messaging our instance of car to drive 10 at the speed of 100. I could have possibly made the method a little more informative and written it as: [car driveFor:10 speed:100].

2. Garbage Collection vs. Retain Counts

Since Mac OS X 10.5, Mac developers have been treated to the simplicity of writing code without having to worry about memory management – in other words, Garbage Collection has been introduced. The only thing to bear in mind is that if you want to write code that is supported by older versions of Mac OS X, namely, 10.4 and the iPhone you will still need manage your memory manually. Fortunately, detecting memory leaks is fairly simple with the Apple developer tool Instruments.

The mechanism by which you manage memory manually is called retain counts. Every time you make an object point to another object you increase that object’s retain count. This loosely means that if you have 10 pointers pointing to an instance, the instance will have a retain count of 10. Whenever you are finished with a pointer you need to release the object. This drops the instance’s retain count by 1. When an instance’s retain count reaches 0 it will be deallocated.

There are many pitfalls with manual memory management. Having a memory leak means that over time your application will consume more and more memory and it will crash the system eventually. There are 2 main ways you can create a memory leak. The first is to have an orphaned object. This is where the object has a retain count greater than zero but there are no other objects pointing to it. The other is to have a retain cycle. This is where Object A points to Object B and Object B points to Object A, and nothing else points to these two objects.

If you want to build applications for the iPhone or for older versions of Mac OS X then you need to be more meticulous with your code. Make sure that your objects always clean up after themselves and use the application Instruments to ensure you have no memory leaks. On the iPhone memory leaks can be disastrous, since you only have a very limited amount of memory to play with. Should your application run out of the allocated memory on the iPhone, it will reboot – basically quit your application.

3. Cool Extras

Objective-C has some really cool features built into it and some downright weird ones. Two really cool features that have no equivalents in Java are: Key-Value Coding and @synthesize/@property directives.

Key-Value Coding is a very neat and dynamic way of querying objects by name. Some people would say that you can do similar tricks in Java with Reflection but Key-Value Coding has a lot more useful features that you cannot leverage in Java without writing a lot of code.

Key-Value Coding works like this:

Car *car = [[Car alloc] init];
[car setValue:@”BMW” forKey:@”carMaker”];

Basically, we are setting the value for the property carMaker to BMW. This seems cumbersome, but bear with me. We can now retrieve the value in the following manner:

NSString *carMakerString = [car valueForKey:@”carMaker”];

We can now read and set objects by their values. The cool thing is that you don’t need to cast any values. The valueForKey method will automatically cast the value for you. Programmer’s used to dynamic languages will probably laugh at the significance of this but if you are from a Java background you will appreciate not having to check and cast the result of the call.

You can also describe keypaths for key-values. A keypath is basically a way of navigating a pointer graph to a property from object to object. For example:

NSNumber topSpeed = [car valueForKeyPath:@”carMaker.topSpeed”];

Where topSpeed is a method that returns an int for the car’s top speed. The int will be auto-boxed to an NSNumber at runtime.

In addition to keypaths, there are also aggregator functions you can use on key-values in arrays. So for instance, if we have an array of car objects and we want the average top speed of all the cars at the BMW dealer we could do the following:

double averageSpeed = [bmwDealer valueForKey:@”cars.@avg.topSpeed”];

If we wanted to something similar in Java or without key-values we would have to loop through the whole array of cars, add the top speeds to a variable and then divide by the number of cars in the array. If you want to learn more about Key-Value Coding, including the most powerful feature for binding values, called Key-Value Observing, check this article out.

Another cool feature that Objective-C contains, that I use all the time are the @property/@synthesize preprocessor directives. The combination of these eliminates the need to write boilerplate getter and setter code. The @property directive, used in the header file for a class, tells the compiler that this is a property of the class. In addition you can make the property read only or readable/writable, by adding read or readwrite in brackets like this:

@property(read) int topSpeed;


@property(readwrite) NSString carMaker;

You can also tell the compiler how to manage the memory for the getter and setter of that property by putting a retain, assign or copy after. Like this:

@property(read, retain) NSString carMaker;

By adding @synthesize in your class file for your properties. The compiler will automatically generate getter and setter methods for you.

@synthesize carMaker;

4. So Far, So Good

So far my experiences with Objective-C have been favourable. I do get confused sometimes when my code won’t compile and it looks correct, only to realise that it would be correct in Java but will never work in Objective-C. Apple’s Interface Builder software is top notch and makes designing and hooking up your interface very simple. XCode’s code editore on the other hand, in my opinion, is a bit behind compared to Eclipse. A Mac developer would, however, probably class Eclipse as bloatware. Instruments is my favourite and makes optimising your application and finding memory leaks a doddle.

Smoothe As Silk – Well Almost…

// September 30th, 2008 // No Comments » // amazon ec2, chesscube, deployment, Openfire, programming, system admin

Launching a new version of your site is always stressful. Launching a site that spans multiple servers can be a nightmare. With a sound plan and practise, however, it can be less difficult than it is usually.

ChessCube Version 3 was launched on Monday and the release went relatively smoothly considering how huge the changes were to both the interface and the underlying architecture. In the past, we were a little too trigger happy in releasing a new version and failed to plan and test the release properly. For this release we had a target of 2 hours of downtime while we upgraded and uploaded software, changed configuration files and deployed the new website files.The changes to version 3, as I have already mentioned, were extensive. The main areas that were changed were:

  1. Improved interface and user experience. We wanted this version to appear to be more simple yet have more features. Instead of packing in thousands of buttons and labels everywhere, we worked hard to ensure that it all flowed correctly and that there wasn’t information overload. This is a lot more difficult than it sounds and the best way to go about it, is to forget as much as possible of the existing interface and try to come up with new and fresh ideas.
  2. A completely rebuilt and redesigned Paper. Paper is the name we have given to the component that sits alongside the board while playing or viewing a game and tracks the moves and chat between the players. You could also call it the Notation View or the Game History Panel. Due to the way Paper is implemented we had to reorganize popup windows and make sure that it resized and was positioned correctly.
  3. Multiple game server support. Clients would have to support and manage multiple connections to game servers and also work optimally with those game servers.
  4. Improved moderation & reporting tools. These changes were implemented to improve the moderators’ abilities to monitor users on the site and ensure that everything is running smoothly.

Other factors that made this release tricky were the upgrading of the version of Openfire that we were using and also having to move software onto more powerful servers, not to mention coordinate the rollout of our Amazon EC2 infrastructure.

The success of the release process was partly due to a few factors:

Testing exhaustively

I can’t stress this enough. If you build in 10% of the allotted project duration into your schedule for testing – double it. Get an independent tester – not a programmer or the boss. The boss can cause stress for the programmers when he finds a bug.

Simulating our live environment

We used to stage all our software on a little machine in our office and access the database on that machine using fancy GUI tools. If you live in South Africa and you have an average connection to the Internet, this is a mistake. The turnaround time for problems on a machine hosted internationally can cause a lot of stress. We commissioned a brand new server to go live on for our new software and set up our entire live architecture using this server, a local database and two EC2 game servers with the plan to rollout two more on launch day.

Setting up the staging environment a week before going live

This way all issues and their solutions you encounter while setting up the infrastructure and getting it running are still fresh in your system administrators’ and developers’ minds. There is nothing worse than forgetting how you solved a problem 6 months prior to release under the pressure of your system being down. We also planned to convert our staging environment to the live environment when the release launched. This meant downtime was kept to a minimum as all we had to do was change a few configuration files and point the server away from the staging database to the live database.

Making use of configuration files and logging wherever possible in our code

This is probably a moot point, but if you have a good set of external configuration files you won’t need to keep uploading new builds of your software if you have forgotten to change a server url.

Extensive log statements help to identify problems very quickly should your system stop functioning for whatever reason. Remember: Absence of logs means you are missing a log4j.xml somewhere (I learnt this one the hard way:) )

Holding on tight

You can’t plan for every eventuality and you can’t hold off your release until you feel the software is perfect. Sometimes you need to just release and see what happens. 15 minutes after releasing we realized we had a few bugs which were serious enough to warrant emergency bug fixes and we had a new version of the client software out 10 minutes later. This can be disruptive to your users but its better to disrupt early and fix the problems than handle all the bug reports and user complaints later.

Most of these tips seem obvious but they definitely played a huge roll in negating major disasters. Just remember, the hard work only really starts after you have launched and never deploy on a Friday.

Thanks to my colleagues: Dave, Tracy, James and Gideon for creating, what I think, is the best chess playing site out there and thanks to Bryan and his testing team for helping us find and swat all the bugs. Thanks to Margaret for her amazing GUI designs and thanks to Mark and the investors for giving us the opportunity to work on such a cool project.

Helper Objects

// September 28th, 2008 // No Comments » // coding style, mac osx, objective-c, programming

I think this is a brilliant comparison between using Helper Objects and Sub-Classing:

Once upon a time (before Baywatch), there was a man with no name. Knight Industries decided that if this man were given guns and wheels and booster rockets, he would be the perfect crime-fighting tool. First, they thought, “Let’s subclass him and override everything we need to add the guns and wheels and booster rockets.” The problem was that to subclass Michael Knight, you would need to know an awful lot about his guts so that you could wire them to guns and booster rockets. So instead, they created a helper object, the Knight Industries 2000, or “KITT the super car.”

Note how this is different from the RoboCop approach. RoboCop was a man subclassed and extended. The whole RoboCop project involved dozens of surgeons who extended the man’s brain into a fighting machine. This is the approach taken with many object-oriented frameworks.

While approaching the perimeter of an arms dealer’s compound, Michael Knight would speak to KITT over his watch-radio. “KITT,” he would say, “I need to get to the other side of that wall.” KITT would then blast a big hole in the wall with a small rocket. After destroying the wall, Kitt would return control to Michael, who would stroll through the rubble.

Solving The Scaling Riddle

// September 27th, 2008 // 1 Comment » // amazon ec2, amazon s3, chesscube, Openfire, programming, XMPP

Monday is a very big day for ChessCube. We are launching version 3 of our online chess playing client. Along with a redesigned interface, we have made some significant changes under the hood.

Version 2 of ChessCube was suffering under immense load created by the increasing popularity of the site. Under this load we were experiencing messages getting lost, very long login times, client interface crashes and, the worst of all, dreaded lag spikes. Lag can be described as the amount of time a message takes to go from the Flash client sitting in the browser to the server. A lag spike is when the overall lag in the system jumps for all users that are on the system. After hunting down the cause of these lag spikes we came to the conclusion that the system was unable to cope with the sheer amount of messages being sent and received between clients and the server. Putting our server software on a larger server would, in light of the steady growth of the site, just buy us a few more months. So the decision was taken to cluster the server software.

The chess playing component of ChessCube, we call it Chat internally, uses a protocol called XMPP. Now before your eyes glaze over and you go back to checking your mail, let me explain very simply what XMPP is. If you’ve ever used Google Talk or Facebook Chat, you would have used XMPP. It can simply be explained as a set of rules used to allow for chatting between people connected to a central server. For ChessCube, we chose Openfire as our XMPP server, for the reasons that its Java-based (a language the team predominantly uses), is easily extensible, due to its comprehensive plugin framework, and is Open Source.

Openfire is great for supporting a small chat community, but as soon as you need to scale above 5000 simultaneously online users it becomes very slow. This is where clustering comes in. Clustering is a term used to refer to a group of computers concurrently working together to spread load across them, thereby improving performance and in some architectures, removing a single point of failure. The company that supports Openfire does offer a clustering plugin but its prohibitively expensive – charges are on a per-user-basis rather than a per-server-basis.

In comes our trusty homemade architecture. Since each game of chess in Chat is played in a separate room we could distribute these rooms off the main Openfire server. So now we have a main Openfire server to handle all the stuff related to presence and chat; and smaller game servers that handle games. We can now have multiple game servers all communicating with the Openfire server about the status of games being played on them and the Openfire server in turn can distribute the games evenly over the game servers.

Distributing the load across game servers is handled with Amazon S3. Each game server writes its status to S3 and the Openfire server polls S3 to see which game servers are available and how much load each server is under. The Openfire server can then send clients to whichever server it feels is under the least amount of load. We can also do cool tricks with routing clients to servers that are nearest to them geographically. E.g. If two players from Europe want to play a game we can put them on a server in our German data centre. Lag is minimized and everybody is happy.

We have also created a customized instance image for game servers on Amazon EC2. Under extraordinary load we are able to bring new game servers online and running games in a matter of minutes.

This version of Chat goes live on Monday with four game servers, running on Amazon EC2. Hope to see you there.

Working Remotely – A Programmer’s Guide

// September 18th, 2008 // 2 Comments » // amazon s3, fourhourworkweek, programming, rsync, scp, ssh, working remotely

Being confined to working in an office is not ideal. Especially if you want to be more creative and have more freedom to spread your time out during the day. I have been working away from the office on Thursdays and Fridays. By “away from the office”, I mean I have been working from home.

The reasons for working from home or remotely are pretty obvious. Firstly, you don’t have to commute to work. This saves me around 1 hour of driving in the car not too mention a whole bunch of money every month in fuel costs. The other cool thing about working from home is that you never feel rushed to finish something, you can sit back relax and get it done. Don’t get me wrong though – its not about shirking your work or being lazy. It just means you don’t feel as though you have to finish whatever you are doing so that you can hop in your car and rush home at the end of the day.

There are other good things that come from being away from the office. I have found new energy and creativity in my work because I feel more relaxed. I can also go for a run/cycle during the day if I feel I need to clear the cobwebs or if I am stuck on a problem. I also get to spend more time with my girlfriend – who works from home as well.

Today I decided to go one step further and got on a plane to Johannesburg to visit my parents for my dad’s birthday. After convincing the boss that my work would not be affected, I had to make sure I had the right tools and environment so that I was not left stranded without an Internet connection – the most dreaded of scenarios in my line of work. Here are some of tips for working remotely – especially if you have a job where you rely on the Internet to get your work done.

1. Travelling

If you are travelling somewhere, try to make sure you waste as little of the middle of the day as possible. I flew at 6:15am which meant I arrived in Johannesburg at 8:10am. I could then have a shower when I got to my mom and dad’s place and start working. If you are travelling further, try to fly in the evenings.

2. Equipment

Equipment is important. If you are not prepared you are asking for trouble. I use a Mac – but I also recommend using Linux. Why not Microsoft Windows you ask? Well, I do a lot of work on remote servers, uploading and downloading files, copying between remote servers and zipping and unzipping files. This is a real pain if you don’t have a bash terminal. You can use a combination of Putty and WinSCP on Windows. If you take the time to learn bash commands you will save time in the long run. More on this later.

The other really essential device is a 3G equipped cellphone with a medium-sized data plan. (This obviously depends on how long you are going away for and how much data you expect to use.) Don’t be fooled, if you are going somewhere that has Internet connectivity, you may find that its either too slow to be usable or just downright unreliable. HSDPA cellphones are preferable as they have faster connection speeds.

Other things I like to take with me are a good set of earphones and a mouse. The earphones are a good idea in case you have to work in a noisy environment – airports, hotel lobbies etc. I take a mouse because I tend to get neck pain if I have to use the touchpad on my Mac for prolonged periods. I like the Logitech VX Revolution mouse. It has a little compartment that you can store the cordless receiver inside and is very comfortable.

3. Software, Tools & Tips

Obviously the software everyone uses is different depending on your job. I am a programmer so I have to be able to get updates to the codebase from my teammates and be able to update them with my changes. We use Subversion for this and there is a nifty little feature in the Subclipse plugin for Flex Builder and Eclipse whereby you can relocate your repository. This means that I can use the external subversion URL when I am away from the office and the internal subversion URL when I am in the office.

I also have to be able to move files around e.g. copying new plugins of our server software to our test server. To copy files I use the scp command in terminal. So if I want to copy a file to our German server I type something like:

scp filename.txt

Copying large files repetitively with scp can be onerous however, not to mention expensive, so I use another command called rsync. Rsync works much the same way as scp:

rsync filename.txt

The cool thing about rsync is that it synchronizes the files or directories you are overwriting on the remote machine and therefore only copies the differences between the two files making the transfer time faster and the transfer size smaller.

These are obviously very simple examples. If you check out the links you can learn how to do more complicated tasks. Like copy a file to a specific directory or get more detailed information while copying.

How to use rsync.
How to use scp.

Another cool tip if you need to get a large file to your boss or a client or whoever, is to use Amazon’s S3 Service. If you have an Amazon account, this is very simple. Visit and sign up for their S3 service. S3 stands for Simple Storage Service and its a very easy way to upload and store files online, as well as make them accessible from the Internet. Here is a whirlwind guide on how to get going:

  1. Sign up for the Amazon S3 Service
  2. Install a Firefox plugin called S3 Organizer – if you don’t have Firefox you can get it here
  3. Open S3 Organizer from the Tools menu in Firefox and click on Manage Accounts
  4. Take the access key and secret key you received from Amazon after registration and put it in the corresponding fields in S3 Organizer
  5. On the right-hand-side of S3 Organizer click on the Create Directory button – the directory name must be unique for the whole of Amazon S3, not just for you. So use something obscure if you need to.
  6. Select the directory you have just created and click Edit ACL. You can then share the directory you have just created based on the options provided. Sharing by e-mail address is the easiest.
  7. Now you can copy files from the left hand window – which is your local computer to the directory you just created in Amazon S3.
  8. Finally, for your boss, client, colleague to access the file you just uploaded – right click the file in the right hand window and select Copy URL to Clipboard. You can then paste the URL into an e-mail and they will be able to download it from their web browser.

Bear in mind that Amazon does charge you for the amount of data you upload and download from S3, but its minimal. Around US$0.12 per gigabyte.

4. Instant Messenger Advice

Using an Instant Messenger is great if you need to interact with your colleagues. The are however, downsides. It takes a lot longer to explain a concept or ask a complicated question if you have to type it out. I try to minimize the amount of questions I ask and really try to solve the problem myself before asking a colleague.

Another downside, is that it can be distracting if you are grappling with a difficult problem and your Instant Messenger starts going berserk with incoming messages and pinging noises. A simple fix for this is not to stay logged in all the time and only log in at specific periods during the day.

All in all, working remotely seems to be working out well. It is taking some getting used to, but I think the benefits are worth it in the end. I have managed to find time to start this blog and also have a more regular exercise regimen. I also don’t feel stressed after spending time in traffic. If you are having trouble working out a strategy to get your boss to allow you work from home, I highly recommend reading the chapter on it in the book The Four Hour Work.


// September 14th, 2008 // 1 Comment » // iphone, programming, ssh, Telkom

Downloading the iPhone SDK is the simple part in getting started with creating applications for the iPhone. Accessing the iPhone Developer Centre is the complicated part. Especially if you are from South Africa. You can log into the centre but from there you are unable to access any of the documentation. Every time I clicked on a URL I would be redirected to a log in screen which would never let me in. No errors. Nothing. After some digging around, it turns out that the way Apple authenticates access to web pages doesn’t play nicely with the SAIX proxy. Thanks very much Telkom! I finally managed to get in using a combination of clearing my browser cache completely and using an SSH Tunnel through my company’s Verizon server. Happiness is…

That’s only half the story though. I didn’t really want to go through this whole rigmarole every time I wanted to get some information about a framework or a class. So I needed to find a way to access the developer documentation offline. In comes XCode’s documentation manager to the rescue. Err. Well sort of. It is possible to subscribe to the iPhone Developer Documentation in XCode, and it will download the documentation to your local machine for you, but its slow and it doesn’t resume.

So after 3 attempts and much wastage of precious bandwidth I turned back to Google search terms and in an “eureka moment”, I found a post on a blog, on how to use NetNewsWire to download the darn documentation and subsequently install it. I just hope Apple doesn’t release a new version of the documentation tomorrow. Good things come to those who bash their heads on the keyboard at consistent times during the day.

Oh and by the way, don’t bother trying to contact Apple for help. Their auto-responder works really well but their support staff obviously haven’t been outsourced to India yet. I have been waiting a week for a reply to all my e-mails, concerning the issues I have been having accessing their website. Maybe there is a trick to it.