malvasia bianca

I wrote my first Ruby code yesterday. It was a port of a date wrapper that I wrote in Java for dbcdb: its only job is to convert to/from written representations, and to have some special dates representing “I read this once, but I don’t remember exactly when” and “I’m in the middle of reading this now”.

It took me an embarrassing amount of time (10-15 minutes?) to get the first do-nothing unit test working, but after a bit of flipping back and forth in what I’m apparently supposed to refer to as the pickaxe book, the test worked fine. From then on it was smooth sailing.

Initial reactions:

• Unlike Java, there was a builtin date class that did almost everything I wanted to, so no need to hand-write parsing code. (And, as a bonus, I get a rather more flexible parser.)
• The builtin date class’s output functionality didn’t quite do what I wanted, so I took that as an excuse to write that functionality by hand. I think I wrote it four separate ways, as I found different formatted output mechanisms; for now I’m doing "#{::Date::MONTHNAMES[month]} #{day}, #{year}", but I may well change that again. (Hmm, one bit of that is calling out for an Extract Method, isn’t it? Let me make that change right now…)
• It was very nice to have the source code for builtin classes lying around, both to find what method to call on Date to do what I want and to give examples of how to write something. (E.g. formatted output.)
• Mixins are cool: I just had to add four lines of code to get all sort of comparison functionality.
• The builtin unit test framework is pretty cool, too: I like how it, by default, runs tests for you when you load a test’s source code, and how you can aggregate your test classes into a suite by just requiring one test class after another.
• Having private mean “private to this instance” as opposed to “private to this class” is an interesting design choice. So far, the only ramification is that I’ve had to make one method protected; that seems like a reasonable tradeoff.
• My Ruby date wrapper is a third the length of my Java date wrapper. (The Java version has one or two minor pieces of functionality that the Ruby version doesn’t have, admittedly.) Having said that, I’m not sure this is a very good comparison, because it says more about the vagaries of the respective languages’ builtin date classes than anything else. And I’m not using much of the real power of Ruby – no blocks yet, for example. Still, shorter is better.
• What is perhaps more interesting is that every method in the Ruby version is either one line long or consists of a case statement where every branch is one line long. (Should I Replace Conditional with Polymorphism? Not yet in this case, I think, but it’s a thought.)
• I’m still trying to get a feel for where it’s most stylish to include (or not include) parentheses. For now, I’m not including very many.
• The choice of M-backspace in Emacs ruby mode to do something other than delete the previous word is, shall we say, idiosyncratic. In general, ruby mode isn’t that great, but I can live with it.
• The documentation that I’ve found can most charitably be described as haphazard. I managed to get the gem stuff setup in my local directory, and the gems documentation was reasonably helpful in that regard. Then I wanted to install the mysql gem. It gave me a choice of five versions; the latest one (2.7.1) mentioned Windows, which seemed strange, given that it knew that I was running under Linux. So I skipped that one, and went to the previous version. (2.7 – but the project’s web page says it’s up to 2.7.4?) It wanted to compile some C code (pretty cool, nice to have that automated), but couldn’t find the appropriate libraries. It did give me an error message listing possible configuration options I might want to give, one of which looked right, but didn’t tell me how to pass that option to the install script! (Easy enough if I were doing it by hand, but I wanted to do it within the gem framework.) And the gem documentation didn’t tell me how to do that, either. Eventually, a random web page turned up the trick, but the experience didn’t impress me too much.
• My favorite documentation, um, quirk, though, is the Og rubydoc page saying “You can find a nice tutorial at www.rubygarden.com“. I’m sure I can, but how about a direct link to help me along? (Searching on rubygarden for ‘og tutorial’ didn’t help, though ‘og sql tutorial’ did the trick.) It then continues “Be warned that this tutorial describes an earlier version of Og. A LOT of new features have been added in the meantime.” Yes, well, then maybe you guys could help out a bit? The rubydoc also had a lovely list of features, with no guidance as to how we might use them: I might want something that “Can ‘reverse engineer’ legacy database schemase[sic]” but I’m not in the mood to troll through random crap to try to figure out how.

In general, I’m happy, but I’m hardly using the power of the language yet. The community around the language feels a bit raw, for better or for worse – little documentation, many abandoned libraries, no clear winners in many important spaces. That’s okay, though; given what I’ve seen of source code, I should be able to figure stuff out myself, and I’m happy to contribute documentation improvements, too.

I have more thoughts on Ruby and SQL, but this post is already long enough, so I’ll start a separate post for that.