JSON, .NET and NSDate

If you’re trying to access a JSON web service created using .NET from an iOS device, you’ve probably discovered that dates are produced in a less than useful format:

/Date(1233423345345)/

The rationale for the date format can be found here, but it’s basically a call to the JavaScript Date object constructor. The numeric value represents the number of milliseconds since 1970-01-01.

Below I’ve added a handy Objective-C function that will extract the value and return an NSDate object. Note that we’re losing accuracy by magnitudes as we translate from .NET DateTime objects (which measure time in ticks) to JavaScript Date objects (which measure time in milliseconds) and finally to iOS NSDate objects (which measure time in seconds).

/**
 * Converts a .NET JSON date in the format "/Date(x)/" to an NSDate object.
 * @param string The NSString to convert.
 * @return the NSDate object.
 */
(NSDate*)jsonStringToNSDate(NSString* string) {
 
	// Extract the numeric part of the date.  Dates should be in the format
	// "/Date(x)/", where x is a number.  This format is supplied automatically
	// by JSON serialisers in .NET.
	NSRange range = NSMakeRange(6, [string length] - 8);
	NSString* substring = [string substringWithRange:range];
 
	// Have to use a number formatter to extract the value from the string into
	// a long long as the longLongValue method of the string doesn't seem to
	// return anything useful - it is always grossly incorrect.
	NSNumberFormatter* formatter = [[NSNumberFormatter alloc] init];
	NSNumber* milliseconds = [formatter numberFromString:substring];
 
	[formatter release];
 
	// NSTimeInterval is specified in seconds.  The value we get back from the
	// web service is specified in milliseconds.  Both values are since 1st Jan
	// 1970 (epoch).
	NSTimeInterval seconds = [milliseconds longLongValue] / 1000;
 
	return [[NSDate dateWithTimeIntervalSince1970:seconds] autorelease];
}

Blogging with Mercurial from the Rocky Mountains

It’s been a while since the last update, but I do have a good excuse. I’ve upped sticks and moved from dingy Birmingham, in the UK, to sunny Littleton, Colorado, in the USA.

So, who’s hiring?

I’ve decided to start blogging about those experiences, but rather than flood this blog with personal posts I’m making a separate blog. But what blogging platform to use? It’s not going to have much traffic, I don’t want to put any admin time into it, I don’t want comments or tags or categories. All I want is to be able to post text as quickly as possible using Markdown.

It would be great if there was a blogging platform for Mercurial like the one available to Github users, but I’ve looked around and haven’t been able to find one. So why not write one?

Here’s my list of requirements:

  • Displays blog posts in reverse chronological order (newest first).
  • Posts are written in Markdown and reformatted into HTML automatically.
  • Posts are stored in a repository on BitBucket.
  • Pushing to the posts repository automatically updates the blog.
  • Allows paging through blog posts.
  • Includes an “Archive” page that lists all blog posts.
  • Has an RSS feed.
  • Maintains a cache of blog posts to minimise queries to BitBucket’s API.
  • Looks a bit like WordPress’ “TwentyEleven” theme, as that’s my favourite theme at the moment.

After a couple of evenings of hacking, here’s the result:

And here’s a demo:

A blog powered by BitBucket and Mercurial. Neat!

I’ve included instructions for getting a BitBlogger instance up and running on AppHarbor, a .NET hosting site that offers a basic freemium option. As BitBlogger doesn’t use any local storage or background events (BitBucket notifies it of changes, rather than BitBlogger needing to poll for updates), it doesn’t need anything above the free package.

I’ve copied bits and pieces of the TwentyEleven theme’s CSS file in order to replicate some of the appearance, so the licence for this application is the GPL rather than my preferred MIT licence. If anyone feels like putting together a simple and very legible theme to replace the current look and feel, I’ll be able to switch it over.

Stuff I Use

Inspired by Scott Hanselman’s enormous list of tools that he uses, used, or heard of once, here’s three comparatively tiny lists of tools I use every day. The first list is comprised of cross-platform software that I use on both OSX and Windows. The second is OSX-only software and the third is Windows-only software.

I don’t use Linux enough to have a set of tools I recommend. As I’m the only person on the planet to think that Unity is actually a small step in the right direction, even if it does need optimising, my opinion doesn’t count.

Cross-Platform

  • Sublime Text 2 - Without a doubt, the best text editor I’ve used on any platform.
  • VLC - The most versatile media playback program around.
  • DiffMerge - 3-way diff tool.
  • Mercurial - Distributed version control.
  • FileZilla - FTP client.
  • Dropbox - File syncing in the cloud.

DiffMerge and FileZilla make the list over other more advanced programs by virtue of being free and cross-platform. Mercurial triumphs over Git thanks to its first-rate Windows support and its spectacular command line UI. I recommend TortoiseHg for Windows as it is often handy to see at a glance if anything in a repository has changed without firing up PowerShell.

OSX

  • iTerm2 - Replacement for the standard Terminal.app featuring tabs.
  • Hex Fiend - Because everyone needs a hex editor.
  • PlainCalc - Calculator with a console interface.
  • Adium - Fantastic IM client.
  • KeePassX - Encrypted password storage.
  • Acorn - Simple image editor.
  • VMWare Fusion - OS virtualisation, great for Windows.
  • VirtualBox - OS virtualisation, great for Linux.
  • The Unarchiver - Decompressor for zip, 7zip, etc.
  • Bean - Simple word processor.
  • XBMC - Media player.

VMWare and VirtualBox both make the list because they have different strengths. VirtualBox is open source, free and cross-platform, but it makes no effort to integrate into the host operating system. VMWare Fusion’s full screen mode means I can three-finger-swipe to switch from OSX to Windows, which is almost magical.

Windows

Was the iPad “Undesigned”?

This is what baekdal has to say about Samsung’s inability to design a tablet that doesn’t look like an iPad:

Apple didn’t trademark their design. They trademarked the natural shape a tablet could have. It’s like the New York Times trademarking the shape of the newspaper.

Samsung is saying that there is no other way to design a tablet, and they are right. They could have used different materials, but the overall shape is not Apple’s design. As I demonstrated in this article, the shape of an iPad is the logic progression of simplicity itself.

This is Steve Balmer, holding a pre-iPad tablet computer running Windows XP:

The similarity to the iPad is uncanny. Why, there’s no other way it could be designed. The sleek, uniform black bezel around the screen, the lack of buttons and surface distractions, the round corners; even the guy in the black turtle neck holding it!

No, wait. It looks nothing like an iPad.

Let’s be honest - all tablets prior to the iPad were junk. They ran desktop operating systems that were entirely inappropriate to the constraints of the hardware (hello Windows 8!). They had terrible battery life. Aesthetically, they were dreadful. However, the iPad isn’t the only possible way to design a tablet. It’s just the best design around at the moment, which is why everyone else is copying it.

All of the ideas Apple suggested Samsung use in their design - non-black surface, hard corners, fat profile, non-centred screen, etc - sound utterly stupid. However, these are precisely the same design ideas that every tablet manufacturer was using before Apple put some thought into the problem. Apple isn’t saying, “You should use these obviously dumb ideas we’ve just come up with so that your product is crippled in comparison to ours.” They’re saying, “You should continue to use the dumb ideas that crippled your products before we showed you how to make tablets that don’t suck.”

Enterprise iOS Apps

Recently I’ve been looking into the potential of iOS devices in the enterprise, which is surprisingly zeitgeisty. Computer users in enterprises typically have to deal with laptops that take 10 minutes to boot because they’re old, running Windows XP and laden with crufty enterprise junk. Users can’t install anything because they don’t have admin rights, and the IT department doesn’t want to spend its time uninstalling the Bing toolbar and Bonzi Buddy from the computers of techno-illiterates who, like magpies, are attracted by anything that blinks, flashes, glows or moves. They have to deal with IE6 and a virus killer that saps their CPU time and their will to live in equal measure.

A few people within enterprises have bought iPads or iPhones and suddenly find themselves with a computer that doesn’t have IE, doesn’t have viruses, allows them to install whatever they want and is always ready to use. They’ve realised that they can do most of their work with nothing more than an iPad and a Bluetooth keyboard. If only there was “an enterprise app for that” they could dump their bottom-of-the-range Dells with their oversized bag and carry around their iPads instead; hence the need for enterprise iOS applications.

The average enterprise application consists of:

  • An enormous, badly-designed database written by guys who didn’t know how to make databases but who once met the brother of a friend of an acquaintance who’d seen a SQL query a few years ago, didn’t really understand it, but thought it was pretty neat;
  • A vile, enterprisey “business logic” layer, with interfaces that describe factory classes that produce factories that produce classes that aren’t used anywhere in the codebase, because all of that clever planning and abstraction was a counterproductive waste of time;
  • A dumb web UI that allows CRUD operations on the database, cunningly designed to be 100% compatible with Internet Explorer 5 and 6 and utterly unusable in anything else, possibly even implemented as an ActiveX control masquerading as a website for marketing purposes.

Enterprise iOS apps will typically replace this last tier of the application stack. At the very least, apps need to be able to interact with the business logic layer to perform CRUD operations.

If you’ve been smart when putting together your existing systems, you’ll have followed Steve Yegge’s advice and built everything as a service. Want to know which user has the network ID “elb”? Point your web browser at your RESTful HR web service and query /employees/elb. The user’s details will be output in easy-to-parse JSON format.

In that case, you can give yourself a congratulatory pat on the back and go grab copies of ASIHTTPRequest and JSONKit. All of your systems are already set up in such a way that you can interact with them from pretty much any device that supports HTTP. It’s even easier if they can perform asynchronous requests and parse JSON.

If you haven’t built a service-oriented architecture, or were misguided enough to use WCF and SOAP - perhaps because you wanted to add a piquant dash of vendor lock-in to an architecture designed for heterogeneity - you could do far worse than take a look at Nancy. This is a micro web framework for C# based on Ruby’s Sinatra that will allow you to create RESTful web services, and indeed full websites, with astonishing ease.

The next issue you’ll have is security. What you really don’t want to do is expose your databases to the internet, particularly if those databases contain sensitive data such as employee details, client data, etc. If your iPhone needs to interact with a web service behind a firewall, what can you do?

You have 3 options:

  • Ignore the security issues and expose your web services to the internet;
  • Only allow the app to work when the iPhone is connected to the corporate network;
  • Connect the iPhone to the corporate network via a VPN.

I like to think of the first option as “the Sony approach”. If you don’t particularly value the privacy of your employees or your clients, don’t mind months of downtime when you try to shoehorn security features into a live system and aren’t embarrassed by publically demonstrating your astounding ineptness, this is a very worthwhile choice. On the other hand, you might recognise it as a security disaster waiting to happen.

The second option introduces some complexities. The whole point of a mobile app is that it’s, well, mobile. A mobile app that can only be used at a single location is obviously not amazingly useful. One possible workaround would be to cache relevant chunks of the database’s data on the iPhone. All CRUD would be performed on the cache. Any changes would get replicated to the master database when the device next connected to the corporate network. Obvious downsides are the need to deal with conflicting edits, either by automatic/manual merging or by asking the user if he wants to overwrite the remotely-edited version with his own changes.

It’s a tidy solution, but it introduces another security risk - your sensitive data is now stored on a highly desirable and easily mislaid phone. You could consider encrypting data stored on the iPhone. More extreme possibilities for securing the data include requiring a username and password to start the app (which would be a massive detriment to usability) or setting up the device in Exchange so that it can be remotely wiped if lost.

The third option is the best tradeoff between usefulness and security. VPN traffic will be encrypted, there’s no need to punch holes in the corporate firewall, and the VPN can be accessed from any location with internet connectivity. The iPhone has an excellent built-in VPN client that appears to offer identical functionality to the client in OSX. This solution obviously relies on the company having an existing VPN infrastructure or being open to the idea of implementing one.

The downside is that a lost device now has access to not only any enterprise apps but the VPN too. The risk associated with this can be mitigated by using a username/password combo to authenticate with the VPN instead of using a certificate. Certificate-based authentication happens automatically, whereas username/password-based authentication requires the user to type in his password every time he tries to connect. This might be the most appropriate approach to adopt anyway, as corporations are fond of implementing expiry policies that would necessitate the creation of new VPN certificates every few months. However, the user would need to manually sign on to the VPN each time they used the app. Worse, the iPhone has a habit of dropping VPN connections whenever it feels like it. How often do you want your users to enter their passwords?

The best approach is probably a mixture of the above:

  • Encrypt all local data
  • Set up all iOS devices in Exchange so that they can be remotely wiped
  • Allow read-only access offline by caching data on the device
  • Require a VPN connection for editing data

The VPN can authenticate via certificate for ease of use or via username/password for heightened security/to appease the password policy patrol.

Our enterprise iOS app architecture now looks like this:

  • MSSQL database used as storage
  • .NET-based business logic layer
  • RESTful Nancy web service exposing CRUD operations of business logic layer
  • VPN connection for encrypted, authenticated communication with the web service
  • iOS UI app that caches data locally for offline browsing and allows the user to interact with the web service via ASIHTTPRequest and JSONKit

Vaguely related to this, I’ve added a simple website/web service for distributing enterprise iOS apps to my BitBucket page:

It presents a list of iOS apps in an iOS-friendly website and allows them to be downloaded straight to the device. It can also be used by apps to determine the latest version number should they want to update themselves automatically.

Website Changes

Things have moved around here at Zombie Towers. First up, this blog has moved from ant.simianzombie.com to simianzombie.com. It was originally in a subdomain because I shared the server with a few friends, but they got their own dedicated hosting years ago. There was no reason to be on a subdomain any more, other than inertia and laziness, so I’ve moved it.

Secondly, I’ve dumped the gtp.simianzombie.com subdomain. This was a collection of ancient Amiga software and music I’d written. The good stuff is available on the Aminet and the rest wasn’t worth hosting.

Graphics Editing in OSX Lion

Problem

I need to edit the top-left pixel of a bitmap in Acorn.

Solution 1

Just edit the pixel, duh. Wait, what’s this? The mouse pointer turns into a resize arrow when I get anywhere near the top-left pixel. In fact, I can’t edit any pixels around the edge of a window thanks to the new window resize behaviour (which I never use and didn’t want).

Solution 2

Make the window full-screen. OK, I’ll fill my 24” monitor with an enormous single picture just so I can edit one pixel. Here we go, let’s edit that pixel! Oh wait, that’s not going to work. The menu bar drops down whenever the mouse pointer is at the top of the screen.

Didn’t Macs used to be the choice for graphics pros?

Installing Hatta on Windows

I’ve been trying to find a replacement for a SharePoint 2007 wiki that was foisted on my team. If you’ve ever used SharePoint’s standard wiki system, you’ll know that it’s just a cruddy wiki-like front-end for a ropey CMS. Browsers other than IE have the WYSIWYG editor disabled and the user is left to edit raw HTML. Wiki markup? What’s that?

I’ve got a number of requirements for the replacement.

Must be cross-platform

As I find myself developing in both C# and Objective-C, I need a wiki for half a dozen trusted users that works in Windows and on the Mac.

Must use a standard wiki markup

I’d prefer Markdown or Creole. As long as I’m not forced to drop into HTML or use a WYSIWYG interface I’ll be reasonably happy.

Must be easy to set up

Preferably I just want to run an installer and have the wiki running. Every dependency I need to install and set up - web server, database server, scripting language - is a mark against it.

Must be simple

I neither need nor want authentication systems, online help, sandboxes, advanced formatting, styles, drawing APIs or file uploading. Just a way to store short, linked text documents.

Must use a DVCS as its storage system

If the wiki stores its data in a DVCS I can clone it and take it home with me.

What I really want, I realised, is an open-source version of BitBucket’s wiki. I’ve looked at dozens of systems. The most promising are MoinMoin version 2, which unfortunately isn’t finished yet, and Hatta.

Hatta is a fantastic little wiki. Its features include:

  • Cross-platform (written in Python)
  • Simple but attractive interface
  • Mercurial storage system
  • Creole syntax (for the most part)
  • Built-in web server

It comes in two forms. You can download it as a pre-compiled binary, with all dependencies included, for OSX and Windows. Alternatively, you can download it as a pure Python solution, though this entails setting everything up yourself.

I started out with the binary distribution, which was very easy to get up and running, but I quickly ran into problems. The binaries are now 4 minor revisions out of date, and according to the author the chances of them being updated are slim to none. Worse, the binary regularly freezes up. That’s no use as a centralised wiki.

Trying to get the plain old Python version working in Windows is a pain as there’s no documentation for it, so here’s how to do it.

Installing Hatta in Windows

Firstly, we need to get Python set up and install Hatta’s dependencies.

  • Download Python 2.7.2 from python.org. Hatta will not (currently) work with Python 3.
  • Install Python using all of the default settings (just keep hitting “Next”).
  • Download “setuptools” from pypi.python.org. Assuming you’re using a 64-bit version of Windows you’ll need to download the “ez_setup.py” script and run it like this:
C:\Python27\python.exe .\ez_setup.py
  • Open up a command line as admin and enter the following:
cd C:\Python27\Scripts
.\easy_install-2.7.exe werkzeug
.\easy_install-2.7.exe pygments

That’s Python installed and two Python packages that Hatta is dependent on. Next we’ll need to download Hatta itself and integrate it with Mercurial.

  • Download Hatta from hatta-wiki.org. You’ll need the zipped version.
  • Unzip Hatta to C:. This should give you the following paths:
C:\Hatta\doc
C:\Hatta\examples
C:\Hatta\locale

Etc. You don’t have to put Hatta in the root of C: but it simplifies this guide.

  • Download the Mercurial source code from mercurial.selenic.com. The binary builds are of no use to us.
  • Extract the tarball.
  • Open the extracted directory and locate the “mercurial” folder.
  • Copy the “mercurial” folder to C:\Hatta\ (giving you the folder C:\Hatta\mercurial\hgweb etc).
  • Copy the “hgext” folder to C:\Hatta
  • Open the “mercurial” folder in C:\Hatta.
  • Open the “pure” folder.
  • Copy the contents of “pure” into the “mercurial” folder (giving you C:\Hatta\mercurial\bdiff.py etc).

We’re done! What we’ve done is copy the parts of Mercurial required by Hatta into the Hatta directory. Yes, this is an ugly hack, but it’s the easiest way of getting Hatta up and running. When new versions of Mercurial get released, you’ll need to delete the “mercurial” and “hgext” folders and upgrade them with the latest source (remembering to fiddle about with the “pure” folder).

You can now test the installation by opening a command line and typing:

C:\Python27\python.exe C:\Hatta\hatta.py

Point your web browser at http://localhost:8080 and, if everything has gone to plan, you’ll see the Hatta editor page.

Another Objective-C Gotcha: Synthesized Properties and Ivars

When synthesizing ivars and properties, Objective-C will give both the same name. Unless explicitly told to use the property by prefixing it with self., Objective-C will use the related ivar instead when referenced within the class.

I spent about two hours trying to track down the problem in the code below. It’s obvious now that I know what the problem is, but trying to isolate it from the rest of the application was tricky. The fact that the code in question was interacting with a block, a cause of much memory-related pain in the past, threw me off the scent for a while.

This is the interface for the class in question:

@interface Person : NSObject
 
@property (copy) NSString* name;
 
- (id)init;
- (id)initWithName:(NSString*)aName;
- (void)dealloc;
 
@end

This is the implementation:

@implementation Person
 
@synthesize name;
 
- (id)init {
	[self initWithName:nil];
}
 
- (id)initWithName:(NSString*)aName {
	name = aName;
}
 
- (void)dealloc {
	[name release];
}
 
@end

Here’s how we’d use it:

Person* bob = [[Person alloc] initWithName:@"Bob"];
 
NSLog(@"%@", bob.name);

This looks fine, but it contains a subtle bug. Trying to retrieve bob.name will result in a crash once the current autorelease pool has been drained. The synthesized property name and its backing synthesized ivar are both called name. When we set name equal to aName in the initWithName: method, we are setting the ivar, not the property. Thus, we bypass the copy logic that we’ve set up in the property and just change a pointer. The string literal @"Bob" is autoreleased, so we’ve got a pointer to a deallocated object.

There are two ways to avoid this mistake:

  • Always declare ivars explicitly, using a name that is different from the property name (ie. _name);
  • Always prefix property names with self. when referring to them.