Ruby

Although I do copiously mention Ruport as a sick obsession of mine, I try not to use this blog to directly promote the project. However, I think that I have some news-worthy info to share about the project, or at least something really exciting to ... [More] me: We just put out our first 1.0 release candidate! This is a rough RC, we expect quite a few changes before things finally gel. We also are farther behind on documentation then we want to be, but the functionality is getting quite good and after a 2.5 month hiding period, we’re excited to open the code back up to a whole lot more eyes. If you’ve seen Ruport in the past, you may have been disappointed with our lack of grouping support, or the absense of the ability to render data by row rather than all at once. Or maybe you didn’t want to figure out how to deal with our rails plugin to use ActiveRecord in a camping project, or standalone. You might have also found our formatting system too brittle or our PDF support too weak. Those things have changed. Come tell us what you think :) Some links: RC1 release notes Ruport Mailing List Wiki/Trac That should be enough shameless self promotion for now, but in all honesty, the overall improvements to Ruport have come through the support of our users, contributors and developers. Also, Mike Milner is now churning about at much code as I am, and you can thank him for the revamp of our ActiveRecord support, which has finally made it’s way back into Ruport’s gem. Looking forward to any and all feedback. If you’re on Freenode, you can usually catch up with us in #ruport, if you want to just chat informally. [Less]

Via loudthinking.com, DHH points to the Magic Multi-Connections plugin by Nic Williams. This plugin could be used in any number of ways, Nic has a recipe for randomly selecting a connection from a pool, but the plugin could just as easily be made ... [More] to work with a set of model objects spread across multiple databases. The interesting story behind this is on DHH’s blog. Read: Alex Payne’s interview, then read David’s response, and finally the post from Sunday Scaling to multiple databases with Rails. Update from Pat Eyler (12:15 PM Central): http://glu.ttono.us/articles/2007/04/15/on-twitter-rails-and-community Kevin makes some important points about how the community should/does respond to people pointing out things that RoR doesn’t do well. He also has a good analysis of the response Alex Payne’s interview and offers some ideas for how this conversation could have happened differently. [Less]

I spend most of my time building relatively large applications with Ruby, and this makes me forget how easy the quick and dirty hacks are. In less than the time it’d take me to google the right UNIX tool for escaping HTML, here is my tiny script ... [More] that I use for things like blog entries and mass spam emails. #!/usr/bin/env ruby require "cgi" puts CGI.escapeHTML(ARGF.read) Mmh,… sweet simplicity. If you’ve not worked with the CGI lib before, there are probably other goodies in there so have a look at the API docs. UPDATE: Sam Aaron does a good job of explaining what this script actually does in the comments [Less]

For the second year in a row, I have the privilege of being a Summer of Code mentor for Ruby Central, the US-based organisation responsible for the promotion of the Ruby language and the parent organisation for both the International Ruby Conference ... [More] and the International Rails Conferences. Summer of Code 2006 was the first time that Ruby Central had an opportunity to participate in the Summer of Code. I gave a presentation to the London Ruby Users’ Group last summer and compiled data about our applications: There were 17 volunteers (mentors). We received 96 applications. We deemed 84 applications eligible (that is, on-topic to Ruby). We had 25 applications that we wanted to support (someone volunteered to mentor). Google granted Ruby Central 10 applications. There were two drop-outs by the mid-term, leaving us with 8 active applications. Of the eight that were left, I believe we had most or all of them complete the work in the summer. I was a mentor for Alex Bradbury’s ARIEL library—and I’ve seen that people have used it since, which makes me really happy. This year, we had 35 mentors judging 41 applications. Thirty-eight project submissions were initially deemed eligible. (One other was later deemed ineligible because the student had submitted two projects and we wanted the student to choose between the two projects.) Of these 38 applications, we had 16 that people indicated that they would be willing to mentor, and Google has granted us 14. If the students and mentors are willing, you will be reading periodic progress updates from these students on this blog. Without further ado, here are the students, their projects, and the mentors under the Ruby Central banner this year, in no particular order: Framework for ETL and Data mining operations in Rubyby Swanand Janardan Deodhar, mentored by Shashank T. Date Matrix module extensions/Various functionality extensions to Ruby’s Matrix moduleby Bonchis Cosmin, mentored by Maurice Edward Borasky dcov - Ruby documentation coverage analyzerby Jeremy McAnally, mentored by Chad Fowler Ruby on Rails load tester pluginby Zachary Coburn, mentored by Scott Laird Cover the core of Ruby with RSpecby Pedro Del Gallego Vida, mentored by Johnathon Hornbeck A Recorder/Code-Generator for FireWatirby Helder dos Santos Ribeiro, mentored by Aaron Patterson Apotomo: Model-Driven Development Kit for Railsby Nick Sutterer, mentored by Patrick Hurley Write a Ruby parser in ANTLR 3.0by wang haofei, mentored by Xueyong Zhi Constraint programming in Rubyby Andreas Erik Johan Launila, mentored by James Edward Gray II A protocol framework for EventMachineby Selem Delul, mentored by Patrick Michael Eyler Extending Debugging Capabilities for Ruby on Railsby Minciu Dumitru Eugen, mentored by Steven A Bristol Rubyland: Extending Desktop Applications with Rubyby Scott Ostler, mentored by Austin Ziegler RSpec suite for Ruby implementationsby Florian Gross, mentored by Marcel Molina Atom Publishing Protocol Support for Ruby Railsby Gerrit Kaiser, mentored by Benjamin Joseph Bleything There’s a lot more details behind the links for each project. I’m really excited about all of the projects this year, not just the one for which I am a mentor. Congratulations to the students: you’ve done a lot of hard work so far. Be ready for even harder work this summer—we’re all excited by your proposals, and we’re ready to help you make them happen. If you want to read more about Ruby Central’s participation in the Summer of Code, check out our page. It’s even worth looking at what the other organisations are doing—this is going to be one hot summer! [Less]

For those who saw my other post on what the RubyForge forum is about, I apologize for the redundancy here. However, I feel like perhaps if some folks pass this reminder along, it’ll get the message out. I’ve seen a huge resurgence of off topic ... [More] posts, and I’m actually feeling bad that people end up waiting for replies only to get the same ‘we don’t deal with those questions here’ reply. The RubyForge support forum is meant to support RubyForge itself. That means that if you have a feature request you might want to talk about before submitting a formal proposal, if you think you might have found a broken service in RubyForge, but you’re not sure, or if you just want to talk to us about some of the stuff we offer, you’ve found the right place. If you have svn access that works on Windows but not on Linux, If you can’t install rails but you don’t suspect our gem servers are broken, or if you just want to ask what a particular library does, please, don’t use the RubyForge forum. You will get much better help elsewhere. I am the only active volunteer monitoring our forum right now, so please… help me out a bit by using the great mailing lists out there! This isn’t to discourage people from using our forum, in fact, if in doubt, post to us anyway. But please, read the FAQ before you post. If others can spread the word by linking my other article on what our forum is for, that’d be very helpful! [Less]

There is Ruby code no mortal being is meant to see, let alone use, for it is pure evil. If you wish to save your immortal soul, then read no further! *SIGH* - Don’t say I didn’t warn you. Since your soul is doomed anyway, I’ll let you in on some of ... [More] the evil things that are possible thanks to Evil Ruby. When Apple released OS X on x86 hardware, thus causing Hell to freeze over quicker than you can say “Power PC”, a solution was needed immediately. It fell upon Belial, acting through his agents Florian Gross and Mauricio Fernandez 1, to solve the problem. Using his fiendish powers, he concocted the Object#unfreeze method: hell = "Hell".freeze hell.frozen? # true hell.unfreeze hell.frozen? # false hell.sub!("Hell", "Heaven") hell # => "Heaven" This is evil, but not half as evil as the machinations of Vassago, who was determined to convert objects of one type into objects of a completely different type! His diabolical plan? To convert dogs into cats! 2 class Cat def mew puts "meow" end end class Dog def bark puts "woof" end end dog = Dog.new p dog.class # => Dog p dog.class.instance_methods(false) # ['bark'] dog.class = Cat # Zing! p dog.class # => Cat p dog.class.instance_methods(false) # ['mew'] Gaap, on the other hand, preferred a much more subtle approach. Instead of altering an object’s class, he decided that it would be much more insidious to allow methods to bind themselves to objects that normally don’t allow it. Using the Object#force_bind method, he could then force dogs to meow! Here’s the code, using our Cat class from above: dog = Dog.new mew = Cat.instance_method(:mew) p mew # #<UnboundMethod: Cat#mew> mew.bind(dog).call # TypeError mew.force_bind(dog).call # => 'meow' In a move that stunned Lucifer herself, Asmodius developed a technique for converting classes to modules on the fly!3 The Object.as_module method allows you to mixin classes without subclassing or resorting to delegation.4 For example: class Bar include Array.as_module end b = Bar.new b.push(1,2,3) p b # => [1,2,3] Lastly, Beelzebub wanted me to mention some of the less evil methods that were added for your convenience. For example you can get the singleton of a class by using the Object#singleton_class method: class Foo end f = Foo.new f.singleton_class # => #<<Class:#<Foo:0x568890>> You can also check to see if you're dealing with a direct value (Fixnum, Symbol, true, false, nil) using the Object#direct_value? method: x = 666 y = 'hell' z = nil x.direct_value? # true y.direct_value? # false z.direct_value? # true This is but a sampling of the evil things possible with evil.rb. There are also methods for implementing a form of multiple inheritance, changing a class’ superclass, and sharing instance variables between two objects. Real world uses All kidding aside, there are some potential uses for the features in evil.rb. For example, you can use it for deferred instantiation and proxy objects 5. It could also be used for implementing certain features of Aspect Oriented Programming, such as cuts.6 There are undoubtedly many other evil uses that this author has not even begun to fathom, but which you may wish to investigate. May the Lord have mercy on your pathetic soul.7 End of Line. 1 Both sold their souls many years ago. Long story. 2 Cats, as we all know, are natural agents of Satan. 3 Not one of Beelzebub’s flies obviously. 4 Scholars have often noted the similarity between “Asmodius” and “as_module”. 5 http://weblog.jamisbuck.org/2004/4/23/side-effects-of-deferred-instantiation 6 http://wiki.rubygarden.org/Ruby/page/show/AspectOrientedRuby,    http://wiki.rubygarden.org/Ruby/page/show/AspectOrientedRuby/NotesRoughDrafts 7 This article is satire. The author does not actually believe that Florian Gross or Mauricio Fernandez sold their souls (to his knowledge, anyway). Nor does he believe in the notion that cats are natural agents of Satan, the four princes of Hell, or that OS X actually runs on x86 hardware. [Less]

If you’re writing a C extension for Ruby, and you’ve got method that has optional arguments, be sure to use rb_scan_args(). Do not count argc. Read on if you want to know why. First, let’s start with an example of bad code: /* Example 1 */ static ... [More] VALUE my_func(int argc, VALUE* argv, VALUE self) { VALUE v_name, v_age; switch(argc){ case 1: v_name = argv[0]; v_age = INT2FIX(25); printf("No age; defaulting to 25\n"); break; case 2: v_name = argv[0]; v_age = argv[1]; printf("Age set\n"); break; default: rb_raise (rb_eRuntimeError, "invalid arguments"); } /* Do something with v_name and v_age */ return Qnil; } Based on this example, it looks like the programmer wanted the my_func method to take one mandatory argument (the name) and one optional argument (the age). If no age is provided by the end user, default to 25. Before I go on to explain why Example 1 has problems, let me show you a good example so that I can compare them point by point later on. Assume this is a method of a ‘Foo’ class: /* Example 2 */ static VALUE my_func(int argc, VALUE* argv, VALUE self) { VALUE v_name, v_age; rb_scan_args(argc, argv, "11", &v_name, &v_age); if(NIL_P(v_age)){ printf("No age; defaulting to 25\n"); v_age = INT2FIX(25); } else{ printf("Age set\n"); } /* Do something with v_name and v_age */ return Qnil; } Let’s start with the obvious. Example 2 is not only a few lines shorter, it’s easier to read. That’s always nice. It’s also easier to maintain. If we were to refactor this method to accept an optional third argument, Example 1 would require yet another case break statement. Worse, if we need to handle “if arg1 and arg3 but not arg2″ we’ll have to drop the switch statement completely and resort to a bunch of if/else clauses. Ick. In example two, we would merely have to alter the rb_scan_args() line slightly to handle a potential 3rd argument. Logic changes would be easier to handle, since we would be checking their values individually instead of trying to base our logic on an argc count. The second issue with Example 1 is that it requires manually raising an exception if the argument count is bad. If you look at the default action for the switch statement it has an explicit rb_raise() call. The rb_scan_args() function, on the other hand, will automatically raise an ArgumentError if you try to pass too many (or too few) arguments. No extra code required. There is more to this issue than automatic arity checking, however. The manual handling in Example 1 doesn’t provide any detail in the error message itself. If you use rb_scan_args(), it will not only raise an error, it will also tell you how many arguments you tried to pass versus how many arguments the method actually accepts: Foo.new.my_func("Dan", 25, 9999) => ArgumentError: wrong number of arguments (3 for 2) Our code from Example 1 would merely have returned “invalid arguments” without giving us a clue as to what we did wrong. One last note about the exception handling in Example 1 - it returns the wrong kind of error! It raises a RuntimeError instead of an ArgumentError, which is what Ruby programmers would expect. By using rb_scan_args() you can avoid making yet another mistake.[1] Lastly, and most importanly, there’s a potentially serious bug. What happens if the user passes an explicit nil? Consider what would happens with the following output: Foo.new.my_func(”Dan”) # No age, defaulting to 25 Foo.new.my_func(”Dan”, 37) # Age set Foo.new.my_func(”Dan”, nil) # Age set ?!?! Did we really want to handle explicit nils this way? Probably not. Your end users may not always know in advance what they’re passing as the second argument to my_func. While not much of an issue in our example, it could be a much bigger issue in more complex code where you could have multiple dispatch going on internally. The code in Example 2 does the right thing - it explicitly checks for a non-nil age instead of assuming that an argc count of 2 means there are two legitimate arguments. Explicitly checking each argument greatly reduces the possibility of your code doing the wrong thing when dealing with explicit nil (or false) [2]. Indeed, it was this sort of code that led me to always add tests for explicit nil and false as a regular part of my test suite regimen. One last point. For some time it was believed that counting argc was faster than using rb_scan_args(). I put that myth to rest in this thread, where my benchmarks demonstrate that the speed difference is so insignificant as to be irrelevant. To sum up, always use rb_scan_args() instead of counting argc because: It’s shorter and cleaner It’s easier to maintain and refactor It does automatic arity checking for you It’s less error prone It’s plenty fast Enjoy! [1] I didn’t just make this up - I’ve seen it. [2] And it can often be eliminated completely by using the defacto type checking that are builtin to methods like StringValuePtr() or INT2NUM() in case they try to pass a bogus non-nil value. [Less]

Here’s a little problem I ran into in some old code of mine. Sometimes we’ve got methods where we want to return a new instance of the same class. It’s tempting to write the following code: >> class A >> def a_whole_new_me >> ... [More] A.new >> end >> end Sure enough, that seems to work: >> a = A.new >> a.class => A >> a.a_whole_new_me.class => A So what’s wrong with it? We forgot about subclasses! >> class B < A; end >> b = B.new >> b.class => B >> b.a_whole_new_me.class => A If we’re expecting a copy of B and get A, this is certainly going to cause trouble, but the scary part is it might not right away (since B usually has all of A’s methods, but not necessarily the other way around) Luckily, this is easy to fix, just use self.class >> class A >> def a_whole_new_me >> self.class.new >> end >> end >> a = A.new >> a.class => A >> a.a_whole_new_me.class => A >> class B < A; end >> b = B.new >> b.class => B >> b.a_whole_new_me.class => B This practice is usually a good idea whenever we want to refer to our class object. Rather than making things rigid, if you use self.class when possible, your code will be easier to extend and behave better in general. Of course, your mileage may vary depending on your task. [Less]

We’ve put some effort into increasing the signal on this blog over the last week or so. I personally am super happy with the new content up here. But it’d be interesting to see what folks think about our progress as a whole. So like a truck driver ... [More] with a “How’s My Driving” sign on his big rig, I’ve created a Jyte claim. It’s simply, “The O’Reilly Ruby Blog has improved since 2007.03.21″ Anyone with an OpenID can come support or bury this claim, and let us know if we’re truckin’ fine or veering off the mountain. I’ll try to stop with the meta-posting… expect a Digging Deep article soon! [Less]

I am often asked if I think that clones of Ruby on Rails will become available in insert-your-language-here, and my answer is always “yes and no”. One of the biggest contributions that Rails has made to the industry as a whole was that it challenged ... [More] the conventional wisdom about the way things should be done. In doing so, it showed that there was a better way by actual demonstration. Many of ideas behind Rails are, in fact, being cloned in other languages and their web frameworks. But it is my firm belief that, while these clone/borrowers can approach the productivity of Rails in their language, they will not be able to match Rails completely. The reason for this is found in one simple word: Ruby. The Ruby programming language has a unique confluence of features that made Rails possible. Those of us who have been programming in Ruby for a long time intuitively understand what those language features are, and how they synergistically combine to form the programming language that makes Rails possible. We can even tick this feature list off in our sleep. But it is rare that we are able to articulate the gestalt of these features in a way the nubies can truly understand and appreciate. I know that I haven’t been able to do it! Fortunately, the pressure is off because Jacob Harris knows how to do it, and he wrote a short PDF book that does precisely this: Rubyisms in Rails (available from Addison-Wesley for $9.99). This book just made my A-list of books I recommend to people who want to know what makes Ruby so special. From the book’s web page: Rubyisms is an examination of how the style of Ruby informs the design of Rails. In particular, it looks at a few specific examples of how Rails’ internal code is implemented in Ruby to instruct about Ruby’s design principles. The main goal is simply aesthetic appreciation. But, if you are a beginning programmer in Rails who is stymied in your understanding of Ruby-or an intermediate Rails developer still writing code that looks like Ruby-tinged PHP or Java-this Short Cut will hopefully impart enlightenment and inspiration about the Ruby way of programming. It also reveals how the revolutionary design of the Rails framework can only be built upon the beauty of Ruby. The book is also available on O’Reilly’s Safari Online service: http://safari.oreilly.com/0321474074/pref01 Very highly recommended! [Less]