I can’t believe I didn’t know about this until recently… it’s such a gem of a tip.

If you type “gem server” in the shell, you’ll start a webrick server that’s listening on port 8808 to dish out all of the help files for your installed ruby gems. Here’s a little alias I made that helps me get right to the documentation from the console:

alias gemdocs="gem server >/dev/null 2>&1 & \
    sleep 0.2 ; open http://localhost:8808"

Basically, it starts the gem server and ignores the log output. Next, it waits a fraction of a second for the server to start listening on port 8808, and then uses the Mac OS “open” command to open the default browser and points it to the gem server so you can start looking at your documentation.

Having a gem server is Brilliant!

Introduction

Merb ActiveAdmin is a drop-in backend for Merb applications that use the Sequel ORM. It gives application administrators direct access to specific models so they can add, edit or delete anything they need to. It also provides a way to add or remove associated data, e.g. one-to-many, or many-to-many relationships between models. These plugin features are provided with very low configuration so that setting it up is as easy as possible.

Watch the Screencast

The screencast is available here on a separate page.

Links

Download and installation instructions can be found at the github repository. See the README.markdown file.

The git repository is hosted at my account on github.

Final Words

Let me know what you think. I’m curious to know, specifically, how many people use Sequel as their ORM of choice. DataMapper and Stone have also been proposed as possible ORMs to support. And of course, ActiveRecord would be a nice choice too

I hope you enjoy it!

What do you get when you mix ambient findability, distributed version control, and social networking? The killer app of the open source movement: github.com.

When I first heard of github through the Merb development crowd, I wasn’t very impressed at first. To me, subversion was such a huge improvement over CVS that I was still quite happy to develop with the simplicity of a single-repository version control system. What’s more, I had tried SVK when it was “cool” and I didn’t really get much out of the added complexity—sure it was nice to be able to copy someone else’s subversion repo, and then modify your own fork without losing the ability to grab new changes from the origin… but there were a half dozen more commands to learn, and software to set up, etc., etc.

So why is git different? Well, first of all, it was designed by Linus Torvalds (the creator of Linux) and it is fast. The speed boost is enough to make me wonder how I could be so complacent about subversion’s performance—I just didn’t know any better. But speed is not the “killer” feature of git: it’s the distributed paradigm made possible by the low forking/merging barrier. When forking a project is as easy as naming the fork, and merging is as easy as a single command, the ability to do so and the desire to do so meet. Anyone can do it, as often as they want, and with whatever code base they want.

Now add social networking and you get an amazing thing: developers can see what other similarly-minded developers are interested in, and watch the growth of pet projects or interesting software. For example, I just found out about an innovative javascript database called jquery-database by browsing what other developers are interested in, and the gitnub tool for Mac OS X by exploring the Popular Watched page. This isn’t a vote-it-up, vote-it-down page—this actually reflects what people are watching on their aggregated feed page, or what code bases they are really forking to work on.

Speaking of forking, contributing may now become trivial too—just fork the project and you can add whatever features you want even without the original author’s permission. If your features stand the test of time, and if they are interesting to the maintainers of the original project, they can merge your changes back in. It’s like automating the process of diff and patch, to an infinite degree, while maintaining the ability to sync with the original code base as you play with stuff.

After getting started on github, I feel like I have shed a little darkness from an era when I was coding without light. For example, I’ve often thought, “Maybe I’m building something that has already been done… but even if my code is a duplicate of someone else’s project, is it worth it to try to get involved with them on the mailing lists?” Or, how likely is it that I will get commit access? It’s possible, of course, but it might be an investment in time that will prove fruitless.

Now, however, searching for other projects on github is so easy that I feel like everyone is helping me. We’re a world-wide network of developers building interesting things. Everything we write,
everything we watch, and everything we search can be shared. It’s all at our fingertips.

As you can tell, I’m excited to be a part of this new network. Github is now open to all for free or paid access, so come on aboard!

The Scheme package we use in class (DrScheme) is based on MzScheme, which is a popular and fairly standard version of Scheme. But it’s also very slow. According to these benchmarks, it’s 10 times slower than C on average, and 5 times slower than (Steel Bear) Common Lisp!

Of course, that’s still loads faster than Ruby, but it bothered me that something as similar to Lisp (and requiring the same amount of brain-wrangling for its parentheses) would not similarly share its speed. Well, it turns out that there several variants of scheme compilers that outperform MzScheme. Here are two interesting benchmarks (Twobit, Gambit) that put Chez Scheme (commercial) and Gambit Scheme (open source) on top.

Gambit Scheme claims to be as fast as C in some cases, which is a pretty ambitious claim. I’ll be checking it out soon.

I very much enjoyed reading about the benefits of functional programming over at Defmacro.org. The author, Slava Akhmechet, goes into some detail about several important advantages that I’ve been trying to enumerate for myself:

1. Unit Testing: Since there are no reference to global variables or external state in FP, unit tests can focus precisely on the function that needs testing, without the difficulty of setting up a particular state before calling the function.
2. Debugging: Again, without references to global variables or external state, debugging is simply a matter of drilling down to the problem.
3. Concurrency: As a mathematical abstraction, functional programs have the potential to be reasoned about by the compilers and interpreters that run them. As a consequence, concurrency becomes a compiler option rather than a difficult-to-implement coding pattern.
4. Hot Code Deployment: I would love to do this on a web server some time! No more software down time.
5. Higher Order Functions: As an alternative to object-oriented programming, this feature caught my eye. I’ve been thinking in terms of closures for quite some time (thanks to Ruby) but I’m still getting used to the idea that OOP isn’t necessarily the best way to do things in every circumstance.
6. Currying: This lets you build up functions from other functions. The typical example is in defining the “inc” function: it is simply the “add” function with the number “1″ bound to it for every subsequent call. No need to write a function to do that, just define “inc” in terms of “add”.
7. Continuations: This aspect of FP (and other languages, such as Ruby) is fascinating. It’s very nearly an assembly language instruction, longjmp, but with the added benefit of an environment where variable state is stored. I like how Slava compares this with putting a computer to “sleep”—when the computer wakes up, it’s like nothing happened, even though time elapsed.
8. Pattern Matching: Nice, but in agreement with the article, pattern matching doesn’t seem all that revolutionary. I could be wrong.
9. Closures: Slava points out that this is a bridge between the OOP world and the FP world. In a special way, closures allow the formal lambda calculus to have a little exception to its strict recursive environments: closures can also access their parent environment in addition to their own.

I highly recommend this article for anyone who’s been thinking of functional programming and wants a “big picture” view. Excellent examples of real-world usage and some fun history to boot

I was kind of excited to hear more about Arc, preferably from someone in the know—is it as cool as Paul Graham says it is? Lispers speak your mind!

Unfortunately, the first comment on the language that has been widely publicised is this one on FoRK. The author is not impressed. Can anyone who knows better than I do give the language a thumbs up or down?

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]