I’ve been working on my burgeoning web service idea for just over a year now and I’m finally at the point where I feel like I’m actually making in roads into a fully usable system. It took 3 complete code dump and rewrites to get to this point but I’m finally satisfied with the way it works and how the client has turned out. Each iteration brought with it a rethink of what the application was going to be and a much better focus on what would be important to it. The decision to dump the last code base and start anew was probably the best decision I’ve made in a long time as the resulting product from it is strongly focused on what initially drove me to build this application.
Still after diving head first into the world of handset programming I can’t help but feel that I might have been going about this the wrong way. I initially started coding up the web client first because it would be the easiest of the lot and would ensure that I had the majority of the APIs working properly before I tried my hand at coding for a completely different platform. For the most part that was true as the API I have created facilitates all the functions I require and will work across platforms so long as they’re able to access the Internet. However had I developed a handset application first instead of going for the web client I would have been forced to make some of the hard decisions quite a lot earlier, possibly saving me those 3 code dumps that led to the current incarnation.
You see the first 3 versions I created were heavily focused on the idea of aggregating information around a particular location. I did this mostly because it was a good programming exercise and got me thinking in right direction for coding services destined for the Internet. At the same time however it had me lost in adding in numerous information streams all of which took a significant amount of time to implement. In the end once I got to the core feature that had been rattling around in my head (that whole location based communication thing) it was lost amongst the noise of the other features and the small trials I did with people didn’t even notice it as a feature.
After taking a month long break from coding I had a look at what I was doing and knew that it needed to change. This, I have found, is referred to as a pivot:
That’s the pattern we see in so many successful startups. They did everything they could to take advantage of what they’d built so far. Most engineers naturally think about repurposing the technology platform, and this is a common pattern. But there are a lot of other possibilities. I’d like to call out three in particular: pivot on customer segment, pivot on customer problem, or pivot on a specific feature.
In particular I was pivoting on a particular feature. Up until that point all I had been doing was finding an information feed and adding it in as an option. The core location based messaging feature became an afterthought but that was the hook with which I felt people would find the most use for it. After reading countless articles and looking to those who had come before me for inspiration I knew that if I intended to use such a feature as the main draw it had to actually be the most prominent aspect of the application. Thus Lobaco was born and I feel as if I’m finally taking steps in the right direction, rather than stumbling in the dark.
Working first on the handset would’ve forced my hand with this as you can’t afford to have a scattered focus when you’re working with such a limited environment. Still the lessons learned from those failed attempts have proven to be quite valuable and the coding experience wouldn’t have come any other way. It’s quite possible that I might have been a lot further down the track had I gone for a handset first but that’s not something I’m going to dwell on. Right now I have 3 handsets and a web front page to code up and I’m looking forward to doing each and every one of them.
When I look back at those 4 long years I spent at university I always feel a wide range of conflicting emotions. Initially it was one of bewilderment as I was amongst some of the smartest people I’d ever met and they were all passionate about what they were studying. During my second year it turned to one of pride as I began to find my university legs and excelled at my chosen specialities. However the last 2 years of university saw me turn on the career I had once been so enamoured with, questioning why I should bother to languish in lecture halls when all of what I learnt would be irrelevant upon completion. Still 4 years on from that glorious day when I walked out of parliament house with my degree in one hand I still value my time there and I couldn’t be sure if I had the chance again would I do it any differently.
Unfortunately for me my predictions of most of the knowledge being irrelevant outside of university did ring true. Whilst many of the skills and concepts I learnt still stick with me today many of the hours spent deep in things like electronic circuits and various mathematical concepts haven’t found their way into my everyday work life. I wholly lay the blame for this at myself however as straight out of university the most lucrative career I could land was in IT support, not computer engineering. This is probably due to the engineering industry in Canberra being none too hot thanks to the low population and high public service employment rate but even those who’ve managed to find jobs in the industry quickly learned that their theoretical university experiences were nothing compared to the real world.
What university did grant me was the ability to work well from a fundamental base of knowledge in order to branch out into other areas. Every year without fail I found myself trying to build some kind of system or program that would see me dive back into my engineering roots to look for a solution. Most recently it has been with Lobaco as I’d barely touched any kind of web programming and had only limited experience in working with real 3 tiered systems. Still my base training at university allowed me to ask the right questions and find the right sources of information to be able to become proficient in a very short space of time.
Flush with success from coding and deploying a working system on the wider Internet my sights turned to something I had only a cursory experience with before: mobile handsets. A long time ago I had tried to code up a simple application on Windows Mobile only to have the program crash the simulator repeatedly and fail to work in anything meaningful way. Still being an iPhone user and having downloaded some applications of questionable quality I thought it couldn’t be too hard to pick up the basics and give it the old college try. Those of you following me on Twitter would have noticed how there was only one tweet on iPhone applications before I mentioned HTML5 as the potential direction for the mobile client, signalling that I might have bitten off more than I could chew.
Indeed this was what happened. Attempting to stumble my way through the other world that is Objective-C and Xcode was met with frustration on a scale I hadn’t felt in quite a while. Whilst the code shares a base in a language I know and understand many things are different in ways I just hadn’t fathomed and the resources online just weren’t the same as what I was used to. I managed to get a few things working but doing simple things like say incorporating the pull to refresh code into my own application proved to be next to impossible and still elude me. After a while though I began to think that I was missing the fundamentals that I had had when developing for other platforms and dreaded the idea of having to drudge through one of the millions of iPhone programming books.
Right in the depth of my plight I came across this Slashdot article on someone asking which mobile platform they should develop for. Amongst the various responses was this little gem that pointed me to something I had heard of but never looked at, iTunesU. I had known for a while that various universities had been offering up their lecture material online for free but I hadn’t known that Apple had integrated it into their iTunes catalogue. Searching for the lecture series in question I was then presented with 20 lectures and accompanying slides totalling several hours of online content. With the price being right (free) I thought nothing of downloading the first lecture to see if there was anything to gain from this, and boy was there ever.
Whilst the first 30 minutes or so were general housekeeping for the course itself the last 20 minutes proved to be quite insightful. Instantly I knew that the way I was approaching the problem wouldn’t work in Apple’s world and I needed to develop a fundamental base of knowledge before I could make any meaningful progress. These lectures have proved to be an invaluable source of knowledge and proved to be instantly valuable, helping me develop a base application that resembles what I hope to one day release to the world.
It’s this kind of knowledge dissemination that will disrupt the traditional education frameworks. The amount of information available to anyone with an Internet connection is unfathomable and those with a desire to learn about a particular subject are able to do so without any limitations. Back when I started at university anyone wanting to attend the lectures had no choice but to be physically present at each lecture. Sure you could probably grab the lecture notes but they’re a poor substitution for actually being there, especially when the classes are as useful as the ones provided by Stanford. They won’t make you an iPhone programming genius on their own but if you’ve done any sort of programming before you’ll quickly find yourself becoming vastly more proficient than you would bumbling around blindly in the Xcode IDE as I did.
In the end I realised there’s really no substitute for starting with the fundamentals and working your way from there. I had assumed that based on my extensive past programming experience that learning an new language and IDE would be a walk in the park. It took me several days of frustration to realise that I was using my Microsoft hammer to bash in Apple nails and that wasn’t getting me anywhere fast. Just an hour spent watching a very basic lecture proved to be more insightful than the hundreds of Google searches I had done previously. It’s still early days for me as an iPhone programmer but I’ve got a feeling that the next few weeks spent coding will be much easier than the week that has led up to it.
There were so many times when I was coding up early versions of Lobaco that I didn’t give any thought to security. Mostly it was because the features I was developing weren’t really capable of divulging anything that wasn’t already public so I happily kept on coding leaving the tightening up of the security for another day. Afterwards I started using some of the built in authentication services available with the Windows Communication Framework but I realised that whilst it was easy to use with the Silverlight client it wasn’t really designed for anything that wasn’t Windows based. After spending a good month off from programming what would be the last version of Geon I decided that I would have to build my own services from the ground up and with that my own security model.
You’d think with security being such a big aspect of any service that contains personal information about users that there would be dozens of articles about. Well there are but none of them were particularly helpful and I spent a good couple days researching into various authentication schemes. Finally I stumbled upon this post by Tim Greenfield who laid out the basics of what has now become the authentication system for Lobaco. Additionally he made the obvious (but oh so often missed) point that when you’re sending any kind of user name and password over the Internet you should make sure it’s done securely using encryption. Whilst that was a pain in the ass to implement it did mean that I could feel confident about my system’s security and could focus on developing more features.
However when it comes down to the crunch new features will often beat security in terms of priority. There were so many times I wanted to just go and build a couple new features without adding any security into them. The end result was that whilst I got them done they had to be fully reworked later to ensure that they were secure. Since I wasn’t really working under any deadline this wasn’t too much of a problem, but when new features trump security all the way to release you run the risk of releasing code into the wild that could prove devastating to your users.
No example of this has been more prolific than the recent security issues that have plagued the popular micro-blogging service Twitter. Both of them come hot on the heels of the release of the new Twitter website released recently that enables quite a bit more functionality and with it the potential to open up holes for exploitation. The first was intriguing as it basically allowed someone to force the user’s browser to execute arbitrary Java script. Due to the character length limit of Twitter the impact this could have was minimised, but it didn’t take long before malicious attackers got a hold of it and used it for various nefarious purposes. This was a classic example of something that could have easily been avoided if they sanitised user input rather than checking for malicious behaviour and coding against it.
The second one was a bit more ugly as it had the potential to do some quite nasty things to a user’s account. It used the session details that Twitter stores in your browser to send messages via your account. Like the other Twitter exploit it relied on the user’s typical behaviour of following links posted by the people they follow. This exploit can not be squarely blamed at Twitter either as the use of link shortening services that hide the actual link behind a short URL make it that much harder for normal users to distinguish the malicious from the mundane. Still Twitter should have expected such session jacking (I know I have) and built in counter measures to stop them from doing it.
Any large public system will attract those looking to exploit it for nefarious means, that’s part and parcel of doing business on the web. The key then is to build your systems with the expectation that they will be exploited rather than waiting for an incident to arise. As a developer I can empathise that developing code that’s resistance to every kind of attack is next to impossible but there are so many things that can be done to ensure that the casual hackers steer clear. Twitter is undergoing a significant amount of change with a vision to scale themselves up for the big time, right up there with Google and Facebook. Inevitably this will mean they’ll continue to have security concerns as they work to scale themselves out and hopefully these last two exploits have shown them that security is something they should consider more closely than they have in the past.