If you look at the biggest websites and internet applications, you can pretty much divide them into two groups. Those that are geographically diverse and those that aren’t. It’s kinda shocking that in 2010, the majority of major internet properties still are located in a single (large) datacenter. Though to be fair there is a good reason for that, geo-diversity has many challenges. Problems like directing traffic to the fastest/closest/cheapest/most available location are pretty easy to solve: most people go with BGP AnyCast, targeted DNS responses, or a combination of both. The real challenge though is making sure your actual served content is coherent among all the locations. It would be terrible for a user to upload a photo, sent the URL to their friends, only for the friends to see nothing or worse, the wrong image.

For static content, this is easy, even RSYNCs will be scalable to push out changes to your content amongst your farm. User uploaded content is quite a bit trickier. Within a single datacenter you can efficiently (though not always affordably) solve this using shared storage, iSCSI or NFS. Then applications pretty much can work as if they’re on a single server, session management can be tackled by using cookie or host persistence on the load balancers to make sure a user stays on the same server. What about servers in different locations though? NFS and iSCSI will not be terribly effective over transit.

You will have to push content between your locations then. If you are trying to geographically distribute your own application, you would just write functionality in to immediately push any user uploaded content out to other locations as its created.  Google/Youtube are great examples of this. When you hit content they’ve hosted, it isn’t even hosted on every server, and they direct you to the closest server that has said content. If that content isn’t available locally to you yet, or at all, they can stream it over their own fiber backhaul and out your closest Google POP.

But what if you are hosting a variety of 3rd party software. To my knowledge none of the popular blog packages, forum software, etc has any sort of geo-diversity designed into them. You could of course fork them and write your own, but then you end up supporting N different software packages for your N clients, not affordable or reasonable.  Rsync would do this task but unfortunately it is very intensive and doesn’t scale particularly well because it md5′s your entire tree constantly to see if things changed. As your content scales, the rsyncs would get slower and slower just seeing if changes occurred, eventually leading to massive delays on syncing out user created content.

In the end, its a cool problem, a problem that not too many people have tackled so far. We came up with our own solution, which I unfortunately probably shouldn’t disclose. I wrote the basis of the software last month, though it still needs some bug fixes, testing and more modules to be written for it. It is a difficult problem to tackle, but having worked in telecommunications, no facility is bullet proof, no power is bullet proof, no connectivity is bullet proof, no hardware is bullet proof: geo-diversity is a must going forward in this highly demanding world where everyone expects connectivity and content 24/7

So my true weakness when it comes to end-to-end application development is always the UI. I think like a developer, am happy with terminals and verbose logging, I nitpick positioning and sizing endlessly, and I generally am never too happy with what I generate.

Now the beauty of the iPhone SDK is that it uses XCode’s interface builder, and Cocoa / CocoaTouch support directly loading polished NIB at runtime.  NIB is of course NextStep Interface Builder, and though they actually use a .xib (XCode Interface Builder) file while you develop them, at runtime and pretty much everywhere else they’re called NIB files. (Because Cocoa *IS* NextStep)

So back to the topic at hand. I have always liked the way Visual Studio did interface building, as it took the coding out of creating a UI and let it be about what it should be, an art*. XCode offers the same experience but with a bit more of a learning curve. The real challenge though is that on the iPhone, you have a lot to live up to. There are a lot of very attractive apps out there. Creating a tool for sysadmins to receive and handle alerts doesn’t require the polish and pizzaz of lets say a Twitter client, but it can’t be ugly or clunky either.

So in Cocoa Touch we have the Navigation Controller (UINavigationController, which provides a bar at the top with text a button on the left and right to navigate through views) and the Tab Bar Controller (UITabBarController, which provides a bar across the bottom with any number of iconable tabs that represent different views) Of course you have the freedom to come up with whatever UI you want outside these, however these conform to Apple’s User Interface Guidelines (a fascinating read, and the iPad guidelines were an even cooler read) and match the look and feel of the iPhone, making it easier for users to navigate. In fact you can even combine the two types and create navigated views within a tab, or a set of tabs within a navigated view. The sky is the limit and its easy to do, which is whats the most fun about XCode and Cocoa Touch.

So I decided to go with the Tab Bar. We are dealing with alert handling here, I know from experience that there are only a finite number of tasks that are required after hours, so we can stuff those as tabs a long the bottom. On Ken’s advice I added a More… tab which contains lesser used but still useful utilities like short cuts to compose emails to common distribution lists @FM, a long with access to the two ticketing systems outside of our department.  Throw in a Core Animation page flip between tabs (the code for animation in Cocoa Touch is really quite impressive) and you have something that looks decent (I think) and is fairly functional.  On a slightly side note, I kept the animation to a quarter of a second, that way it looks flashy but doesn’t slow down work flow, thats important to me. I’ve likely disabled every animation OS X has to offer on my computers after all..

I’ll likely write a follow up discussing my experience with some of the other UI widgets at a later time, but I wanna touch briefly on the spinning selector as seen in my Tab Bar screen shot. The iPhone’s user experience is superior to any other touch phone. (Android, Pre, Storm, I’m looking at you guys) I was very reluctant to use a touch screen interface because they usually annoy me long after the cool factor wears off. Apple has gone to great lengths to design the user interface of their own apps to work really well with fingers. The spinning selector is a great example of that. On the desktop, we normally select a choice of one from many in a drop down box. This works great, but is a tad annoying on something like an Android phone. The spinning selector is more of a wheel you spin with your finger that has very intuitive acceleration and deceleration such that its very easy to use. Because Apple makes it so easy to deploy these widgets in your own applications, you are very unlikely to see kludgy desktop-esque UI on the iPhone, making the user experience of 3rd party apps all the more familiar and better. That and they theoretically could stop you from publishing apps that don’t conform to the user interface guidelines, though in practice they pretty much only ban apps for their own dirty anti-competitive purposes…

*Design is an art, and UI design is at the forefront of that these days. Just look at all Apple products. You may not like their design (lord knows I’ve stripped OSX so bare its just a tiny bar on the right, no desktop and the Finder process isn’t running most of the time), but its still intuitive and attractive. In the end Apple is a design company. A PC is just a PC until its in a sleek, durable unibody aluminum case, then its a Mac. BSD is just a server operating system until its got an attractive, intuitive user interface, then its OS X.

So on Sunday I got the inspiration for my second iPhone app, fmNotify. (the first was a simple multi-tab webkit integration for a friends website that made use of some clever code to hide the tab and status bars when rotated as well as the shake gesture to go back on the current page)

fmNotify will be (ok I’m being a tad presumptuous but I have faith :>) our internal notification service for emergency alerts. It utilizes Apple’s fantastic push notification service (APNS, APN or APS depending where you read it) and some clever UI to streamline alert handling. Basically alerts and phone registration is handled by PHP code running on a server(s, easily redundant using mySQL replication) inside our network, stored in an SQL database. This allows for  pretty extensible triggering of alerts, everything from Nagios, email via procmail, and our own internally developed software.

The real thing I wanted to talk about is how impressed I am in the APNS bits of the SDK. iPhone SDK 3.x is really where the iPhone hit its stride, and the push SDK is a big part of that. (Prior to 3.x it was a pretty disappointing device IMO and more than a fancy toy for teenagers than anything workable.) OS 3.x makes the device a powerful device for any industry. (Though MobileMail.app is still so woefully inferior to the Blackberry)

BUT I DIGRESS. Working with APNS is a coders dream. When your app is setup with Apple for push support, you get a cert that can be used to connect to the APNS cloud with. APNS requires a connection via TLS or SSL, which of course can be done easily with libopenssl in C or in this case PHP. From there all you need to do is send json blobs that contain: the device id of the handset, the alert text you want to display, the badge number to show on the app (if desired) and the sound to play (if desired). Beyond that you can include whatever other custom data you want, within 256bytes. This may seem like a rather limited amount of data to work with, but its really just to trigger your app to connect to you own servers, which can then pull down whatever data you want.

So while your app isn’t running and a notification comes in, a popup will occur with vibration/sound if desired, and a link to automatically launch your app.  While it is running an event is triggered within the app delegate and you can handle it however you want. Pretty awesome. Throw that all together with a nice GUI and you have a really streamlined alert / alert handling work flow!

So the app itself is pretty simple. Just a basic UI for seeing alerts / alert history, and then panels for dealing with common alerts.  The backend is basic PHP / mySQL / simple JSON / openssl integration to handle registration (including the device id and desired alert sound) for each phone, and directing of alerts to whoever is oncall. I really look forward to future projects using APNS, considering this took less than a day to throw together, the sky is the limit!

So I’ve decided to catalog some of my development projects / experiments as well as make my general rants bigger than the SMS sized text field twitter allows. So for the 800th time, I’m launching a blog.

So far I think I’m going to approve comments by hand, but once someone has an approved comment they can post instantly. That shouldn’t be too much effort, but we’ll see how it goes. I’m feeling too lazy (it is Sunday morning after all) to dig up some captcha plugin and install it. WordPress is always very enjoyable to install, its quick and painless. The photo I threw uptop was taken last Fall in Mississauga’s Port Credit. Here it is in its entirety. I chose it due to fairly similar colors to the theme I chose. I will likely change it in the near future.

(I did however throw up a Twitter plugin to syndicate all my rants to my various social media outlets. I apologize for any perceived spam in advance!)

Don’t have too much to say other than that, it is Sunday morning after all. Cheers!