It’s been an amazing 3.5 years, but all incredible, life-and-career-changing experiences must eventually come to an end. This week I’ll be leaving my role as Senior Engineer at Appcelerator and moving on to Innovu, a new startup in my hometown of Pittsburgh.

Callbacks are a necessity when developing an asynchronous API in node.js. No, really, I promise. To that end, here’s a little trick I originally spotted in the node.js source code. When creating a function that will require a callback, but has a flexible invocation signature, I always use the maybeCallback() function.

1
2
3
4
5
6
7
8

// you can use lodash or underscore for this
var isFunction = function(o) {
  return Object.prototype.toString.call(o) === '[object Function]';
}

function maybeCallback(callback) {
  return isFunction(callback) ? callback : function(err) { throw err; }
}

For the last few months I’ve deviated from my usual Alloy duties at Appcelerator. I’ve instead been working on an internal project with Dawson Toth, Simon Murtha Smith, and Jeff Haynie (since he so quickly gets bored of being CEO). We’ve had a few names for it so far, but for the sake of this post I’ll refer to it as API Builder.

In short, it bridges the gap between app and API development, taking the functional links of the Appcelerator Platform and turning them into a powerful, cohesive chain. The following screencast is a (very early) preview where I’ll show you the following:

• Creating an API against arbitrary data source(s)
• Publishing that API to node.acs
• Creating a secure, API-specific SDK for Titanium
• Downloading and installing that SDK via Appcelerator Studio
• Using that SDK to make API calls to the published node.acs endpoints

All of that done automatically, simply by defining your API in the Appcelerator 360 dashboard. Way more to come, not publicly available yet, so stay tuned.

should.js is my assertion library of choice when unit testing my node.js and Titanium projects, for a few reasons:

1. Works flawlessly with mocha. Not a surprise since they have the same author.
2. Works in node.js, browser, and Titanium.
3. Extremely readable and expressive.
4. Extendable to be even better at #3, if you know how.

Resolving bug reports is like trying to rescue developers lost on a desert island. Sometimes you get the privilege of rescuing the developer who started a signal fire you couldn’t possible miss, kindled by reproducible test cases and detailed specifics of their environment. They make the rescue easy and still thank you profusely for the aid. In the end, everyone involved is happy. But this isn’t always the case…

If you follow me on twitter, my current love affair with task management via the node.js module grunt is no secret. Long story short, it is a deliciously simple way to automate development tasks, with a multitude of those tasks (like linting, minification, file watching, etc…) already done for you. I could babble on about it here, but I think a tweet of mine best encapsulates my experience with it.

The Appcelerator community has long been asking for a clear choice for unit testing. While many (including myself) have used Jasmine, I have over time gained preference for another. Mocha has quickly become my unit testing framework of choice for all node.js development, due to its stability, flexibility, and the consistently awesome work of its author, TJ Holowaychuk. There was one small problem.

Get the source: Automata on Github

Every once in a while I like to engage in some wildly impractical coding experiments. You know the sort, the “Hey, I got Gentoo running on my toaster!” stuff. Today’s experiement was implementing Conway’s Game of Life using nothing more than Appcelerator Titanium views and deploying it to iOS. Let me explain a bit more why this is a ridiculous idea…

Get the full demo: jsstl on Github

Recently Github announced that they were integrating a web-based STL viewer into their interface. The STL file format has become very well known as of late do to the growing popularity of 3D printing among makers. STL is the format of choice for most 3D printing devices and is as such the format used by almost all accompanying software. So whether you want to print, manage STL files, or convert them to some other format, you need to get to know them well.

One aspect of my current project, the Alloy MVC framework for building cross-platform mobile apps, is simple integration with local storage via SQLite databases. SQLite is a powerful and relatively simple way to store data for offline use, or just to cache remote data to speed up interactions. Unfortunately, the current data and structure of SQLite databases can sometimes be tricky to ascertain when housed on mobile devices, emulators, and simulators. This is especially true when developing for multiple platforms and having gone through multiple iterations of your data structure.