“Like Instapaper for Videos”

It has occurred to me more than once in the recent past that it would be neat to have a service like Instapaper, but for videos. A post appeared on Hacker News today announcing Instafilm, which seems poised to fit the bill after the site becomes more stable (I’m getting a lot of errors at the moment, probably due to server overload). In the comments section of the HN post, however, a number of alternative sites were mentioned, including:

They all appear to be free, at least for the basic service. Some of them, like Squrl, also have companion iPhone/iPad apps. Are there any others you’re aware of? Let me know in the comments!

Literate Programming and Clojure

Michael Fogus just published a post about Marginalia, a new documentation system for Clojure based on Jeremy Ashkenas’ Docco for CoffeeScript. It’s work that Fogus started on late last year, and which Zachary Kim (the creator of ClojureDocs) picked up and improved on. The goal for Marginalia is to build a literate programming system, or something close to it, around Clojure.

My first exposure to the concept of literate programming was about ten years ago, when I was still doing a lot of work with Python. Edward K. Ream’s Leo was the tool that I used to experiment with LP, and to be honest, I didn’t get it. The idea of LP, as I thought I understood it then, was that you wanted your documentation and code to be intertwined, and readable: more like literature for humans, and less like a structured formula for computers. But the user interface for Leo required you to build up your system in a highly structured outline form. It was tedious. Writing code with Leo didn’t feel like any sort of programming I’d done before, and trying to write documentation with Leo sure didn’t feel like any sort of writing I’d done before. So after playing with it for awhile, and then getting frustrated with it, I moved on and haven’t thought any more literate programming until this morning.

Marginalia (in its current incarnation) takes a decidedly different, and for me more familiar tack, of embedding documentation comments directly in code. In that sense it’s no different from JavaDoc, or RDoc, or most other software documentation systems today. As you would hope, it picks up directly on the docstrings that you provide for namespaces, functions, etc.

It also parses out more general documentation text that you embed in comments that start with two semicolons.

Note that it supports Markdown-style formatting in both your docstrings as well as these special documentation comments. There’s also support for some fancier stuff, like displaying mathematical formulas written in LaTeX, that uses the MathJAX engine under the hood, but I haven’t gotten around to trying that yet.

I must admit that the primary attraction of Marginalia for me at the moment is that it produces pretty documentation. I’m a sucker for pretty documentation. But I am intrigued by Fogus’ claim that “The very process of using Marginalia will help to crystalize your understanding of [the] problem and its solution(s).” Near the end of his blog post, he proposes a set of guidelines (based on a similar set by Reg Braithwaite) for incorporating Marginalia into your Clojure software development process to achieve that goal.

Now, if you’re really into literate programming, Fogus’ blog post also refers (in a footnote) to Tim Daly’s work on “Clojure in Small Pieces”, a fork of the Clojure source code (re)written in LP style. This strikes me as a very ambitious effort, but one that I plan to keep tabs on as well. It will be interesting to see how studying this re-interpretation of the Clojure code influences one’s understanding of Clojure’s design and implementation.

HuntFunc Meeting: January 4

From the better-late-than-never department, a reminder that the next meeting of the newly-formed Huntsville Functional Programming Group (HuntFunc, for short) will be held Tuesday, January 4, starting at 11:00 a.m. at the 347. That’s tomorrow, for you and me. The plan is for Joe Kutner to give a presentation comparing the concurrency features in various functional programming languages (Clojure, Erlang and Scala). Bret Young will also be presenting a brief introduction to Clojure.

If you’re interested in meeting with fellow software developers to learn more about functional programming languages, how to think about them and use them in your own work, please come join us! We have folks of all experience levels and all are welcome, whether you’re new to FP or have been doing it for years.

hsv.rb Meeting: December 16

The next meeting of hsv.rb (the Huntsville Ruby Users Group) will be held this Thursday, December 16, at 11:30 a.m. The location is the HudsonAlpha Institute, and it sounds like we’ll be meeting in a room “on the first floor facing the atrium on the bistro side.” So there you go. If you’d like to buy lunch there and just bring it to the meeting, you can stop by the Atrium Cafe.

Bryan Powell will be leading a discussion of MacRuby, which is an implementation of Ruby on the Objective-C runtime. Here is a nice introductory article that demonstrates how to build a simple Cocoa application in Ruby, using MacRuby.

Another topic of discussion is the hsv.rb community project. There’s been some discussion of it here, but the goal is to nail down some plans so that we can start this in earnest in the new year.

HuntFunc Meeting: December 7

The next meeting of the newly-formed Huntsville Functional Programming Group (HuntFunc, for short) will be held Tuesday, December 7, starting at 11:00 a.m. at the 347. The plan is for Joe Kutner to give a presentation comparing the concurrency features in various functional programming languages (Clojure, Erlang and Scala).

If you’re interested in meeting with fellow software developers to learn more about functional programming languages, how to think about them and use them in your own work, please come join us! We have folks of all experience levels and all are welcome, whether you’re new to FP or have been doing it for years.

Installing Openfire on Ubuntu 10.04 LTS

When I officially quit working on FXRuby back in August, one of the motivations was to give me more time to work on developing an idea that has been bouncing around in my head for quite awhile now. While I’m not yet ready to make an announcement about that, I will occasionally be writing here about some of the pieces of that app as I get around to implementing them. One such piece is an XMPP (aka Jabber) server.

There seem to be a lot of XMPP servers out there, but two especially popular ones are the Java-based Openfire and the Erlang-based ejabberd. ejabberd has a lot going for it and is used in a number of high-profile settings (most notably, as the basis of Facebook’s Chat service). Nevertheless, I’m more familiar with Java, and I don’t want to get too bogged down with the details of how the XMPP server works (i.e. that’s not the focus of this project), so I’ve decided to start out with Openfire. I did run into a few little problems while trying to get it up and running under Ubuntu 10.04 server, and so I thought I’d take a minute to write about that experience here.

My first step was to download the latest release of Openfire from the downloads page. If you choose the “Linux” option on that page, you’ll be offered four different download package options. I chose the Debian package since I was installing on Ubuntu.

The first snag I ran into was that this Debian package has a dependency on the older “Sun” JRE packages (either sun-java5-jre or sun-java6-jre), which have more recently been replaced by the OpenJDK packages. Assuming you’ve already installed the OpenJDK package(s), you can work around this dependency by telling dpkg to ignore dependencies:

dpkg -i --force-depends openfire_3.6.4_all.deb

The next snag was closely related to this, and has to do with the Openfire startup script that’s installed to /etc/init.d. The first bit of this script attempts to determine JAVA_HOME, but it does so by assuming that you’ll have one of the aforementioned Sun JRE packages installed. To work around this, modify this block of code so that it also checks for the OpenJDK as follows:

At this point you should be able to start the Openfire server by typing

sudo /etc/init.d/openfire start

and then access its administrative console for further setup.

First Steps with Clojure

So I’m starting to learn Clojure, using Stuart Halloway’s book Programming Clojure as a guide. It’s a steep learning curve for me as I’ve only ever done procedural and object-oriented programming, save for a brief dalliance with Scheme in a programming course I took in graduate school.

I get the basic concepts of functional programming (immutable data, functions without side effects, etc.) but am nowhere near the point where this functional mindset comes naturally to me. I still want to break things down into objects, with methods that carry out actions step-by-step.

One of the the things about Clojure that seems to be tripping me up a lot is the syntax surrounding the ns, use and require special forms. For example, one of the first references to use occurs on p. 19 of Programming Clojure, and it looks like this:

A bit later, on p. 38, he reintroduces use, but this time the example looks like this:

Now, I get that in the first example, he’s saying “only use the str-join function from the clojure.contrib.str-utils library,” while in the second example he’s using everything. What I don’t get is the differing syntax, using a quoted vector in the first example, and a quoted list in the second. It sort-of makes me think that this should work too:

but of course it doesn’t, and I get a mostly useless error message in the REPL. Now, if you’re an experienced Lisp, Scheme or Clojure programmer, you probably understand why this last example is wrong and you really don’t understand how I could possibly think that could be right, but I’m just not there yet. But I’m working on it!

Another thing that has hindered my progress a bit is the way that Clojure’s standard library and its API documentation are organized. Take the clojure.core library for example: it contains several hundred functions, and unless you already know the name of the function you’re looking for, tracking down just the right function for what you need is like looking for a needle in a haystack. For example, a little program I was playing with yesterday dealt with a list of maps, like so:

Now what I wanted was to convert this list of maps into a single map, where the names of the relation types were the keys and the values were the relation types themselves; i.e. a result like this:

After looking through the API documentation for clojure.core I decided there wasn’t any function that would perform this kind of transformation directly (or at least not that I could tell). I also determined (I think) that there’s only one function, hash-map, that will produce a map from its inputs; everything else seems to produce a list/sequence. So anyways, I ended up going with this approach:

and it works, but I’m looking at it and wondering, is this the best way to do this? Is there maybe a more efficient approach than first constructing a list of the type names, then interleaving those with the types to produce yet another list, and finally using hash-map to convert it into a map?

Having said all that, the challenge of learning this new (to me) approach to programming is fun, and I anticipate that it’s going to affect how I think about programs that I write in the languages that I already know well, like Ruby and Java. I’m also excited about finally having what feels like a more “practical” Lisp to play with, one that I can use with existing Java libraries that I work with every day.

Moving On

When Jamis Buck wrote last year about ceasing development on Capistrano, his post really struck a chord with me. If this post reminds you of that one, it’s because I re-read it before sitting down to compose this one. It was the next best thing to having Jamis on hand to give me a pep talk before I had to stand up and say something that I’ve been putting off saying for too long. As a bonus, I could visualize him calmly and quietly making one of those neat little string figures while I tried decide exactly what it was I wanted to say.

It is with mixed feelings that I announce that I’m stepping away from FXRuby development, effective immediately. I will no longer be accepting bug reports, support requests, feature requests, or general emails related to FXRuby. I will continue to follow the mailing list, but I am no longer the maintainer of this project.

When I started developing FXRuby back in late 2000, it was a lot of fun for me. I was still new to Ruby (most of us were, back then) and Ruby was in need of a good GUI toolkit, so working on FXRuby provided me with not only a good way to learn the ins and outs of the language, but also to get really plugged into the community. In recent years, however, working on FXRuby has become a chore. I’m a decade older, at a different place in my life and career, and there are frankly just too many other things that I’d rather be working on at this point. These feelings are compounded by the fact that FOX development has, as best I can tell, stalled out, and without anything new to look forward to on the FOX front there’s little motivation for me to continue working on FXRuby. So it’s time to make a clean break and call it quits.

I would like to take this opportunity to thank everyone who did participate in the FXRuby community over the years. Knowing that you found my work of some value means a lot to me, and I appreciate the encouragement that I received from you along the way. I was never successful at organizing a development team around FXRuby, something which I regret, but a number of people contributed patches or third-party tools and extensions to FXRuby. If I tried to name all of those contributors, I would invariably leave someone off the list by accident, so let me just say: Thanks, you guys; you know who you are. A special thanks as well to those of you who bought the book. And of course, I owe an immense debt of gratitude to Jeroen van der Zijp, without whom there would be no FOX toolkit, and thus no FXRuby.

Someone on the mailing list asked whether FOX and FXRuby are “pretty much dead.” I can’t speak for Jeroen or the FOX project. As for FXRuby, however, that’s up to you. FXRuby is, and always has been, an open source project. If you are interested in hacking on FXRuby, or even taking over maintenance of the project, please feel free to fork the project on GitHub and release updates as you see fit. The Wiki has a lot of information about setting up a development and build environment on Windows, Linux and Mac OS X, and if you have specific questions about the build chain I’ll do my best to help you get set up.

If no one steps forward to maintain FXRuby, that’s fine too. The code has been pretty stable, if not bug-free, for quite awhile now, and it may the case that the code’s “done” anyways. If you feel that way and want to continue using FXRuby, it’s not going anywhere. If on the other hand, you have some fresh new ideas about how to move ahead, go for it! I will be cheering you on from the sidelines.

In closing, thanks again for all of your support over the last ten years. I’m certainly not done with Ruby, and I’m looking forward to exploring other ways in which I can participate in the Ruby community in the future.

Book Review: Debug It!

I started programming as a teenager. My first paid programming job involved writing a sort of mail-merge program in BASIC, on a TRS-80 Model II at my Dad’s office. Over the years, I figured out that by adding enough print statements here and there I could eventually figure out what was going on and make the bugs (or at least their symptoms) go away.

Another ten years or so passed, however, before I really learned how to debug software. That happened at my first job out of graduate school, when I went to work for a company that produced commercial software for computational fluid dynamics (CFD) analysis. The sort of scattershot debugging approach that I’d used up until then would no longer suffice. We had customers paying pretty hefty licensing fees to use our software, and when they reported a bug we needed to make sure that we could get a solid, reliable fix out to them so that their work wasn’t disrupted. It wasn’t enough to make the symptoms of the problem go away. We needed to understand what was broken, how it got that way, and only then implement a solution. Fortunately, one of my mentors at that company taught me this more rigorous approach to debugging software, one that I continue to use to this day.

Earlier this year, I had the opportunity to do a technical review of Paul Butcher‘s new book, Debug It! and now that it’s been published I’m pleased to be able to review the final product. A number of classic programming books, such as Steve Maguire’s Writing Solid Code or Steve McConnell’s Code Complete, touch on debugging as one aspect of the software development process, but I’m not sure that I’ve ever seen or read an entire book devoted to the topic of debugging software. In that regard, Paul’s new book fills a pretty interesting niche.

Paul breaks the debugging process up into four stages: reproduce, diagnose, fix and reflect. These stages are covered in detail in the first five chapters of the book, and this is the most important section. In the chapter on reproducing bugs, he touches on topics such as how to control the environmental conditions under which bugs manifests themselves, and techniques for reproducing the inputs that trigger the bugs. He also addresses some of the difficulties involved in dealing with especially difficult-to-reproduce nondeterministic bugs. In the chapter on diagnosis, Paul moves on to the process of forming a hypothesis about what’s causing the bug and then performing experiments to refine that hypothesis until you settle in on a root cause. There are a lot of useful guidelines here, including my favorite: Only change one thing at a time! The chapter on fixing bugs is relatively short, which reflects the reality that once you understand what’s going on it’s usually not that difficult to fix the problem. Here the author stresses the importance of adding regression tests, and making sure that you’re fixing the root cause and not merely the symptoms. The last step is to reflect on the significance of this bug and what it might be telling you about the overall quality of your code (e.g. are similar bugs lurking elsewhere in the code?)

The second section of the book (“The Bigger Picture”) takes a higher-level look at the issues surrounding software bugs, namely, how do you create an environment such that you stay on top of bugs and not fall into an “infinite defects” situation. It addresses topics such as tracking bugs and working with users and the support staff to better understand the bugs they’re seeing in production. The third section of the book (“Debug-Fu”) is sort of a hodge-podge of more advanced topics, I suppose. Some of the information in these later chapters is arguably out of place in this book. For example, Chapter 9, “The Ideal Debugging Environment,” stresses the importance of having automated tests, a continuous build system, and so forth. There’s no question that this is good advice; I’m just not sure that it’s completely on-topic for this book. Having said that, they are good disciplines for any programmer to have, and if the stuff in the rest of this book is new to you there’s a good chance that Paul’s advice on testing and continuous builds is new to you too.

It is important to note that the focus of this book is the debugging mindset, and strategies and techniques that you’ll use when debugging software. It does not teach you how to use any particular debugging tools. If you merely want to learn how to use the GNU debugger (gdb), or the graphical debugger in your IDE of choice, this is not the book for you.

In conclusion, I would highly recommend Debug It! to any junior-level programmer who’s interested in developing a more disciplined approach to debugging. If you’re not a junior-level programmer but still feel like you waste a lot of time debugging, you will probably find this book helpful as well. It’s like having a mentor sitting there with you, teaching you how to take your debugging game to the next level.

Wait, what was that last bit?

So some of you may have seen the news about Gemcutter.org changing its name to RubyGems.org and becoming the new default gem repository for the Ruby community. I’m not completely clear yet on all the pros and cons of this move, but I do have to admit that the new site is pretty to look at. As a maintainer, I like the idea of being able to just type “gem push fxruby” (or whatever the command syntax is) and being done with it. So I think this will probably turn out to be a good thing.

Buried a few paragraphs down in the news, however, is this tidbit:

So, what does this mean for RubyForge? The Ruby-specific functionality and data will be moved into RubyGems.org, and the parts that other hosting sites (GitHub, Google Code, SourceForge) can do better will be pruned away.

In the comments, I asked for clarification on exactly what RubyForge services will be going away, and Tom Copeland’s reply seems to indicate (to me) that the answer is “everything”:

… We’re putting together a schedule for standing down (or making read-only) various bits of RubyForge. The thing is that now there are much better options for hosting code/forums/lists/files/etc, so that stuff is going to be retired. I think back in 2003 it made sense for the Ruby community to have a dedicated site for hosting that stuff. Now I don’t think it does… I think GitHub/Google Code/SourceForge can all do a better job at that, and Ruby Central doesn’t have to expend resources/time/money supporting functionality that others are doing better.

This is troubling to me since several FXRuby-related services (such as the web page hosting, bug tracker, and mailing lists) are handled by RubyForge, and have been for a long time now. For me, it’s not merely a question of, say, finding a new place to host the mailing lists. It’s also making a decision about what to do with the archives, and dealing with all of the non-readers who will go out their way to try to subscribe to the old lists even when they’re clearly marked as inactive and then send e-mails to me to ask why that’s so. But I know that Tom and company are sensitive to these concerns, and we’ll figure out a way to make the transition work as painlessly as possible, so I’m going to try not to be a grumpy old man about it.

So in the meantime, I’m beginning to consider what my post-RubyForge options are. Setting up a dedicated Redmine installation, as Jim Weirich has done for his projects, is an attractive option as it provides one-stop shopping (and I’ve had some experience with setting up Redmine for other projects already). Another option is to go with different sites targeted at the different services, like entp’s Lighthouse for bug tracking, maybe Google Groups for the mailing list hosting, and maybe piggybacking the static web site content off of my personal web site somehow (ugh). What about you, dear reader? If you’re hosting one of the 8,500 projects at RubyForge, what plans are you contemplating for RubyForge’s looming retirement?