It’s been a while since I’ve made any changes to the Ruby on Rails bundle for TextMate—not because there aren’t worthy changes or contributions, but rather, because I’ve been squeezed for time and using Rails itself less often than I used to.

SO, in good open source manner, the maintainership is being passed on to one Dr. Nic Williams of Australia (he’s a good guy, you’ll like him). Thanks to Dr. Nic, we should be seeing some new and tasty things for the Rails bundle that correspond to the Rails 2.0 changes.

If I may say so, TextMate’s Ruby / Rails support is second to none. It was made possible by the efforts of many people, and soon to be more. Thanks Dr. Nic, and to everyone else who has contributed!

Dr. Nic’s email address is dr nic williams at gmail dot com (no spaces).

The “Getting Things Done” philosophy and workflow is something I’ve been trying to implement lately. The costs up front are high, but the benefits are many—eventually, I hope to tune my brain to work something like a pre-emptively scheduled multicore processor. Heh. We’ll see.

In the meantime, here are some interesting applications for the Mac that have caught my attention. I’ve written a short review of each of them—why I like it or why I don’t. Please feel free to chip in if I’ve missed a feature, or if I’ve missed out on a great application somewhere.

ShoveBox ($25)

ShoveBox is a little gem I found a while ago that is simple and very useful—it acts as a fantastic aggregator of random bits of information throughout the workday. It has an “inbox” where new things get shoved so you can organize later when you have the time. Just drag and drop.

While not truly a “GTD” application, there are plenty of reasons why ShoveBox could work like one. For example, I’m particularly fond of the QuickJot window—press a shortcut key of your choosing (I have it bound to F7) and a transparent window appears where you can quickly type a message or note to yourself for later. Also, power users can use “rules” to sort items automatically, and they can even execute shell commands!

Once items are “shoved” or “jotted” into ShoveBox, you can open the Organizer window to … well, organize. There is a Mail-like interface that is quite familiar—just drag items to folders and keep things where they belong.

The search capability in the Organizer seems to work well, although I would like to see better keyboard support. At present, you must use the mouse to click the search area, then type, then use your mouse again to select the item you want out of the result list.

In fact, if I have one complaint for this application, it’s the overall poor keyboard support. For example, if you want to open an item from the Organizer window, only a double-click will do it (if you press “enter”, it helpfully lets you edit the title, but there’s no way to get out of editing mode if you made a mistake). If the folders on the left have the keyboard focus (i.e. pressing the arrow keys moves from folder to folder), then there is no way to move the focus to the items on the right.

If the author would pay attention to keyboard-only workflow, I would probably drop any GTD-specific application for this one. It’s that sharp.

Thinking Rock (Free)

Thinking Rock is much more of a GTD application than ShoveBox. In exchange for simplicity, you get quite a powerful tutor that has all of the bells and whistles you’d expect of a GTD app. Thinking Rock guides you through a lot of the “flowchart” involved in making decisions—is it actionable? should it be deferred? can you put a date to it? what context should it be placed in?

One of my favorite things about Thinking Rock is the overview (”home” icon). Unlike other GTD applications that assume you understand the Getting Things Done workflow, Thinking Rock provides a graphical flowchart / overview page that looks like this:

Another part of ThinkingRock that is especially well thought out is the way in which the form pages change dynamically to reflect your decisions about an item. For example, there is a radio button with two options “This item is actionable”, “This item is NOT actionable”. When you choose “not actionable”, most of the form gets cleaned up so that you just focus on reasonable choices: i.e. “Ok, if it’s not actionable right now, when would you like to schedule it?”

The downside to ThinkingRock (at least on a PPC Mac) is that it’s a Java app. In practice, what that means for me is that it takes between 15 and 20 seconds to load the application, and changing from screen to screen is like molasses. In addition, there is no syncing with iCal. Also, since it’s not a native Mac app, it does suffer from not following the Apple design guidelines—for example, the icons are quite small and not very intuitive. It took a little poking around to know how to get back to the overview screen.

With these caveats in mind, however, I haven’t found anything as well-designed and carried out for those of us who need a little guidance through the GTD method. I will probably use ThinkingRock as a learning tool until I settle on a Mac OS X native app.

Things ($49)

Now for a real GTD app that’s also a native Mac OS X app. There are several applications that would fall under this category (and I’ve listed some of them below, “Other Apps”) but after reviewing several, I’ve found Things to be the most intuitive, beautiful, and least complicated of the group.

Tasks are simple and easy to add to the system—in fact, I don’t think I’ve used a cleaner interface for tasks. UI widgets that you don’t need are tucked away when you don’t need them, and available when you do (such as date, reminder). Tasks can easily be promoted to become projects (drag and drop to projects). And the “tags” system of categorizing and managing contexts is both flexible and simple. I’ve found that I don’t need many contexts yet, so I don’t use tags much—but I sense that as I rely more heavily on Things to do my organizing, I will depend on tags for structure and filtering.

One thing that really appeals to me about Things is the use of “areas” in addition to “projects”. For some reason, it irks me to put something like “maintain my relationship with Kelty” in a “project”. It’s not really a project, it’s an ongoing area of interest and concern. Thus, there is a place to put items and projects that have no due date but still need to remain “in the queue”. They’re kind of like system background processes. (Or “high priority foreground processes” in the case of my relationship with Kelty )

Currently, Things is in alpha and has some limitations (and probably some bugs). For example, items in the sidebar can not be dragged. Also, items within projects cannot be turned into new projects (but unfiled items can), and the shortcut key that brings up a quick-entry transparent window cannot be bound to the F (function) keys.

Overall, Things is my favorite pick so far—as soon as it comes out of Alpha (sometime this spring), I will probably purchase it. Oh, and by the way, if you sign up for the mailing list by the 31^st of January, you’ll get 20% off when the final product is shipped.

Other Apps I’m Keeping My Eye On

Actiontastic (Free), iGTD 2 (Free), OmniFocus ($80), Midnight Inbox ($35)

All of the above apps look excellent and may be suited to others. iGTD 2 is particularly good-looking, but only works on Leopard (I haven’t upgraded yet.) OmniFocus looks to be the most well-rounded and professional application. But Midnight Inbox is a close second, with some very nice collection features (e.g. it can systematically grab files, emails, notes, or other items from other Mac applications and put them in your inbox for sorting.) Actiontastic hasn’t reached 1.0 yet, but it also looks promising.

It’s here again! The Mountain West Ruby Conference will be held this March 28th and 29th (Friday / Saturday), this year in Salt Lake City. I went last time it was held in SLC and loved the location—the library there is remarkable, and seemed a nice location for a conference.

I’m looking forward to meeting Ezra Z., the author of Merb, and as yet an “internet-only” friend of mine. There will be many other friends and brilliant minds there too. Come on out if you’re looking to learn more and meet new people in the business.

As you may have noticed from my recent posts, I’ve been on a language kick—exploring mostly functional programming languages and comparing the merits of various choices. I’ve finally narrowed my “next language” down to a single entry: Erlang.

I was reluctant to learn Erlang when I first heard about it. Perhaps it was because I hadn’t felt some of the pain associated with Ruby yet. Or maybe it was because all of my cool Ruby friends were learning Erlang. (I tend to resist fads as much as possible.) But Erlang looks to be more useful than a fad, and a good move on the part of my friends (you know who you are). For those of you who are Erlang early-adopters and advocates: well done

So, why Erlang? My reasons are 4-fold:

1. Speed: Erlang is a very fast language, earning a sweet 5.7 on this benchmark. Ruby, by comparison, earns a 54.
2. Reliability: Ericsson (the telecom company whose employees built Erlang) reports that since deploying their Erlang communications application, their downtime has averaged 5.2 minutes per year. That’s 99.999% uptime. They’re definitely doing something right!
3. “Functional”-ity: It turns out that I missed Erlang in my functional-language round-up a few days ago. Erlang is a functional language, and therefore benefits from a concise and expressive syntax. In addition, it doesn’t seem to suffer from some of the same difficulties that purely functional languages do when dealing with I/O.
4. Concurrency: Erlang is famous for its speed-boosts when adding hardware concurrency. Because of its message-passing architecture, upgrading a CPU to a dual-core or quad-core actually has the effect of doubling or quadrupling the execution speed. This is a very nice feature to have just baked in—especially at a time when Intel is making 2ⁿ concurrent processor cores.

Anyway, not that anyone was really on the edge of their seat wondering what language I would pick to learn next… but in case the information is useful, I pick Erlang.

Notable Resources:

• Yariv’s Blog, Ericsson’s Biggest PR Blunder
• Pragmatic Programmers, What’s All This Fuss?
• WagerLabs, Java vs. Erlang
• Erlang.org, Getting Started [pdf]

Ok, I have two nearly unrelated but interesting things to blog about today—let’s see if I can combine them into one post.

First, Shakespeare. Wow, what a poetic and expressive programming language that gets nearly nothing done! I had a friend over yesterday (Jamin) and we read the “acts” and “scenes” involved in generating prime numbers in the language. We laughed about the idea of actually having a theatre group perform “Primes”. The plot itself might not satisfy the theatre-connoisseur’s appetite. But then, I wonder, would the audience be impressed to find that the story performed before them had actually been an algorithm in action? Nah, maybe not. Well, unless the audience was composed of CS students and math geeks.

Moving on. Second, a decades-old question: Can dynamic languages scale? Ted Neward adds much-needed clarity to the discussion about “scalability” and points out that we must be more careful about what we mean by “scale”. Here are his two definitions:

1. Size of project, as in lines-of-code (LOC)
2. Capacity handling, as in “it needs to scale to 100,000 requests per second”

Shakespeare obviously can’t scale, (in neither the scale(1) way, nor the scale(2) way, but possibly in the scale(3) way of “creativity…”) But the distinction helped me to frame my own programming challenges in a new way—I’ve absolutely loved the scalability(1) of Ruby, but in recent months I’ve become somewhat frustrated by the in-scalability(2) of it as well. Algorithmically, there is still a lot that we can do to improve our MemoryPress.com system, but still, it’s frustrating to be bound by a language that is 40-50x slower than C . I’m starting to eye Erlang, Scheme, and Haskell jealously.

As a software engineer, I find that new material to learn is not in short supply. Gratefully, with discussions and challenges like this, I will be a satisfied student of computer science for years to come (whether I’m paying tuition or not!)

Erik Engbrecht has posted a well-written piece on his blog regarding a way of classifying programming languages. His purpose, he writes, is to make a structure for opening up debate and discussion on the subject. I like the dimensions he chose, and the resulting classifications of certain languages:

Read Programming Language Continuum.

I heard about MacHeist last year when it was in its first glorious round. This year, they seem to be doing even better, with last year’s record in sales (16k) already broken.

Basically, a bunch of Mac software developers got together and offered their products at a huge discount just to spur interest in the independent development community. The success from last year was great, and the software this year is really cool. Even the single photoshop-like program, Pixelmator, makes the purchase more than worth it—but you get 9 other apps on top of that. With thanks to my generous wife, I am now the enthusiastic owner of 1Password, CSSEdit, SnapZ Pro X, and Pixelmator, among others.

Check it out! (Your interest will help unlock the last app, NoteBook )

With each class period, the features of Scheme seem more and more enticing. I’ve wanted to explore functional programming languages for a while, so with my toe now in the pool, I’m looking at other languages and thinking about swimming

• Scheme: The one I’m exploring most right now. As suggested by Professor Windley, our class is using the DrScheme editor and interpreter. It is not purely functional, since it has side effects. Also, its dynamic typing system (while advantageous in many cases) makes it so the interpreter cannot assume things that would otherwise make for cool features, such as in…
• Haskell: Seems to be the cool kid on the block, with loads of academic new features. From discussions around the web, the fact that it is a “pure” functional language that has no side effects (except within well-determined blocks called “monads“) makes it special. Also, Haskell’s type system is (apparently) to be envied. There is an online book called the School of Expression that comes recommended to me.
• Ocaml: The fastest compiled code and the least rigid functional language. I am told that if you need to do imperative code or enlist an object-oriented style of coding, Ocaml will accommodate those options even though it is a functional language at its base.
• AliceML: This has some pretty cool concurrency features that are worth looking in to.
• Clean: Seems to share the same heady space as Haskell in that its features are often experimental PhD students’ ideas. I like its direction, and the fact that its IDE is built in the Clean language definitely says something of its practical use. Like Haskell, Clean is also a “pure” functional language.

I benefited from this Haskell vs Ocaml discussion thread on O’Reilly.

Update: The Qi language also looks interesting. It appears to be a derivative of Lisp, with some new syntax.

Also, there’s an interesting benchmark shootout for all of our favorite languages. It looks like Clean is pretty dang fast.

I’m taking a computer science class this semester called “Concepts of Programming Languages” from Dr. Phil Windley. We’ll be using the Scheme language as a tool to explore language features and concepts.

Since I am most familiar with another dynamic, late-bound language (Ruby), of particular interest to me is how Scheme and Ruby differ. Here are some notes so far:

• Macros: There is no way to create a true macro in Ruby. For example, one cannot create an “if” function, or an “and” operator—these are embedded in and defined by the language itself.
• Speed: Scheme is about 30 times faster than Ruby, if my sources are correct. On a scale that sets the speed of C at 1.0, Dr. Windley (as an estimate) put Scheme at 2 or 3, Java at 5 or 6, and Ruby at 30. Ouch.
• OO: Ruby is an object-oriented scripting language. It doesn’t have to be, I suppose, but it is used most powerfully when its OO features are embraced. Scheme, on the other hand, is not inherently object oriented. However, from what I understand, because it has nested scope and closures, it is possible to use it in an OO way (I have yet to understand this properly).

I also recommend this discussion thread on Ruby vs. Scheme which was recently highlighted on dzone.com.

With speed, deployment and concurrency all becoming important elements of my programming requirements, I’m excited to take a look at other languages and see what they have to offer. Scheme is one that looks to be enlightening.

I can’t wait ’til we really dig into macros

One of the requirements for our typesetting engine at MemoryPress.com is the ability to use images within a document such that the text flows around each image. This has been done before in several TeX macro packages, but the only one available for Plain TeX (or eplain) was figflow. FigFlow almost did the job, but had two shortcomings in our case:

1. Images that had to be carried over to the following page could not appear in the first paragraph of that page,
2. Images could only appear on ONE side of a paragraph at a time.

As I learned about TeX itself (in order to overcome the first obstacle), I began to see a way that it might be possible to enhance FigFlow to allow figures on BOTH sides of a paragraph. The “way” turned out to be much longer and more difficult than I thought, but it turns out that it is possible using a dash of “parshape” macro and several tablespoons of hacking. Click on the image to the left to see an example page from a PDF document.

The TeX source code for the macros that make this possible is available in this zip file. This is version 0.5.