Well, no, I read other people’s code and learned how to code from that. I read books that dissected good code, but mostly I read books on things that weren’t specific to code (e.g., 3D maths used in games). I taught myself to read code and write code like the code I read. I read the Quake 1 source code,¹ I read the Quake 3 SDK’s source code, I read Ruby scripts, I read Lua scripts while I worked on a game that used Lua,² and so on.

I asked myself how others did it and I read how others did it to answer the question. I was curious what code written by people who really knew how to code looked like. So I learned to read code, but I still wrote bad code probably for a long time, and maybe still do, but I leave that up to others to decide. After that, I taught myself to code.

Except really, it’s more like I taught myself to use a debugger before I learned to really code. I couldn’t write code if I didn’t know what it did. So, I wrote code or took other folks’ code and I stepped through it and saw how it worked. I read code while it executed, and this let me know how things worked even if I didn’t and sometimes still don’t know how everything works at the lowest level. I know how conditionals work, for example, in assembly, but I couldn’t tell you why the assembly worked with the hardware.³

I was curious about what code did and had to know how it worked before I could really code. So, I learned how it worked and what it did, and after that, I taught myself to code.

When I taught myself to code, I never really started small, I just started esoteric or weird, whatever prodded me just enough to raise questions that seemed out there. My idea of fun wasn’t writing blackjack for a terminal, though I wrote blackjack programs, it was always more along the lines of modifying virtual method tables at runtime or building code to automate other tasks in programming, like writing code to generate Lua bindings.⁴ I was curious about how I could handle any given situation and what different ways I could approach it.

The whole key here — to how⁵ I learned to code — is curiosity. Curiosity killed the cat, sure, but the cat had nine lives, and before it touched the capacitor in the CRT, it got a pretty good look at how things worked. Because of my curiosity, I want and need to solve problems. I see puzzles in the crevices between ideas. Programming is not a job, but a strange search for new problems, one part learning to learn, one part problem solving, and one part borderline-obsessively-curious tinkering. A self-taught programmer must necessarily have all three of those parts to survive as a programmer.

Without those parts, that programmer will never seek knowledge, never fix anything, and never try anything new. He or she will be the programmer you don’t want to know, self-taught or not.

But with them? With them, that programmer will never feel limited, never stay bored, and never grow tired. With these things, that programmer will always enjoy programming. With these things, you’ll be a great programmer.

Sublime Text Starter, by Eric Haughee, probably isn’t what you’re looking for to get started with the now-rather-popular programmer’s text editor, Sublime Text 2. As the title suggests, this book intends to get you started with the editor and for three quarters of the book, it really will start you at the very beginning: installation and saving a document.

The book’s downside is that it doesn’t seem to know quite who its audience is. It begins with basic installation instructions – the sort we take for granted and gloss over in all software manuals, especially the ones programmers ignore on a day-to-day basis because we think we know better. After installation, you’re given five pages on how to create, or open and modify, a file, and how to save the results.

This shows how basic the book starts at, which is fair enough for anyone not too used to these tools. However, given Sublime Text 2’s core audience is programmers, it may come across as odd at best and possibly demeaning at worst. Either way, the first 28 pages are likely not intended for programmers. So, we’ll skip past those 28 pages as redundant and get to the parts that don’t pertain to every piece of software intended for modifying some kind of file on the planet.¹

We go on to learn about the minimap, multiple cursors, distraction-free mode, vintage mode, the goto panels and the command palette. Except for the explanation of vintage mode, these are all perfectly acceptable and include helpful screenshots and relevant key-bindings. My only complaint with these is that they are more or less covered by Sublime’s front page, as well as likely comprising the subjects of all Sublime Text 2 tutorials. For vintage mode, the book’s explanation only scratches the surface of its use and suggests only Vim users should use it, but I’m not sure a Vim user would read this book, so I’m again unsure who the book is for.

There is minor one downside to vintage mode’s explanation though, a bit of misinformation on the part of the book: it tells users to modify Sublime’s default preferences. This is a no-no, you never modify the default preferences. If you suggest the user modify preferences, you tell them to modify the user preferences, pictured to the right.

For most purposes, this won’t produce a noticeable difference, but it does result in a user unable to easily copy his or her settings over to new installations or versions of Sublime. This might not seem like an issue now, but it will present an issue with the coming release of Sublime Text 3. So, there is a small risk of future frustration involved.

Starter also goes on to mention Package Control, including some perhaps frustrating installation instructions fraught with potential bit-rot. This isn’t likely to be an issue for most people, but typing seven lines of Python into the Sublime Text 2 console is not the most pleasant experience. Thankfully, the author includes a link to the Package Control site as I have above.

The explanation of snippets is mostly sufficient, though the formatting of the book results in some unfortunate line wrapping in the snippet that produces less than eye-catching imagery. In addition, the snippet example provided by the book is invalid and will cause Sublime to insert nothing when using it. This sort of error is par the course for tech books, so I’m inclined to forgive it even if it highlights the sorry state of tech books.

Finally, the book finishes up with macros (never once mentioning how to create your own plugins, but this book is a “starter” and not likely to cover anything advanced despite expecting users to know how to work with XML and JSON). Custom key-bindings are shoehorned in as a part of macros rather than their own rather expressive feature, which is disappointing and perhaps not showing users just how much they can customize their key-bindings to their liking. Either way, the discussion of macros is mostly sufficient, though likely to frustrate users when they discover the limitations of Sublime macros (like certain commands not being recorded or working in macros).

Ultimately, the book seems to expect some level of experience with technology but simultaneously assumes none from the start, so the first chunk of the book might be well-suited for those who don’t know how to install software, but they would be lost in later sections. For those experienced enough to breeze past installation and those who know how to save a document, the rest of the book might work for them, but its brevity leaves something to be desired — again, a byproduct of the book’s attempt to get readers started with Sublime, but never seeming to try to imbue them with the skills needed for further use.

Rather than purchasing the book, either $4.24 for a digital copy or the much more expensive print copy at $19.99 (effectively $20, which is far beyond what anyone ought to pay for 46 pages, 28 of which cover installing an application), I’d recommend waiting for another edition — if you still want to consider this book. Wait for one that cleans up the few errors in the book and goes into enough depth to leave you with the feeling of knowledge gained.

As it is, though the book might be of use to someone, I’m not sure either I or the book know where to find that someone. The audience for the book would have to be someone who doesn’t program, doesn’t know how to install software, and possibly uses Internet Explorer 6. Instead, do as the end of the book suggests and take a gander at Jeffrey Way’s Sublime Text videos, read over the unofficial documentation and for anything else, join the Sublime forums.²

• Android still has an obsession with wasting large amounts of home screen real estate with enormous clocks. Why all the large clocks? You already have a clock in the corner of your screen, it’s in the status bar. The analog clock sucks as well since it’s very lousy at telling time.
• Scrolling is mostly smooth for the first time in Android’s history. It’s still not great, but the input lag is mostly gone, though it regularly seems to skip rendering stuff just to keep up with the input, which looks ugly. Still, it’s an improvement.
• Scrolling inertia feels very strange. I flick and it doesn’t seem to do a whole lot, but I flick again and it’s like I’ve broken the speed of light. Very inconsistent and very weird.
• Screen resolution is acceptable but the way the UI is designed makes it a rather poor decision. You’ve got two mandatory bars on the top and bottom of the screen at all times, so in landscape orientation, your vertical space is limited by a lot. Further, if you try to use the keyboard in landscape, you’re given a tiny sliver of an area to work with — even less if the field pops up the predictive text bar too. This obsession with widescreen aspect ratios really needs to end if tablet manufacturers want to continue making tablets designed for both orientations.
• The onscreen keyboard in portrait is excellent, especially with Android 4.2’s addition of swipe-typing (basically ripping off whoever came up with it first, doesn’t really matter, though I expect Swype is slightly miffed). In landscape, typing out things with my thumbs is easy enough. Typing any other way, including swiping, is tedious and better off done in portrait.
• Google Currents, which was pre-installed, is excellent. Beats the everloving hell out of Flipboard, which really, really sucks (both on iOS and Android these days).
• App selection is still garbage. There are no good apps for writing aside from — amazingly — Google Docs, which is actually completely usable via the Google Drive app now. It’s very good, though limited (which is fine for me — I don’t want a full-featured word processor, just something to write in).
• The bezel is too small in portrait. I’m frankly not sure how you’re suppose to hold the thing like this without accidentally tapping the screen.
• The Gmail app is worse than I remember it. No unified inbox and no pull to refresh and so on. Seems unusually limited. I seem to remember the Gmail app being better, but I guess iOS just improved a lot over time.
• Also, really, we’re still using two separate apps for Gmail and regular mail? Give me one app and let me have my inboxes all in the same damn place.
• The official Twitter app is shit. End o’ story there.
• The Google+ app is far worse than its iOS equivalent. It really sucks in comparison, which is strange considering one would expect Google to make Google+ more compelling (I hate that word) on Android.
• People call this thing “pocketable,” and while I can fit it in a pocket, I think the sheer goofiness of having a tablet in your pocket and the shame that comes from that is enough to make it un-pocketable. Also, the power button is too easily pressed, so putting it in your pocket will probably result in it being frequently woken from sleep.
• Holding this thing in the palm of your hand, with a thumb on one side and your remaining fingers on the other, is stupid and uncomfortable too. I don’t know why this attribute is considered positive.
• Notifications as usual are best in class.
• AndChat is still free and it’s still a great IRC client. Also, thanks to the way Android handles multitasking, I never lose my connection to a server.
• Chrome is an acceptable improvement over Android’s original browser, though it pales in comparison to every other mobile browser and Google should be ashamed of themselves for shipping such a lackluster piece of crap. Hell, it’s on a tablet and it doesn’t even have a bookmarks bar, so I can’t use any of my nice Javascript bookmarks.
• On the topic of bookmarks, there is no good way to access them. I either have to replace my current tab with Chrome’s bookmarks UI or go back to the home screen and put a widget down to see my bookmarks. Why can’t I just browse them via a popover? Also, small icons with tiny captions are not the best format for bookmarks. Give me a list so I can actually see the titles of my bookmarks.
• The Kindle app works fine. Google Books is still garbage and a usability nightmare.
• Google Maps beats Apple Maps, but you knew that already. They’re about on par around here, though, so it makes little difference.
• The 1Password app on Android sucks. It’s basically an attempt to clone the iOS UI, and you can guess how well that went.
• Google Music is very, very strange. I try to upload a playlist and it kills random songs from it even though the songs have been uploaded. The app itself is a confusing mess. For some reason I can only see how many songs a playlist has in landscape. Overall, it sucks, but at least it’s not Winamp.
• Google Music’s icon is the ugliest thing on this OS.
• Google Calendar has the most schizophrenic and useless user interface ever. I like that I can scale the week view, though.
• Kevin Coppock’s Holoku is still the best sudoku app for Android.
• I shouldn’t have to tap a button seven times to enable the developer settings. Really, that’s stupid.
• Voice search is about the same as Siri — good for setting alarms and reminders. Unfortunately, Google just creates a calendar entry for a reminder, so it’s a bit annoying that there’s no difference in priority between a calendar entry and a reminder.
• Dropbox sucks on here.
• Viewing PDFs in either the PDF viewer that’s built in or Acrobat is slow as all heck and I don’t know why.
• Updating one or more apps causes the OS to become rather unstable and not register touches. The Play Store app is nigh unusable while any apps are updating as it will constantly attempt to refresh its UI and generally ignore whatever you’re doing.
• The speaker can get very loud but sounds very shitty no matter what volume you use. Use headphones.
• Setting the wallpaper is much easier now and the UI for doing so is very well designed. That said, why when pressing the back button after I’ve selected an image am I taken back to the home screen and not the view for selecting an image? What if I just decided a different image was better? I don’t want to have to long-press somewhere on the home screen just to get back to my pictures and select a wallpaper image again. This is retarded.
• Speaking of retarded, the back button’s fairly inconsistent about where it’ll take you. This is especially obvious if you get taken to the browser, whereupon the back button seems to just be the browser’s back button.

Most of the WordPress theme ported over cleanly. The stylesheet is the same, save for a few changes to accomodate the Google +1 button and to remove any vestigial traces of WordPress. The theme previously made use of a sidebar, which meant bits of the default WordPress widgets were themed. All of that’s gone now, so it’s surprisingly clean. The theme’s overall structure is still something of a mess from accumulated cruft over the years, but otherwise it works as expected.

The feed was my main concern. First, I’d previously never looked into generating RSS feeds, so I expected a great deal of pain and suffering to get it working. Turns out I was wrong: RSS feeds are dead simple. I suppose it lives up to its name in that regard – it’s a very, very pleasant format to work with.

Second, the RSS feed location changed. As you can see in the previous post, I created a FeedBurner URL for the feed, but this turned out to be more or less unnecessary. mod_rewrite took care of most of the URL-changing pains (previous permalinks were year/month/post-slug, whereas they now have a post/ prefix). As a result, the feed issue is mostly gone. The FeedBurner URL will remain active because I’m a jackass and didn’t consider the options at the time, but it won’t harm anyone to switch.

So, Spifftastic now uses OakTree. About damn time.

If you’re currently reading this via an RSS reader, you should probably update your feed URL to the new FeedBurner URL at http://feeds.feedburner.com/Spifftastic. Ordinarily, I would like to avoid changing the feed location, but I’ll be moving Spifftastic over to OakTree shortly, and given my infrequent updates, would at least like to give folks a chance to switch over before I pull the plug on the old feed (which will be replaced with a new feed that FeedBurner can automatically move you to).

There will be a few more changes to Spifftastic, including the addition of a Google +1 button (until I decide I hate them) and the removal of the site’s search function (because it’ll be static HTML). I hope these changes won’t affect anything drastically, as the button is fairly small and part of the post meta and the search function never really got any use anyway.

So, update your feeds and you’ll be good to go when I finally plant OakTree.

bork initially started out as a series of shell scripts with a fairly simple structure inspired by git (whether git is actually structured this way, I do not know, I’m simply going off appearances): a main jumppad sort of script that calls into other scripts that actually do what I want. This ultimately led to a structure that basically looks like this:

|++ bin
    |- bork
    |++ bork-exec
        |- bork-add
        |- bork-relative-path-to
        |- bork-rm
        |- bork-station
        |- bork-update
        |- ... and so on

This sort of structure actually lends itself fairly well to the particular idea I was going for, where you can work with bork in two different ways:

1. By using the jumppad script: bork add ...
2. By using the scripts directly: bork-add ...

The reason this worked well is that each bork command depended on other bork commands. Most bork commands depended on bork-station to get an absolute path to the nearest bork station, the directory containing all hashed files and tags and so on that allow bork to work. It works in a fashion similar to git as well (and likely Subversion and other tools like them) in that it searches the current working directory (CWD) and all directories above the CWD for a station. Almost all commands required a bork station, so they’d run bork-station to get a path (if there was one) and do their thing. Some others depended on bork-update, such as bork-rm and bork-find, both of which modified the station and therefore depended on it being up-to-date.

A second upside is that this potentially allows me to replace various commands down the road with new implementations. Ideally, I should be able to pull out an old shell script, replace it with something written in C, and call it good. Shell script isn’t particularly fast, so I was expecting this to become an issue fairly quickly, and I was right.

What I was wrong about was the ease with which I can replace commands with new implementations. To do a new implementation that doesn’t simply go out, run a new process to do something, and return some results back to the calling command means rewriting most of bork in the new language. Having two separate implementations of a particular aspect of bork isn’t really the best idea, so the way I saw it was fairly simple: rewrite the whole thing and ditch the original structure or put up with the less than pleasant idea of dealing with reading/writing from pipes to other processes. Not too difficult, but also not fun. The latter is unpleasant enough to do a complete rewrite, so rewrite I did.¹

I was more or less settled on using Ruby for the project, so that was the target language. bork’s predecessor, a series of Ruby scripts to do roughly the same thing,² had proven that Ruby was good for the job, so it wasn’t about to change. Next step: gemification (this was the branch name). bork was originally a tool to generate Makefiles, so I had a gemspec sitting around for it and recycled that. The directory structure was mostly there already, though at the time you wouldn’t have known it by looking at the git repo.

I kept the jumppad script, which had always been written in Ruby for convenience (its Kernel#exec provided an easy way to jump from bork to the command script). It was heavily refactored, but for the most part you can see a lot of the same code in the same places. I moved command scripts into individual Ruby files under a Commands module, each registering itself with the default Bork::Hub instance, which collected command classes for the jumppad and allowed commands to run other commands (provided they’d been loaded).

The Bork::Station class ended up becoming the most important class, containing all methods for accessing data contained in any given station and manipulation those stations. I’d ordinarily feel bad about this, but stations are so small in their functionality that the class never becomes too big. If anything, some of the methods could use refactoring into smaller methods, but otherwise the conversion went fairly well. The important point of this, however, is that the Bork::Station class is effectively bork – everything that makes bork bork resides in it. The hub is only there for the jumppad’s sake and the command classes simply get to a station and do stuff with it.

So this means that there is an opportunity to build other projects around bork’s stations. It’s entirely possible that one could subclass a station and add new functionality to it, new metadata, and so on. So, there’s a lot of potential there, provided I refactor the hell out of some of the functions. Eventually, it would be nice to split up the station into the interface and a backend. Either that or simply define a base class for stations to implement and let them go from there. Who knows what maddening things I could do there.

So, that’s bork’s shell to Ruby conversion in short. I have to say, it was a lot of fun writing bork, so I’m glad Ruby makes this stuff so pleasant.

Why leave Facebook now? Mainly because they moved everyone’s email address over to an @facebook.com address.¹ This by itself is a fairly benign change at face value, but it also creeps me out and violates my one rule of social networking: never modify the information a user provides.

By changing everyone’s visible e-mail address, Facebook likely hopes to route all communications through its servers. Access to user emails gains them further access to personal information in e-mails and such, and that information furthers their advertising goals. Google more or less does this with Gmail already – it’s not as though Facebook has committed themselves to some heretofore unseen evil. However, I trust Google more than Facebook. This level of trust is likely arbitrary, but it’s still there. As such, the one rule comes into play.

The assumption I make with a social network is that the data I give them is immutable on their end. They are then free to connect it to other data, do whatever creepy things they see fit to do in the background, and generally do the usual slimy things with my data. But for the profile I give them, I expect the data to remain as I set it. If the network changes my data, it has then violated the idea that I control my information. Facebook disagrees with this rule and believes they control my information. I’m obligated to condemn their actions, so I danced my worthless protest and closed my Facebook account.

For now I’ll reside mainly on Google+ and Twitter. Google still retains more of my trust than it perhaps deserves. That said, it’s not entirely misplaced: they’ve stored my emails in relative safety for years. Twitter seems benign enough that the information they have seems useful only in a union of all other social network data. Therefore both retain my membership for the time being.

Adiós, Facebook. I won’t miss you.

I privately declared Ascension a finished project some time ago, mostly around when I finally decided Android development depressed me. A few users have since contacted me and learned this as well. I’d never declared a project finished before, at least not a user-facing one. Sure, I’ve made libraries and they’re finished, but nothing sold directly to consumers. The decision came easy, though: I wanted nothing else out of Ascension, wanted nothing to do with Android, so I stopped. I prefer to work on what makes me happy. Working on Ascension brought only the opposite feeling. So I stopped.

Ascension became feature complete the day I released it, with bug fixes and small additions afterward as a sort of bonus while it continued to sell well enough to cover a cheap meal a day. But sales slowed down despite updates and I decided then that only bugs would get me to update it. Then I decided that only bugs that I could test would get me to update it. Turns out Ascension lacks many bugs, if any. I’d received a few bug reports of unusual foreign handsets failing to run it, but I honestly didn’t care. They appeared to fill the cheap phone role, and I had no interest in supporting those users. They were all Lite version users anyway.

The Lite version may have been my one big mistake. I released a feature-stripped version of Ascension for users to try, mostly as an experiment. If it resulted in increased sales, the free version would stay. If it hurt things, it would go. Unfortunately, results were mixed, and I let the Lite version be. Ultimately, it seems more likely that only people interested in getting a free app downloaded the Lite version. I pulled it from Google Play earlier this year.

In the end, Ascension pleased a good number of people. The e-mails users sent me seem to prove that. The comments on the app seem to prove that. The consistently high rating on the Market seems to prove that. I made something I wanted for my phone, sold it, and easily made back the cost of development. It was a worthwhile project. But it’s done, so I suppose I should get back to my current project. Back to the project that makes me happy.

The Nil Theme

Regarding colors, blue is the active buffer/selection, orange is a dirty buffer/selection in tabs and open files, and subdued orange is inactive and dirty in tabs and open files. Aside from that, everything is a shade of grey and keeps my eyes in a state of relative happiness. In particular, the tab colors are intended to communicate state better than something that might be easy to overlook, like a little dot.

Installing The Theme

The theme can currently be downloaded on Github. I’ve submitted it for inclusion in Sublime Package Control, though if and when that happens seems indeterminable right now. Installation is fairly simply, and the README covers it all. However, for the sake of simplicity, or in the event that you don’t want to visit Github, the instructions are as follows:

You can download or clone the repository into your Sublime Text 2 Packages directory. To do this, simply navigate to ~/Library/Application Support/Sublime Text 2/Packages (or wherever it is on your particular operating system) and run the following command:

$ git clone git://github.com/nilium/st2-nil-theme.git 'Theme - Nil'

It’s very important you clone the repository into the Theme - Nil directory otherwise the theme won’t locate its assets and will take on an eldritch appearance. You don’t want Shub-Niggurath crawling out of your screen, so remember, put it in the right directory.

So there you have it. If the theme appeals to you in any way, go right ahead and download it.

Acknowledgments

The theme itself is a fork of Raik Ilves’s Pseudo OSX theme, which is in turn a fork of Ian Hill’s Soda theme. So, we’ve got a bit of a chain going now. Additionally, I would not have done this at all had I overlooked Liam Cain’s Refresh theme, which is another nice alternative. Basically, if you don’t like the Nil theme, these three are all excellent alternatives. I wouldn’t have done this without the three of them. Check ‘em out.

The PlayBook itself is much nicer than I’d expected. RIM knew how to create a nice OS and a nice tablet, at least. In particular, it doesn’t feel cheap. My HP Touchpad suffered from creaky plastic, it felt cheap, but the PlayBook avoids this. The device has a back coated in some rubber-ish material which makes it pleasant to hold. The power button, despite what reviews have said about difficulty using it, seemed easy enough to press. Overall, it’s a very nice piece of hardware and remarkably comfortable in the hand.

The only complaint I have about the device itself is its bezel: RIM printed “BlackBerry” across the bezel. If I pick up the device and hold it at any orientation other than the text’s, it looks stupid. The iPad benefits here from having really no markings on its front aside from the home button, and that doesn’t demand a proper orientation. If I pick up my iPad and start to use it upside down, the screen will reorient itself. It doesn’t look stupid, it just works. It accommodates the user. I’m not sure why RIM feels it must remind the user they’re holding a BlackBerry device, but, again, it looks stupid.

The PlayBook ships with a number of apps and their quality varies, which I expect. Most apps are reasonably nice, but slow. I just expect scroll lag in non-iOS software now. webOS suffers from it, Android suffers from it, and QNX, the PlayBook’s OS, suffers from it. It’s especially noticeable, of all places, in App World, RIM’s app store. When I attempt to scroll through applications in App World, it stutters through a small list of applications, frustrating me. This is curious, but I assume it’s a side-effect of certain applications using either Adobe AIR or WebWorks (essentially HTML/JS apps). AIR apps all seem to suffer performance issues. I haven’t seen many WebWorks apps, but I assume they suffer the same – browser performance on these devices just isn’t there. The iOS can’t handle it, and my own little tests with WebWorks seem to show the PlayBook can’t either. Maybe future browsers and devices will make web apps appear equal to native apps, but until then it’s a bad idea.

This presented a problem for me when I decided to look at how a developer might make a fairly normal GUI app. Currently, you have two options: Adobe AIR and WebWorks. Again, these suffer from performance issues. The WebWorks route is simple, but RIM offers developers very little assistance. There is no usable GUI framework via JavaScript. You’re very much on your own there, which is fair enough for web apps, but makes it difficult to create apps that fit in with the rest of the OS.

AIR offers a GUI framework of sorts, but the performance issues are so frustrating that I can’t imagine subjecting a user to them (and yet RIM has done just that). In addition to that, I find the entire development process for AIR apps frustrating. While WebWorks keeps the process simple, AIR seems built only for developers using Adobe’s wonderfully overpriced software rather than command-line tools. So, if you’re not willing to pay anywhere from $250 the $700 USD, you might as well ignore AIR altogether.

Your third option² for app development is the NDK: C and C++, not much else. You get your common libraries for these devices, including OpenGL, APIs for the OS and its windowing system, and other expected libraries. That’s about it. This should change with the next version of the OS, apparently BlackBerry 10, as RIM introduces Qt and Cascades, the latter a framework used by The Astonishing Tribe (TAT). To put into perspective how important that last bit is, let me just say that the applications that seem most apparently built by TAT are also those that never experience lag. Never. Their apps, however, are also about as useful as toys, so make of that what you will. Currently, however, Cascades and Qt are not exactly ready. You can demo them now, but I don’t imagine you’ll make a PlayBook app using either.

The NDK, despite its lack of a GUI framework, is actually the nicest of the three options for application development. Game developers in particular seem pretty well off here. RIM provides some utility code to create an EGL context, render text, handle orientation changes, and so on. It’s not much, but it reduces the amount of code one has to write. Additionally, one can inspect the code to see that it’s not doing anything funny and otherwise just learn how RIM expects developers to handle things. I think RIM knew what they were doing here, so it’s a shame that they didn’t put more into it. AIR and WebWorks are, by comparison, garbage. AIR in particular offers the most tortuous route to application development. WebWorks is nice but it’s too early to view HTML apps as competitive with native apps. For someone like me, the NDK is really the only good option for PlayBook development.

I’ll probably continue writing some posts about this, but this should serve as a sort of introductory post for future writing on the PlayBook. If there’s something in particular someone is curious about, I’ll be glad to divert some focus to that as well. Personally, I’d rather write about development, so now that my semester is over and I have a summer’s worth of time to do some work, I’ll try to offer some sort of commentary on development for the PlayBook and other devices.

Now count the number that don’t suck.