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?

What Happened on Friday

Ben Mabey opened the Hoedown Friday morning with his overview of how to use Cucumber (and related tools) in the Behavior-Driven Development (BDD) of software. He made the point that BDD is a mindset and not a toolset. In other words, BDD is not synonomous with Cucumber and RSpec, and it’s less important which tools you’re using than that you’re doing BDD. Ben’s talk moved at a very quick pace and I found it difficult to follow despite my familiarity with the basic concepts. A number of his slides also included dark text on dark backgrounds, which were difficult or impossible to read. Despite these flaws, he did provide some useful information for Rails developers who are looking to take their BDD skills to the next level. Several of the tools and techniques he mentioned (such as using HtmlUnit with JRuby) were new to me and have given me ideas about how to do more effective testing.

Corey Donohoe was up next. The title of Corey’s talk was “How to Be Simply Awesome,” but I’m not exactly sure what the topic was. It was a bit of a ramble, but entertaining nevertheless. The part that most resonated with me had to do with how he and his co-workers at Engine Yard have structured their internal software projects as collections of services instead of monolithic applications. It gave me some ideas about how we could maybe use Sinatra and JRuby to provide a RESTful interface (for third-party clients) to one of our existing Java-based web applications that’s hurting for an API.

After a break for lunch, Leon Gersing gave a presentation on desktop and mobile application development with Appcelerator Titanium. Titanium has been on my radar for awhile now, and so I was especially looking forward to this talk. One of the most interesting takeaways for me, and one that I had not yet picked up on, was that Titanium’s compiler (if that’s the correct term) will convert embedded Ruby or Python code into Javascript, or at least something that can talk to the rest of the runtime via a Javascript bridge. Don’t quote me on that. But it’s something approximately that cool.

Next up was Luke Kanies, talking about how to use Ruby to develop external domain-specific languages (DSLs). I’ve heard Luke speak about Puppet before, and was afraid this was going to be another Puppet-centric talk. (Not that Puppet isn’t cool, but you know, I’ve heard about it before.) But this was really more of a lessons-learned kind of talk, and a good overview of the motivation, tools and general process for developing external DSLs. Although most of the information that Luke presented was familiar to me, it was nevertheless a timely reminder that despite all of the recent attention on building internal DSLs on top of Ruby, there are some very good reasons to opt for an external DSL. For example, one of the dangers of using an internal DSL is that it makes it harder to restrict what the user is able to do.

Following Luke was Luigi Montanez, on “How to be a Civic Hacker.” Now this was an interesting topic, and one that I don’t believe I’ve ever seen addressed at a Ruby conference (or other tech conferences for that matter). Luigi works for Sunlight Labs, part of the Sunlight Foundation, and their mission is using the Internet to promote government transparency. Luigi posited (a little tongue-in-cheek) that the pinnacle of participatory government, much better than merely tweeting about your pet cause or joining a Facebook group to promote your candidate, is to engage in “civic hacking.” He gave a number of examples of how people are taking the raw data published by the government and turning it into useful information via web applications and other services. The only drawback to the presentation came near the end, where Luigi veered off into a quick demonstration of how one could take advantage of Google’s App Engine gem to publish their JRuby applications to the cloud (and get free hosting to boot). It would have been a good topic for a lightning talk, or even a separate full-blown presentation, but it felt sort-of tacked on to the end of an otherwise coherent talk.

Due to a cancellation earlier in the day, a slot had opened up in the schedule by the end of the day, and so were treated to a surprise presentation by Jim Weirich on “Source Control for People Who Don’t Like Source Control.” He opened by promising us that despite the title, “this talk is not about Git.” Jim went on to construct from first principles how his ideal source code control system would work, if he had to design one from scratch. As time went on, it became clear that while he was describing a mythical SCCS called “csc”, he was in fact talking about how Git works under the hood. Like every presentation of Jim’s that I’ve ever seen, it was thoroughly engaging, entertaining and educational.

What Happened on Saturday

Something I ate on Friday really did a number on me, and let’s just leave it at that. The result was that I didn’t get much sleep on Friday night, and I slept in and generally took it easy on Saturday morning, so I missed several presentations. I heard through the grapevine that there was a good presentation on Heroku, and another on how threads work in Ruby 1.9, so I hope to review the slides for those talks at some later date.

The first talk that I heard after my return to the living was David Chelimsky‘s talk on the use of mock objects in testing. It wasn’t really an introduction to the topic, more of a “best practices” type of talk. I was encouraged (sort of) to see that other people are struggling with some of the same problems that I struggle with when using mocks. For example, it can sometimes be tricky to decide whether to use a “stub” or a mock in a particular situation. David’s advice in this situation is to use stubs to enable execution, but to use expectations (via mock objects) to express the intent of the test. For some of the thornier questions about how to deal with mock objects, David recommended the forthcoming Growing Object-Oriented Software, Guided by Tests, by Steve Freeman and Nat Pryce. (A free preview of this book is also available online.) He also managed to get in a plug or two for the RSpec book, which is currently in beta but should be available in print later this year. I’m reading the beta of this right now, and can highly recommend it for anyone who’s interested in learning how to use Cucumber, RSpec and Webrat for test-driven development.

Then came the lightning talks. I didn’t take many notes on these, but this seems like the time to mention that there was a lot of buzz about MongoDB this weekend. Luigi made reference in his presentation to the fact that MongoDB just reached 1.0 status, and at least two different lightning talks were about MongoDB.

The Ruby Hoedown proper closed with Jamis Buck‘s keynote address. I can’t remember for sure, but I think this was the first time I’d ever heard Jamis speak. He’s very good at it. Jamis opened with a discussion of the art of making string figures. He covered the different notations (or languages) that people use to describe string figures, the “libraries” or patterns of standard moves that are combined and incorporated into more complex patterns, and the string figure-making community at large. He made the point that at first, before you’ve taken the time to really understand how string figures are constructed, the process of turning a simple loop of string into a complex figure can be appear to be “magic”. He went on to relate this to our experience as software developers. The difference between good and great programmers, Jamis said, is the level of understanding, and there are four ways to increase your understanding and thus become a better programmer:

1. Know Thy Tools. Take the time to learn how the tools you use regularly, such as the operating system, text editors, the shell, source code control systems, etc. work.
2. Know Thy Languages. You’re rarely working with just one language, such as Ruby or Java. If you’re doing any sort of web application development, at a minimum you’re also dealing with HTML, CSS and Javascript. Take the time to understand the finer points of these languages.
3. Know Thy Libraries. Know why you’re using the particular libraries you’re using, and what distinguishes them from competing libraries. Engage in code spelunking to understand how libraries work under the hood.
4. Know Thy Communities. Don’t merely be a “consumer” of community resources like mailing lists, forums and IRC channels. Be actively involved, recognizing that for these communities to really work it requires both giving and taking.

And with that, the conference concluded. I know that there were various after-hours parties on Friday and Saturday night, but I didn’t make it to any of those so I’ll leave it to others to say what went on there. It looks like a few photos are starting to appear on Flickr, and I know that people were making pretty liberal use of the #rubyhoedown hashtag on Twitter despite our failure to make the “trending topics” list, so be sure to check out those sources for more insight into the weekend’s festivities!

Update: Tommy Morgan has posted his recap here. If I come across any others I’ll try to remember to link ‘em up here.

Jeremy has set a goal of $15,000, which would cover the basic costs of a venue in downtown Nashville (this year’s conference site), sound and promotional materials. Obviously, if you’re associated with a business that’s able to make a sizable donation, that would be great, but individual donations of any amount are greatly appreciated. See Jeremy’s blog for more details about how you can participate.

As much as I was looking forward to seeing his talk, I’m not a big fan of standing in one place for 30 or 45 minutes, even if I have a wall to lean against, so I headed next door to sit in on David Koontz’s talk on Monkeybars. No problem, I figured, because the Confreaks guys were there recording all of the talks, and the video of Gregg’s talk would be up on their web site at some point after the conference ended. As David Black had noted in a conversation the night before, the fact that you can just catch videos of any of the talks you might have missed has quelled his concerns about RubyConf evolving from a single-track conference to one with multiple tracks.

Fast-forward to this morning, and I’m reading Peter Cooper’s review of one of the latest RailsEnvy screencasts, entitled (wait for it) “Scaling Ruby”. It is a 40-minute long, highly polished version of the presentation that Gregg gave at RubyConf, and it sells for $9. And I think this is great. Gregg and Jason provide a ton of absolutely free material to the Ruby and Rails community, including their popular weekly RailsEnvy podcasts. I’m sure that a lot of work went into producing the video, as well as the PDF that comes with it, and it is probably a great value for anyone who’s interested in purchasing it.

The thing that I didn’t realize until I got to the review’s comments section, however, is that Gregg apparently chose not to have his RubyConf presentation recorded. I didn’t even realize that this was an option, probably because it’s an option that no other RubyConf presenter has ever exercised. Jeremy McAnally, organizer of this year’s Ruby Hoedown, also indicated that Gregg didn’t want his Hoedown talk recorded either. Bottom line: If you (like me) missed his talk at RubyConf this year, you’re not going to see it.

Gregg did chime in with his response to some of the negative comments on the review, and you can (and should) read those to hear his side of the story. His defense is that he put a lot of time into preparing for his presentation, and that he deserves to be compensated for that, and that if a free Confreaks recording of the same material were available that no one would buy the screencast. All of those things are probably true. (He does neglect to mention that the $250 conference registration fee is waived for presenters; perhaps he also chose to pay that fee in lieu of having his talk recorded.)

Let me be clear that while it is quite possibly a serious PR blunder on his part, Gregg didn’t break any “rules” and hasn’t done anything unethical per se. There’s also nothing on the RubyConf site, or in the conference materials, that guarantees video of each and every conference presentation will eventually be available on the Confreaks site. And before someone accuses me of being a free software zealot who believes that “information wants to be free”, let me reiterate that I’m not opposed to folks charging money for their work. Baby needs new shoes and all that. I would simply request that in the future RubyConf organizers consider requiring conference speakers to agree to have their talks recorded; or, barring that, being a little more up-front somehow communicating with conference attendees about which conference presentations are truly “can’t miss”.

The conference was held at the Omni Orlando Resort at ChampionsGate. The Omni is big place, and they were hosting several other conferences at the same time as as RubyConf (including, ironically, some sort of tanning convention). The resort has two or three swimming pools, including a “lazy river” which I took advantage of for a couple of hours on Saturday afternoon. They also have a golf course if you’re into that kind of thing, and free shuttle access to the Disney parks. As a location for a technical conference, however, the Omni is sort of a mixed bag. There are a number of seating places throughout the hotel where groups of Rubyists could gather to talk or hack on things, which was convenient. The (free) Wi-Fi coverage throughout the hotel was also very good. The resort is fairly isolated, however, and as a result those of us without cars were mostly restricted to eating at the pricey on-site restaurants. A shortage of power outlets in the conference rooms also presented a challenge for those of us using notebooks with short battery lives, but in hindsight I think it was a good thing that I wasn’t able to leave my computer open for very long during the presentations. I was a lot less distracted by IRC, Twitter, e-mail, etc. and I got a lot more out of the presentations as a result.

If there was a unifying theme for this year’s RubyConf, it was probably “love”. We heard a lot about love this weekend. And that’s not a bad thing, but it was no doubt a reaction to some of the pre-conference controversy and the more general problem of divisions in the Ruby community that have become more pronounced over the last couple of years. We also took time out to recognize the contributions of Guy Decoux and Itojun, both important Rubyists who passed away this past year.

This year’s RubyConf had three tracks, and I saw a lot of really excellent presentations. I’m not going to try to summarize the talks, because the conference videos will be up on the Confreaks site in due time, but I will mention a couple of presentations that you should look for. I’ve been trying to up my testing game over the last month or so, and Francis Hwang’s talk on “Testing Heresies” (Thursday afternoon) dealt with a number of dogmatic beliefs that we tend to have about testing and why some of those ideas may not hold up under examination. Greg Borenstein’s presenation on “Ruby Arduino Development” (Friday morning) was really interesting to me, and included a number of really compelling demos (including, at the end, a Ruby-powered drink mixer). Jim Weirich’s talk on “What Every Rubyist Should Know About Threads” (Friday afternoon) was a good refresher course for me; as I told someone, about once a year I need to hear (or read) what someone smarter than me has to say about developing mutli-threaded applications, so I’m sure still on the right track. Jake Scruggs’ talk on metrics (also on Friday afternoon) was a good survey of the tools available for static code analysis (such as RCov, Flog, and Saikuro) and how to interpret their results. Finally, Neal Ford’s talk on “Advanced DSLs in Ruby” (on Saturday morning) covered a number of techniques for building DSLs in Ruby and the best practices for doing so (along with some of the problems you can run into in the process).

So, all in all, another great RubyConf. Many thanks to Ruby Central, the conference organizers, and FiveRuns, the conference sponsor!

You kept asking for it and so here it is – the new short, intensive, online course that helps you create UI’s using FXRuby and with YAML and ActiveRecord (with Migrations) helps you access a database.

I think I may have been a little under the weather, or maybe it’s just old age, but for whatever reason it was a really low energy weekend for me and as a result I didn’t get as much out of the conference as I’d hoped. I also came to realize that there are some downsides to attending a Ruby conference in your home town: when (if) you head home after the conference is over, you miss out on a lot of the informal stuff (like hacking and Werewolf) that takes place in the conference hotel(s) after hours. But it was a great conference nonetheless, and I do want to comment on a few things that I observed.

The RailsEnvy guys kicked things off with a whirlwind tour of “Ruby Innovations” during the last year or so. They actually went into more depth than I was expecting, and it was a really informative and entertaining presentation. Hopefully, they will post their slides soon, as it’s just too long of a list for me to try to reproduce here in any detail.

Next up was Robert Dempsey, who spoke generally about cloud computing and more specifically about how you could use Ruby and Rails with cloud computing services. It was an interesting topic, but Robert spent a lot of time talking about the various vendors of cloud computing solutions and comparing their plans, at the cost of a rushed presentation towards the end of how to actually do anything with those services. Given the audience, it might have been better to just pick one of those services for demonstration purposes and focus on showing actual running code.

Jim Weirch’s and Joe O’Brien’s wonderful “Mock Dialogue” presentation confirmed what I already knew, which is that I still have a lot to learn about software testing. I understand why it’s important, and I do it, but I’ve always had the feeling that I’m not doing it quite right. During a subsequent lightning talk, Bryan Liles mentioned that when he decided to get serious about testing, he made a point of really digging in and studying it, to see how other people were testing (or maybe I just imagined that he said that). I think that’s what I need to do, really immerse myself in it until it comes more naturally.

There was actually a lot of focus on testing throughout the conference, another reminder of how integral the concept is to software development with Ruby and Rails. I was really looking forward to Rick Bradley’s talk (on day two), which promised to “show how to transform a Ruby application without tests into a well-spec’d system with good test coverage.” Given that I’ve recently started working with two large Rails applications that have no tests, I was hoping that Rick would reveal some big secret that would solve this problem for me in no time. As it turns out, the method that he outlined, of writing what he calls “characterization tests” as a stepping stone to real specifications (and refactoring along the way) is more or less what I’ve been doing. Ah, well. Work goes on.

The last regular presentation on Friday afternoon was Rein Henrichs’ talk on “Ruby Best Practice Patterns”. Because I had only a few days earlier read Rein’s article in The Rubyist, I didn’t get a lot of new information from this talk—but that’s not Rein’s fault. It was entertaining, and he was able to use humor to make his point very effectively. There was also a really good discussion during the following Q&A about what constitutes “best practices” in Ruby software development. I’m looking forward to reading Rein’s upcoming book on this topic.

Chris Wanstrath’s keynote presentation on Friday evening was unlike any other I’ve seen at a Ruby conference, and it was a nice change. He talked about a lot of things, but what I took from it was that it’s important to keep refining your skills because you never know what opportunities those skills will lead to; you may not ever paid for your work on open source side projects, but the experience that you receive and connections that you make may result in new employment or business opportunities. It was an inspiring speech (without any slides), and I hope he’s planning to post the text on his blog.

Day two started with Troy Davis’ presentation on “Calling Your Code: Gluing Phone Calls to Ruby”. I noticed that Troy was throwing around a good bit of technical jargon, but I was late arriving to his talk and it may be that he explained a lot of those terms at the beginning. Regardless, it didn’t take away from the impact of the live demos that he gave of the technology. Troy demonstrated two or three really neat applications that used Ruby (via Adhearsion) to accept and react to incoming phone calls, or to place outgoing calls.

Another issue that I’ve been dealing with in those Rails applications that I mentioned earlier is the sometimes complex business logic used to determine how the models transition between various states. I was familiar with how rule engines worked, and I’d even heard Joe Kutner talk about his Ruleby project before, but it wasn’t until his presentation on Saturday afternoon that it finally started to click with me about how I might be able to use this to extract and codify the various rules that have snaked their way throughout the models and controllers of our code base.

Heading into the conference, there was a lot of hype about Giles Bowkett’s Archaeopteryx talk (versions of which he’s given at earlier conferences). I made a point of not viewing any of the videos from the previous times he’s given this talk, so I don’t know how much this one differed from those, but it wasn’t exactly what I was expecting. Without giving too much away, Archaeopteryx isn’t the real focus of the talk. Watch it if you get a chance. It was entertaining, to be sure: Giles’ presentation style is sort of a Takahashi on speed. I predicted in the IRC backchannel that his presentation would spawn a lot of bad copycats (of his style, not the content) and was assured that there has already been at least one such (failed) attempt.

The conference closed with David Black’s Saturday evening keynote talk on Ruby versions, past and present. It’s really cool to see someone with a such a deep understanding of the language (as David has) workthrough the evolution of Ruby from its earliest days until the present. He began with a demonstration of Ruby version 1.0, noting some of the bread-and-butter Ruby features that were missing from that version (such as the frequently used puts and methods methods), but also highlighting some of the core metaprogramming features that were already present even in that very first release (such as opening singleton classes to add functionality to instances). During the latter part of his presentation, he introduced some of the new features from Ruby 1.9 and talked about the implications of those changes. It was a great way to wrap up the conference.

As always, one of the best things to come out of the weekend was the opportunity to meet new people and learn from them. One of my concerns over the last few months has been what we could do to jump-start our local Ruby and Rails user group. The group was originally organized last summer, and we got off to a reasonably good start, but as time went on people lost interest and the group is more or less disbanded at this point. Which is unfortunate, because if the number of people subscribed to our Google group is any indication, there’s a good bit of interest in Ruby and Rails in this area. So I made a point of speaking to several people about what has or hasn’t worked in their local user groups, to get an idea of how we might reconstitute the Huntsville group. I think that a major problem we had was that there was no focus for the meetings. We couldn’t get very many people to sign up to give presentations, and as a result most meetings involved the guys sitting around and chatting for awhile before taking off. One suggestion to overcome this was to try out a lightning talks format, to engage people who don’t have the time to put together a full-blown formal presentation but might willing to speak for five or ten minutes on something interesting that they’re working on. Another suggestion was to try to organize a BarCamp or some other sort of informal conference, to bring more attention to the group.

Somewhere around the end of the first day, Jeremy announced that he’s working on Nashville’s Opryland Hotel as the site for next year’s Hoedown. His goal is to have the conference funded entirely by sponsors, and for attendance to be free (it was $199 this year). It’s an ambitious goal to be sure, but I’m interested in seeing how things turn out and to what degree it will impact attendance and participation.

• Giles Bowkett will be speaking about Archaeopteryx, a Ruby-based system for auto-generating, self-modifying music. I’ve heard nothing but rave reviews of this project, which Giles has previously spoken about at GoRuCo and the MountainWest Ruby Conference.
• Gregg Pollack and Jason Seifer (of RailsEnvy blog and podcast fame) will be speaking about a number of the most useful, ingenious and innovative developments to come out of the Ruby community over the past year. If you saw Gregg and Jason in the MVC Public Service Announcement videos at RailsConf, you know that this is bound to be an entertaining presentation.
• Rick Bradley will be speaking about the problem of transforming a Ruby application that doesn’t have any tests into one that’s well-spec’d and has good test coverage. I’m especially looking forward to hearing this talk!
• Rein Henrichs is the author of an upcoming book on Ruby best practice patterns (inspired by Kent Beck’s Smalltalk Best Practice Patterns book) and he’ll be speaking about that, with examples from the book.
• Robert Dempsey will be speaking on how to employ Ruby in “cloud computing” applications, via services like Amazon.com’s Elastic Compute Cloud (EC2) and Simple Storage Service (S3). This is another talk that I’m looking forward to, given all of the recent development in this area.
• Joe Kutner will be speaking about Ruleby, a rule engine for Ruby. If you’ve never used a rule engine before, you may be surprised to learn how this declarative style of programming can complement the procedural Ruby code that you’re used to.
• Finally, Troy Davis will take a look at different APIs you can use to develop Ruby applications that can interact with phone calls to varying degrees (via platforms like Asterisk and FreeSWITCH).

In addition, we’ll have a Charity Tutorial Breakfast session during which Jim Weirich and Joe O’Brien will discuss the use of mock objects in testing. Sounds good, right? If you haven’t registered yet, get to it! The Hoedown will be held August 8 and 9 in Huntsville, Alabama. We’re looking forward to seeing you there!

$ sudo gem install gchartrb

def bar_chart
  GoogleChart::BarChart.new('600x200', 'My Chart', :vertical) do |bc|
    bc.data 'Trend 1', [5,4,3,1,3,5], '0000ff'
    bc.data 'Trend 2', [1,2,3,4,5,6], 'ff0000'
    bc.data 'Trend 3', [6,5,4,4,5,6], '00ff00'
  end
end

The toescapedurl method for the BarChart object returns a URL from which we can retrieve the chart image data in PNG format. We can in turn use that data to construct an FXPNGImage, and place it inside an FXImageFrame:

FXImageFrame.new(self, nil, :opts => LAYOUT_FILL) do |f|
  f.image = FXPNGImage.new(app, open(bar_chart.to_escaped_url, "rb").read)
end

The result is a nice little bar chart, as shown here:

The keynote speakers for this year’s conference will be David A. Black and Chris Wanstrath. If you’re interested in speaking at the Hoedown, proposals for presentations will be accepted until June 2. There are approximately 5 slots for full-length presentations (no more than one hour in length, with an additional 10-20 minutes for questions afterwards). You’ll also be able to sign up on the day of the conference for one of the approximately 8 slots for lightning talks if that’s more your speed.

If you register now you’ll pay only $149 (a savings of $50 off the standard registration fee). Last year’s conference in Raleigh was a blast, and I hope you’ll join us this summer in the Rocket City!