Posts Tagged‘lobaco’

Gamification Doesn’t Always Make Sense.

When I first started hearing about achievement systems I honestly thought they were a total waste of time. I usually play games just for the sake of playing them, not because I want to have some kind of meta-performance tracker that I can show off to my friends. I did start to warm to them when the encouraged novel or interesting kinds of game play like many of the achievements in Team Fortress 2 did. It wasn’t long after achievements caught on that the whole gamification movement took hold and all new start ups started adding game features to their products.

Now I wasn’t immune to this either. When I was working on Lobaco I thought it would be a great idea to add in some achievements in order to encourage people to participate in local discussions. Indeed I was going to take it a couple steps further and have things like local leader boards and titles based on your overall score in a particular area. All of these things were done in the name of increasing user engagement as many studies and successful start ups have shown that game like elements keep people coming back. Of course everyone then saw it as the panacea to their ills and game elements started appearing in places that they really shouldn’t.

I came across one such example this morning in my usual troll for blog fodder. Microsoft, for some strange reason, decided to code up an achievement system for Visual Studio, their flagship development environment. It looks to be an extension to Visual Studio itself and currently only works if you’re coding with Visual Basic or C# (arguably the most common languages though). There’s dozens of achievements already in there and even a leaderboard of the top 15 people who’ve gained the most achievements. Taken at face value I can see this being a good thing by encouraging good programming habits through achievements.

Microsoft’s implementation is anything but that.

Many of the achievements are either pointless, inane or actively encourage bad coding habits. 50 projects in a solution? A class that has every kind of scope in it? I can foresee situations where these things might happen (but they still shouldn’t) and it begs the question as to why these were added in. The flip side of this is people creating one shot projects in order to get these achievements (which everyone on the leaderboard has done) which makes the achievements even more meaningless. Indeed the whole idea just seems like a poorly thought out attempt at getting into the gamification scene, one that will be rightly ignored by most proper developers.

Just like in Lobaco where adding in game elements didn’t make complete sense (at least not at the great expense of other features, which it did) there are many times where the gamification of something just plain won’t work. If the core of your idea is based around a game idea then it probably makes sense to include achievements. If it does not then realistically you shouldn’t be adding them in until you’ve done everything else possible to deliver a good product/service to your end users. Attempting to keep people interested with cheap tricks like gamification won’t work if the underlying product has no redeeming value, nor if the core use of the product isn’t a game mechanic itself. The sooner people realise this the better as the spread of crappy, tacked on game mechanics is really not doing anyone any favours.

Un/Conscious Influences.

If I’m honest I can’t really tell you where the inspiration for Lobaco came from. Sure the idea itself is pretty simple (what’s going on there?) but I can’t really tell you what place or event first inspired me. The pursuit of the idea itself is much easier as it basically comes down to my inner dialog that constantly shouts put up or shut up at the back of my head and I felt hypocritical telling people to aggressively pursue their goals if I myself didn’t do the same thing. The 3 redesigns and one renaming Lobaco have much more solid roots having all stemmed from taking a break from developing and then taking a fresh look at the work I was doing.

Most of the inspiration came from a conscious desire to improve the product. In an effort to duplicate what I currently perceived as success many of the changes came from me taking ideas from places like Twitter and Foursquare and wrangling them into my product. Some of these ideas worked quite well like the UI redesign that took some serious cues from Twitter (large post box in the middle of the screen, 3 column layout) and others like the achievement service which mirrored Foursquare’s badge system (only has one unlockable, First Post!) proved to be a whole lot of effort for not a whole lot of gain. If you’re one of the brave souls testing the iPhone client (you can sign up here) you’ll notice that the latter feature is completely absent, for that exact reason.

Unconsciously however I believe I was thinking that Lobaco would end up being the platform upon which location based communication would be done. Sure many of the design decisions I made like making the API RESTful and JSON based were to increase cross-platform compatibility but ultimately I knew that the real power was being a platform, and even blogged to that effect. Whilst I don’t believe Lobaco suffered unduly because of this I hadn’t really considered the influence that outside forces were having on me subconsciously until 4chan creator Christopher “moot” Poole said this:

One of the biggest startup cliches is that every other startup wants to become a platform for other startups to build on. But to Christopher Poole, the founder of Canvas and 4Chan, that is the wrong approach. “People get caught up in trends—game mechanics, building a platform,” he tells Chris Dixon in the Founder Stories video above. Instead of trying to copy what works for others, founders should “focus on building what you love, focus on the product and building the community.”

He doesn’t understand “this obsession with building platforms. Focus on building something worth scaling. You don’t even have something worthy of an API yet. Focus on users and have them fall in love with your thing.” Amen.

Indeed many of the ideas I had emulated in Lobaco were done because I saw other successful companies doing them and figured that they would work for me as well. In reality I would have been much better served by focusing on the core product, refining the idea to the point where its utility was obvious to anyone. Since the idea was hinged on the idea of localized information I probably should have done things backwards, getting the core handset product right before attempting to bring it onto the web. That would have forced me to cut all of the fat out of the application, lest I create a cluttered and useless handset experience.

No matter how hard you try to fight it you will always be influenced by your experiences and for an information junkie like myself this meant that the service I was building emulated those which I considered most successful. My latest endeavor (which shall remain a secret, for now) is already showing signs of this kind of influence but I’m at least taking the lessons learned from Lobaco and applying them aggressively. I’m hoping this current project will be the fast track to self-sustainability that I’ve been hungering after for almost 2 years now and hopefully the time spent in the trenches for Lobaco will pay dividends in bringing this project to fruition.

 

Lobaco 1.0: iPhone Testers Required!

It’s been a long 7 months since I first laid eyes on Xcode and the iOS SDK all that time ago and I’ve had quite the love/hate relationship with it. There were times when I could spend only a couple hours coding and blast through features barely breaking a sweat, and others when I’d spend multiple torturous hours figuring out why something just wasn’t working the way I thought it should. The last couple months have been quite successful as my code base has grown large enough to cover most of the rudimentary functions I use constantly and my muscle memory with certain functions is approaching a usable level. Last weekend it all came to head after I polished off the last of my TODO list and sank back into my chair.

Then it hit me, this was a feature complete 1.0 release.

Apart from the achievements (which are barely implemented in the web client) you can do everything on the iPhone client that you could do with the full web client. I’ve taken design cues from many iPhone applications that I’ve been using and I feel its quite usable, especially if you’re familiar with the myriad of Twitter clients out there. I’ve been fiddling with it over the past few days and it seems to be stable enough for me to unleash on others to see how it goes and that’s where you, my faithful readers, come into play.

I’m looking for people to beta test this application pending a full release of it to the app store. If you’re interested in testing out the application and have any 3G and up iPhone (2G might work, but it would be dreadfully slow) hit me up on my gmail [email protected] and we’ll take it from there. I haven’t really experimented with Apple’s beta testing yet so the first lot of you are more than likely to be in for a fun ride as I stumble my way through deploying the application to you, but this is all part of the fun of being a very, very early adopter 🙂

Despite all the trials and tribulations that developing this client has brought me the experience is proving to be invaluable as it’s helped me refine the idea down to the core ideal I started with almost 2 years ago: getting people communicating around a location. It’s also been the first new language I’ve learned in almost 5 years and it has reminded me just how much fun it was learning and creating in a completely new environment, so much so that I’m almost completely sold on the idea of recoding the web client in Ruby on Rails. Still that’s all pie in the sky stuff for now as the next big improvement to Lobaco is moving the entire service off my poor VPS and into the wonderful world of the cloud, most likely Windows Azure. I hope you’ll jump on board with me for testing Lobaco and hopefully in the future this will grow into something much more than my pet project.

Absence Makes The Heart Grow Fonder (or Not).

My time spent developing my passion project hasn’t been continuous since the time I first started working on it. The first iteration lasted about a month and was a mad rush to cobble something together to mark the momentous “milestone” of 100 blog posts. I then spent the next couple months experimenting with Silverlight managing to replicate and extend the base feature set out to a point where I felt I was making progress. I then went on a 6 week hiatus from developing Geon to work on The Plan which, whilst making me a decent sized profit, never turned out to be the ticket to freedom I had hoped it would be. After taking a month off after that and coming back to look at Geon I couldn’t help but think that I was going about things in all the wrong ways, and came up with a completely new design.

This, I’ve found, is a common trend for me. Unless I continually work on a project I’ll always end up questioning the idea until I end up wondering what the point of doing it in the first place was. Initially this was quite good as whilst the first few iterations of Geon showed solid progress they were in all honesty horrid applications. However it was devastating for overall progress as the paradigm shifts I underwent during these times of developmental absence meant that the new vision was wholly incompatible with the old and I could see no way other than starting anew to get them back in line again. This is why the first2 iterations didn’t have any form of user logins and the third was such a horrible process that I don’t blame anyone for signing up for it.

I had thought that short breaks were immune to this idea as I had often taken a weekend or two off when a family event called or I was starting to feel burned out. However I hadn’t had the chance to do much work on Lobaco over the past 2 weeks thanks to me being otherwise occupied and those little tendrils of other worldly perspective started to creep in. Maybe it was the booze fueled weekend where I had a list of 5 other potentially marketable ideas or maybe it was just me pining for another break but suddenly I felt like there was so many other things I should be doing than pursuing my almost 2 year old idea. I let myself think that I could take part of the weekend off to work on one of those ideas but for some reason I just kept working on Lobaco.

I’m not sure if it was my persistence or hitting the submit on my application to Y-Combinator that did it but instead of pursuing those ideas that had tempted me all week long I just fired up Xcode and started plugging away. Whilst not my most productive weekend ever I did manage to tick off 2 more features for the iPhone client, leaving about 3 to go before my deadline of the end of March. I think the combination of a solid code base (that has all those rudimentary things done so I don’t have to spend time researching them) and almost half a year of iOS development under my belt is enough to keep the momentum going, making sure I don’t give up on this version until it reaches 1.0.

I used to think that time away from coding was just as valuable as time spent in code but that doesn’t seem to be holding as true as it used to be. Sure my first breaks led to radical changes in my vision for the end product (and is responsible for the Lobaco that exists today) but once you hit that sweet spot time away can be quite destructive, especially if you’re as prone as I am to distraction by new ideas. Thankfully the last 6 months of momentum aren’t lost on me and 2 weeks away wasn’t enough to distract me from my end goal. It would have been to easy to start procrastinating again without realizing it.

Focused Simplicity.

It’s really easy to fall into the trap of trying to build something you think is simple that ends up being a complicated mess. Us engineers are amongst the most common offenders in this regard, often taking a simple idea and letting the feature creep run out of hand until the original idea is coated in 10 layers of additional functionality. I’d say that this is partly due to our training as modular design and implementation was one of the core engineering principles that was drill into me from day 1 although to be fair they also taught us how quickly the modular idea fell apart if you took it too far. There’s also the innate desire to cram as much functionality as you can into your product or service as that would make it appear more appealing to the end user, however that’s not always the case.

When Geon was starting out I had a rough idea of what I wanted to do: see what was going on in a certain location. That in itself is a pretty simple idea and the first revisions reflected that, although that was probably due to my lack of coding experience more than anything else. As time went on I got distracted by other things that forced me away from my pet project and upon return I had one of those brainwaves for improving Geon in ways I had not yet considered. This lead to the first version that actually had a login and a whole host of other features, something I was quite proud of. However it lacked focus, was confusing to use and ultimately whilst it satisfied some of the core vision it wasn’t anything more than a few RSS feeds tied together in a silverlight front end with a badly coded login and messaging framework hidden under the deluge of other features.

Something needed to change and thus Lobaco was born.

Increasingly I’m seeing that simplicity is the key to creating an application that users will want to use. On a recent trip to Adelaide my group of friends decided to use Beluga to co-ordinate various aspects of the trip. Beluga really only does one thing, group messaging, but it does it so well and in such a simple way that we constantly found ourselves coming back to it. Sure many of the functions are already covered off by say SMS or an online forum but having a consistent view for all group members that just plain worked made organizing our band of bros that much easier. It’s this kind of simplicity that keeps me coming back to Instagr.am as well, even though there’s similar levels of functionality included in the Twitter client (apart from the filters).

Keeping an idea simple all sounds like it would be easy enough but the fact that so many fail to do so show how hard it is to refine a project down to its fundamental base in order to develop a minimum viable product. Indeed this is why I find time away from developing my projects to be nearly as valuable as the time I spend with them as often it will get me out of the problem space I’ve been operating in and allow me to refine the core idea. I’ve also found myself wanting simple products in lieu of those that do much more just because the simple ones tend to do it better. This has started to lead me down the interesting path of finding things I think I can do better by removing the cruft from a competing product and I have one to test out once I get the first iteration of the Lobaco client out of the way.

I guess that will be the true test to see if simplicity and focus are things customers desire, and not just geeks like me.

It Would Be So Easy To Give Up.

I’ve been an on again, off again developer ever since my first year of university. I wasn’t particularly good at it either and it took me a good year of slogging through various programming languages before the penny finally dropped when I started using C#. After that initial hump however I found it much easier to pick up on new languages and technologies which has ultimately culminated in me attempting to create my own web application from the ground up, something I would’ve seen as impossible just a few years ago. It’s just over a year and a half since I began work on my pet project and in that time it’s gone through 3 complete rewrites, 4 redesigns and several months of me staring at a computer screen wondering if this is the best thing to do with my time.

It was that little hater getting into my head again.

I hadn’t really been thinking about much until a friend of mine commented on how he’d noticed that my writings indicated I was getting tired of developing Lobaco. After thinking about it for a while I knew he was right, the long weekends spent coding and testing had been taking their toll on me mentally. I had begun to fantasise about other applications I could be developing or other hobbies I could pick up, losing hours in research. After a while they started to meld together and my new found hobbies were turning into other potential start up ideas and I began lusting after them as they began to look so much more tangible than Lobaco. It was the dreaded unknowing procrastination beginning to slip in again and I had been welcoming it willingly.

As Jay Smooth put so aptly it was being in the thick of creation for so long that was making me lose sight of the end game. I’ve been writing on this blog for over 2 years now and there have been many times I’ve thought I should just give it up and shut the whole thing down (I would gain a considerable amount of time per day back again) but every time I get a comment either here or in real life I know that the work I do here is appreciated and it keeps me going that much longer. I’ve finally come to terms with the fact that some days I just won’t be able to find anything to write about and that doesn’t mean this blog is worthless. Still I do enjoy blogging and when I’ve got a topic I’m passionate about I feel it shows and it’s posts like that that keep me coming back every day in the hopes I’ll hit on one of those topics.

Ever since that realisation I’ve been making great strides with the Lobaco iPhone application. Last weekend was probably my most productive ever with 4 core features being implemented and many improvements made thanks to some open source libraries I hadn’t come across before. Now it feels like I’ve hit one of those points where my progress as an iPhone developer is accelerating and my formerly hacker style approach is now becoming more standardized and new features are just rolling off my fingers. I’ve still got a couple months of development effort ahead of me before I’ll be releasing the iPhone application to beta testers but now its only a matter of time rather than the impossible mountain it used to be.

I guess this is why the majority of start ups are founded with more than just a single person. It’s so easy to get lost in your own world when you’re trying to bring an idea into reality and having someone there beside you really helps to keep you in the game and focused on the goal. Whilst I haven’t found anyone (yet, but I’m still looking!) who’s willing to go on this startup journey with me my group of close friends have acted as the sounding board and grounding rod that’s gotten me this far into the project. The next few months are going to be the make or break time for Lobaco but with the progress I’ve made in just the past couple weeks I have a much renewed level of confidence, and a desire to succeed that is yet to be satiated.

Necessity is the Mother of Invention.

I’ve been developing computer programs on and off for a good 7 years and in that time I’ve come across my share of challenges. The last year or so has been probably the most challenging of my entire development career as I’ve struggled to come to grips with the Internet’s way of doing things and how to enable disparate systems to talk to each other. Along the way I’ve often hit various problems that on the surface appear to be next to impossible to do or I come to a point where a new requirement makes an old solution no longer viable. Time has shown however that whilst I might not be able to find an applicable solution through hours of intense Googling or RTFM there are always clues that lead to an eventual solution. I’ve found though that such solutions have to be necessary parts of the larger solution otherwise I’ll just simply ignore them.

Take for instance my past weekend’s work gone by with Lobaco. Things had been going well, the last week’s work had seen me enable user sign ups in the iPhone application and had the beginnings of an enhanced post screen that allowed users to post pictures along with their posts. Initial testing of the features seemed to work well and I started testing the build on my iPhone. Quickly however I discovered that both the new features I had put in struggled to upload images to my web server, crashing whenever a picture was over 800 by 600 in size. Since my web client seemed to be able to handle this without an issue I wondered what the problem would be, so I started digging deeper.

You see way back when I had resigned myself to doing everything in JavaScript Object Notation, or JSON for short. The reason behind this was that thanks to it being an open standard nearly every platform out there has a native or third party library for serialising and deserialising objects, making my life a whole lot easier when it comes to cross platform communication (I.E. my server talking to an iPhone). Trouble with this format is that whilst it’s quite portable everything done in it must be text. This causes a problem for large files like images as they have to be changed into text before they can be sent over the Internet. The process I used for this is called Base64 and it has the unfortunate side effect of increasing the size of the file to be transferred by roughly 37%. It also generates an absolutely massive string that brings any debugger to its knees if you try to display it, making troubleshooting issues hard.

The image uploading I had designed and successfully used up until this point was now untenable as the iPhone client simply refused to play nice with ~300KB strings. I set about trying to find a solution to my problem hoping to find a quick solution to my problem. Whilst I didn’t find a good drag and drop solution I did come across this post which detailed a way in which to program a Windows web service that could receive arbitrary data. Implementing their solution as it is detailed there still didn’t actually work as advertised but after wrangling the code and over coming the inbuilt message size limits in WCF I was successfully able to upload images without having to muck around with enormous strings. This of course did mean changing a great deal of how the API and clients worked but in the end it was worth it for something that solved so many problems.

The thing is before I went on this whole adventure had you asked me if such a thing was possible I would’ve probably told you no, at least not within the whole WCF world. In fact much of my early research into this problem was centred around possibly implementing a small PHP script to accomplish the same thing (as there are numerous examples of that already), however the lack of integration with my all Microsoft solution means I’d be left with a standalone piece of code that I wouldn’t have much interest in improving or maintaining. By the simple virtue that I had to come up with a solution to this problem meant I tried my darnedest to find it, and lo I ended up creating something I couldn’t find anywhere else.

It’s like that old saying that necessity is the mother of all invention and that’s true for both this problem and Lobaco as an idea in itself. Indeed many of the current great Internet giants and start ups were founded on the idea of solving a problem that the founders themselves were experiencing and felt that things could be better. I guess I just find it fascinating how granular a saying like that can be, with necessity driving me to invent solutions at all levels. It goes to show that embarking into the unknown is a great learning experience and there’s really no substitute for diving in head first and trying your hardest to solve an as of yet unsolvable problem.

Fast Scrolling UITableView: Updates for iOS 4.2.

I’ll be honest and say that most of the programs I’ve built have never really been that resource intensive so optimising them for performance really hadn’t been much of a priority. Sure there were the occasional thing that I’d catch and try to improve, like when an early copy of Geon had a dropped shadow around the map that inexplicably made it run like a dog, but for the most part I’d just code them up and leave it at that. Coding for the iPhone and other resource poor systems however does not afford me such luxuries and performance tuning the app has taken up a considerable amount of my development time, but the pay offs have been quite great.

After getting my first shot at the Lobaco app up and running I noticed there was considerable slow down when scrolling through the main list of items. Since I’m a big fan of the official Twitter app I knew that it was possible to have quite smooth scrolling even when you had multiple images and gobs of text on the screen. As it turns out I wasn’t alone with this performance problem with UITableViews (the class used for that main list display) and the developers behind it posted up some code to demonstrate how they achieved such fast scrolling.

If you follow that link you’ll notice that that particular blog post is now over 2 years old, back when the iPhone 3G was still the top offering from Apple. Whilst the code given in that blog post still functions I ran into a couple of issues implementing it in the latest SDK (4.2). The first issue you’ll hit when trying to use this code is the initWithFrame function, which is used to create your cell, is now deprecated. Whilst it should still function I could not get my code to work until I made the following change in ABTableViewCell.m:

// Copyright (c) 2008 Loren Brichter
//
// Permission is hereby granted, free of charge, to any person
// obtaining a copy of this software and associated documentation
// files (the "Software"), to deal in the Software without
// restriction, including without limitation the rights to use,
// copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the
// Software is furnished to do so, subject to the following
// conditions:
//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
// OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
// HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
// WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
// OTHER DEALINGS IN THE SOFTWARE.
//
//  ABTableViewCell.m
//
//  Created by Loren Brichter
//  Copyright 2008 Loren Brichter. All rights reserved.
//

#import "ABTableViewCell.h"

@interface ABTableViewCellView : UIView
@end

@implementation ABTableViewCellView

- (void)drawRect:(CGRect)r
{
	[(ABTableViewCell *)[self superview] drawContentView:r];
}

@end

@implementation ABTableViewCell

/*- (id)initWithFrame:(CGRect)frame reuseIdentifier:(NSString *)reuseIdentifier
{
    if(self = [super initWithFrame:frame reuseIdentifier:reuseIdentifier])
	{
		contentView = [[ABTableViewCellView alloc] initWithFrame:CGRectZero];
		contentView.opaque = YES;
		[self addSubview:contentView];
		[contentView release];
    }
    return self;
}*/

- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier
{
	if(self = [super initWithStyle:style reuseIdentifier:reuseIdentifier])
	{
		contentView = [[ABTableViewCellView alloc] initWithFrame:CGRectZero];
		contentView.opaque = YES;
		contentView.backgroundColor = [UIColor whiteColor];
		[self addSubview:contentView];
		[contentView release];
    }
    return self;
}

- (void)dealloc
{
	[super dealloc];
}

- (void)setFrame:(CGRect)f
{
	[super setFrame:f];
	CGRect b = [self bounds];
	b.size.height -= 1; // leave room for the seperator line
	[contentView setFrame:b];
}

- (void)setNeedsDisplay
{
	[super setNeedsDisplay];
	[contentView setNeedsDisplay];
}

- (void)drawContentView:(CGRect)r
{
	// subclasses should implement this
}

@end

The main change is to replace the old initWithFrame with the new initWithStyle. This also requires changing the super call to the UITableViewCell class we’re subclassing, but apart from that everything else remains the same. Once I had that problem out of the way my custom cells were now drawing properly and appeared to be scrolling much more smoothly than they were before. However I was noticing another strange issue with my cells, they seemed to be displaying data at random from my data array. Try as I might to find the solution to this problem I couldn’t, until went back to the fundamentals of the UITableView.

You see creating cells with a UITableView is a pretty expensive process, just as it is for any system when creating new objects. This is even more pronounced with the resource limitations of the iPhone and so the iOS SDK employs a simple trick to work around this. Instead of creating and deleting a new cell every time one is needed it will instead reuse a cell that’s no longer in use, I.E. one that’s scrolled off screen. Since the cell will usually have new data in it at this point when it comes back on screen it should redraw itself to reflect this. However it seems that the ABTableViewCell class wasn’t doing this and the only way I could get it to update the data was by clicking on the cell, which caused a refresh.

If you’re not using this class then you’ll probably never encounter this issue and I believe this is because of the way ABTableViewCell does it’s drawing. You see in order to get the performance improvement you’re basically bypassing the regular way of drawing the cell and doing it yourself. This has enormous performance benefits since you’re not doing any unnecessary drawing, but it appears that the UITableViewCell class doesn’t call the drawContentView function as part of its normal drawing routine anymore. Thankfully this can be solved with a one liner in your UITableView controller class by letting the cell know it needs to redraw itself with setNeedsDisplay:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

    static NSString *CellIdentifier = @"Cell";
	int nodeCount = [displayItems count];

    LobacoTableCell *cell = (LobacoTableCell *)[tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        //cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier] autorelease];
		cell = [[[LobacoTableCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier] autorelease];
    }

    // Configure the cell...

	if (nodeCount > 0)
	{
		Post *post = [displayItems objectAtIndex:indexPath.row];
		cell.post = post;
		if (!post.profileImage)
		{
			if (self.tableView.dragging == NO && self.tableView.decelerating == NO)
			{
				[self startImageDownload:post forIndexPath:indexPath];
			}

			cell.image = [UIImage imageNamed:@"Placeholder.png"];

		}
		else
		{
			cell.image = post.profileImage;
		}
	}
	[cell setNeedsDisplay];
    return cell;
}

I do this after I’ve done all the reconfiguration of the cell so that it’s drawn with all the correct information. The image code in this part will also trigger a redraw of the cell when it’s finished downloading the image (in this case the user’s profile picture) ensuring that it’s displayed immediately rather than when the drops out and comes back into view again. With all these fixes in place my new custom UITableViewCell works perfectly and the scrolling performance is glassy smooth.

All of the above issues I encountered after I upgraded my Xcode installation to iOS 4.2 and despite my intense Googling I couldn’t find any real solutions to these problems. If you’re a budding iPhone developer like me struggling to figure out why some things just aren’t working the way they should I hope this post gives you a little insight into what was going wrong and ultimately how to fix it. It’s these kinds of curious problems that frustrate the hell out of me when I’m in them but they’re always quite satisfying once you’ve managed to knock them over.

Procrastination Takes Many Forms.

I really can be my own worst enemy sometimes. It’s been almost a month since I got back from the USA and despite the best of intentions I haven’t really done that much work on Lobaco apart from a little work on the API and web UI. Whilst I was pretty sure I wasn’t going to hit the code hard immediately after touching back down in Australia I still thought that after maybe a week or two of lazing about the coding bug which had firmly bitten me before I left would take a hold once again, pushing me to build on the momentum I had set up. Sadly it wasn’t to be and instead I just resided myself to feeling guilty about what I should’ve been doing and pulling the meter tall weeds that had grown in our front yard.

Partly to blame is that sense of perspective I get whenever I take time away from a project to work on something else or to just have a break. Usually the first thing that pops into my head is “why the hell should I bother” and I’ll spend a good chunk of time focusing on the negative aspects of whatever I’m doing. After a while though I’ll just try to do a feel small things, a few quick wins to get me back into the mindset of getting things done. After that it’s usually pretty easy going (this usually takes about 2 weeks) until I hit a wall again or I feel like getting my weekends back for a while so I can relax and get my head back together. The last few iterations of this cycle are what lead to the 3 major revisions of what is now Lobaco.

This time however was different. After being back for 2 weeks and being firmly thrust back into the world that had barely changed since I had left (even though I expected it to be wildly different,  for some reason) I still really couldn’t get into coding without feeling like I should be doing something else. My usual routine of getting a couple quick wins with the API and web UI didn’t translate into jumping back onto my MacBook and smashing out some iPhone code. Instead I started wondering whether or not a native client was the way to go and the possibility of doing a web based client for the phone itself. I had been down this road before and ultimately found that whilst iPhone programming was a world away from I’d done before the progress I had made with only a couple weeks of effort was far more encouraging than the same amount of time spent trying to wrangle HTML5 and Javascript into something workable.

Then along came Sencha.

I was going through my 700+ post backlog of Techcrunch articles when I came across this one about Sencha, a web startup that just released their Touch framework which provides the basis for building native looking applications in HTML5 and Javascript. Thinking this might be my salvation to writing native clients for all handsets I quickly downloaded the framework and started hacking around to get something workable. I was able to get the example running in one weekend and made a few modifications but I didn’t get into the real meat of it until last Friday night. After managing to replicate the UI I had built in objective-c within the Sencha framework I uploaded it to my web server to see what it would look like on the iPhone and instantly I realised what was wrong.

This client was just an elaborate way of procrastinating.

Now whilst the client looked decent and didn’t take too much to set up it didn’t look anywhere near as good as my native app nor could it hold a candle to its performance. Sure my hack job probably ensured that the performance wasn’t as good as it could be but in comparison to the native client hack job I did it was pretty stunning. After coming to that realisation I booted up my MacBook to start getting acquainted with Xcode again and spent last weekend coding up some performance improvements¹ for it which I had put off before I left for the USA. I’m sure this won’t stop me from looking at going down that path in the future but I can at least rest easier now that I’m feeling the urge to program once again.

It’s been a weird learning experience for me since I’m usually pretty good at knowing when I’m procrastinating. Usually I have a good reason for it (like having 1 bit of work to do and not doing it since it’s not due for months) but this is the first time I caught myself doing something I thought was useful when really I was just making excuses for doing the work I knew needed to be done. With a good week of holidays coming up over the Christmas/New Year period this realisation couldn’t have come at a better time and I’m looking forward to making the most of my time off with the hope that the momentum will carry me on into the new year.

¹I’m going to do a big post about this hopefully tomorrow. I hit some really, really esoteric problems getting everything to work but I have and the results are, to put it bluntly, bloody amazing.

There Might Just be a Silver Lining to the Cloud.

Cloud computing, it’s no secret that I don’t buy wholly into this idea mostly because everyone talking about it either a) doesn’t understand it or b) has forgotten that it’s an old paradigm that was tried a long time ago and failed for many reasons. Still as an IT professional who likes to stay current with emerging trends I’ve been researching the various cloud offerings to make sure I’m up to speed on them should a manager get the bright spark to try and use them in our environment. There’s also the flip side that my chosen specialisation vendor, VMware, has their own cloud product aimed at building your own internal cloud for hosting all your applications. Whilst I still sit on the sceptical fence about the cloud idea as a whole there are some fundamental underpinnings that I think I can make use of in my current endeavours. I might even stop feeling dirty every time I mention the cloud.

As any budding start up engineer will tell you one of the things that always plays on the back of your mind is how you’re going to scale your application out should it get popular. I’ve had a lot of experience with scaling corporate applications and so thought I’d have a decent handle on how to scale my application out. To give you an idea of how most corporate apps scale it’s usually along the lines of adding in additional servers in each tier to handle the data load and then load balancing across them (or in simple terms throwing more hardware at it). This works well when you’ve got buckets of money and your own data centre to play with but us lowly plebs trying to break out into the real world face similar problems of scalability without the capital to back us up.

Right now I host most of my stuff directly off my home connection on a single server box that I cobbled together for $300 some years ago. It’s done me well and is more than grunty enough to handle this web site but anything above that has seen it crumble under the pressure, sometimes spectacularly. When I was looking for hosting solutions for Lobaco I knew that shared hosting wasn’t going to cut it and getting a real server would cost far more than I was willing to pay at this early stage. In the end I found myself getting a Virtual Private Server from SoftSys Hosting for just under $600/year. At the time it was the perfect solution as it let me mirror my current test environment with the additional benefit of being backed up by a huge pipe and enterprise level hardware. It’s been so good that I’m even considering moving this blog up there, if for the only reason that it will mean it won’t go down again just because the net dropped at my place.

However my original ideas of scaling out the application don’t gel too well with the whole VPS idea. You see scaling out in that fashion would see me buying several of these each with the same price tag or higher. Just a simple load balanced web and database server farm would set me back $2400/year neglecting any other costs incurred to get it working. After looking at my various options I begrudgingly started looking at other solutions and that’s when I started to take cloud computing a little more seriously.

Whilst I’ve still only scratched the surface of most offerings the most compelling came in the form of Windows Azure. Apart from the fact that it’s Microsoft and should therefore be blindingly easy to use the fact that they provide free accounts (with discounted rates thereafter) to budding entrepreneurs like myself got me intrigued. A couple Google searches later showed that porting my WCF based services to the Azure platform shouldn’t prove to be too difficult and they provide in built loading balancing to boot. The pricing model is also attractive as it is on a unit basis, you only pay for what you actually use. Azure then could easily provide the required scalability without breaking the bank, leaving me to focus on the more pressing issues than whether or not it will work with a decent chunk of users.

Whilst I won’t be diving into the clouds just yet (the iPhone, she beckons) it’s now on the cards to port Lobaco across so that when it comes time to launch it I won’t have to watch my server like a hawk to make sure it isn’t dying a fiery death under the load. I don’t think the cloud will be the solution to all my scalability issues that might come up in the future but it’s looking more and more like a viable option that will enable me to build a robust service for a good number of users. Then once I’ve got my act together I can start planning out a real solution.

With blackjack, and hookers.