Nial Giacomelli

Neven Mrgan recently posted an excerpt of an IRC conversation in which he confronts users over the supposed piracy of his iOS game, The Incident. During the course of the conversation many users congratulate Neven on The Incident (as they should), but ultimately tell him that it’s a “way of life”, that he’s just going to have to learn to “deal with it”.

For me, the most interesting aspect of this entire conversation was that Neven seemed almost surprised to find his videogame circulating amongst the pirate community. After all, isn’t this the same Neven who works for Panic, one of the Mac’s largest and most respected software houses? Surely Panic must deal with this calibre of theft on an almost daily basis?

But that’s exactly the point Neven is making here. Panic deals with piracy like a business. Because Panic is a business, right? The Incident, on the other hand, started as a passion project. A labour of love. The two are mutually exclusive. It’s a black and white distinction, surely?

Not so much.

As a long time Panic customer, and an avid fan of The Incident, I can tell you that the likes of Transmit and Unison are just as much passion projects as any iteration of The Incident. The same care and attention to detail went into both projects. The only differential here is that Panic works out of an office, and Big Bucket Software works out of their respective homes.

When I purchase software, be it an iOS application or something for the Mac, I look at it as an investment. Sure, I’m getting a fantastic piece of software, but I’m also letting its developer know that I support their efforts. That I’m glad they spent those two fateful days in front of a whiteboard. Because in the end, everyone benefits.

In many ways, I think the success of the App Store has caused a lot of problems for the indie developer. The press parade various rags to riches stories and, inevitably, people assume that the majority of developers are getting rich quick. The reality of the situation is that the majority of App Store developers are probably operating at a loss. Because the cold truth of it is that good application development is an expensive process.

But one that certainly deserves to be rewarded.

I’m tentatively pushing Rhombus out into the world today. It’s been a fairly simple evening and weekend project of mine for a while now. Rhombus’ objective is simple: archive and deliver price changes on the Steam digital content network. To make the data as accessible as possible, users also have access to an RSS feed and a Twitter account. Currently, Rhombus comes in two flavours: tracking both the US and UK versions of the Steam store.

The reason for Rhombus’ existence is simple: I love videogames and great deals. Rhombus combines the two.

I recently added HTML5 cache manifest support to Showtime in an attempt to decrease load times for users on older hardware and for those with spotty network connectivity. As Stoyan Stefanov mentions: the current iPhone will not cache individual components if they are larger than 15K and will wipe all caches when the device is powered down or restarted.

This represents an inherent issue with using the jQTouch library for iPhone-related web app development. Although jQTouch keeps itself fairly focused in terms of support (and thus lean), jQuery is bloated by its necessity to support all manner of rendering platforms and browser technologies. At the time of writing, a minified version of jQuery 1.4 will weigh in at about 72KB. As a result, jQuery must be remotely served each time your web application is accessed. While there has been talk of forking the jQuery codebase to shave away all non-essential (specifically, non-Webkit related implemenations and other pieces of fluff), those of us currently running web apps need a slightly more immediate solution.

That solution is the HTML5 cache manifest. As the Safari Dev Center explains:

The manifest file specifies the resources—such as HTML, JavaScript, CSS, and image files —to download and store in the application cache. After the first time a webpage is loaded, the resources specified in the manifest file are obtained from the application cache, not the web server.

Although I had read about the cache manifest around the Internet, it wasn’t until I read Jonathon Stark’s wonderful Building iPhone Apps with HTML, CSS, and JavaScript: Making App Store Apps Without Objective-C or Cocoa that I came across a cleverly dynamic means of generating a manifest and supplying it to the browser. There was only one problem: Stark’s implementation didn’t account for web apps that made use of dynamic content.

To resolve the issue, I forked his manifest.php implementation to account for .php files:

header('Content-Type: text/cache-manifest');
echo "CACHE MANIFEST\n";
 
$hashes = "";
$lastFileWasDynamic = FALSE;
 
$dir = new RecursiveDirectoryIterator(".");
foreach(new RecursiveIteratorIterator($dir) as $file) 
{
	if ($file->IsFile() && $file != "./manifest.php" && substr($file->getFilename(), 0, 1) != ".") 
	{
		if(preg_match('/.php$/', $file)) {
			if(!$lastFileWasDynamic) 
			{
				echo "\n\nNETWORK:\n";
			}
			$lastFileWasDynamic = TRUE;
		} 
		else 
		{
			if($lastFileWasDynamic) 
			{
				echo "\n\nCACHE:\n";
				$lastFileWasDynamic = FALSE;
			}
		}
		echo $file . "\n";
		$hashes .= md5_file($file);
	}
}
 
echo "# Hash: " . md5($hashes) . "\n";

The above code should be fairly clear. Jonathon Stark’s original manifest.php made use of PHP5′s RecursiveDirectoryIterator class to generate a complete list of all the resources your web application relies upon (with the exception of the manifest.php file itself). I’ve simply altered it slightly to do a fairly primitive regex check to catch any files with a .php extension and preface those files within the manifest with a NETWORK flag (which forces the files to be requested from the web server, rather than the local cache).

Documentation on the application cache is fairly scarce at the moment, and I’m not professing to being any kind of expert. I just hope this code can help anyone else looking to use the cache manifest as a means of speeding up their dynamic mobile web applications.

It’s been just over three weeks since I released the first Showtime public beta. Since then the app’s undergone two major re-writes. The first involved a significant backend reshuffle, but ultimately meant that Showtime was able to track hundreds of additional programmes with greater accuracy, while the second, which hit devices earlier this week, centred exclusively on the front-end.

But development aside, I’ve noticed that Showtime has been involved in a number of recent debates over the future of the iPhone as a platform, and, perhaps more poignantly, questions over the relevancy and effectiveness of web-based applications as opposed to native solutions. Perhaps the major catalyst for Showtime’s involvement in said discussions was a tweet by the inimitable @gruber of Daring Fireball fame, which read:

Common answers so far for best iPhone web app: Gmail, Google Reader, Hahlo, Glyphboard, Showtime (http://showtime-app.com/) So: not much.

The tweet itself led to a flood of traffic (both directly and through subsequent retweets), as well as a direct response from Justin Williams, who stated:

The Web only Showtime allows you to see when your favorite TV shows air next. Both of these are great applications, but they miss the mark for a few reasons.

[...]

I believe that with the current crop of Web technologies available in MobileSafari, apps like Hahlo, PocketTweets and Showtime could thrive as an alternative to their native counterparts if Apple allowed developers to adjust the scrolling/drag coefficient of Mobile WebKit.

I’m not going to get into the web app vs. native discussion in any great detail here. It’s been covered far more extensively elsewhere. But I would like to take a moment to say that I agree with Williams on almost every level. Apple has created something special with Mobile WebKit, so let’s hope they support web app development in the future with a more extensive API.

The final point I’d like to make revolves around the fact that web app development has allowed me to avoid the App Store in its entirety. As a result, Showtime updates can be deployed in seconds, allowing me to accurately gauge user reactions. An experience which, rather paradoxically, native app developers (who pay for the privilege) sadly seem to miss out on:

Just when I start to get comfortable with the App Store again, shit like this happens. I understand Apple is completely inundated with updates and applications, but that’s not my problem. If you’re going to set up a system with this many requirements, you’d damned well better be able to handle it efficiently. 30 days to approve a simple update is not efficient.

And what does waiting mean? As I’ve said before, it means tons of email a day and tons of bad reviews. It means answering the same question (“My GA widgets all report zero… what gives??”) 20 times a day. It means watching negative reviews pour in. Here are some excerpts from lovely recent reviews:

via Garrett Murray (who develops the incredible Ego app.

Of course, the best part of Showtime development is meeting total strangers who use the application on a regular basis and find it useful:

Another app that shows webapps can be just as good as native ones: http://showtime-app.com

@DouweM

‘Showtime’ sets the standard for web apps on iPhone, absolutely incredible!

@petemwah

all #mobile #webapps should work like #showtime

@theadb

An interesting read on HTML powered iPhone application development.

PCWorld has an interesting article on the EU volume restrictions for personal music players.

• 80 decibels is equivalent to the level of noise you’d hear on a busy city street;
• 90 decibels is lawnmower-like loudness;
• 110 is as ear-shattering as a loud rock concert;
• 120 to 130 matches the level of an airliner taking off — or, in less technical terms, “GET USED TO PEOPLE ALWAYS HAVING TO SHOUT AT YOU!”

Luke Wroblewksi describes Facebook’s interesting approach to implementation and design. A unique take, but I personally can’t see myself being able to work like this.

MindMeTo is a reminder service which makes use of Twitter to introduce the concept of social task management. We launched the service earlier this week and so far reception has been great. It was my first time working with Alexander Kohlhofer and Filip Visnjic, and I enjoyed the project immensely.

Perhaps the most interesting aspect of working on projects such as MindMeTo is that problems will come along that totally knock you out of your comfort zone. In terms of web programming, it’s pretty easy to get yourself in a groove. You create countless websites which essentially use the same techniques, the same database and session abstraction classes, the same schema and queries, etc.

One of our major goals with MindMeTo was to make a service which was both quickly accessible, but also highly extensible. It became clear that, in order to allow the service to feel instantly familiar for new users, we would have to rely on a human-readable command structure. Take the following MindMeTo request as an example:

Even if you had no comprehension of what MindMeTo was all about, you’d still understand the request. What’s really interesting is the social implications of running a reminder service through Twitter. Given that reminders can be set via @reply (as well as Direct Message and through our web interface), the request is already framed within a particular context. When put in context, the full command reads a little something like this:

Remind me to buy some cat food tomorrow

Now ask yourself how many times you’ve said something similar to a loved one, and hopefully you’ll see what I’m getting at. Reminders are largely a social construct, and I think it’s interesting to see how they’ll behave on a service like Twitter.

Of course, the problem with introducing a service to such a social environment is that people naturally expect to communicate as if they were talking to a person. Specifically when setting a time and date for reminders. To tackle this problem, I considered timestamps in two basic capacities: specific and vague. It’s possible to set the following reminder:

But it’s also possible to do something like this:

Perhaps the hardest aspect of developing a system devoid of any form of syntactical delimiters is that our parsing engine has to make an informed decision based on a number of potential results. Firstly, we must figure out where a reminder finishes and it’s timestamp begins. To do this, our parsing engine relies on what I call contextual flags. Let’s take another look at our two previous examples:

While they differ greatly in the level of detail used to set the reminder timestamps, both carry contextual flags that MindMeTo recognizes and acts upon. Contextual flags also (as you may have guessed) help us to put the timestamp in context. A contextual flag of ‘in’ suggests that the timestamp we’re receiving is relative to the current time, for example:

Is the system perfect? Far from it. But it doesn’t need to be. The beauty of introducing a human-readable format is that we accept the possibility of error (to err, after all…). After all, if you were to ask someone to remind you of something and they didn’t understand the request, they’d simply ask again. Provided the service fails gracefully, the user’s given another opportunity to express themselves. It’s our job to give them enough options so that hopefully they eventually find a way that is most suitable for their personal usage.

It’s always the simple ideas that people seem to be captivated by. Recently, in an attempt to force myself into taking my status as a Type One diabetic more seriously, I setup Diabetting as a way of putting a fun slant on an otherwise serious illness. Not only that, it got me checking my blood sugar regularly and really considering my diet.

The project took a day or so to complete and after putting it online I pretty much forgot about it. However, it looks like the site has proven popular. Having been featured on OnePageLove, the site gained traction and began appearing on various different blogs (and even a few wikis), before becoming a popular story on Metafilter.

The site was primarily put up for my own benefit, but it’s also become a platform for additional information on diabetes. Looking at a few of the comments from Metafilter, it looks like the site has gone down as it was intended:

This is great, it is an excellent way to motivate him to be sure to take his readings, and will really improve his health while possibly settling the odd bet. Win-win!

this site is great for diabetes understanding promotion. demonstrating a little fun shows that you too, can have fun with type 1.

And although I’ve never played Dungeons & Dragons in my life, this one put a smile one my face:

I have trouble taking my blood sugar as often as I should. If I were a nerdy computer programmer I would totally do something like this to force myself to take it.

Unfortunately, I am a nerdy D&D guy, so I just roll a D20 to make a constitution check.