My recommendation is to switch to MKNetworkKit by Mugunth Kumar. It follows a very similar approach. It too has a central service controller (a.k.a. network engine) that performs the service requests (a.k.a. network operations).

Where MKNetworkKit shines is that is much further fleshed out. For example, it adjusts the number of active connections to match the current network condition. It comes with support for caching, as well as freezing active requests. The cURL-able debug lines are nice touch too. From what I have seen so far everything that KVServerInteraction could do, can be done with MKNetworkKit as well.

It is quite straightforward to convert your code from KVServerInteraction to MKNetworkKit. Below are two snippets that shows how a service request (a.k.a. network operation) is done. Both methods would live on your custom subclass of your service controller (a.k.a. network engine).

1
2
3
4
5

- (KVServiceRequest *)fetchGuestbookEntriesOnPage:(NSUInteger)pageIndex completionHandler:(KVRequestCompletionBlock)completionHandler {
    NSURL *URL = [self.baseURL URLByAppendingPathWithRelativePath:@"entries"];
    URL = [URL URLByAppendingParameterName:@"page" value:[NSNumber numberWithUnsignedInteger:pageIndex]];
    return [self performRequestWithURL:URL HTTPMethod:@"GET" bodyData:nil requiresToken:YES allowCaching:YES forceRefresh:NO completionHandler:completionHandler];
}

1
2
3
4
5
6
7
8
9
10
11

- (MKNetworkOperation *)fetchGuestbookEntriesOnPage:(NSUInteger)pageIndex completionHandler:(void (^)(id result))completionHandler {
    NSMutableDictionary *params = [NSMutableDictionary dictionaryWithObject:[NSNumber numberWithUnsignedInteger:pageIndex] forKey:@"page"];
    MKNetworkOperation *operation = [self operationWithPath:@"entries" params:params httpMethod:@"GET"];
    [operation onCompletion:^(MKNetworkOperation *completedOperation) {
        completionHandler(completedOperation.responseJSON);
    } onError:^(NSError *error) {
        completionHandler(nil);
    }];
    [self enqueueOperation:operation];
    return operation;
}

Some rumors were correct: Retina Display. Some rumors were off: touch feedback. Nevertheless, afterwards (and this time, heck why not, already before) many articles appeared all over the internet claiming disappointment with what the new iPad offers.

There is something important overlooked though: the satisfaction of existing iPad users. Apple wants to woo in new customers, but it also wants to keep existing customers satisfied. A satisfied customer is one that comes back to buy again. And one of the surest way to piss off a customer? Coming out with a new much improved model shortly after they bought theirs. Sure, this still happens, but Apple makes sure that the improvement is such that an existing user can justify either way to buy or not buy the new model. Users of models that are two generations older have a much harder timer resisting the new model. But theirs is by then almost 2 years old, a ripe old age for any tech gadget.

So the reason for the disappointment amongst the tech journalists covering the new iPad comes from the fact that Apple doses the improvements well. Unlike regular iPad users, they have to upgrade, because it is their job to cover the latest and greatest. The regular users however can chose either way and still feel satisfied with their choice. They’ll keep liking their current iPad, or they’ll fall in love with their new iPad.

This pattern is also clearly playing out for the iPhone. For iPhone 4 users the iPhone 4S looks like a nice upgrade, for owners of the iPhone 3GS and older models it is pretty much irresistible.

That’s all there is to it.

The first two are very handy when dealing with JSON dictionaries. The last one if you need to replace strings and want to avoid having (null) all over the place.

“Selecting multiple files under ‘Build Phases’ and pressing enter sets multiple compiler flags at once. Timesaver! #ios”

Xcode lets you set compiler flags per file in the ‘Compile Sources’ build phase. A very common need these days it so have to set -fno-objc-arc when code is not yet readied for ARC. More often than not this involves a bunch of files. Repeating the process of setting this flag for a bunch of files gets old really quick.

So here is what you do:

1. Select the files in the ‘Compile Sources’ build phase
2. Press enter
3. Enter the compiler flags in the popup
4. Press done

As I said: golden!

“The controller that presents a modal controller should dismiss it. Don’t do [self dismissModalViewControllerAnimated:NO] in the child.”

and:

“Calling [self dismissModalViewControllerAnimated:NO] on child is like committing seppuku. A child shouldn’t kill itself.”

He does have a good point saying the presenting view controller should also be the one deciding when the modal view controller should disappear. However, it is not too far fetched to say that the modal view controller itself can determine best when its time has come.

I am uncertain wether we can deduct from Apple’s sample code and/or API which approach they recommend. Even if all sample code lets the presenting view controller decide (I haven’t checked this), the API clearly allows the modal view controller to dismiss itself.

My biggest objection though arises as he next attempts to explain that under ARC it is not possible to have proper memory management simultaneously with letting the modal view controller dismiss itself. This is just false.

In his non-ARC examples in both cases he retains the modal view controller before presenting it. This may be useful on occasion, but there is no need for it. The modal view controller is namely already retained when the -[presentModalViewController:animated:] method gets called. It is perfectly valid to pass an autoreleased view controller to that method. That would also avoid the ugly memory management that he uses in his second method. (There is BTW also a memory leak when he assigns the modal view controller to its property.) On -[dismissModalViewControllerAnimated:] the modal view controller gets released again.

There is nothing in this that changes under ARC vs. non-ARC. In both cases this works fine, wether you let the presenting or the modal view controller dismiss doesn’t matter. So this only leaves the ‘purity’ of which way is cleaner. That is a debatable issue.

So, I’d conclude, feel free to do it in the way that makes sense to you. Keep an eye on your memory management, also with ARC, but either way can work.

Update: Mugunth Kumar:

“@johankool Good, but you still haven’t shown a ARC example.”

Okay, fair enough. The below is a sample of how I would do this with ARC. As I said, there doesn’t really change anything in ARC vs. non-ARC.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

- (void)showModalViewController {
    SomeViewController *someViewController = [[SomeViewController] alloc] initWithNibName:@"SomeViewController" bundle:nil];
    // Note: under non-ARC I would call autorelease on someViewController
#if DELEGATE
    someViewController.delegate = self;
#elif COMPLETION_BLOCK
    someViewController.completionBlock = ^(NSUInteger result) {
        self.result = result;
        // Note: there isn't really any need to reference someViewController in this block
    };
#endif
    [self presentModalViewController:someViewController animated:YES];
}

#if DELEGATE
- (void)someViewController:(SomeViewController *)controller pickedResult:(NSUInteger)result {
    self.result = result;
}
#endif

1
2
3
4
5
6
7
8
9
10

- (void)pickedResult:(NSUInteger)result {
#if DELEGATE
    [self.delegate someViewController:self pickedResult:result];
#elif COMPLETION_BLOCK
    if (self.completionBlock) {
        self.completionBlock(result);
    }
#endif
    [self dismissModalViewControllerAnimated:YES];
}

The implied link between OS version and the occurrence of crashes surprised me. I am not quite so sure if such a link in fact exists. I’d also argue that a higher crash rate says little about the quality of the OS version, or even of the app.

But we first lets go over the type of crashes that can occur. I am an iOS developer with very little to no knowledge about Android, so the discussion will focus on iOS crashes.

Memory Kill

On iOS the system is quite unforgiving to apps using too much memory or CPU resources. The app does receive warnings if memory usage gets too high, but it the app fails to properly respond timely by freeing up memory is will unceremoniously get the boot. As a developer I don’t call this a crash, but poor memory management. It is nevertheless a serious issue and developers should make sure to stress test their apps.

Crashes

If the app does not get the boot but actually does crash, it is often caused by one of two reasons: bad memory management or calling a method unknown to the callee. There are other reasons for crashes to happen, but I expect the majority of crashes to be either one of these two.

Memory Management

For an experienced Cocoa developer the memory management approach of Cocoa has little secrets anymore, but it is unsurprising that the large number of developers new to Cocoa and Objective-C (of which there are many, judging by the rise of Objective-C in the latest Tiobe index) have difficulties with it. One mistake is enough to cause a crash. Unfamiliarity with the coding conventions on memory management easily gets newcomers to make such mistakes.

With iOS 5 Apple introduced Automatic Reference Counting (ARC) which helps them, as well as the experienced developers, greatly. However, as this is a very new technology not all developers have picked it up yet.

The old way is not directly bad however, as it does give much finer control over memory usage than is possible with garbage collection. The latter being what is used in many modern languages (including in Java on Android) to manage memory automatically. This does however come with overhead which is very undesirable on a mobile platform. So here Apple chose to require more skills from the developer in order to give the user a better experience.

The beauty of ARC is that it gets the benefit of garbage collection, but does not come with the extra overhead. ARC automatically inserts the proper memory management at compile time. With ARC the manual memory management skills of a developer are no longer quite so essential. So as developers pick up on ARC, memory related crashes should go down.

Unknown Selector

Because Objective-C is a weakly typed system, it is possible to call methods on an instance that the instance does not expect. This can be avoided with strongly typed system, but at the cost of foregoing the sophisticated solutions that are possible with a weakly typed system. Basically, with great power comes great responsibility. As a Cocoa developer you need to be willing to take this responsibility.

Reproducibility

Another way to look at crashes is to see how easily they can be reproduced. Some can be easily reproduced: trying to use feature will crash the app. Others can only be reproduced in specific circumstances: trying to use a feature using a particular setting will crash the app. And then there are some crashes that only sporadically cause trouble: using a feature on Mondays at midnight causes trouble.

So where one bug can easily cause a plentitude of crashes, a bunch of others may only cause a handful of crashes. This is the main reason why concluding that the code in an app, or an OS version, is of poor quality based on the number of crashes is wrong. At most you can argue that the crash should have been caught during testing, so that the crashes reflect poorly on the overall quality of the app.

Back to the article, Tomio Geron, its author, further says:

“Anecdotally, I know that certain apps I use on my iPhone crash and they crash often.”

That an app keeps crashing if you keep on trying to use it in the same way can hardly be called surprising. Surely the developers of those apps have some work to do here, but it’s hard to make sensible conclusions from this.

As for the number of crashes occurring in a particular OS version it basically says nothing about the quality of the OS version. The vast majority of crashes are caused by bugs in the app code, not by bugs in the system. It is more likely that crashes in a new OS version such as iOS 5 are caused by apps that have not yet been updated by their developers. If an app needed changes it was however often due to false assumptions being made in the code while it was developed for iOS 4. If apps are designed according to Apple’s documentation for Cocoa it is unlikely to encounter issues on a new iOS version.

Developers have little excuse anyway, as test versions of new iOS versions are made available to them for testing.

Hardware

The Forbes article quotes Crittercism CEO Andrew Levy as saying that crashes can be caused by hardware issues (GPS or camera), or the availability of a network connection. If that is the case, it is mostly, if not completely, due to poor developer skills. It is the duty of the developer to anticipate all expected situations. Expected situations include the unavailability of the users location, a camera or a network connection. It also shows that the app has not been tested rigorously enough. There certainly is API in iOS to deal with all of these situations and developers don’t really have an excuse not to do so.

Third Party Code

The point raised in the article about third-party services is certainly valid. It is vitally important to realize the risk of using a third-party library in your app. It only takes one shoddy library to turn your app into a crash prone piece of crap. Evaluation and testing of third-party code is for this reason very important. If you are developing for a client, you need to be able to communicate to them that willy-nilly adding of outside code can be a risky affair. Anyway, the desire to include multiple analytics packages into one app has always puzzled me. But then, my ideal app doesn’t include any.

In this way the data collected by Crittercism is also skewed. It is based on crashes reported by apps that include its library. So these are apps by developers who are likelier to not be squeamish about third-party code.

App Store

The App Store is indeed a hindrance in providing quick bug fixes to users. There is nothing so frustrating as having a fix ready and then having to wait a couple of days before it can get to your users. On the other side, there is real value in having a vetted store to keep the crud out. It is difficult to say what the right balance is here. It would be great if Apple would let updates go through right away for developers with a proven track record. But that would open another can of worms, because what constitutes a proven track record? It would also put newcomers at a severe competitive disadvantage.

Conclusion

The number of crashes reported for an app does not necessarily directly reflect the number of bugs in its source code, nor does it necessarily reflect the overall quality of the source code. The number of crashes of apps on a particular OS version is even less indicative of the quality of the OS version. There are two many other factors at play, but mostly, app crashes are 99 out of 100 times a bug in the app’s code as opposed to the OS code.

The App Store is a frustrating obstacle for a quick response to deliver fixes, but one that iOS developers just have to learn to live with.

I have to say that it is quite satisfying to see ones work promoted on a 7 by 8 meters large display. Though not quite as satisfying as it topping the free iPad apps list in the Dutch App Store for a full fortnight already!

RTL Nieuws is a well known Dutch news television bulletin by the Netherlands’ largest commercial broadcaster. By introducing this app they are embracing the new possibilities opened by the iPad. They are touting this app as ‘the first real digital newspaper of the Netherlands’.

The app has a wide range of news content, from general to entertainment and sports, and has a strong focus on photography. (It actually uses a slightly adjusted version of KVImageCache under the hood.)

It looks like the app is off to a good start, and is climbing fast in the App Store charts. Most reactions on Twitter are very positive too.

I am very proud to have been part of the team that created this!

Update (29/1/2012): It certainly was a good start! The app reached the number 1 spot for free iPad apps in the Dutch App Store on the same day it was released, and has remained at number 1 since (ten days so far).

It felt a little too risky to do this while I was traveling, so I only got around to it last week. Anyway, I am glad that I finally got around to moving away my 3 domains, as I had been wanting to do this ever since I heard about GoDaddy’s CEO’s elephant hunting hobby. (Seriously, what’s wrong with this guy?!)

I am ashamed it took me this long to walk way from GoDaddy, so I do this as my public walk of shame.

Naked domain

Another thing I finally got around to was to have this website’s URL drop the ‘www’. From now one is it just the naked domain: ‘koolistov.net’. This website is now hosted via GitHub and no longer via Google App Engine. The combination GitHub and Octopress is certainly a more pleasant one.

FileMerge won’t open for third party app

When trying to view differences using GitBox, nothing would happen. This symptom started after I had installed a beta version of Xcode. Once I realized that GitBox opens FileMerge via the command line utlity opendiff the fix was easy: selecting the proper Xcode installation.

This is done as such:

xcode-select -switch /path/to/developer-folder

Symbolicating crash logs failed

When trying to symbolicate some crash logs I got this error:

Error: Can't run /usr/share/xcode-select/xcrun (no such file).

This was somewhat puzzling, because also on my other Mac, where symbolicating crash logs did work, there was no such file.

The command line utility xcrun is by the way what is used by a number of scripts to find out which Developer folder to use.

Luckily the fix turned out to be quite straightforward: reinstall xcrun. Simply reinstalling Xcode does the trick, or you can take the shortcut I took, and go into the Install Xcode bundle to find xcrun.pkg in /Contents/Resources/Packages/.

Once that installer package was installed, xcrun ran happily again.

To symbolicate crash logs you run this command:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash /path/to/crash-log

(Yes, you probably should use some way to shorten that.)

I have been working hard on one major iPad project together with the awesome people at Egeniq. My contribution was a significant part of the iPad app coding, but there are way more people involved for design and backend development, and not just at Egeniq either. Last Friday I had the honor of doing the last code review for build 1.0 of the app, and by virtue of approving the merge on GitHub, setting in motion the final build. Whoot!

The opening of the curtains is planned for January of next year and shouldn’t go unnoticed for the Dutch, the target market. There are plans for TV commercials announcing the app, as well as outdoor advertising. Wicked!

Git, GitHub and code reviews

For me this was the first big project using git. Git combined with GitHub really is a winner. The amount of time I spent on fighting with SCM was significantly lower than when using Subversion. There were some disagreements between me and git, but we worked it out.

Something that was actually very neat was the strict rule that code was to be reviewed before it got merged into the main repository. If you know it’s not just you reading the code it makes that you’d doubly want to commit great code. That only works if the code reviewers have a great competency level too, which luckily was the case.

We worked from our own forks, then did pull requests via GitHub. Their interface is great and it is generally quite easy to spot issues. Some things did slip through code review though, mainly bugs where the diff snippets in GitHub didn’t provide enough context for the reviewer to spot the problem. GitHub lets you click through to the full file, but as this lacks highlighting of the changes, it does little in helping to spot problems. Some Ajax-y way to load more context would be a great enhancement.

One rule that we had for code review was that commented out code was not allowed unless a comment was present explaining the reason. The explanation better be a good one too. This was useful in keeping the code base clean. I have noticed that in earlier projects I have let such commented out code blocks accumulate. Usually it would end up being deleted in the end, or if reinstated not work quite as expected anymore due to changes made elsewhere. This commented out stuff just doesn’t belong in your code base. And remember, you are using SCM so you can always get back to it if needed anyway.

Pivotal Tracker

Another tool we used was Pivotal Tracker. I am actually quite enthusiastic about this one. Its strength is its simplicity. You break up what needs to be done in small units of work, stories, and these go through the states: started, finished, delivered and then accepted – or rejected if you messed up. Works fine, though there is one state that I would add: blocked. Too often you run into something where you cannot continue with the work due to a missing image file, specification, backend issue, etc. etc. It would help the project managers to more easily spot where the hold ups are if such stories could be marked as blocked.

Fireworks

One thing that didn’t quite go so smoothly was the delivery of artwork. The designers used Adobe Fireworks. Quite the misnomer, as there is not much that really works in it. Not that I have been able to find any software that could sensibly be used as its replacement, but still. The designs were sliced to extract the needed artwork, but with every change to the design the slices came out with different names, so yeah that was fun. Also, it must not be straightforward enough in FireWorks to name slices something sensible, as we ended up with a bunch of very similarly named image files. Luckily there is QuickLook, but this still sucked.

Third party frameworks

The client wanted integration with some 3rd party services which provided services such as social media, analytics and mobile advertisements. This meant we had to integrate frameworks developed by these parties into the app. Clearly not all frameworks are created equal. We had some excellent ones that were easy to use, and didn’t cause any issues. There were some that gave some build warnings, but worked okay otherwise. And then there was the framework that ignored a number of Cocoa conventions and gave us many instability issues.

In my opinion this underlines the importance of not only choosing a service on promised features and pricing, but also needs technical vetting of the provided framework. It only takes one buggy framework to make the whole app prone to crashes. Luckily the respective third party framework developer was responsive and managed to get us an updated framework just in time for our deadline.

Conclusion

All together it was a fun project to work on, and I am looking forward to its public release. And now I should get back to work: version 1.1 is going to be even better!

It is a sad sad day today. We all knew it was coming. We all knew it was coming sooner than we were praying for. Steve Jobs’ passing away is still a painful stab in the heart. He was crazy enough to think he could change the world, and damn it, did he ever!

It must have been somewhere around 1991 that I for the first time got to play with a Macintosh. What got me right away was the passion that so obviously had been put into building it, into making it a joy to use, easy to use. It was not about typing ‘magic’ commands at a blinking cursor, it was about getting things done, and having a good time doing so too!

Today I am typing this on an iMac with possibilities I could not dream of in 1991. Yet it dwarfs the potential of the iPhone and iPad on my desk. Today is the future. And he is the one who made it all possible!

It is a dream come true for me that today I earn my living developing for Mac and iOS. And it is all made possible by the drive of Steve for the very best. He did not do it all by himself, not even close, but he did manage to motivate and push many, many talented people to reach beyond what they could imagine achievable.

I have not met him or worked with him. I have only seen his work from the sideline. But yet, it feels like he was my motivator too. To tell me good is not good enough, to always aim higher. I like to think some of his passion rubbed off on me.

It is a sad sad day today. Coping with the mourning is though. Humor is one of the few mechanism we have to deal with it, so I’ll end this with a lighter note:

Blessed are those who die after Steve Jobs for them awaits the perfect heaven. He is rethinking the whole concept with God at this moment.

Thank you Steve! You are missed.

URL Building Blocks

Let’s have a quick look at how a URL is constructed. The various parts of an URL are:

scheme://username:password@domain:port/path?query#fragment

The pragmatic approach works well if the base URL does not contain a path, query and fragment. The presence of a path is usually not a problem, it gets trickier when a query is already present, and most solutions definitely fail when a fragment is present.

The code provided below takes the presence of path, query and/or fragment into account. Don’t just take my word for it, you can run the provided unit test to ensure it does it right.

Path

To replace a path complete, use - (NSURL *)URLByReplacingPathWithPath:(NSString *)path. Alternatively, use - (NSURL *)URLByAppendingPathWithRelativePath:(NSString *)path if you want to append a relative path. This also allows to you walk up the path using for example ../foo. The path will get simplified if possible.

Parameter

The most effective way to add parameters is to use - (NSURL *)URLByAppendingParameters:(NSDictionary *)parameters. The dictionary is expected to contain NSStrings as keys. The corresponding values may be either NSStrings or should respond to the method - (NSString *)stringValue, otherwise the value will default to - (NSString *)description. Both keys and values will get URL escaped.

It is valid in an URL to have a parameter name appear multiple times, unlike it is for keys in NSDictionary. You can work around this by calling the method - (NSURL *)URLByAppendingParameterName:(NSString *)parameter value:(id)value multiple times with the same parameter name.

Code

The code is available as a gist on GitHub. The license for the code is a simple BSD license. You don’t need to attribute me or Koolistov in your app (although appreciated if you do), but you need to leave the copyright notice intact on the source files.

Actually, I have to congratulate Microsoft on this one. Like mine (yes, not a subjective opinion, but who cares) theirs is a pretty baby too! A fresh and unique approach is something we don’t often see coming out of Redmond. The tiles, the side-by-side mode, sharing between apps are all great features to have. Also smaller things like being able to swipe between pages whilst dragging is a fun new gesture.

My Desktop is Not a Phone

But it wouldn’t be Microsoft if there weren’t a number of rather baffling decisions. I can see Metro style apps work beautifully on touch devices like phones and, in Microsofts parlance, slates. On desktop and laptop computers without touch these apps are woofully out of place. As a iOS developer I have some experience here, as I often debug apps running in the iOS Simulator. For debugging that works great, but I’d never want to use an app that way on my desktop all day long. Some gestures are nearly impossible, or even completely impossible. Think pinching, rotating, or anything involving more than one finger. Yet, Metro apps are expected to be able to be driven by mouse and keyboard too. If developers have to take that usage method into account, they are targeting the lowest common denominator. You don’t want that.

When Apple announced that with Lion the new features and ideas learned from iOS would make it ‘back to the Mac’, they were actually quite conservative in what they brought along. The current desktop metaphor is still a strong one, and it works wonderfully well with a keyboard and mouse (or trackpad, or both). Apple didn’t put a touchscreen in their desktops and laptops, nor do the let you run iOS apps on the Mac. For a good reason: it doesn’t fit that usage type. Microsoft would have done better to introduce Metro for just touch devices. It would have been a great time also to drop the “Windows” name, which in a chromeless UI as Metro is now just a plain silly name. I think Microsoft also underestimates the negative association many people make when they hear the name “Windows”.

Today’s trend is towards touch. Microsoft correctly saw that. The desktop computer as we know it is here to stay though, that is, with keyboard and mouse. I see desktops and touch devices getting more and more acquainted with each other, but I doubt they’ll ever become one and the same. Just as you don’t connect a mouse to your touch device, bringing touch to your desktop computer won’t do the trick either.

Apple, er… Window Push Notifications

But back to Metro, because on touch devices it looks rather promising. I had a good chuckle when they started talking about push notifications. They call this service “Windows Push Notifications Service”, abbreviated as “WNS”, I guess abbreviating it as “WPNS” was to close to “APNS” as Apple’s push notification service is known. These days having push notifications in your OS is definitely a must. It took Apple until iOS 5 before it finally introduced a notification center. I don’t think I break any NDA rules if I say that I really love having this feature on my iPhone. Microsoft has decided otherwise: “That,” they say, “is not a notification center, but a junk drawer. All those notifications pile up there, and you have to go clean them up or eventually your drawer will overflow with junk.” I wonder how long it will take them to make a full 180 and eat their words on this.

App Branding

Using an icon is now considered “antiquated” by Microsoft. Funny language to hear from the masters of backward compatibility to the extreme. Although I like the general idea of the live tiles over icons, there is one major concern that I have here. It waters down for the user what is your app and what is the OS. This is further emphasized by the use of templates for the live tiles. The icon, before the most important branding an app had, is now a generic tile. Also within the apps Microsoft wants developers to use Microsofts templates and Microsofts typography and Microsofts layout. If the non-geek user already has trouble naming their web browser, in Metro they will have an even harder time identifying which app they are using if they even recognize it as such. I think that as Metro app developer it will be a big challenge to gain name recognition for your Metro app.

Competition Welcome

Although there is a lot of new stuff, it is evident Microsoft took a good look at Apple’s iOS. I don’t doubt the reverse will happen too, and would welcome side-by-side apps in iOS 6. Also the sharing services are great additions and a good feature to have in a mobile OS. It is good that Apple is facing some more competition here now. Until now competition was not too impressive: Android is still playing catchup, WebOS is being kicked around by CEOs and Blackberry… not sure why I even mention them.

The legendary Matt Gemmell had been feeling the need to freshen up his personal blog recently too, and this is how I got to learn about Octopress. Octopress is framework based on Jekyll created by Brandon Mathis. It provides you with a great looking, HTML5 based blog. You run it locally on your own computer where it creates a static website which can be hosted anywhere. Despite being static, it actually offers quite a nice number of features by wisely letting established third parties take care of those, such as comments and searching. It’s quite configurable, and by creating static html you are not getting locked in to one hosting provider. Great stuff!

Octopress has support for deploying directly to GitHub Pages, or rsync-ing to a plain webserver. However, the previous website of Koolistov was running on Google App Engine. There are a few features that I implemented there that are in use by some of my apps, and/or that I would not really want to part with. As it turns out, I can have the best of both worlds: keep my website on Google App Engine, and use Octopress.

The first hurdle though was to get Octopress to run locally. The installation isn’t particularly difficult but there was one gotcha worth mentioning. The installation instructions assume that you are using the bash shell on Mac OS X. If, like me, you have been using a Mac OS X for longer than you can remember, yours may still be the tcsh shell. Once I did the installation via a temporary bash shell, and also use such a bash shell when working with Octopress, all is fine. Maybe someday I’ll catch up with the times and change my default shell to bash, but that’s not for today.

A number of solutions showed up when searching for ways of hosting a static website via Google App Engine. By far the best solution I found made it as easy as putting everything in a folder named static and adding a bunch of handlers to app.yaml. This solution beats others in that it doesn’t require any processing, and that it can serve up the index.html of a folder when such folder is accessed without resorting to performing redirect to the index.html.

Now if only Google App Engine would support naked domain names… I guess we need to keep something to dream about.