22 Feb 2011

Programming Language Survey Results

Posted by Jamis on Tuesday, February 22

A couple of weeks ago (already!) I asked two simple questions of my Twitter followers: what are (up to) four programming languages that you know and love, and what are (up to) four programming languages that you would like to learn?

Around the time I asked the question, I had almost 4200 followers on Twitter. Of those 4200, 38 responded. That’s almost one percent, and it is most definitely not a large enough sample from which to draw meaningful conclusions! Even if all 4200 of my twitter followers responded, it would still have been a strongly biased survey: most people following me on twitter are (or were) Ruby/Rails programmers, or found me through some other Ruby/Rails programmer. Asking this group what their favorite languages are is bound to have some strong biases.

And, sure enough, the top ten “know-and-love” languages among the 38 respondents were:

  1. ruby (32)
  2. javascript (25)
  3. java (13)
  4. python (9)
  5. c (9)
  6. c# (7)
  7. php (6)
  8. c++ (5)
  9. perl (4)
  10. lisp (4)

Compare that to the top ten “want-to-learn” languages:

  1. erlang (22)
  2. objective-c (12)
  3. clojure (12)
  4. python (12)
  5. lisp (10)
  6. haskell (9)
  7. scala (9)
  8. lua (5)
  9. r (5)
  10. c (5)

Ruby didn’t even make that list! (It actually came in at #11.)

So, what I’m trying to say is, the data is strongly slanted toward the preferences of Rails programmers who enjoy Ruby as a programming language. Still, there are some interesting tidbits to find here. I am definitely not a statistician, but here are four points that emerged that I found enlightening:

Every respondent included at least one object-oriented language among their know-and-love’s. For most people, that was Ruby, but Java, Python, C++, Objective-C, and others were mentioned, too. 17 people mentioned two object-oriented languages, and 17 more mentioned three. Three people gave all four of their know-and-love languages as object-oriented languages. What do I take away from this? All we really know is that object-oriented languages are apparently widely taught/learned among my twitter followers. No surprise there!

Only 8 respondents indicated that they know-and-love a functional language. Six people gave only a single functional language among their four know-and-loves, one more gave two, and one more gave three. Is this because people don’t love functional languages? Definitely not. There is simply not enough data to draw any conclusions about why this number is smaller than OO languages, but it does make you wonder, doesn’t it? Are programmers with predominantly OO backgrounds intimidated by functional paradigms? As you’ll see in the next question, it’s definitely not a lack of interest!

The four functional languages that people gave as “know-and-love” are:

  1. lisp (4)
  2. haskell (3)
  3. erlang (3)
  4. clojure (1)

Now, compare that with the next point:

33 of the 38 respondents wanted to learn at least one functional language. That’s almost 87%, versus only 21% that already knew a functional language. There is some serious curiosity there; people know OO, but want to learn functional. And what functional languages are people curious about?

  1. erlang (22)
  2. clojure (12)
  3. lisp (10)
  4. haskell (9)
  5. scheme (2)
  6. ocaml (2)
  7. ml (1)
  8. f# (1)

Erlang, far and away, is the one most people are curious about. Interesting!

The last point: 32 respondents included at least one object-oriented language in their want-to-learn list. 12 people wanted to learn one OO language, 16 wanted to learn two, and four people wanted to learn three OO languages. Which languages?

  1. python (12)
  2. objective-c (12)
  3. scala (9)
  4. lua (5)
  5. ruby (4)
  6. c# (3)
  7. smalltalk (3)
  8. java (2)
  9. javascript (2)
  10. c++ (1)
  11. io (1)
  12. coffeescript (1)
  13. groovy (1)

Curiouser and curiouser! I love that a predominantly Ruby-centric group wants Python and Objective-C above all others. ObjC actually makes sense to me, even aside from the popularity of iOS as a platform. ObjC has many similarities to Ruby, and is a great language for Rubyists. Python, though…I love that it’s tied for #1. It shows a certain open-mindedness in the Ruby community, which gives me warm fuzzies.

Anyway, I’ll say it again: there really wasn’t a large enough sample set to draw meaningful conclusions here. But it’s still fun to look at seeming patterns in the data. Hopefull you’ve found something useful here, too!

Posted in Projects | 4 comments

19 Feb 2011

Kaleidoscope

Posted by Jamis on Saturday, February 19

It’s funny how knowledge leads to knowledge. You start digging deeper into one thing, and discover threads leading off into related fields. I began by researching maze algorithms, decided I wanted to see what mazes in more complex tesselations would look like, and after one thing or anouther found myself learning about Wythoff constructions.

The result is Kaleidoscope, a library for generating uniform tilings using Wythoff constructions.

gem install kaleidoscope

A uniform tiling is a tesselation of a plane using regular polygons (with a few other constraints that I won’t go into here). What this means is that, in essense, you give Kaleidoscope a few input parameters, and it hands you a bunch of regular polygons.

1
2
3
4
5
6
7
8
9
10
11
require 'kaleidoscope'

pattern = Kaleidoscope::Pattern.new(6, 3)

pattern.generate! do |point|
  point.x * point.x + point.y * point.y < 10
end

pattern.polygons.each do |polygon|
  # ...
end

The polygons are generated around the origin of the plane, within a region you specify via the block to the generate! method. Once done, you can translate and scale the polygons to wherever you like, for rendering purposes. Kaleidoscope will even include basic tricoloring data for the polygons, to make it easy to decorate your pattern.

Some obligatory pretty pictures:

Click here to read the rest of this article.

Posted in Announcements Projects | 5 comments

09 Feb 2011

Mazes in CoffeeScript

Posted by Jamis on Wednesday, February 9

Several people have asked how I did the Javascript demos in my maze algorithm articles, and while I’ve answered them a couple of times in the comments, I thought it might be interesting enough to warrent its own post.

The demos are actually implemented in CoffeeScript, a really elegant little language that compiles to Javascript. CoffeeScript lets you ignore (most of) Javascript’s warts, while still enjoying all of Javascript’s strengths. I like.

So, the CoffeeScript sources for my maze demos are at https://github.com/jamis/csmazes.

I’ve tried to anticipate most questions about building, installation, and usage in the readme, but in a nutshell:

  1. You’ll need to install CoffeeScript if you want to do anything with the code.
  2. “cake build” will compile the sources to Javascript.
  3. “examples/index.html” has widgets for all the implemented algorithms for you to play with.
  4. “Maze.createWidget” is the quick-and-easy way to embed a maze somewhere.
  5. You can do it the hard way, too, if you need more control: instantiate a maze with the algorithm of your choice, then call Maze#step until the maze is generated (or Maze#generate to do it all at once).

Note that the implementations there are optimized for animating the algorithms; the source code is not a good place to learn how a typical maze implementation might look. Every algorithm is broken down so that it can be called piecewise, one step at a time. If you were going to implement any of these for any “serious” purpose, odds are you’d do it much more efficiently, and without all the ceremony that csMazes requires.

Still, if you just want to embed an animation of a maze algorithm on a web page, csMazes works quite well. Except for IE7. And probably other IE’s as well. (If you’re an IE guru, I’d appreciate patches, but please make sure your fixes don’t impact the animation performance on other browsers. I was able to make IE render the mazes okay, but then the animation performance on Chrome was abyssmal.)

The code is in the public domain, so do with it what you will. If you do something fun with it, let me know!

Posted in Announcements Projects | 1 comment

20 Dec 2010

Theseus 1.0

Posted by Jamis on Monday, December 20

Whenever I tackle a new programming language, I need a project to apply it to. Just experimenting with syntax isn’t enough; there has to be a real context for it, or it doesn’t stick. Some years ago I discovered a great “default” project: generating mazes.

Mazes explore a lot of the nooks and crannies of a language: random numbers, decision making, recursion and/or iteration, and several data structures, at the very least. If you want to be able to tweak your mazes without changing code, you then need to learn about passing arguments via the command-line, or environment variables, or even configuration files. Add the possibilty of actually displaying the maze and you introduce string manipulation and console IO (if emitting ASCII art), or graphics libraries and file IO (if writing to an image file).

The actual algorithms behind building a maze are pretty straightforward, which is ideal. You don’t want to waste time understanding algorithms when you’re trying to learn a new programming language.

This has served me well for several years. C++, C#, Haskell, Erlang, Scala, Io, and even Prolog! But I realized I’d never actually tried it in my favorite language: Ruby.

So, I gave it a try. And I had a blast. It kind of took on a life of its own, with features evolving as fast as I could implement them. The result: Theseus.

I released Theseus 1.0 last night, and it is available for installation via RubyGems. (You’ll get syntax errors if you try it on Ruby 1.8, though, so beware.) Feel free to fork it on GitHub, too. It’s in the public domain, so you can do whatever you want with it.

I am rather ashamed of the lack of tests, though. I realized as I was building this out that I need a good lesson in real test-driven development. I had a difficult time seeing how to test something like this. I’m going to be reading Kent Beck’s book next, I think.

Here are some examples of stuff that Theseus can do:

Click here to read the rest of this article.

Posted in Announcements Projects | 7 comments

23 Nov 2010

Ekawada: Approved for Sale!

Posted by Jamis on Tuesday, November 23

Last night I received a long-awaited email: Ekawada is finally approved for sale in the App Store!

It’s been a pretty wild ride, from start to finish. The first commit was made on May 25, but I’d been tinkering on it for at least a month before that, learning Objective-C and Cocoa and basically trying to prove to myself that this was something I could actually build. The app was submitted to the App Store on November 3rd, rejected (due to a bug in Ekawada) on the 11th, resubmitted, and finally accepted just last night. And here I am, almost 6 months since that initial commit, offering my creation to the world.

Really exhilarating. Even if no one else likes what I’ve built, I’ve learned a lot, and since I built the app primarily for myself, there will always be at least one passionate user!

So, the sales pitch: if you have an iOS device (iPad, iPhone, iPod Touch) with at least iOS 3.0, head on over to the App Store and download Ekawada. It’s free, comes with eight figures for you to learn, and includes nine tutorials to help you along. And if you happen to like what you see, there are almost 100 more figures (in 5 packs) available for purchase in-app, $0.99 per pack.

And let me know what you think, either with ratings and reviews in the App Store, comments here, notes on Twitter, or even just an old-fashioned email.

Thanks!

Posted in Announcements Projects | 4 comments

09 Nov 2010

Design Forces in Ekawada, Part 5

Posted by Jamis on Tuesday, November 9

In making Ekawada a free app, one of my hopes is that people with little or no experience with string figures might be tempted to download it and give it a try. But a list of string figures and some cryptic instructions are not going to be particularly encouraging to these newcomers; I needed to make sure that Ekawada was suitably welcoming to them, without getting in the way of more experienced users.

The three screenshots below illustrate the approach I took:

Home screen Tutorials list Frequently asked questions

The first screenshot is the home screen, which is the first thing a user will see when they open Ekawada. It includes a limited set of options, and the very first one the user will see is labeled “New to string figures?”. If they tap that option, they’ll be shown the second of these three screenshots: the tutorial list.

Ekawada will ship with 9 tutorials initially. These range from selecting your first string, to basic string maneuvers like the Navaho and loop exchanges. These tutorials are intended for rank beginners, and are focused on teaching things like how to read the notation used in the instructions. The tutorials also include links to some of the included figures, to encourage people to apply what they’ve learned.

If, however, you’re not a complete neophyte, you might not identify as “new to string figures”, but you may still have questions about Ekawada itself. If so, the second option in the list is intended to attract your attention: “Got a question?” Tapping on that option will take you to the third screenshot: “Common Questions”.

There aren’t a lot of questions here right now: just six things that I expect people might want to know. As I get feedback from people using Ekawada “in the wild”, I’ll grow that list.

I’m sure that as the app gets used, deficiencies in my approach here will surface. In the end, the best anyone can do is guess until the app gets put in front of real people, but I’ve tried to anticipate some of the common concerns.

Ekawada is currently “in review”, according to iTunes Connect, and has been since Monday morning. I’ll post as soon as I have more news. You can bet I’m refreshing iTunes Connect some few times per day!

I’ll be heading to New Orleans tomorrow for RubyConf, but if I’ve got some time while I’m there, I’ll try and do another post this week focusing on the Ekawada store, and the process I went through deciding how to organize the initial offering of figure sets.

Posted in Projects Under the Hood | 0 comments

04 Nov 2010

Ekawada: Submitted!

Posted by Jamis on Thursday, November 4

Last night I finished the marketing site for Ekawada (at least, the first draft of it), plugged the last of the memory leaks reported by the Instruments tool, created some app icons that I finally felt did the app justice, and…and… YES! I submitted Ekawada to the App Store!

I’ve been told that the review process for new submissions is currently taking a little more than a week, so with a bit of luck Ekawada could be available for download sometime late next week.

I’m giddy!

Posted in Announcements Projects | 6 comments

03 Nov 2010

Design Forces in Ekawada, Part 4

Posted by Jamis on Wednesday, November 3

For many people, string figures are games that they learned as children, and haven’t touched since. The years are rarely kind to memory, so what this means is there are a lot of people who remember doing figures, but can’t remember what they were called, or how they were done.

I knew, back in April, that Ekawada needed to address this somehow.

The list of available criteria groups

The solution I came up with is based on filtering figures by their attributes. For example, suppose you remember, way back when, doing a figure that had a bunch of diamond shapes in it. You don’t remember what it was called, or how it went, just vaguely what it looked like.

You’d go to Ekawada’s index list, and tap the magnifying glass icon, which would take you to the filter criteria selection page (pictured on right). From here you could drill down further into the specific criteria you want to filter on.

The list of available appearance criteria

In our case, we’d choose “appearance” (since we only remember that the figure looked like diamond shapes), which would take us to the list of appearance criteria.

(Note that with an initial set of only eight figures, most people won’t see much to select here. Then again, they wouldn’t really need to use the filters, either, since eight figures are trivial to scan. But with the other 98 figures installed from the five available packs, the available filter criteria are pretty extensive.)

There’s “diamond”. We’d select it (and any other criteria we want to filter on), and return to the index view.

The index view, filtered to show only diamond figures

The resulting list is still longish (diamonds are a very common theme in string figures), but it’s much better than trying to scan all 100+ rows.

Now, I’m not 100% pleased with this filtering system. It’s functional, but the flow isn’t quite right. I intend to revisit this in later versions, possibly ripping out the current incarnation and replacing it with something more flexible. I’d like to add the ability to search by name, for one thing, as well as the ability to combine filters together. (Currently, selecting more than one filter returns all figures that match any of them: an “or” condition, rather than an “and”.)

In spite of that, the system works as it is and it does let you answer the question, “what was that figure I used to know?”

Ekawada itself is nearly done; I’m wondering if I could possibly have it available to download by RubyConf, though the bottleneck is going to be the App-Store review process. I also still need to flesh out the website and help pages (and a few other marketing-related things), but I’m almost there! It feels like I’ve run a marathon.

I’ll do a few more posts before Ekawada launches; the next one will talk about how Ekawada answers the question: “I’m new to all this—where do I start?”

Posted in Projects Under the Hood | 2 comments

01 Nov 2010

Design Forces in Ekawada, Part 3

Posted by Jamis on Monday, November 1

String figure books are great resources, but they can be incredibly frustrating, too. Even if you’ve never tried to use one, it’s not hard to imagine having a string looped around your fingers, trying to hold the book open with your knee, and then discovering that the next step wraps onto the next page. You somehow need to turn the page without dropping any strings, and without closing or dropping the book.

It is no surprise, then, that this became one of the design forces that drove Ekawada’s construction.

Figure detail shows steps in scrollable table

Now, given the constraints on the size of an iPhone screen, it isn’t feasible (in general) to display all of the steps for a figure in one screen, so there still needs to be some kind of “next page” operation. However, the touchscreen makes this much easier to do than with a physical book.

This screenshot shows the “figure detail” view. It gives you a nice big picture of what the final pattern will be, and then a sequential list of the steps to accomplish it. As you can see, the number of steps for “Osage Diamonds” (a.k.a. “Jacob’s Ladder”) exceeds the available screen real-estate, and so bleeds off the bottom. But that’s no problem on an iOS device, because you can simply swipe to scroll, and a swipe is much easier to do with strings on your fingers than trying to turn the page of a physical book.

Zoomed detail shows each step in full screen

Further, if you tap any row in the instructions, you’ll be taken to a “zoomed” view. Here, each instruction is displayed full-screen, including any illustration or clarification for that step. (Not all steps have illustrations or clarifications, but for those that do, you’ll find them in this view.) You’ll also get an indicator of how much further you have to go to the end of the figure, and icons for going to the next (or previous) step.

Why icons? I considered doing a “swipe” gesture to go to the next page, but really, a tap is easier to do with strings on your hands than a swipe. (The less motion involved, the better.) I tried to strike a balance between size of the icons (a larger target is easier to hit) and maximizing the viewable area for the step (the less often you have to swipe to scroll a step instruction, the better). The size as it is now seemed best, empirically, but later versions may adjust the balance further.

This zoomed view also answers another one of the design forces behind Ekawada: “I don’t understand what this step is telling me to do.” You don’t want to just add verbosity to the instructions, because more verbosity can actually hurt readabilty. (Just try reading these instructions for the “Apache Door” figure, if you want a concrete example of what I mean.)

Thus, for steps where the instruction itself may be too terse, or ambiguous, I can use the zoomed view to add an illustration, or extra clarification, without bloating the instruction list. When you need more information, you can get at it easily, but for the common case, you can just scan the instruction list.

Tune in next time, when I’ll address another design force behind Ekawada: “I remember learning this one figure as a kid, but can’t remember how to do it now.”

Posted in Projects Under the Hood | 9 comments

28 Oct 2010

Design Forces in Ekawada, Part 2

Posted by Jamis on Thursday, October 28

In my previous post, I talked a bit about one of the “forces” that influenced the design of Ekawada, my as-yet-unreleased string figure catalog app for iOS. In this post, I want to talk about another of the forces that affected the app: “What are some easy figures to do?”

It’s not hard to imagine someone with little-to-no string figure experience being curious about the app, especially since it is free, and downloading it just to see what it’s all about. They might want to start with the easiest figure, just to see if it is something they could really learn. How should the application show this to them?

The figure list, sorted by complexity

From the UI point of view, I took the easy way out: in the upper-left corner of the index is a toggle that lets you switch between “ABC” (alphabetical) and “123” (difficulty) orderings. I’m not best pleased with that solution, though: it’s not very self-explanatory. Expect that to change in a future version of Ekawada, after I have more opportunity to think about how best to present that.

(Ignore for now the blue button at the bottom—that’s there because the view is being filtered to show only the “starter set” of figures. Tapping that button would return the view to the default of showing all installed figures.)

At any rate, toggling the view to “123” gives you the figure list, sorted by difficulty (actually complexity—more on that shortly). The first figure in the list is the least complex, and the one at the bottom is the most complex.

Here’s where things get sticky, though. There is no formal, standardized way to evaluate a string figure and say how difficult it is. If you look at the various string figure web sites that try to categorize figures by difficulty, they all do it in a very subjective way. Sure, you may agree that the “easy” ones are easier than the “hard” ones, but you may also disagree with specific categorizations.

Anyway.

I wanted a way in Ekawada for people to order figures by difficulty, and thus I needed a way to objectively rate figures. After a bit of experimentation and observation, I came up with a system that considers what types of maneuvers are used in each step, and assigns a number to each type of maneuver. Then, the various maneuvers used in a figure are summed, and the figure is given a rating. “Opening A”, for instance, is rated a 10, “An Apache Door” is a 61, and “Cat’s Cradle” is a whopping 196 42. (edit: I updated the system to handle figure sequences better, so Cat’s Cradle has a much more sane complexity rating.)

This gets to the point of “complexity” versus “difficulty”. Cat’s Cradle is rated at 196, but that’s because it is a complex figure (actually, series of figures), and is not actually very difficult. Thus, the rating still doesn’t necessarily tell you what is easy and what is hard, only what is simple and what is complicated.

Often, that’s good enough. I do plan to tweak the algorithm for computing the complexity after Ekawada is released, based on feedback from users. However, I think it’s good enough for version one as it is.

Next week, I’ll talk about how Ekawada balances another of the design forces on my list: “I can’t hold a figure on my hands and turn pages at the same time.”

Posted in Projects Under the Hood | 2 comments

27 Oct 2010

A look inside Ekawada's design

Posted by Jamis on Wednesday, October 27

Around the time I was thinking of doing a native iOS app for cataloging string figures, my co-worker (and master designer) Ryan Singer posted this article and video about “designing with forces”. My take-away from it was that you don’t design with a list of desired features in mind, but instead with a list of focused scenarios that describe barriers that you want your application to overcome. These barriers are “forces” that are acting on the space your solution ought to fit into.

Taking one concrete example in Ekawada, I could imagine someone downloading the app and thinking, “I want to learn a figure that looks cool.” I wanted Ekawada to be able to address that user’s goal, and so this goal became one of the “forces” that the app needed to interact with.

My next step was to consider ways that Ekawada could “balance” that force, pushing back usefully on the “what looks cool” question. It was obvious that in order for a user to know if a figure looked cool, they had to be able to see it, so I knew right away that I needed the illustrations of each figure to feature prominantly in the figure list.

Ekawada index screen

The result is the index screen. The thumbnails are small, but I’ve found that they are sufficiently large to give a good impression of what the final figure will look like. I originally had a second view, with images that were 4x as large, which was intended to let you browse the figures by their illustrations. I took a couple of weeks to build it out, and learned a bunch about subclassing and customizing UITableView. Alas, it was a darling I had to kill, though I may bring it back eventually (once in git, always in git, eh?). It turned out that the view was not really much more useful than the index itself, and removing it helped to simplify the UI a bit.

All told, my original list of “forces” included nine different questions and scenarios that I wanted Ekawada to be able to answer, and for this first version I believe I’ve been able to address at least eight of them. I may do some more posts about those other design forces and how I tackled them, so watch this space.

Ekawada approaches—last night I was able to knock off a few more items from my to-do list (and, well, add one or two more items to it), and I’m really excited about how it is coming. I don’t want to give a release date or anything yet, but my list of remaining issues is only about seven items long, none of which should take more than 30-60 minutes to complete. Almost done!

Posted in Projects Under the Hood | 3 comments

24 Oct 2010

Still here...

Posted by Jamis on Sunday, October 24

Yeah, I’m still around. Just haven’t had a whole lot to say!

I’ve been working, on the side, on an iOS app. It’s been my sole side-project pretty much since March, and in that time I’ve gone from practically zero Objective-C to proud-of-myself. My project is nearly ready to launch.

I’ve talked about it some on Twitter. It started as a web app for collecting string figures (yeah, yeah, I’m still a string figure nut). It’s now a native (and universal) iOS app. It will be called Ekawada (the Nauruan term for string figures).

As I said, I’ve learned a ton. In particular, I’ve realized how much I’ve missed compiled languages and memory management. (I’m not being sarcastic there—I’m serious. Done right, explicit memory management can be extremely satisfying.) I’d like to get back into C/ObjC more.

I’ve learned a ton about iOS, too. It really has a beautiful UI framework, even in spite of the horrendously long method names. I’m still trying to learn “best practices” (I hate that term, but you all know what I mean), and my code base is one long trail of blood and tears, but I think I’m figuring it out.

Ekawada will be available “soon”—I’m pretty much down to word-smithing and setting up infrastructure (web site, FAQ, etc). It will be a free app, featuring 8 string figures of varying difficulties, as well as 8 tutorials to get you up to speed on the notation I’m using. (It’s the ISFA standard notation, if you’re curious.) If the 8 figures are enough to whet your interest, there is a store in-app that lets you purchase “packs” of additional figures. Initially, there will be 5 packs available, each with 19 or 20 figures, and each available for $0.99.

I hope to add additional packs after launch, though they will cost more. The initial set of figures uses the (public domain) illustrations from Caroline Furness Jayne’s String Figures and How to Make Them, but figures I add from here on out will have to be illustrated by yours truly, and that takes a lot of work for an artistically challenged left-brainer like myself!

I’m really pleased by how Ekawada is turning out, and I hope by making the core application free that more people can be introduced to string figures. If you’ve got an iOS device, keep your eyes peeled for the announcement!

Posted in Projects | 4 comments

01 Mar 2010

Unobtrusive, yet explicit

Posted by Jamis on Monday, March 1

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.

Posted in Projects Tips & Tricks | 36 comments

14 May 2009

BucketWise v1.1.0

Posted by Jamis on Thursday, May 14

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.

Posted in Announcements Projects | 20 comments

08 Apr 2009

BucketWise: Preview #2

Posted by Jamis on Wednesday, April 8

“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. :)

Posted in Projects | 12 comments