iOS/Web Developer's Life in Beta

I’m a fairly decent web designer.  I’m not great by any stretch of the imagination, but I’m not really visually creative.  I tend to express my creativity in the apps I build, as well as in my writing.  So given the fact that I’m really proficient in CSS and HTML, I can make simple web applications look good if I don’t have the help of a designer.  That being said nothing replaces a great UI designer, who are worth their weight in gold!

But when it comes to my blog, I want it to look attractive without having to spend a ton of time on it.  I’ve given up on trying to write content management systems.  To me they’re a solved problem – maybe not solved particularly well, but it is to the point where I don’t feel I’d like to contribute anymore to the field – so tweaking my own website content by hand holds no interest to me.

But seriously, why do the available blog templates out there have to look so damned horrible?  Even the commercial blog templates for WordPress all seem to be lacking in some serious areas.  Is it really too much to ask that I can have an easy-to-read blog template that will adjust to the width of the browser that doesn’t have serious CSS problems on one browser or another?

Over the next few days I may be tweaking my blog’s template a bit, because I’m tired of the standard one-size-fits-none layout that most templates have.  I might even pay for a commercial template, if it means my blog doesn’t look like the sidebar of a print newspaper anymore.

While developing myDrumPad, I came across an interesting problem for my in-app purchase support. The app allows users to download additional packs of sounds (referred to as “sound packs” in the app) that they can use to tap out songs and rhythms. The sound packs themselves were a collection of CAF-encoded uncompressed PCM audio files, with a single configuration file describing the labels and arrangement of the sound files on the drum pad’s grid of buttons.

I wanted to be able to add additional sound packs without issuing a new release of the app, but since the information describing the sound packs is largely static, I didn’t want to have to worry about maintaining a dynamic server for the app to continue functioning. I wanted it to largely be “fire and forget”.

What I came up with is, I think, a best of both worlds. The app functions without needing me to maintain a server, but I can still dynamically add additional resources to the app instantly.  Read on to find out more.

(more…)

I’m an avid “Idea Man”.  I love coming up with new ideas; for iPhone apps, for web apps, and even for real-world inventions.  Most of my ideas only sound great in my head, but when I open my mouth the idea seems to turn sour.  A smaller number of ideas manage to survive the thought-to-word boundary.  An even smaller minority of those ideas manage to make it down onto my “Idea Book” that I use to keep track of all the potential projects I’m going to work on.  Admittedly it’s not so much a single “book” as a collection of binders, scraps of paper, and in some cases 3×5 index cards.

Suffice to say amongst all those ideas, some gems manage to stand out above the rest.  A few I’ve actually finished, such as Boomle and myDrumPad.  The end product is seldom what I’d planned when I came up with the idea, but either due to time constraints, or the project evolving during the course of its development, things change.  Mostly I’m pleased with the end result, but there are some things I wish I had time for.  For instance, I’d like to re-implement Boomle using Cocos2D to make the animations smoother, and maybe add some extras such as obstacles, more challenging levels and Game Center integration.

Unfortunately, while I absolutely love myDrumPad, my original plans for it involved the creation of loops and patterns within the app.  Once I built it and started playing with it in real-time, as opposed to my ideas jotted down on paper, I discovered that the interface — while easy to use for quickly tapping out beats — doesn’t lend itself easily to creating loops.  I could create loops, sure, but my goal was to create an app that could be used in live performances, and sadly the interface just doesn’t lend itself to real-time editing of loops.  That’s not to say that I’m unhappy with myDrumPad.  Sales are going fairly well, and I have a few more updates planned.  I’m still adding additional languages to it using ICanLocalize.com (currently it has native support for English, Korean and French, and Japanese and German are following soon).

One of my constant loves for as long as I have been programming has been music and sound production.  And since I’m a rather unconventional thinker, I’d like to try my hand at an unconventional music interface.  I like the idea that someone without any knowledge of music notation or performance can learn to use my apps to produce the music they hear in their head, and to express themselves in ways they wouldn’t otherwise be able to.

I’m still formulating an idea in my head, but the loop and patterns features I was planning for myDrumPad are going to be built into a new application instead, with a completely different interface.  Like myDrumPad, it will be an experiment to see if producing music in this new UI metaphor will be successful.  It’s hard to explain, so I’m going to wait until I have a more accurate prototype to show.

But this app idea doesn’t exist in isolation.  In my little book of ideas I have several on-the-go prototypes just itching to get started, but since I still maintain a day job (and will for the foreseeable future) my time is limited to a few hours per day, and weekends.  My web-based space game, my photo sharing web application, my sonar-based iPhone utility app…all these ideas are stuck in my head as fantastic ideas I’d love to pursue, if only I had the time.

I’m sure it will be an interesting adventure to see which idea wins out in the end.  Do I build a web-based MMOG space game set in an infinitely-scalable universe?  Or do I build a Core Audio-based iPhone utility?  How do I determine which project has the highest likelihood of succeeding, or at least have the greatest likelihood of being finished in a reasonable time-frame by a single developer?

In an ideal world I’d build all of them.  Unfortunately, as an idea man, I think of ideas of varying awesomeness faster than I can build them.  As long as I require sleep, I suppose I’ll be stuck in this situation.

Wow the past few months have been quite a wild ride, and a ton of things have happened!  So much has gone on and I’ve been writing so much software that I haven’t had the time to blog about it.  In the time I’m not writing software, I’d rather spend it with my wife than spend it writing about the software I’d written.

Over the past few months, while the PhoneGap team started a major refactor of their codebase, I spent some time learning more about Objective-C and UIKit, and discovered that writing native software on the iPhone is a heck of a lot easier than I’d previously expected. It shouldn’t have surprised me, because I’ve heard rave reviews from developers I have a great deal of respect for, and it also shouldn’t come as a great shock that Apple treats their developer SDKs with the same degree of polish and attention-to-detail that they do to their hardware. So while I was working with PhoneGap I’d contributed a number of plugins exposing the iPhone’s native UI elements to JavaScript-based apps, I’ll no longer be updating or adding any new plugins.

While my blog was collecting dust, I also finished a PhoneGap-based app, Parking Mobility, and while it was nice to start the project in familiar languages like HTML and JavaScript, a ton of time ended up getting eaten up chasing random bugs, memory leaks, and strange UI behaviours that required odd work-arounds to eliminate.  In the end I discovered I’d spent more time getting the application to market than if I had built it in native code.  Starting this past weekend I’ve begun doing just that, writing the application in UIKit and Objective-C in order to get more performance and a better user-experience out of the app than we have currently.

One of the other big reasons why I haven’t been as chatty on my site as usual is, of course, the launch of the iPad and the iPhone 3.2 SDK.  I decided to hit the ground running with this platform, and used this new SDK as my playground for learning more native development skills.  I developed two applications for the initial launch of the iPad, Boomle and myDrum Pad.

Boomle is an easy-to-play game featuring peaceful sounds, low-touch interaction, and an addictive gameplay.  It was a lot of fun to build, and got me started working with OpenAL, manually drawing displays, and dealing with real-time games.

myDrum Pad in contrast is an interactive drum pad that aims to allow people to tap beats out with a variety of sound packs along to music, or create their own riffs.  It’s still in active development, but this has been a blast.  I’m developing it with CoreData, OpenAL sound playback, multi-touch displays, In-App purchase and asynchronous downloads from Amazon S3.  It’s a highly dynamic UI with a smooth user experience.  It’s also the first iPhone project that I’m directly involving a graphic designer with the whole process, and once we get a beta ready, I’m sure you’ll like the screenshots and demo images we’ll be putting up.

Last, and certainly not least, I’ve changed roles in my day job at Sophos, and am working once again in the Email Security team developing our Email Security Appliance.  I get to play with all sorts of complex problems, web-based administration interfaces, and pretty much every technology under the sun.

Now that these projects have all stabilized, I’ll hopefully be blogging more about Objective-C, Javascript web applications, and technology in general. Plus Summer’s quickly approaching, so hopefully I’ll have some pictures of my motorcycle and any trips my wife and I take this summer up here soon.

My friend Scott McWhirter, who heads up the Vancouver Perl Monger’s group, asked me yesterday to give a last-minute talk on anything in particular at tonight’s Vancouver.pm meeting. He wasn’t exactly begging, but I know he’s short on speakers this month, and he wanted something interesting to show.

So I decided I’d talk about building and testing Perl-based projects using Hudson. I’ve been planning on writing a blog post on the subject for the past month, but haven’t found the time to finish off the post properly. So if you’re interested in the topic, and you don’t want to wait for me to get around to writing about it online, please feel free to drop by tonight!

It’s too bad I can’t use it at work, but HTTP::Engine rocks my world. It does “The Right Thing ™” for negotiating HTTP requests and their content in a wonderfully transport-agnostic way. That means that if you’re running in mod_perl, FastCGI, plain ‘ol CGI, or even running as a stand-alone development-mode daemon, it will just work.

At my work, we’re building new user interface components to our email security appliance product, and for the first time we’re building a web interface that will be used by a potentially high number of public users. Up until now, all of our target users were internal to our customers, meaning system administrators and a small number of workgroup users. Now however, their customers and the recipients of potentially a high number of emails will be able to interact with our appliance. This means we have to scale a lot higher than we have needed to in the past, all with limited hardware and memory.

So for the first time in eons, since before I started working with mod_perl back in the late 90′s, I’m having to parse HTTP POST data, including file uploads, by hand. Catalyst does it really well, but unfortunately the list of dependancies it has makes it prohibitive to pull in to our build. That’s when I discovered HTTP::Engine. It looks great, it does what Catalyst does for managing HTTP requests in a flexible and extensible way, gives all sorts of great developer hooks to access internal information about the request, and it doesn’t require that you buy in to Catalyst’s way of doing things (of course, when I’m at home, I develop my apps using Catalyst).

Sadly though, HTTP::Engine’s list of dependancies is almost as long as Catalyst’s. Normally this wouldn’t be a problem, but given our restricted memory limits, I just can’t justify using it. Which really blows, because as CPAN modules go, this one is pretty darned sexy!

I’ve decided to simply write a sub-class of HTTP::Request that does what we need, and tie it in to the Nginx 3rd-party module for file uploads.

Maybe someday I’ll be able to use Moose, Catalyst and HTTP::Engine on our appliances deployed in customer locations around the world, but for now I’ll just have to roll my own.

It’s probably not the kind of Iron Man competition that you’re used to hearing about. This one is a challenge to blog at least once per week, every week, about Perl and Perl-related technologies.

My buddy Matt Trout, co-founder of Shadowcat Systems, creator of DBIx::Class, a core contributor to Catalyst, as well as all sorts of other great Perl goodies, is starting a blogging contest to try to get the word out that Perl is still alive and well, and perhaps try and overthrow the public perception that Perl is use old-school “use CGI;”. And he’s also a hilarious public speaker too.

I’m going to be taking part from this blog. I love Perl, and have been writing software in it for nearly 15 years. The problem with a lot of people like myself is that we already know that Perl is great, and is used throughout the world to solve mission-critical problems on a daily basis. But we tend to forget that unlike Java, .Net, and other crappy newcomers, Perl doesn’t have a marketing department trying to convince people that their language doesn’t suck. Anyone who’s had to deal with Java CLASSPATH problems, .Net’s problems like – well, that it’s .Net, for starters – knows that just because there’s industry buzz about something doesn’t mean it’s lacking in the “SUCK” department.

Please check out http://www.enlightenedperl.org/ironman.html and join in. Or alternately you can email ironman@shadowcat.co.uk if you want to contribute. At the very least, I suggest you follow the Enlightened Perl Iron Man blog. If you’re following this one, at the very least you’ll be following a small part of it.

I keep finding amazingly good blog posts or links of interest that I end up bookmarking for my own uses, but I end up having to tell people on a case-by-case basis why one article is good for one reason or another. I end up bookmarking on my Delicious account and sharing blog articles I like via my Google Reader account, but it’s becoming increasingly obvious that this isn’t enough.

So instead, I’m going to write a weekly (hopefully) article on links I’ve come across and why they’re cool. So, without further ado, here’s the first installment of Links Of Interest.

Object-Oriented CSS

I came across a link from Ajaxian, which talks about Nicole Sullivan’s work on Object Oriented CSS. Here’s an excerpt:

How do you scale CSS for millions of visitors or thousands of pages? Nicole first presented Object Oriented CSS at Web Directions North in Denver. Since then, the response has been overwhelming. OOCSS allows you to write fast, maintainable, standards-based front end code. It adds much needed predictability to CSS so that even beginners can participate in writing beautiful websites.

The idea is intriguing. I’m curious to see how it can be applied to mobile iPhone development. The important thing though is that most people get web development wrong. Either JavaScript, CSS, semantic markup, or all of the above. I even know people who still do their layout with tables!

Typically when you consistently find a problem with development across a series of projects, the problem is most likely you, or at least the way you’re doing things. Take a step back and re-think the problem, and re-educate yourself on best practices.

There have been articles across a number of respectible web development blogs talking about writing reusable code, and defining client-side logic in classes (even when you think you might never re-use that application logic again). But I’ve never seen that principle applied to CSS. I definitely recommend reading more on this topic.

Juicer: JavaScript and CSS Packaging

YUICompressor, and its friends, are great methods for compressing CSS and Javascript, but my biggest wins you can possibly make in optimizing the size of your script or style content is simply to not include the things you don’t need. This is why I perked up when I saw a post on Ajaxian on a project called Juicer, which is a tool to package JavaScript and CSS while applying best practices as it does its work.

When developers start a project, they’ll go to the site for their tool of choice. For me, I first go to MooTools and download a kitchen-sink build of MooTools-core and -more, and as I develop I’ll use more and more features of it.

However, when it comes time to ship, I need to scale back what my MooTools build includes since probably 75% of it won’t be needed by my project. But the question is, which 75%? This is mostly a trial-and-error process which is made all the more difficult to deal with because I’m used to Perl and CPAN resolving dependancies almost flawlessly.

So my hope is that Juicer can help me solve some of these problems, and I can use it at build-time so I not only can resolve dependancies and build the proper Perl modules to deploy my webapps, but that it can trim down my JavaScript libraries to include only the features I need.

QFocuser

This seems like quite a simple script, but it solves an important problem. In a nutshell, it creates a way of handling focus and blur events for fields and other sorts of widgets so you can make your web applications accessible. Ajaxian gives a little summary of QFocuser, but I had thought that this could be quite powerful for reasons other than accessibility.

At my day job, we style our text fields specially when they are disabled, selected, or just regular plain fields. Most of our legacy code manages this manually, by setting attributes and CSS properties independantly, and many places gets it wrong. I’ve been implementing some changes in our framework to eliminate this problem, and largely involved implementing much of what QFocuser does, but in a more specific way.

I’m curious to see how I can apply it here, and use it as a generic mechanism to make our UI behave more consistently.

Internet Marketer’s Checklist

Over at SEOmoz there’s this great post, titled “The Internet Marketer’s Checklist For Determining If a Business Idea is Worth Pursuing“. The title is a mouthful, but it’s a great discussion of the things that will make an online application succeed or fail. As programmers and technical types, we often lose site of the actual goal of doing what we do: building stuff that people will use.

I’m a terrible example of your average user. I use the keyboard primarily for navigation, even on my Mac (Quicksilver FTW!), I use the command-line almost exclusively. Most users wouldn’t be caught dead using their computers that way. This extends to other areas as well. Applications that would appeal to us techies won’t appeal to the nontechnical, teen-with-flashy-website crowd.

I’m fortunate that my wife not only is very technically savvy, but still is in touch with her non-technical roots, and has a psychology degree and her lab experience to know how people think. I use her as my litmus test to see if an idea is worth pursuing. But beyond knowing if someone will be able to relate to a website, this checklist looks like a great way seeing end-to-end if a site would be understood, would be marketable, and if it would actually stand a chance of being used by the general public.