funkatron.com

Folks who got the fancy lad Palm® Pre™ on opening day found the App Catalog chock full of superapps. One of them is Spaz, a ground-up rewrite of the award-winning desktop application I created for the Adobe AIR platform using pure HTML+JavaScript. Getting Spaz on webOS™ has been a big undertaking for me, and the process has certainly had it’s ups and downs. But I’m proud of the fact that we shipped a truly open source, transparent app on the first day of a new platform.

But much like Spaz on the desktop, this is not a revenue generator for the project. Everyone who works on the Spaz project is a volunteer, and we rely on motivated folks to help us make cool software. It doesn’t need to be a huge commitment — even just getting involved in the discussion and coming up with ideas is a big help. But here’s where we need help the most:

Coding

While I intend to be the lead on Spaz for webOS™ for a while, I really could use help — I’m working in my free time, and that’s pretty limited with a family and a day job. The full source code of Spaz for webOS™ is available on GitHub, and people who want to help make new features happen are encouraged to check it out.

Even if you’re not well-versed in webOS™ coding, if you have a good JavaScript background (or don’t and are just interested in developing one), we need help to build up SpazCore, our component library that drives Spaz for webOS™, and will drive all our projects in the future. Hacking on SpazCore requires no knowledge of webOS™.

Support

We have a brand new, very awesome support site at http://spaz.tenderapp.com/ which is sponsored by the awesome folks at ENTP. We need to direct people there, and we need to get involved in helping them there. We also should build up the FAQ/Knowledge base. In addition, identifying folks on Twitter who are trying Spaz or having issues and pointing them to the support site is very important.

Advocacy

Do you like Spaz? Why? First off, let us know — I’d like to build a repository of positive mentions like that. In addition, telling people about Spaz and encouraging them to check it out is great. Hwoever, this needs to be done in a nice, non-abusive, non-spammy way, and we always need to respect other applications and their developers. THIS IS NOT A COMPETITION — it’s making people aware of quality alternatives to closed, non-transparent software.

Design/UI

I’m an opinionated fellow and rather controlling of how the Spaz apps look, but I also know there are better designers and UX experts than me. If you’re interested in helping with design and UI work on Spaz — including additional themes — I’d love to hear your ideas.

What About the Desktop?

You are not forgotten. Spaz’s desktop client is long in the tooth, and we have Big Plans for a full rewrite based on SpazCore. That’s long-term though, and in the interim work is still being done on the current Spaz codebase, including adding multi-account support and improving filtering capabilities. We also intend to transition away from AIR to the Titanium platform.

So if you want to stop bitching in your Twitter account and actually make things better, here’s your change. Drop me a line at spaz@funkatron.com and we’ll sort out the best way for you to kick ass.

I’ve been developing with AIR for over a year now. It’s all been HTML/JavaScript apps, but the complexity of most of them has been pretty low. Spaz, the Twitter client I created, definitely isn’t simple, though – mostly because I’m kind of a crappy coder, but also because it just does a lot of stuff.

Lately I’ve been getting a little bummed about AIR, because I’m starting to bump into limitations of the platform more and more. What’s particularly frustrating is that some of these limitations are specific to HTML AIR app dev. So what follows is a couple of issues that have been particularly troublesome when developing Spaz and other HTML/JS AIR apps.

AIR gets greedy under OS X

Julien Viet, who has contributed significantly to Spaz, made a post recently about the base resources used by the AIR runtime. In it he finds that the basic “Hello World” sample app provided by Adobe used about 20MB of RAM, and hovered at about 2% CPU usage even when idling. I replicated these tests on my Macbook (2.2Ghz, 4GB) under OS X 10.5.4 and WinXP SP2, and had similar results:

I also created a Flex-based “Hello World” application to compare base usage if the Webkit renderer isn’t being used. Memory usage was slightly lower, but otherwise it was comparable to the HTML app.

The constant CPU usage seems to be specific to OS X: WinXP will jump back and forth between 0% and 2%. This is consistent with my observations of CPU usage in Spaz as well: in OS X, we get 10-15% CPU usage constantly, but under XP and Vista, CPU usage is 0% while idling. Initial memory usage is also about 30% higher with Spaz under OS X than it is under Windows. Something is goofy with AIR on OS X.

That aside, I don’t think the memory and CPU usage of AIR are surprising, considering the technology. AIR is a full Flash runtime, and HTML apps add a Webkit renderer on top of that. The memory and CPU usage is in line — or a bit lower — than most SSBs. Using traditional browser tech to build a desktop app is going to be a tradeoff in terms of memory and CPU usage, just like many other technologies that make development easier. But for one reason or another, the expectation seems to be that AIR is a lightweight technology, and it’s really not.

AIR HTML apps are leaky

What is particularly problematic is that there seem to be memory leaks within the Webkit engine as used in AIR – or at very least, it’s pretty easy to leak memory. Apps like Spaz run into this problem because it’s constantly pulling in large amounts of new data and images, and is often left running for hours or days on end.

Some of this is almost certainly because you can get away with that kind of thing on a web site, where users are unlikely to leave a single page open for days on end. Even if a web site does causes a big leakage, the browser almost always gets blamed. The libraries and tools available for HTML/JS devs, being browser-focused, typically don’t pay much attention to long-term performance issues.

Essential tools, like profilers and step debuggers, are non-existent

But memory leaks are a problem for most desktop app developers. That’s why memory profiling tools are common in desktop frameworks. And Adobe certainly understands this to be the case with Flex, as it’s FlexBuilder 3 IDE ships with memory and peformance profiling tools, as well as a full-featured debugger with breakpoints et al. That’s perfect if I was writing something in Flex, but it is completely useless for HTML/JavaScript AIR apps. I was able to get Spaz to run from within Flex Builder with a tiny bit of hackery, but the profiler gets no information about what’s going on within Webkit.

Other common choices for debugging web apps aren’t available either: Firebug is Mozilla-specifc, and the Drosera debugger and Web Inspector tools can’t hook into AIR’s Webkit instances. The information on Drosera does say:

In WebKit there is a WebScriptDebugServer which is started when WebKit starts and listens for a DCOM connection. Once a connection is made it will begin to interact with Drosera via Drosera’s ServerConnection class. WebScriptDebugServer informs Drosera about every line of JavaScript executed.

I would assume that WebScriptDebugServer exists inside AIR’s Webkit, but AFAIK this has not been utilized in any way. Adobe does have a nice AIR-specific tool called the AIR Introspector in the SDK, and it does offer some very useful functionality, but it too lacks step debugging and profiling capabilities.

That leaves us with good old console logging as our only option for debugging AIR HTML apps. That’s okay for simpler stuff, but tracking down execution bugs in more complex applications becomes extremely tedious. And console logging is basically useless for memory profiling, as there’s no insight into the underlying operations of Webkit.

I’m proud of the work I’ve done on Spaz, but as the application has grown in complexity, I’ve found the limitations of HTML app dev in AIR more and more problematic. Adobe has consistently stated that the HTML dev side of AIR is as important as the Flash/Flex side. To quote Mike Chambers:

Adobe AIR is as much about JavaScript, HTML, CSS, etc… as it is about Flash / Flex. #

If that truly is the case, Adobe needs to commit to providing a toolset for HTML/JS developers comparable to what Flex developers have. Until that’s changes, Mozilla’s XULRunner and Prism platforms are looking more and more appealing.

It’s been many months since I’ve posted about Spaz here, but I’ve actually still been working on it quite a bit. Spaz recently had its 1 year anniversary, which is a pretty good milestone for one of my projects – I usually lose interest well before this. Not only is Spaz one of the oldest Twitter desktop clients still under development, but it’s also one of the few FOSS clients. I also believe Spaz is one of the most sophisticated AIR HTML apps out there, and is a good example of what can be done with HTML and JavaScript on the desktop.

The newest release of Spaz, which came out a couple days ago, adds some significant new features:

• Image uploading via Twitpic.com
• Crossposting support via Ping.fm. Try beta code “vivalaping”
• Support for microblogging services with Twitter-compatible APIs, including Identi.ca
• A Dock icon badge with the unread message count. This is probably less significant if you are not running OS X.

You can read the whole fat list of what’s new. Also, if you want to talk to other users or help with development, here are some resources:

• Spaziki – The Spaz Wiki and FAQ
• Spaz-users Google Group
• Spaz-SVN Google Group
• IRC: #spaz on irc.freenode.net

I have these five promo codes from Dreamhost. They expire in three days. Apparently you get super-hot deals with them, like:

• Four times the normal disk and bandwidth
• $150 off a 5-year plan
• $200 off a 10-year plan

I would not sign up for 5 years with any shared host. However, I do think DH is pretty decent for small-ish sites that can work with shared hosting. I’m well aware that they’ve had a couple embarrassing public flubs in the past couple years, but I generally think they’re good folks who try to do right by their customers. Some will certainly disagree, of course. 8)

I still maintain my old account there for low-cpu, high-bandwidth/storage stuff. They do quite well with PHP hosting, and can handle Ruby and Python setups with a little effort. They’ll let you do crazy stuff like compile your own PHP if you are fine with using FastCGI, and have a nice GUI to setup SVN repos. Not many shared hosts will do the same at a similar price point.

Anyway, here are the codes. They’re first come, first serve. Yes, I make money if you sign up with one of them. I will not be hurt if you don’t use them.

• 998942362256
• 916860787004
• 591140700044
• 047271781406
• 160643597831

Dreamhost Signup Page

I’ve been working at Purdue for over 6 years now, and I have to say that I’ve enjoyed it immensely. While the experience can vary from department to department, in general it’s a fairly low-pressure environment with a lot of opportunities to learn and develop new skills for motivated folks. Purdue offers great benefits, and the Greater Lafayette area is a pretty cool, decently progressive environment considering the size – US News & World Report recently picked West Lafayette one of the “Best Places to Retire” in the US.

A job just opened up in the Math department for a “Web Programmer/Analyst”. This position calls for strong PHP, PostgreSQL and MySQL skills; Linux and Unix fu (you should be able to admin the web stack); good communication skills (you’ll be working with a number of different people with varying tech backgrounds); and plenty of independent motivation.

I’m not involved in the hiring process at all, but I’m friends with those who are, so if you have specific questions, I can route them to the right person. Please email me directly – do not post questions in the comments.

• Web Programmer/Analyst - West Lafayette - Mathematics