My résumé is online. Full up-to-date and current. Finally. And although I’m not looking for a new job (I love working at Fingerprint!), I’ve been meaning to update my résumé and get it online for quite a while now.

My portfolio is online. A visual timeline of my work over the years — complete with screenshots!

Arrow Functions in JavaScript

The ECMAScript 2015 (ES6) standard introduced “arrow functions” to JavaScript, which on the surface looks like syntactic sugar over JavaScript functions, but have some subtle—but useful—differences.

First and foremost, you can use arrow functions anywhere you would use an anonymous function. For instance, in a timeout:

setTimeout(function() {
  console.log('Timeout reached')
}, 500)

In ES2015, the above can be written as:

setTimeout(() => {
    console.log('Timeout reached')
}, 500)

NOTE: In the above examples, we have no parameters (), but if we had only one parameter, we could leave off the parenthesis and that would still be valid. With arrow functions, zero or more than one parameter requires parenthesis.

Inherited Context

So we reduced the first example by five characters, and while that’s a welcome enough change when you’re working in JavaScript all day, that’s not the only benefit you gain from using arrow functions. Before I get into what those are, what do you think the following example prints out?

function myFunc() {
  setTimeout(function() {
    console.log('My name is: ' +
  }, 500)
}{ name: 'Jonathan' })

// My name is undefined

“My name is: undefined” is probably not what the code had intended to output, but that’s what happened. To get the function that is passed to setTimeout() to inherit its parent’s context (e.g. this), you need to bind that function to the context:

function myFunc() {
  setTimeout((function() {
    console.log('My name is: ' +
  }).bind(this), 500)
}{ name: 'Jonathan' })

// My name is Jonathan

The difference may be hard to spot, but it’s there. This time we pass a bound function to setTimeout() instead, which entails wrapping the function in parenthesis and calling bind(this). With arrow functions, none of that is necessary because they automatically inherit the surrounding context (this of its parent scope):

function myFunc() {
  setTimeout(() => {
    console.log('My name is: ' +
  }, 500)
}{ name: 'Jonathan' })

// My name is Jonathan

Not only is that less typing than the bound function example, it’s also more intuitive, which ultimately translates into less bugs. In fact, with arrow functions, you should rarely (if ever) need to use bind(this) ever again. As another example, a common scenario is to pass a bound function as a listener:

myObj.on('click', this.handleClick.bind(this))

You can use an arrow function instead to make the code more natural:

myObj.on('click', event => this.handleClick(event))

In the above example, we are actually passing the listener as an arrow function and all it is doing is forwarding the parameter (event) to the real handler function (this.handleClick()). In this case, arrow functions do not decrease the lines of code, however, by being explicit about the arguments we pass to the function, the code is more “honest” and thus more clear.

Implicit Return

Another subtle difference in behavior is that arrow functions can have an implicit return when written as an expression (no curly braces, which would be a block): => x * 2)

Is the same as… {
  return x * 2;

This particular feature is “syntactic sugar” that makes your code more compact by allowing the omission of the return statement, a bit like CoffeeScript and Ruby, but not exactly because this only works in cases where the only thing in the function body is the return statement. Personally, I think that was a good decision because allowing implicit returns with other logic would just make code more unreadable in my opinion.

And that’s about it! While not much, it turns out arrow functions provide a little more than just simple syntactic sugar. The subtle changes in behavior are welcome additions to JavaScript, and contribute to a more pleasant coding experience overall.

Digging Through the Archives

This website started life as a Tumblr blog ( way back in 2010 before I finally registered a domain name for it ( Since then, my life has changed immensely, and so has this website. I’ve reset it and reboot it more times than I can count. Recently, I started posting entries to this site once again. This time, however, I decided to take a different approach.

Rather than blowing everything away and starting new, I thought I would attempt to scour the internet for all traces of past incarnations of this website and restore the archives. Thanks to the Wayback Machine, I was able to restore most of all my previous entries. I also discovered that I had written a lot more over the years than I realized.

Unfortunately, there were several entries that are lost forever due to not being able to find any cached copies anywhere, but I was able to get most of them because there were more snapshots during the times I was more active on this website.

Overall it was a very nostalgic experience for me, and sometimes a little sad, particularly remembering the great experiences we’ve had with Carlos Icaza (my mentor who had passed away last year). For each entry, I could remember the snapshot in time when that entry was written. It really highlighted just how much my life has improved since 2010, and how exciting it has been over these years.

During the process, I tried to fix any links that were broken (or redirect to a cached version if it was available) and add notes wherever necessary. It was a lot of work, but I’m glad I was able to preserve most of the website’s past.

Here’s to no more huge gaps in the archives!


Today I published a new package on npm: xcfg.

It’s a cross-platform config file management package that’s fairly simple, but pretty useful for those who write Node.js applications such as command-line utilities or desktop software in the form of Electron apps.

Since all the details of the project are on the package page, this entry will just cover the technology I used to create it.

JavaScript (ES2015)

First and foremost, this is a JavaScript package for the Node.js ecosystem, written using the ECMAScript 2015 standard. I had explored Python 3 recently, but ultimately decided to move forward with the Node.js ecosystem. I was momentarily torn between the two, because I think Python 3 is a fantastic language. However, I’m vastly more comfortable in JavaScript, and I’m a big fan of Node’s package manager (npm). Conversely, I really don’t like Python’s distribution story. In fact, I think it’s a nightmare compared to the npm experience.

Case in point: I started writing xcfg yesterday evening and finished up the remaining tests and documentation this evening before finally pushing the project onto GitHub and running npm publish. It’s a small package, so that’s obviously why I was able to finish it in such a short amount of time, but the process of setting up a package.json and publishing to the npm registry was an absolute breeze. Publishing added only a very minimal amount of time and effort on top of coding, writing documentation, and adding unit tests.

Documentation and Testing

As far as documentation goes, I put some basic usage info in the project’s README and used ESDoc for the API docs. ESDoc looks great by default and has a familiar set of tags so it wasn’t difficult to use, despite never having used it previously. The only problem is, out of the box, it doesn’t work for Node.js projects but that was easily fixable with the esdoc-node development package.

For the unit tests, I used a combination of Mocha and Chai and at version 1.0.1, there are 10 unit tests (all passing, of course). I thought Mocha was pretty good but I may explore other assert libraries for my next project because Chai has a strange API and was a little annoying to validate with my chosen style guide, which brings me to my chosen…

JavaScript Style Guide

I personally believe it’s important for a project to follow a style guide. Not only does it make it easier for multiple people to work together on a single codebase, the consistency that a style guide enforces really helps improve programming discipline and ultimately results in less bugs in the final product. Given JavaScript’s dynamic nature, following (and linting with) a style guide is a great—if not essential—way to prevent a whole class of (stupid) bugs.

I recently discovered the JavaScript Standard Style and chose to follow it for xcfg. The project has it as a development dependency and can be linted with a simple npm command: npm run lint. I found that I agreed with all of its rules, even the more controversial decision to disallow extraneous (in other words, most) semicolons.

And that concludes my technical overview of xcfg 1.0.1. If you find any value in this package, please take a moment to star the GitHub repo.

Python for JavaScript Developers. Published in November of last year by Mario Pabon. Very useful for experienced JavaScript developers who are trying to get up to speed with Python 3 quickly.

Array.prototype.splice() in Python

I’ve been digging into Python 3 lately, and so far I’m really liking it. One of the things I miss coming from JavaScript, however, is Array.prototype.splice(). Although Python’s list (and string) slicing syntax is really convenient, things seemed to get unnecessarily complicated when I wanted to insert and remove items at an arbitrary position within a list. The simple one-liner I was used to in JavaScript became a multi-line affair in Python.

Given the breadth of Python’s standard library, I was surprised I couldn’t find the same functionality buried somewhere. And while it’s possible it’s there and I just haven’t looked hard enough, I thought it might be fun to port over JavaScript’s implementation anyway.

Here it is (also available as a Gist):

def list_splice(target, start, delete_count=None, *items):
    """Remove existing elements and/or add new elements to a list.

    target        the target list (will be changed)
    start         index of starting position
    delete_count  number of items to remove (default: len(target) - start)
    *items        items to insert at start index

    Returns a new list of removed items (or an empty list)
    if delete_count == None:
        delete_count = len(target) - start

    # store removed range in a separate list and replace with *items
    total = start + delete_count
    removed = target[start:total]
    target[start:total] = items

    return removed

I tried to be as close to the JavaScript implementation’s behavior as possible (and as in JavaScript, the target list is mutated). Here’s an example:

arr = ['a', 'b', 'c', 'd', 'e', 'f']
removed = list_splice(arr, 2, 3, 'x', 'y', 'z')
print("modified:", arr)
print("removed:", removed)


modified: ['a', 'b', 'x', 'y', 'z', 'f']
removed: ['c', 'd', 'e']

BBEdit Light theme for Sublime Text

Despite moving “Back to BBEdit” back in 2014, I’ve since had to move back to Sublime Text 3. Something I really missed though, was the default color scheme that shipped with BBEdit 11.

While I did find some ports of the older default BBEdit color scheme, I couldn’t find the easier-on-the-eyes version that came with 11 as a tmTheme, so I was forced to port it over myself.

BBEdit Light for Sublime Text

To install, copy BBEdit-Light.tmTheme to ~/Library/Application Support/Sublime Text 3/Packages/User/ and restart Sublime Text. It’ll then be available in the Sublime Text > Preferences > Color Scheme > User menu.

Plain Text Notes

After bouncing between various note-keeping apps, I finally settled on a very simple solution that is flexible, cross-platform, freely available, and will surely stand the test of time: plain text.

Journal entries. Recipes. Work log. Grocery lists. Things I need to quickly pull up on my phone when I’m on the go. Ideas for gifts I want to buy my wife and kids. Anything, and everything. Digital notes have been an absolutely essential part of my personal and professional life. What I use to manage the notes essentially serves as my secondary brain.

Without putting a lot of thought into it initially, I started out using the stock Notes app on iOS and the OS X, which worked until I took a detour into the land of Linux and it suddenly became annoyingly painful to access my notes. In my frustration, I began thinking about my mobile needs. If I were to move away from iOS in the future, even if temporarily (be it Android or something else), what would I do then? I often need to access my notes when I’m on the go, so this was a big concern.

It was clear that I needed a cross-platform solution that could withstand my (admittedly erratic) computing habits over time. I don’t think vendor lock-in is an acceptable option for me.



Evernote was the first contender, but I ultimately decided against it because, like Apple Notes, it stores notes as Rich Text. I really dislike WYSIWYG editing, and that is the bread and butter of Evernote. Not necessarily a bad thing, but not for me. I’ll admit that being able to embed media and adding attachments to notes is really nice though.


Simplenote was next in line, and I almost went with it as it was very similar to what Apple offers, but notes are plain text and the service is cross-platform due to being web-based. However, there were some concerns that kept me at bay.

3rd-party app selection. I don’t like being tied to the web app and wasn’t completely happy with the available 3rd party clients (I did like the first-party iOS app, however). There is a script that can be used to sync notes to a local folder, but I didn’t really want to have to go through that, and more importantly, I wasn’t confident enough that the script wouldn’t wipe my notes on accident, or be maintained long enough to withstand any API changes that Simplenote might introduce in the future.

Limited ways to organize my notes. I really want better organization for my notes, such as a “Work” folder for work-related notes, a “Journal” folder for journal entries, and so on. I know I could use tags instead of folders, but that leads me to my next point…

Is it future-proof? What happens if Simplenote shuts down before I no longer need to keep notes (in other words, before I die)? Simplenote does have an export option, but it gives each note a crazy, random filename and the tags don’t seem to be preserved (there goes any work I put into tag-based organization).

Evernote is pretty great about allowing you to organize notes into separate “Notebooks”, and I’m sure there are other services that do something similar, but the other two points mentioned could easily apply to just about any app or service.

The thought of relying on my chosen note-keeping to outlive me makes me a little uncomfortable, so the only remaining option seemed to be manually handling the notes myself via locally saved, old-fashioned plain text.

The Setup

All of my notes live in a single, top-level folder on my computer’s hard drive. I have sub-directories for Work, Personal, Journal, Projects, Media and Attachments. The notes themselves are just plain text files, saved as Markdown.

Sync and backup

Since I need to be able to access my notes from multiple devices (my laptop, desktop, and phone), syncing is a huge requirement for me. I already use Dropbox, so my top-level “Notes” folder lives in my Dropbox folder. Any changes I make to notes are automatically synced (and backed-up online).

If Dropbox ever goes away, or I want to stop using it, I can just turn my notes folder into a Git or Mercurial repository and host it privately on GitHub or Bitbucket. I’m tempted to go this route now for the ability to track changes and revert notes to an older state (if necessary), but what’s holding me back from this approach is mobile. While there are many great mobile apps for viewing and editing Markdown files in a Dropbox folder, I haven’t yet found the same for a hosted repository.

Editing and viewing

This is where “everything as plain text” really shines. I spend most of my day in a text editor (BBEdit), so it’s just comfortable for me to edit my notes in the same app. BBEdit also has a nice Projects feature, so all I need to do is open Notes.bbprojectd and all my notes are there, nicely organized in the sidebar. I can now take advantage of BBEdit’s robust search capabilities for all of my notes, which is a huge plus.

As far as mobile goes, all I needed was a text editor that could link to Dropbox. I’m pretty happy with iA Writer, but there are other options as well (some of which are free). My requirements for mobile aren’t that extensive, however, as I rarely do any significant editing of notes on my phone, but I often need to view them.

Media and attachments

This is one of the big selling points of Evernote, and is surprisingly easy to duplicate with my current setup. In my top-level folder, I have sub-folders for Media and Attachments. Since I save my notes as Markdown, I can easily embed images, videos, and links as I would when writing a blog post.

![My Image](../Media/2016-02-12-my-image.jpg)

In fact, if I really want to get fancy, I could turn my notes into a private Jekyll blog, but I digress (that’s probably overkill anyway). In any case, BBEdit has a Markdown previewer (as well as iA Writer), so I can just use the built-in viewers when I want to see embedded media and links.


All in all, this plain text setup has been working out really well for me, and I don’t feel like I’m missing out on any features by not going with a dedicated app or service. If you’re in search of a note-keeping service, or feel like a change, I recommend giving the plain text approach a shot!

Ignore the Noise

Whether you’re new to the JavaScript ecosystem or have some experience, unless you’re super-human, you’ll inevitably become overwhelmed at the sheer number of frameworks, libraries, build systems, preprocessors, template engines (the list goes on and on) that are available.

What’s worse, as you put a significant chunk of time into a certain stack, there will inevitably be other libraries, frameworks, and tools that gain more popularity than the ones you chose, and likely brand new projects that became the shiny new thing while you were busy getting things done. Before long, you start to feel like you’re suddenly becoming irrelevant.

Joe Gregorio argued in 2014 that we should abandon all frameworks in favor of plain HTML+CSS+JS in his zero framework manifesto:

I think it’s time to rethink the model of JS frameworks. There’s no need to invent yet another way to do something, just use HTML+CSS+JS.

The landscape has only gotten more cluttered since then, so I don’t think the web development community as a whole agrees, probably because that approach may not be practical for everyone and for every project. Still, I think it’s a good starting point. More on that later.

A couple of years ago, I invested quite a bit of time into Backbone.Marionette, and once I had some breathing room and took a step back, I saw that Angular was actually the cool kid on the block. I also used Less and Handlebars (for CSS preprocessing and HTML templating, respectively), although tons of shops prefer Sass and there are many other popular alternatives to Handlebars. It’s easy to feel like you’re not keeping up, and that your skills will soon become irrelevant if you’re not sprinting at top-speed, 24 hours a day. Unfortunately, no matter what you do, at least when it comes to web development, you’re going to be “behind” in one way or another.

All this to say: it doesn’t matter. Ignore the noise.

But that begs the question, how can you determine what path to choose when there’s this vast sea of choices out there? Fortunately, depending on your personal situation, there’s a way through this.

Your Own Projects

For personal projects where you have complete control over your technology stack, I recommend starting with just plain HTML+CSS+JS (which have standards that don’t become outdated very frequently), and only add libraries that fit your needs—as needed. In other words, let the requirements of your project determine its dependencies. If you do want to go with a full-blown framework, take a look at some of the more popular and stable options out there and just go with the one that matches you and your project best and proceed full steam ahead.

Don’t worry about falling behind. Just do some research, choose something, and move forward with with your decisions. The important thing to remember here is that you don’t need to be a pro at everything, or worry if you chose the best thing out there (that’ll change anyway, and probably next week). You’ll end up learning a ton about your chosen stack and that experience alone will be valuable.

I mentioned research, but it’s worth emphasizing. Last year, Jimmy Breck-Mckye wrote about the “State of JavaScript in 2015” and cited “framework churn” as a major problem. Angular, one of the most popular front-end JavaScript frameworks, was used as an example:

At the close of 2014, it’s difficult as a JavaScript developer to back a particular library or technology with confidence. Even the mighty Angular, which seemed set to establish itself as the One True Framework of Single Page Applications, looks destabilized by recent events.

I’m not in the Angular camp, at least not currently, so I have no comment on that in particular, but it’s an interesting perspective from someone who obviously was.

I personally tend to favor the “pick and choose small libraries to fit your needs” over the the “one size fits all” approach of monolithic frameworks, but your mileage (and requirements) may vary. If you do go the monolithic framework route, it’s worth making sure what you choose is actively maintained and has a healthy community around it—unless of course, you plan on maintaining it yourself, which is probably not likely.

Work Requirements

If you’re employed and your company has chosen the stack for you, then you already have your answer. If you don’t have a say-so, you don’t need to worry about drowning in choices because you won’t have one! Spend time learning and improving your skills in Marionette, Angular, React, Backbone or whatever it is your company uses. With your own time, you can choose to develop other skills or improve on your work-mandated ones.

On the other hand, if you’re in a position to have some say in these kinds of decisions, then tackle it as you would with your own projects. Research the actively developed, mature options out there and choose the frameworks and/or libraries that fit your project and team best, ignoring the others (no matter how new and shiny they are) until there’s a problem you can’t solve—or solve well—with the decisions you’ve made.

Developer for Hire

The more difficult scenario is if you’re trying to build up your skills in hopes of getting hired as a JavaScript engineer, and need to decide what the best course of action is to achieve your goal. Unless there’s a specific role you’re targeting, in which case what to learn should be a little more clear, I recommend starting your own open-source project, making it public, and stick with it through completion. When you’re done, you can always choose a different stack for your next project, swap out the pieces that didn’t work well for you, and go from there. Over time, you’ll gain some valuable experience and you’ll not only know enough to be relevant, you’ll be agile enough to adapt to any other stack that’s thrown your way by a future employer. Without a doubt, doing is the best way to learn anything, and that absolutely applies in this field.

Make a Choice

Today, as JavaScript developers, we are flooded with choice. Fortunately, if you can block out the excessive noise and commit to making some decisions, you’ll find that having an abundance of choices can actually be a benefit: there is something for just about anyone, and any project you can think of. The worst choice you can make is no choice at all, allowing decision paralysis to prevent you from getting any meaningful work done out of fear you’ll make the wrong choices and waste a bunch of time.

Don’t fall into that trap. Make decisions. Stick with them. Adapt as needed. Keep moving forward. That is how to stay relevant as a JavaScript developer in today’s tumultuous environment.

iPads: The Bad, The Good And The Takeaway. Very insightful analysis by John Kirk. This line in particular was an eye-opener:

If the iPad were its own company it would be larger than Facebook, Twitter, Yahoo, Groupon, and Tesla combined.

Back to BBEdit

It doesn’t suck.®

BBEdit originally debuted on Macintosh System Software 6, and while it may have been surpassed—feature-wise—by other text editors in recent years, it’s actually one of the only OS X text editors that can meet the following criteria (and meet it well):

  1. Truly native Mac software; feels “at home” visually and works as you would expect a Mac app to work. In other words, it’s very “Mac-like”.
  2. Has a history that can provide assurance that it’ll most likely be sticking around and actively developed for many more years to come.
  3. It is fast.

We’re getting to a time where text editor speed is almost taken for granted, but point 1 is often difficult to meet because of cross-platform requirements, and unless your vim or Emacs, there’s really no competing with BBEdit’s history. Bare Bones as a company is up there with The Omni Group and Panic as far as the respect it has among Mac software enthusiasts.

Sublime Text is blazing fast, but it has a somewhat spotty development history and correct me if I’m wrong, it looks like it’s created and maintained by a sole developer (Jon Skinner). Out of the box, as a Mac app, it’s ugly as sin. You can customize it to look better, but that doesn’t make everything else about it any more “Mac-like”. Really the one true thing I love about Sublime Text is the way it does multi-word selection via CMD+D, and that’s by no means a deal-breaker.

Chocolat definitely hits points 1 and 3. Visually, it looks very nice, and while I’ve seen some users complain of its speed with some text files, it’s fast enough on my machine and for my particular usage (I’m not editing any megabyte-or-larger sized text files). It doesn’t currently have anything that makes me want to use it over BBEdit, however.

Why I’m switching at all

I’m a developer, so I’m obviously switching “back” to BBEdit from something. Well in my case, it’s two somethings. I’m a web developer by day (Backbone + Marionette) and my company’s workflow is heavily dependent on IntelliJ IDEA (lots of servlets and such). On my “own” time, I still do lot of contracting work developing Corona apps, and for that I’ve been using Sublime Text (version 3 beta).

I want to change things for the following reasons:

  1. IntelliJ can be dog slow on my machine. I use it for web development with a late-2012 Mac mini. It has a 2.3 GHz Intel Core i7 with 16 GB of DDR3 RAM and a 250 GB solid-state drive, so there’s no reason why my development environment should ever feel like it’s crawling. It does. Often. I even limit my number of open editor tabs to 10, and I followed all the optimization tips I could find. I want to use something faster than IntelliJ, period.

  2. As previously mentioned, Sublime Text is fast. Really fast. But it’s only used for some of my work. It’s also jarring to have to switch between using two different editors. I want one programming environment to rule them all (even if I’m still bound to IntelliJ in some ways, more on that later).

  3. I love BBEdit, and I miss it. I’ve been dying for a reason to dust off my license and make it my full-time text editor again. I used TextWrangler for a while back in 2010 to do all of my work at Ansca and then I purchased a BBEdit license when version 10 launched. I continued to use BBEdit for a while until I started working at Lanica, where we used Titanium Studio (Eclipse rebranded—yuck) and I eventually jumped onto the Sublime Text bandwagon based on recommendations from some colleagues. I began using it and got very used to it, but I never loved it.

So dust off my BBEdit 10 license I did, and I’m now using it as my full-time editor for all things programming (and writing for that matter, this blog post was happily written in BBEdit). How did I do it?

Replacing IntelliJ with BBEdit

I have to use IntelliJ because of there are servlets combined with a Tomcat Run/Debug configuration we use at my company that are required for me to do my work. Once those are running, however, 100% of what I’m doing in IntelliJ is editing text. Why can’t I use an external text editor of my choice and just have IntelliJ do it’s thing separately without me needing to be in it to do my actual work?

There’s a big problem I ran into with this approach, however. If a file is modified outside of IntelliJ, it being a Java app (not a native Mac app), you have to click “Synchronize” on the toolbar (or CMD+OPT+Y) for it to pick up the changes (which it needs in order for the servlets to serve the proper stuff). I refuse to do that.

Every time I have a change I need to test in the browser, the last thing I want to do is click the IntelliJ window and “synchronize” before clicking away again into the web browser. It’s bad enough I already have to do that whenever I pull in changes from SourceTree (my Mercurial client of choice). My goal is to make my development environment more pleasant, not less.

Then, I remembered BBEdit’s excellent AppleScript support. There’s even an AppleScript menu, and you can assign hotkeys to individual scripts. Perfect. The only problem is, I don’t know AppleScript. Fortunately, a lot of folks on the internet do, so after some Googling, I was able to shamble together a script that does the following:

  • Activate IntelliJ and invoke the keyboard shortcut to “synchronize” files.
  • Put BBEdit back in front of IntelliJ, for easier access when I need to go back to programming.
  • Launch and/or activate Google Chrome

So now I can do my programming in BBEdit, and when I’m ready to test my changes, I can simply invoke a keyboard shortcut that will synchronize the files in IntelliJ, and Google Chrome is activated (thus updating assets and resources due to “frame deactivation”). I’m all set.

Here’s the AppleScript (bound to CMD+OPTION+Y, same as IntelliJ synchronize):

-- Store reference to BBEdit in a variable, for later activation
set currentApp to path to frontmost application

activate application "IntelliJ"
tell application "System Events"
    delay 0.1

    -- Invoke IntelliJ's keyboard shortcut for "synchronize"
    keystroke "y" using {option down, command down}
end tell

-- Give IntelliJ a couple of seconds to refresh files
delay 2

-- Put BBEdit back in front of IntelliJ
activate currentApp
delay 0.5

-- Launch and/or activate Google Chrome
tell application "Google Chrome"
    if it is running then
        open application "Google Chrome"
    end if
end tell

So with minimal fuss (an added keyboard shortcut to my workflow), I get to use a (much faster) text editor I’m very comfortable with. Reasonable trade-off.

Replacing Sublime Text with BBEdit

So that takes care of my IntelliJ workflow. What about my work that I use Sublime for? That one’s an even easier AppleScript. I just need it to launch/activate the Corona Simulator (also bound to a keyboard shortcut):

activate application "Corona Simulator"
tell application "System Events"
    -- Relaunch the Corona Simulator
    keystroke "r" using command down
end tell

And that’s it. Just two AppleScripts and my workflow completely lends itself to BBEdit.

Favorite Features

Here are some of my favorite things about BBEdit (and yes, I’m well aware Sublime either has all of the following, or has a package that can do it, but I much prefer the BBEdit approach in overlapping features):

  • This is one of the few text editors that has a default syntax color scheme I actually like (good thing too, because BBEdit’s online color scheme selection is admittedly pretty weak).
  • Awesome searching capabilities.
  • Cmd + R symbol search, just like Sublime (meaning I don’t have to get used to a different keyboard shortcut). I think this must have been added fairly recently (I’m using version 10.5.13 currently), because I don’t remember this being available last time I used BBEdit around the time version 10.0 was released.
  • Projects are easy to create and re-open.
  • The AppleScript menu + custom key bindings to individual scripts.
  • Very well-presented Preferences pane. No more editing a JSON file (Sublime), and no more dealing with IntelliJ’s horrendous implementation.
  • Scratchpad. I used to have to open a TextEdit window when I needed this functionality. Now it’s built-in.
  • Clippings.


I’m pretty happy with BBEdit, but of course it doesn’t have everything I could possibly hope for. I plan on submitting the following items as feature requests to Bare Bones, and if I’m lucky, maybe one (or more?) will be included in a future update:

  • Per-project AppleScripts with their own keyboard shortcuts. Remember the AppleScripts I mentioned earlier? It would be nice to assign them both to the same keyboard shortcut, and have the correct script run depending on the project I’m currently working in.
  • Multiple selection/cursors implemented exactly as Sublime Text does it.
  • Git and Mercurial as first-class citizens, on par with BBEdit’s Subversion features (which I currently have no use for).

And that’s really it. BBEdit is almost perfect for my needs, and I plan on sticking with it for the long haul. If you’re in the same boat as me and want to switch to BBEdit but are tied to other tools, see if an AppleScript can’t do most of the heavy lifting for you.

Things 2.5 released. My favorite task management app for Mac (and iOS) just got updated to support OS X 10.10 Yosemite. The visual changes mirror that of Yosemite’s: refreshing but still familiar.

I haven’t got used to using Notification Center Widgets regularly yet, but the new “Today” widget in Things may be just what I need to get started.

Siracusa Reviews OS X 10.10 Yosemite. For some, John Siracusa’s OS X reviews are almost as anticipated as the OS release itself. Myself included.

His conclusion sums up all twenty-five pages well:

The Mac today is just one part of a conceptually, organizationally, and (increasingly) technologically unified platform that spans from wrist to workstation. The hardware-based platforms of the past remain relevant to developers, but Apple seems determined to make them much less important to its customers. With Yosemite, the Mac has taken its first step into a larger world.

Josh Ginter Reviews the iPhone 6 Plus. Posted yesterday on the newly redesigned Tools and Toys website:

Apple’s newest iPhones are a story of tradeoffs for the first time in their history. Gone are the days of true corner-to-corner one handed use. Say goodbye to not noticing your iPhone in your front pocket, or even carrying your iPhone in your front pocket.

I just received my iPhone 6 Plus yesterday (finally!), so my review will be posted once I’ve had enough time with it.

Mac App Store: The Subtle Exodus. Milen Dzhumerov:

The Mac App Store can be so much better, it can sustain businesses and foster an ecosystem that values and rewards innovation and high quality software. But if you talk to developers behind the scenes or explore the Mac App Store, you’ll find something completely different.

Windows X

I’m not a Windows user myself, and haven’t been for almost six years now, but I was forced to use it for the first part of my computer-using life so I still enjoy following new releases. This next one brings Windows and OS X closer together than every before, and I’m not talking about just the version number.

Top New Feature

On September 30, Microsoft unveiled the next installment of their operating system, Windows 10, and consistently at-or-near the top of every related news article is this revolutionary new thing called the Start Menu. Suddenly I’m having a really strong case of déjà vu.

Sarcasm aside, Windows 95—the OS where the Start Menu really was a new feature—is the first operating system I really got to know, and one of the things I actually liked about the Start Menu was how concise it was. Does anyone else out there think the Windows 10 Start Menu is a little… bloated? I know I would if I was still a Windows user, but then again, maybe I wouldn’t if the previous major version’s replacement for the Start Menu (the Start Screen) actually took up the entire screen.

Putting the X in 10

Operating systems have an (understandable) history of “borrowing” features from one another. Over the years OS X borrowed features from Windows and vice-versa, but as I read about new Windows 10 features, as an OS X user I couldn’t help but notice quite a bit of familiarity:

  • Start Menu tiles. These are actually taken from the Windows 8 Start Screen, not a “borrowed” feature from OS X, but I’m reminded of Notification Center widgets in the soon to be released OS X Yosemite.

  • Task View looks hands-down like a Windows port of Mission Control, a feature I’ve become pretty fond of on my Mac.

  • Virtual desktops. I first experienced these while dabbling with Linux, and was glad they were available OS X when I first made the switch from Windows six years ago. Not everyone uses these, but if you do, you can’t live without it.

  • Command prompt improvements seem to be inspired by the Unix Terminal.

  • Continuum seems to be the Windows version of Continuity for OS X (Yosemite), and even have a similar name. Both are a little different in that the former is for hybrid devices and the latter for sharing an experience across multiple devices (since there are no “hybrid” Macs), but both are about adapting the user experience to match the form factor you are using right now.

Of course, Yosemite and Windows 10 were—for the most part—developed in parallel, so any shared features across these releases are likely coincidence, not inspiration.

Floating Apps

One major Windows 10 feature that has no OS X equivalent is the ability to float Metro… I mean Modern, no, Universal (!) apps over the desktop (as opposed to requiring them to run full-screen as in Windows 8).

This is definitely an improvement over having mandatory full-screen apps, but it seems like a bandaid for a much deeper design flaw. If these Modern apps are floating on the desktop, what’s the difference—from a user perspective—between these apps and any other apps. Why is there a distinction at all?

Of course, modern apps look different and are optimized for touch, but now you have touch-optimized apps all over the desktop. It’s not as awkward as having full-screen apps on a 27” monitor, but it still feels like two worlds colliding, even if the impact has been blunted. Native apps on the desktop shouldn’t feel like virtual machine instances.

Imagine how strange it would be to have iOS apps, as-is, running on OS X. As cool as that may seem to some, it introduces a lot of inconsistency into the UI and makes things more complicated for both users and developers. I’ve dabbled with Linux here and there over the years, and one of the things that made me cringe were all the UI inconsistencies between apps that used different UI frameworks, even more-so than running an iOS 6 (or lower) app in iOS 7/8.

Perhaps this is a case where Microsoft really should have taken a page from Apple’s playbook and require desktop apps to use desktop APIs (and thus have the desktop-mode look and feel), and add a “fullscreen” button to the title bar that maximizes the app into the full-screen Modern version. I’ve seen OS X apps that update the UI into a more iOS-style interface upon going into full-screen, and returning to the Mac paradigm when exiting full-screen mode. It seems to work well.

At the very least, Microsoft could do a Yosemite-scale UI overhaul of the desktop interface to at least make it match the modern look and feel, similar to the mockups Joseph Machalani posted in December 2013, which would be the more practical solution since they are already committed to the floating apps feature. At least every app, whether Modern or Oldie, would still feel like a “Windows” app.

Anyway, with all that out of my system, let’s see what history has to say about this next release of Windows…

The Star Trek Theory

I remember reading an article before Windows 8 launched that pointed out a trend where every other version of Windows since Windows 3.1x was good, while the in-between releases “sucked” (much like Star Trek movies).

I tracked down said article, titled “Why it’s likely Windows 8 Will Suck” posted on March 1, 2012 by Chris Keener, and I’m glad I did:

What I have seen is that, starting from about Windows 3.1x, every other Windows release has sucked (I’m also discounting the server and business releases). So, lets review:

  • Windows 3.1x (1992) - Good
  • Windows 95 (1995) - Mixed bag, at the beginning it sucked
  • Windows 98 (1998) - Good
  • Windows ME (2000) - Sucked (hard)
  • Windows XP (2001) - Good
  • Windows Vista (2006) - Sucked although not as hard as ME
  • Windows 7 (2009) - Good
  • Windows 8 (2012?) - ???

So, it seems fairly obvious that every other release of Windows has in fact sucked, but why has it sucked?

Keener goes into all a lot of explanation, positing that the every other release is intentionally crippled by Microsoft (more on that in a moment) before making his predictions:

So, based on the history we’ve seen, I’m making two predictions:

  • Windows 8 is going to suck.
  • We’ll see Windows 9 (or whatever they’re going to call it) released sometime in the next 3 years and it will fix nearly every problem in Windows 8.

Windows 8 would definitely meet the author’s “sucked” criteria, so… he pretty much nailed it. Windows 10 hasn’t been officially released yet, but based on what we know about the developer preview, it’s obvious that one of its primary goals is to “fix nearly every problem in Windows 8”.

I don’t buy into the conspiracy theory of Microsoft purposefully crippling every other release, however. As a developer, I know that the likely scenario is that it’s much easier to fix, or rather fine-tune something that’s flawed than it is to get it right the first time. It’s not a whole lot different than OS X Snow Leopard’s ZERO new features… feature, except Windows 10 actually does have a lot of new things in addition to dealing with gripes people had with Windows 8.

All in all, Windows 10 looks like it’s going to be a solid update. If you ask me though, I think what Windows users really need is a new Recycle Bin icon.

The Empire Reboots. Speaking of rebooting, I came across this long article from Vanity Fair that details a lot of interesting Microsoft history, specifically events surrounding Bill Gates, Steve Ballmer, and the drama that occurred before Balmer stepped down as CEO last year before delving into Satya Nadella’s new era in Redmond.

Starting an Open Source Project that People Use. Great advice from Barry Clark for anyone developing an open source project. As he puts it:

Starting an open source project is a great way to build your web developer portfolio while creating something for everyone’s benefit.


For the past year, maybe more, I’ve pretty much neglected all of my web properties. I had a Tumblr blog a few years back where I used to post reviews, the occasional opinion, and Corona SDK-related code snippets, tutorials, news, etc.

The Tumblr blog was actually gaining quite a bit of traction before I was hired by Ansca (now known as Corona Labs), in which my work there took priority and the type of content I would post to my blog was being published on the company blog anyway[1], so there was little time or motivation for me to continue. Over the years I registered a couple of domain names and tried to start writing again but it never quite caught on for me.

Things are different now, however. I’m in a professionally stable position (I’ve long since left Corona Labs). My personal life is great. And I really, really miss writing and sharing stuff on the web. Therefore, I decided to make a clean break with the past and delete my previous website hosted at this domain, redirect my other domain to this blog, and set the stage for a writing environment that motivates me to turn this web property into a place that is informative, somewhat educational, and at the very least, entertaining for those interested in the same topics as myself.

A long time ago I learned that maintaining a blog, while at times fun and rewarding, is very difficult to do consistently over time, especially with personal and professional responsibilities taking up much of my time. Therefore, in order to “set the stage” properly and position myself to continue writing over the long-term, I came up with five major things need to be in place before I can begin:

  1. Choose the right publishing platform
  2. Implement a design I’m pleased with
  3. Reduce costs as much as possible
  4. Have a frictionless publishing workflow
  5. Redefine success

Publishing platform

No more Tumblr. No more Svbtle. No more WordPress. Don’t get me wrong, there’s nothing wrong with any of them, but I don’t want to be put in the position of one day having to take the time to “migrate” my website if any of the services shut down, or impose some kind of limitation that I don’t agree with. And while that doesn’t really apply to a self-hosted WordPress setup, even that’s just too “heavy” for what I want: a very simple website—fully mine—where I can routinely publish my writings and links.

After some research, I found a solution that meets my needs perfectly: Jekyll. It’s painless to set up, easy to customize, has all the features I need, and best of all, publishing a new post is as simple as creating a new text file, putting my words in it, and pushing in the changes via git.

As a huge plus, the entire thing ends up being just a folder of static files so if I ever decide to switch hosting providers in the future, it’ll just be a matter of uploading all the files to a different web host (and making the required domain changes of course). No databases, no PHP, and no web interface to fight with—the perfect solution for me.

Website design

The way my website looks is important very to me. So much in fact, I have a tendency to spend too much time tweaking things until everything’s “just right”[2]—time I should be spending writing new content. Therefore, I decided to get that all out of my system right off the bat and make the website look, feel, and work just the way I want it to before writing anything. I ended up going with a very minimal design that’s likely to appeal to me for a long time (fingers crossed)[3].

Reducing costs

Feelings of guilt, even if minor, can be a major de-motivator and that’s the last thing I need when it comes to maintaining a website. If I’m spending money every month—money that could be spent on my wife and kids—to keep something going, something’s that’s not brining in any income initially, then it’ll help me personally to stay motivated if I know I went with the most affordable option I could (without sacrificing quality, of course).

A nice benefit to using Jekyll is that I can host this website using Github Pages, which is completely free (as in free beer). In fact, they encourage users to use Jekyll with their service. So at the moment, it’s costing me a whopping $10 a year to keep this website live, and that’s for the domain name (which I recently just renewed). It’s amazing that we live in a time where words can be published instantly and read by countless numbers of people around the world at hardly no cost.

So far I’m happy with the quality, but as I mentioned before, if Github Pages doesn’t end up working out in the long run for whatever reason, I can easily switch to another hosting solution within minutes since Jekyll-generated websites are simply a collection of static files.

Publishing workflow

The amount of friction between drafting a post, editing, and finally publishing needs to be as little as possible for me to keep the motivation to continue writing. Fortunately, my setup hits the sweet spot here. I write and edit my posts in Byword and do a quick commit/push into my site’s Github repo. Within seconds, the post is live.

When I used Tumblr or Wordpress in the past, I would end up writing my posts in a text editor, and when it’s ready, copy/paste into the web interface. That’s too much friction in my opinion, so being able to cut out the “middle man” is a big win for me[4].

Redefining success

Since it’s costing me practically nothing to run this site, and I’m making a decent living from my job and other contracting gigs, I’m under no pressure to turn this blog into something that’s going to generate my primary source of income so I can work from home.

I already work from home, which is a goal I had for a long time before it happened, so that need is already met. My purpose for this website is to simply serve as a source of joy for myself as an outlet for my thoughts, and to provide value to readers by being informative, educational, and—at the very least—entertaining. I want this site’s feed to be one you look forward to seeing new updates from, much like a few of the blogs I subscribe to and read every day.

If down the line, this website gains enough readership that it can actually contribute to my bottom line, great—it’ll be an added bonus, not a goal I’ll have needed to meet to consider this project a success. Rather, my definition of success for this website is if I meet my goal of posting to this site reguarly, and if a handful of readers get some value out of it.

So now with all five points met, the stage is set. Let the reboot commence.

  1. In addition to being frameworks engineer, I wrote weekly tutorials for Ansca. The work I posted to my blog was one of the contributing factors to my getting hired, so it wasn’t all for nothing.

  2. Another reason I didn’t go with WordPress this time: it’s way too easy for me to get lost browsing and trying out new plugins. Jekyll supports plugins too, but I’m not familiar with the process so it’s easy to stay away from it. That’s not the case with WordPress, however, where new plugins are just a click away.

  3. The Jekyll theme I’m using is a highly modified version of Gereksiz by Berk Özbalcı, with colors being from the Solarized palette.

  4. I know I could have went with sofware like MarsEdit, but I’m most comfortable writing in a plain text editor, particularly one made for writing (such as Byword), not necessarily blogging.

Just Joined the Svbtle Network. Found a nice surprise waiting for me in my inbox today. I’m actually shocked to have received an invite to Svbtle’s high quality network of online writers, but very flattered and thankful nonetheless.


TiLauncher is a free, lightweight build utility and app console for Titanium SDK and PLATINO projects.


  • Launch apps in the Simulator and build for device (testing and deployment).

  • Save build settings on a per-project basis (automatically reloads most recent project upon launching the app).

  • View console/logcat output while your app is running (in the same window)

Develop without needing the heavy-weight Titanium Studio (Eclipse) or the advanced Titanium Command-Line Interface to test apps or make builds. More Details Here

Lanica's ANIMO Code is Awesome

For those who missed it, Lanica launched a Game Development Platform earlier this week, which includes an entire product line for all phases of game development. This post will focus only on ANIMO Code, which is just a single product in the entire suite.

ANIMO Code is a full-featured integrated development environment (IDE) for PLATINO, Titanium SDK, and Corona SDK projects. You read that right: you can use ANIMO Code even if you haven’t yet switched over to Lanica’s Game Engine (PLATINO).

And while I’m obviously biased, I’m also very picky when it comes to development tools (especially anything that includes a text editor). I can definitely see myself having not written this post on my personal website if I did not in-fact like—nay, love—the product.

And here’s why…

1. Lightweight

ANIMO Code is a full-featured IDE, but it performs like a simple text editor. Here’s a screenshot of my Activity Monitor showing Xcode, Titanium Studio, and ANIMO Code all running:

(image removed)

As you can see, of the three, ANIMO Code takes up the least amount of resources and you can feel it!

2. Nice Features

It supports multiple different SDK targets (PLATINO, Titanium, Corona), run apps with the push of a button, sidebar filetype filters (and searching), and here’s a unique one: you can optionally record the Simulator screen when you build, so you no longer have to rely on third-party software to make demo videos of your product.

And on top of all that, it’s a great text editor for JavaScript and Lua code.

3. Great-Looking Interface

ANIMO Code resembles Xcode, but there are differences. To describe it better, it’s like if you took Xcode and trimmed away all the extra fat and crazy (although necessary for Xcode) complexities:

(image removed)

You have your project’s files in the left sidebar, the right sidebar is a searchable function list for the currently opened file, file tabs on top, and the console at the bottom (for when you build/run your apps). Everything you need is right there in front of you, yet it somehow manages to stay uncluttered.

I also love how the toolbar got moved up to the titlebar in the most recent update — it frees up even more space for other things.

Don’t take my word for it though. If you want to give it a shot, there’s a free trial available on the Lanica website.

Lanica Cross-Platform Game Development Platform


To read more entries, visit the archives or subscribe to the RSS feed.