A few weeks ago I started a new side project (a string-figure catalog, not yet ready for an audience, sadly), and I figured it would be a good opportunity to dabble in the new goodies in Rails 3. It’s been a fun experience, for the most part, but I’ll save my “wins and fails” for a separate post.

For now, I want to focus on one particular frustration: Unobtrusive Javascript (UJS). In any project of even moderate complexity, I’ve found that Javascript plays a role, and in Rails 2 the primary way to play that game was by inlining your Javascript. (This is where you put Javascript directly into your tags, for instance in “onchange” or “onclick” handlers.)

→ Click here to read the rest of this article.

This is the fourth (and final) article in a series titled “There is no magic, there is only awesome.” The first article introduced the four cardinal rules of awesomeness, the second was about knowing thy tools, and the third encouraged you to know thy languages .

First off, I apologize for dragging this out. It’s really become a weight on my shoulders. I’ve been fretting and fretting about writing the last two or three posts in this series, and I just couldn’t find the inspiration to make them come out like I wanted…and they’ve been holding up other posts I’ve been wanting to write.

So I’m going to cheat. You’re going to get a braindump, more or less, of the last two rules of awesomeness. Yes, I am entirely cognizant of the irony here. Nonetheless, here goes.

→ Click here to read the rest of this article.

This is the third article in a series titled “There is no magic, there is only awesome.” The first article introduced the “four cardinal rules of awesomeness”. The second article discussed knowing your tools.

Opening A.—Pass index finger of right hand distal to the little-finger loop, and passing round the ulnar side of that loop, bring it up from the proximal side into the thumb loop, and with the index finger pointing downard, take up with the back of the index finger the radial thumb string and return.

Even to string figure adepts, it can be challenging to parse those instructions. That paragraph is an extract from the instructions for an Eskimo Caribou string figure, written in 1903 by Dr. A. C. Haddon and published in American Anthropologist (you can read the whole thing on Google Books if you’re really feeling sleepless).

The original string figure notation described by Drs. Rivers and Haddon in 1902 used very technical anatomical terms to identify each finger, and the location of the string on each finger. As in that paragraph, you’ll see terms such as proximal (closer to the base of the finger), distal (closer to the finger tip), radial (closer to the thumb), and ulnar (closer to the little finger). These and other terms are used to describe locations relative to the fingers, as well as to name specific strings (“radial thumb string”) on the hand.

The strength of this notation is that it is very precise, and can be used with little need of external illustration. However, it is also fairly verbose, making it hard to parse without very focused attention and (potentially) multiple read-throughs. Also, the use of the technical anatomical terms makes the descriptions hard for novices to pick up.

→ Click here to read the rest of this article.

This is the second article in a series titled “There is no magic, there is only awesome.” The first article introduced the “four cardinal rules of awesomeness”.

If you’ve ever watched someone make string figures, it’s pretty obvious that the tool set includes a loop of string, and your fingers. But if you haven’t played with string figures much, you might be surprised to learn that you’ve got a lot more than string and fingers at your disposal.

There are figures that require the use of your wrists to hold the string. Some require you to use your lips, teeth, tongue, or nose. I know a few that use the neck. There are some that use the elbow, knee, foot, or toes. A few require you to set the figure down on a flat surface to manipulate it.

There are many figures that require the use of another person, or several people. Some figures actually require multiple strings. Some require additional props, such as sticks.

Different figures might require different types of string. Some, like Eskimo figures, work best with a thicker, shorter, stiffer string, while those of the Pacific islands tend to prefer longer, more supple and slippery strings.

With so many variables, and so many ways of combining them, how then does one ever excel at string figures? Is it hopeless?

Of course it isn’t. As with any other activity, there are simply a set of tools to be employed, and the expert will be well acquainted with them. It’s rule #1 of being awesome: know thy tools.

→ Click here to read the rest of this article.

The following is the first of a series of articles that I will be posting in the coming weeks, based on the keynote address I gave at the 2009 Ruby Hoedown in Nashville, entitled “There is no magic, there is only awesome.” I originally intended to publish the entire series of articles as a single article, but it got too long. At any rate, I think it’ll be more easily digestible as multiple posts.

I’m always surprised to discover that there are people who have never heard of string figures. These are the games that are played (in western culture, at least) primarily by children, using a loop of string. They place the string on their hands and, either by themselves or with a friend, manipulate the string into various patterns. As a kid, I learned how to do a few such patterns, including Cat’s Cradle and the cup and saucer, but it was just a novelty, and I was interested in other things. I promptly forgot nearly everything about these games, except that they existed.

Fast-forward almost thirty years. My wife bought one of those Klutz books for our kids, this one about string games. It only described a handful of figures, but it was enough to pique my curiosity. I hopped online to see if there was any other information available about the subject.

Thus did the floodgates open! I discovered that string figures are a nearly universal pastime, being found in almost every culture around the world. In fact, many widely separated cultures share string figure repertoires—a discovery that fascinated and intrigued ethnologists over a century ago.

→ Click here to read the rest of this article.

Dmitry Belitsky sent an email to prominent Rubyists with several different questions around the theme of “How to become a successful Rubyist”. He then posted their answers in interview form on his blog. I was a bit late to get my answers submitted, but they’re there now. Essentially, my advice is to participate in open source, use moderation, and have non-virtual hobbies, but you can read the entire interview if you like.

Thanks, Dmitry!

So, I’ve now been using BucketWise for almost two months, and it’s been fantastic. Admittedly, as the author of the application, I’m willing to overlook a lot of the warts and inconsistencies, but I can honestly say I’ve felt more control over my finances these last two months than I’ve felt in the last 10 years. It’s an awesome feeling!

Tonight, I tagged version 1.1.0 of BucketWise, which (if you haven’t been following along) fixes a few bugs and adds several new features (account reconciliation, memorized transactions, actor name autocompletion, simple budget reporting, and more; I’ll just refer you to the changelog for the full list). It’s really been a fun project to tinker on. The last feature I myself really want is scheduled transactions; I may be hacking on that one in the near future.

I figured this might be a good time to talk a little about how I, personally, am using BucketWise. I’ve been surprised by a few things, both good and bad: some features I’ve found to be less useful than I anticipated, and others have been surprisingly handy!

Firstly, when you log into BucketWise, you see a short list at the top, called “Recent transactions”. This list was intended to let you see, at a glace, what you most recently had entered. (It also provided a handy landing place for newly entered transactions.) It hasn’t been very useful, though; I find that what I really want is to see the register of transactions for my checking account. I may be reworking that dashboard view soon.

Also, bucket reallocations haven’t been quite as useful as I expected. I do use them, and they are definitely handy, but I find that if you shuffle money around too much, it muddies your register. The reallocations are basically noise, especially when viewing transactions at the account level. I’m going to be pondering ways to reduce their visibility.

Buckets, though, I’ve found to be spectacularly useful. I’ve got my savings account partitioned into three buckets (short term, medium term, and long term), and that’s been a great way to keep track of how those savings funds are earmarked. Also, I’m trying to save 10% of each paycheck (trying, but not very successfully yet!), so I’ve got a “savings” bucket in my checking account, too. When the funds get to a certain threshold, I transfer the money to my savings account. (Yeah, I could just do a transfer with each paycheck…but I find I’m more likely to do it if I do it infrequently. Not sure why that is.)

Buckets are also great for indicating money that was given as a gift. My wife and I share the same checking account, so when it was her birthday, I transfered money from my Paypal account and put it in a “Tarasine” bucket. She was then welcome to record whatever purchases she wanted against that bucket. Similarly, when I receive money as a gift (birthday, Christmas, whatever) I just deposit it into a “Jamis” bucket.

Lastly, having credit card debt repayment built into the application has been awesome. I’ve loved being able to immediately indicate which checking account bucket a credit card purchase will be repaid from, and seeing that those funds are set aside, inviolate, ready for when the credit card bill comes.

My checking account currently has 35 buckets, and I can see my wife and I adding more. Most are purely for budgeting purposes (“groceries”, “auto fuel”, etc.), but they are so handy as ways to arbitrarily earmark money. Tithes, charitable offerings, savings, and credit card repayment are just some of the ways I’ve used them. (In fact, I’ve found myself wishing I could mark additional buckets as being “aside” buckets; I’m still pondering ways to make that happen, if it needs to.)

I’ll probably blog more about BucketWise down the road, and talk about specific use cases and how it’s helped me with them. However, I’d love to hear from others, too. Are you using BucketWise? If so, what do you like and dislike about it? I’m definitely only writing this application for me, but I’m curious to hear what the experience is like for others.

Lastly, if you’re interested in giving BucketWise a test drive, I’ve set up a demo account that you are welcome to log into and play with. I’ll reset the data there periodically, so feel free to try out all the features! Just go to http://www.bucketwise.com, and log in with the “bw.demo” user (password “demo”). Note that this is hosted on a modest Linode host, and will almost certainly be swamped into unusability with any significant traffic, but you’re welcome to try it out.

BucketWise is now available! It’s far from “done”, but I’m labelling it “1.0.0” because giving code pre-1.0 version numbers is a coward’s game. (ha!)

At any rate, fork it on GitHub, see what you think, and contribute back if you feel so inclined. The TODO includes a list of unresolved issues and features I’d like to see land someday: knock yourselves out. :)

Note that I’ve tried to document the REST API for BucketWise, too; the first draft is in doc/API.rdoc let me know if any of that is too confusing or not informative enough (I’m sure that will be the case). I’m really looking forward to seeing what people use the API for.

Note that while the source code is now available, I’m only actually hosting the application itself for myself and a few close friends. But please feel free to deploy it to your own servers, or even just run it locally. And let me know what you think! BucketWise is super opinionated, so I’m sure I’ll get some hate mail, but that’s the name of the game when you’re playing things like this on the Internet. For me, personally, BucketWise has already proved more than worth the time I’ve invested in it so far; hopefully it’ll prove useful to others as well.

Enjoy!

“Buckets” is now “BucketWise”. The name was more unique, easier to identify as an application, and just felt better than “Buckets”.

To celebrate the new name, I’ve also made another screencast, this one demonstrating BucketWise’s anti-debt features. It’s a bit more long-winded than the first one: five and a half minutes of me talk-talk-talking:

BucketWise Preview #2 (QuickTime, 5:30, 10MB)

I’m slowly working my way through the list of things that I want done before I release the code. For the curious, here’s what I’m wanting done before I open it up:

Existing bugs:

• after saving a reallocation event, the line items don’t reset
• green “your transaction has been recorded” notice doesn’t disappear when starting a new event
• date column for event row is squashed in safari
• “Add a new bucket” should set focus on new bucket line
• check number and “select repayment options” links are out of whack when editing an event
• deleting event from account perma results in ajax error (maybe only when there is only a single event in the account?)
• Reallocating a bucket doesn’t change the updated_at field for the bucket?
• “move in” and “move out” links on dashboard don’t use existing form—they go to events/new
• make all autocompleting fields refresh their source array after event creation

Remaining features:

• tag delete (optionally move transactions to different tag, e.g. “tag merge”)
• tag rename
• API
• validations
• rake tasks for user and subscription creation
• change style for event detail view: “window shade” style isn’t really working
• attr_protected everywhere (perhaps implement an update_override method or something for places where it would be useful to do mass updates despite protected attrs?)
• spinner for ajax actions
• user info page (for password change)
• password reset from login page
• cache balances on events (?)
• README with installation instructions
• CHANGELOG

Those lists are straight from my TODO file. But for those who think I’m waiting for too much to be finished, never fear. I’ve got plenty that I want to implement, but which I’m willing to wait until post-release to work on:

• signup process
• exception notifier (?)
• /subscriptions index
• autocomplete actor field in event form
• better 404 and 500 error pages
• searching & reporting
• account reconciliation
• transaction templates (“saved” or “memorized” transactions)
• scheduled transactions (occur automatically at specified intervals)
• show check numbers in event detail view
• add a memo field for events
• print stylesheet
• oauth authentication for API
• filter event views to show only events with a non-zero balance for the account in question
• filter event views to show only deposits, or only expenses
• normalize ‘actor’ so we can do actor-centric queries more efficiently
• full-text searching on the memo field
• show bucket and account balances next to names in drop-downs
• make bucket reallocation work from bucket perma

Depending on how soon my bank sends the next statement for my checking account, I may or may not need to have “account reconciliation” done before launch, too.

As before, let me state: I’m writing this application for myself, and really only for myself. If other people like it, that’s cool. I’m more than happy to share and let other people hack on it. I may even release it into the public domain (I haven’t yet decided what license I’ll use). But BucketWise will always be very opinionated. If you prefer having your finance app download your transactions from your bank, you’ll be disappointed by BucketWise. If you need currencies other than the US dollar, you’ll be disappointed by BucketWise. If you need pretty charts and graphs to analyze your cash flow, or if you want to track investments, or any number of other things, you’ll be disappointed by BucketWise.

Just FYI. :)

So, yeah. With Capistrano and friends off my plate, I’ve actually found time to work on a project that has been in the works for years (and that’s no exaggeration, I first mentioned it in a blog post in October 2004). I’ve named it and renamed it (“Penny Pincher”, “Chump Change”, “Make Me Rich”, and “BudgetWise”) but its current incarnation is “Buckets”.

Buckets is a simple web-based personal finance application that I’ve been working on, written specifically for my wife and me. Its focus is on simple budgeting, and reducing debt, and It is intentionally “feature-poor”. It is loosely based on an envelope budgeting strategy, and while it definitely isn’t the only web-based finance app using such a strategy, it just may be the simplest.

I recorded a screencast demonstrating the budgeting aspect of Buckets; it’s a 5M QuickTime movie, 2:42 in length. Click here to view it, if you care to..

Buckets is still private: it has been deployed and my wife and I are using it, but that’s it. The source code is in a private repository on GitHub, and the production instance of the app is currently only accessible to me. That will change eventually (maybe a couple of weeks, depending on how initial testing goes), but I want to make sure it’s actually going to be useful before I open it up.

It is with mixed emotions that I announce two things this evening.

First, I’m announcing the final release of both Net::SSH (2.0.11) and Capistrano (2.5.5). Both are minor changes: Net::SSH 2.0.11 adds support for a :key_data option, so you can supply raw PEM-formatted key data. Capistrano 2.5.5 enhances the role() method so you can now declare empty roles. Either way, not much to get excited about, but the changes were pending and deserved releasing.

Secondly: I’m ceasing development on SQLite/Ruby, SQLite3/Ruby, Net::SSH (and related libs, Net::SFTP, Net::SCP, etc.) and Capistrano. I will no longer be accepting patches, bug reports, support requests, feature requests, or general emails related to any of these projects. For Capistrano, I will continue to follow the mailing list, and might appear in the #capistrano irc channel from time to time, but I am no longer the maintainer of these projects. I will continue to host the capify.org site and wiki for as long as they are of use to people.

This was a very hard decision, and one that has taken me months to come to grips with. I cannot express how much I appreciate the huge support from everyone that has found value in Capistrano, in particular. Your kind words and encouragement have meant a lot to me. But I’m burning out, and I have to drop these before things get worse. Maybe after some period of time I’ll come back to them—I don’t know. But I’m not planning on it.

So where do these projects go from here? That’s entirely up to the community. If you have a neat idea for any of these, please feel free to fork the project on GitHub (see my profile page for the links to the individual projects) and release updates on your own schedule. If no one steps forward, that’s fine—I’m not asking for volunteers. But if someone feels passionately that any of these are not “finished”, and has ideas for how they could be further improved, I will not stand in the way.

However, please know that I am not available for questions about the code, or for advice on how to implement changes. I’m trying to cut as cleanly as I can. Any emails I get asking about the code will likely be ignored. I’m not trying to be rude; I’m just setting expectations.

I won’t disappear, though. These libraries were just becoming millstones around my neck; without their weight dragging me down, I look forward to being able to experiment and play with new projects and new ideas. We’ll see what the future holds!

So, thanks all for a fantastic couple of years.

This is a multi-project release announcement, so brace yourselves.

In short, Net::SSH 2.0.9, Net::SFTP 2.0.2, Net::SSH::Gateway 1.0.1, and Net::SSH::Multi 1.0.1 have been released. Get ‘em while they’re hot!

It’s all just bug fixes, for the most part, but if you want more nitty gritty, read on.

Net::SSH 2.0.9

The following issues have been addressed in Net::SSH 2.0.9:

• If you specify a non-nil user argument to Net::SSH#start, it will override whatever setting exists for User in your .ssh/config file. (Prior to this, the .ssh/config’s User setting would always be used, regardless of what user you specified to Net::SSH::start.)
• Some naughty ssh servers send channel requests even after the channel has been closed. Net::SSH handles these spurious requests better now.
• Net::SSH::Connection::Session#shutdown! has been added for hard shutdown scenarios (where an error leaves the connection in an ambiguous state and you just want to terminate the connection without all that touchy-feely “graceful shutdown” nonsense).
• The key loading behavior has been further tweaked so that Net::SSH will try to load public keys first (by appending ”.pub” to the given key file name), and if no public key with that name exists, the corresponding private key will be attempted. This way, operations that only need the public key will not require the (possibly encrypted) private key to be loaded in order to succeed.
• The :passphrase option was being dropped on its way to the key manager. It is now passed all the way through, so that specifying the :passphrase option actually works now.

Net::SFTP 2.0.2

Only one bug fix: if an exception was raised from within the Net::SFTP::start block, it could leave the Net::SSH session trying to gracefully close channels on a borked connection. Net::SFTP will now, instead, do a hard shutdown of the ssh session connection, rather than trying to gracefully close, if an exception every bubbles up outside the block. (A side effect of this is that Net::SFTP 2.0.2 depends on Net::SSH 2.0.9, so you can’t get one without the other.)

Net::SSH::Gateway 1.0.1

Just one minor new feature was added: you can now specify the exact port number on the local host that you want the gateway to be created on. Just pass an optional third parameter to Gateway#open. This will default to the original behavior (selecting the next available port number), but now allows you greater flexibility in how you use Net::SSH::Gateway.

Net::SSH::Multi 1.0.1

Just one minor new feature: an Channel#on_open_failed callback hook was added, to mirror the on_open_failed callback hook in Net::SSH.

Back in October I released a Vim extension for mimicking TextMate’s cmd-T file lookup feature. I use it heavily now, and it works great for me.

Sadly, the author of the FuzzyFinder Vim script, upon which my extension depends, keeps changing internal implementation details that I had to hook into to make my extension work. The result? Every few weeks my extension breaks with the latest FuzzyFinder.

Needless to say, this is work I don’t need. The fuzzyfinder-textmate stuff works fine for me. It works fine for people on older versions of FuzzyFinder. And I really don’t care to support this anymore.

If you’re passionate about this, please feel free to fork the project on GitHub and release your changes independently. Feel free to post your changes on the vim script page, even! I hereby release that code into the public domain. Do with it as you please!

So, I’ve got a new sqlite3-ruby release pending (just a minor bug fix, is all), but I’ve learned my lesson about releasing a new version without a windows version pre-built.

The problem is, I’m not a Windows guy. My build environment for Windows is cobbled together and painful to use, when it works at all. I’ve decided that I won’t put myself through that pain anymore.

If you are a developer on Windows, and you have a sqlite3 build environment, and would be willing to compile the sqlite3-ruby extension for me, please do the following:

1. Add a comment to this post, indicating your name, and what platform you would be willing to build for (cygwin, native windows, whatever. I don’t even know the right names.)
2. Reload the page, and make sure no one commented before you, claiming those platforms.
3. Grab the latest version of sqlite3-ruby here: http://github.com/jamis/sqlite3-ruby/tree/master.
4. Build the extension, and email it to me at jamis at 37signals dot com.

Once I have a build of sqlite3-ruby for windows, I’ll release the new gem. (It amazes me how painful Windows makes this process. Mac OS X, Linux, BSD, etc. —you just gem install and build the source. No such luck in the Windows realm, apparently.)

It appears that Confreaks has posted the video of my ‘Recovering from Enterprise’ talk from RubyConf 2008. As usual, Confreaks did a great job recording the talks at RubyConf.

For those who missed it, I also posted an article version of my presentation, titled Legos, Play-doh, and Programming.