Ruby

Got a favorite gem you want to tell the world about? Or one you want to warn other people about? You can do both with Gemtacular! Gemtacular (http://www.gemtacular.com) is a place to rate and review Ruby gems. It’s a great place to not only find ... [More] opinions on various gems, but also to see the most recent gem uploads, find the most highly rated gems, or just search for existing gems. Some quick guidelines: * Gemtacular is not a place to report bugs. Use the project page for that. * Be nice. If you have a problem with a particular gem, please explain why without getting nasty. * Don’t be lame and rate your own gems.1 1I already have a feature request in to try and prevent this at http://rubyforge.org/tracker/index.php?func=detail&aid=10063&group_id=2863&atid=11067 [Less]

The most important thing I’ve picked up with each RubyConf I’ve attended is a new outlook on my work. Each year the talks invite people to have their minds bent a bit, both technically and philosophically. Though I didn’t take notes and my ... [More] attention span is usually too low to keep a full talk in my head, the following discussion is largely based on ideas from various talks I attended, especially from Nathaniel Talbott, Eric Hodel, Ryan Davis and Evan Phoenix. It also has some sprinklings from the hallway track, as well as some delusions from the back of my mind. Sorting all that out is up to you. So what is real productivity? Maybe we can look at it as the coding nirvana that we’re all striving for, but I think it’s even more simple than that. True productivity just involves eliminating apathy from your life, leaving you with nothing left but things you care about, and no choice but to take care of them. What follows is a simple extension of that general idea into software practices. Know yourself and your needs. We can learn practices by rote memorization, or we can fake the funk and pretend that some idea we’re holding on to is helping us when it’s really getting in our way. Neither of these things will end up helping us become better programmers, much less happier people. Here are plenty of examples of things from my own life that maybe some of you can relate to: It took me over a year to ‘get’ why TDD/BDD is a good idea. I refused to use TextMate for years because I believed there was one true editor (vim). I’ve followed community models designed for projects with 50 active commiters for projects that only had me and casual contributors involved. I used to think it was inconceivable to not host all your project services on RubyForge I used to care whether or not my projects worked without RubyGems We probably can’t stop ourselves from getting caught up in this cycle now and again, but when we miss the next bit, we’ve really got ourselves in trouble. Listen to the world around you If eight people call you an ass, there might be a pattern forming. Same goes for any serious criticism that pops up again and again. Listening is more difficult than hearing and responding. If you’re skilled at debate, you can present yourself as being correct, justified in your actions, and even untouchable. But the bottom line is, if you’re still an ass at the end of the day, you’ve only succeeding at saving an ass-face. The funny thing is, this isn’t necessarily a permanent state, some really nice people will surprise you with how bull-headed they can become if they get involved in a flame war on a blog or mailing list. I’m not sure if I qualify as ‘really nice’, but I’m probably ‘nice enough’ and if you search some Ruby archives, you can find more than a few instances where there is no evidence of that whatsoever. This almost always is the result of failing to really listen. All it takes is a second of hearing what you wanted to hear instead of what someone actually said, and you’re off on a dead end path. But this isn’t supposed to be a lecture on kindness or ethics, it’s about productivity. Getting mad about technical or philosophical issues rarely results in growth, so cutting it out of your life will inherently make you more productive. Here’s what’s more: In this global community of hackers, we have limitless access to criticism from very smart people. That’s a very powerful tool, if used right. Be meticulous about your practice Some of you may know that I spend a lot of my non-coding time studying Buddhism. Though this is certainly not the forum for religious discourse, there is an especially good concept I found in one of my Dharma books which I’ve applied to all aspects of my life, including software development. This one is so simple, but kind of hard to keep up with: Just be very rigorous about what you do. We try so hard to discipline ourselves, to teach different mind tricks that let us be more productive: The various GTD systems are an example of this. However, it’s worth realizing that the core of all of this is just paying attention to what’s going on in your life. If you find yourself stumbling over a bug more than once and you haven’t written a test for it, write the test. If you can’t do that right away or you don’t know how you’ll do it, write that down somewhere. Noticing that the last hour of your working day always goes way slower than the rest? Look at your schedule and try to figure out why. Whatever problems you’re having in your code, don’t let anything slip through the cracks without at least noticing it. There is a tremendous difference between thinking “Oh, I should learn how to fix this problem”, and “This is the 20th time this problem has come up, and I still haven’t taken the time to learn it”. The latter lets you know exactly where you stand and how these things effect you, the former is the ‘maybe someday’ trap. Take care of the small annoyances, and ignore the big things Whatever happiness we have, it’s mostly relative to how happy we just were. I’ve been playing a lot of the board game Go lately, and it’s really taught me how a single mistake can throw off your mental state and send you tumbling through a downward spiral. Seeing this while playing a game, has allowed me to see it in my work. Ruport provides a great source to practice this idea with for me. I spent over 2 years focusing on how the whole system would come together and how we’d address the problems of our users and even our mythical potential users, completely ignoring a bunch of the small annoyances. Recently, I’ve turned that on its head. Now, whenever I see a method that throws back an absurd error that’s completely incomprehensible, I throw in a fix that handles the case better. Each one of those shaves a few seconds off of my thinking time every single time I encounter the problem again. Sure, maybe there is some big shiny thing in the future that will make my life better, but it’s probably expensive, and it probably won’t pay off right now. The small stuff does. That’s all for now Here is where I start to run out of steam. Maybe it’s because I’m tired, or maybe it’s because if I keep on rolling, I’ll deviate completely from technology and start talking about the divine theoretical toaster of doom, or something even more absurd. But really, what I’m interested is what kinds of things influence your lives as developers, and some of the thoughts and practices that drive you to be productive and happy. So… what is real productivity to you? [Less]

Did you know you can do this with Ruby out of the box? # A real lambda λ { puts ‘Hello’ }.call => ‘Hello’ # Sigma - sum of all elements ∑ [1,2,3] => 6 # Square root √ 49 => 7.0 How difficult was this to implement? Keep reading! # Be sure to ... [More] run with the "-Ku" flag! module Kernel alias λ proc def ∑(*args) sum = 0 args.each{ |e| sum = e } sum end def √(root) Math.sqrt(root) end end Pretty tricky, eh? Just remember the “-Ku”. :) [Less]

Did you know you can do this with Ruby out of the box? # A real lambda λ { puts ‘Hello’ }.call => ‘Hello’ # Sigma - sum of all elements ∑(1,2,3) => 6 # Square root √ 49 => 7.0 How difficult was this to implement? Keep reading! # Be sure to ... [More] run with the "-Ku" flag! module Kernel alias λ proc def ∑(*args) sum = 0 args.each{ |e| sum = e } sum end def √(root) Math.sqrt(root) end end Pretty tricky, eh? Just remember the “-Ku”. :) [Less]

Via ComputerWorld: “Leopard also offers a veritable playground for developers, with Ruby on Rails, Mongrel and Capistrano all baked into the operating system. Developers also get DTrace, which is built into the operating system’s core, allowing ... [More] developers to observe, debug and tune applications in real time.” I guess that also implies that it comes with RubyGems baked in? (Apologies for the shameless Mac-touting and link blogging.) [Less]

Check out Ola Bini’s blog: Updated JRuby on Rails performance numbers. Excerpt: …we are talking about 9.5s MRI to 13.8s for JRuby, which I find is a quite nice achievement if you look at the numbers from Friday. We are inching closer and closer. ... [More] Both the view and the controller numbers are looking very nice. This is actually indicative of a nice trend - since general JRuby primitive performance is really good, the slowness in our Regular Expression engine is weighed up by much faster execution speed. JRuby/MRI seems to be the metric that Ola’s focused on: his numbers give a ratio of 1.45 for Rails Petstore (13.8/9.5) on October 16th. Take a look at this post to JRuby’s Dev list on Oct 4th from Christian Seiler: “JRuby vs MRI - Petstore shootout”. In it he charts the improvement between JRuby revision 4383 (sep 25th) and 4470 (early oct). And he demonstrates about a 20% performance improvement between those two revisions. On October 4th jRuby/MRI was 1.565 for Rails Petstore (29.89/19.10). C. Nutter is also focused on Performance Updates. [Less]

This is a short followup to my last post where I compared library RubyForge statistics against CPAN. This week I compare RubyForge against…the Ruby Application Archive! Yes, I know, the RAA is just a listing service and RubyForge is not. That’s not ... [More] the point. Please read on. In the last post I made a rough guess of about 200 libraries on the RAA that are not hosted on RubyForge. I’m going to go into a little more detail about my findings. Because, man, was I off! First, time in service. RubyForge has been in existence since July 2003. The RAA has been around since December 1999.1 Second, number of projects. As I stated before RubyForge has about 5000 distinct libraries. The RAA has 1610 projects owned by 820 distinct authors.2 Obviously there’s a lot of overlap between the RAA and RubyForge, in that many of the libraries on RubyForge are already listed on the RAA. But many are not, and vice-versa. That’s the point of this article. :) Finally, the overlap. Of the 1610 projects on the RAA, 1182 are NOT on RubyForge!3 It also means that, of the 5000 or so projects on RubyForge, a scant 428 are also listed on the RAA.4 What does that mean? If nothing else, it means you should search both the RAA and RubyForge when you’re looking for a library. There’s some good stuff you won’t want to miss like algebraic libraries, a bunch of blogging libraries, cgi libs, cvs libs, doc manipulators, event libraries, libraries for creating executables, language extenders, feed handlers, html parsers & generators, wrappers for 3rd party C libraries, linguistics stuff, memory mapping, network interfaces, regex engines, graphics libraries, randomizers, and unicode libraries, oh my! It also probably means we should try to get tighter integration between RubyForge and the RAA. Perhaps some mechanism where we can autolink RubyForge projects to the RAA. Thoughts? 1 The oldest listed library is ‘rubymgl’ by Akifumi GuionShouja Nakamura, for those interested. 2 Mostly distinct. There are probably slightly less than 820 authors because a few sometimes use their full name and sometimes they use a nickname. Let’s call it 805 to give us a nice, round 2:1 ratio. :) 3 A few are dead. I didn’t test all the homepage links. 4 The figures aren’t _quite_ that exact because a few people have placeholder projects on RubyForge but host elsewhere. Call it 25%. [Less]

Anyone else think that Godwin’s Law should be amended to include Rails? Just a thought.

Why I switched back to PHP after 2 years on Rails INTRO / BACKGROUND: Back in January 2005, I announced on the O’Reilly blog that I was going to completely scrap over 100,000 lines of messy PHP code in my existing CD Baby (cdbaby.com) website, and ... [More] rewrite the entire thing in Rails, from scratch. I hired one of the best Rails programmers in the world (Jeremy Kemper aka bitsweat), and we set off on this huge task with intensity. The first few months showed good progress, and Jeremy could not have been more amazing, twisting the deep inner guts of Rails to make it do things it was never intended to do. But at every step, it seemed our needs clashed with Rails’ preferences. (Like trying to turn a train into a boat. It’s do-able with a lot of glue. But it’s damn hard. And certainly makes you ask why you’re really doing this.) Two years (!) later, after various setbacks, we were less than halfway done.* (To be fair to Jeremy’s mad skillz: many setbacks were because of tech emergencies that pulled our attention to other internal projects that were not the rewrite itself.) The entire music distribution world had changed, and we were still working on the same goddamn rewrite. I said fuckit, and we abandoned the Rails rewrite. Jeremy took a job with 37 Signals, and that was that. I didn’t abandon the rewrite IDEA, though. I just asked myself one important question: “Is there anything Rails can do, that PHP CAN’T do?” The answer is no. I threw away 2 years of Rails code, and opened a new empty Subversion respository. Then in a mere TWO MONTHS, by myself, not even telling anyone I was doing this, using nothing but vi, and no frameworks, I rewrote CD Baby from scratch in PHP. Done! Launched! And it works amazingly well. It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and and I owe it all to Rails. Inspired by Rails: *- all logic is coming from the models, one per database table, like Martin Fowler’s Active Record pattern. *- no requires or includes needed, thanks to __autoload. *- real MVC separation: controllers have no HTML or business-logic, and only use REST-approved HTTP. (GET is only get. Any destructive actions require POST.) *- all HTML coming from a cute and powerful templating system I whipped up in 80 lines, all multi-lingual and caching and everything *- … and much more. In only 12,000 lines of code, including HTML templates. (Down from 90,000, before.) Though I’m not saying other people should do what I’ve done, I thought I should share my reasons and lessons-learned, here: SEVEN REASONS I SWITCHED BACK TO PHP AFTER 2 YEARS ON RAILS: #1 - “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.” For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap. I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be damned. But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much. Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed. Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so. #2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION By the old plan (ditching all PHP and doing it all in Rails), there was going to be this One Big Day, where our entire Intranet, Storefront, Members’ Login Area, and dozens of cron shell scripts were ALL going to have to change. 85 employees re-trained. All customers and clients calling up furious that One Big Day, with questions about the new system. Instead, I was able to slowly gut the ugly PHP and replace it with beautiful PHP. Launch in stages. No big re-training. #3 - DON’T WANT WHAT I DON’T NEED I admire the hell out of the Rails core gang that actually understand every line inside Rails itself. But I don’t. And I’m sure I will never use 90% of it. With my little self-made system, every line is only what’s absolutely necessary. That makes me extremely happy and comfortable. #4 - IT’S SMALL AND FAST One little 2U LAMP server is serving up a ton of cdbaby.com traffic damn fast with hardly any load. #5 - IT’S BUILT TO MY TASTES I don’t need to adapt my ways to Rails. I tell PHP exactly what I want to do, the way I want to do it, and it doesn’t complain. I was having to hack-up Rails with all kinds of plugins and mods to get it to be the multi-lingual integration to our existing 95-table database. My new code was made just for me. The most efficient possible code to work with our exact needs. #6 - I LOVE SQL Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables. I was always fighting against Rails and its migrations hiding my beloved SQL from me. #7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER Rails was an amazing teacher. I loved it’s “do exactly as I say” paint-by-numbers framework that taught me some great guidelines. I love Ruby for making me really understand OOP. God, Ruby is so beautiful. I love you, Ruby. But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now! You look back at your old ugly PHP code, compared to your new beautiful Ruby code, and think, “God that PHP is ugly!” But don’t forget you wrote that PHP years ago and are unfairly discriminating against it now. It’s not the language (entirely). It’s you, dude. You’re better now. Give yourself some credit. Ok. All that being said, I’m looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning. But I hope that this reaches someone somewhere thinking, “God our old code is ugly. If we only threw it all away and did it all over in Rails, it’d be so much easier!” [Less]

It’s often been said that Perl’s greatest strength is CPAN, Perl’s vast collection of free libraries contributed by developers from around the world. Recently I started to wonder about RubyForge and how RubyForge stacks up against CPAN in general.1 ... [More] First, length of service. CPAN has been around for 12 years (October 1995). RubyForge has been in existence for just over 4 years (July, 2003). Second, the number of users. RubyForge boasts over 20,300 users. CPAN, on the other hand, has far less at just over 6,150 registered users.2 Not every registered user is associated with a project, however. There are 3635 users are associated with a project on RubyForge, while on CPAN there are 3774 users associated with at least one library. Of the 3635 users on RubyForge, 849 are associated with more than one project.3 Third, the number of libraries. CPAN boasts approximately 13,500 separate libraries. RubyForge currently has approximately 5000 separate libraries, organized into about 4800 projects. That means, on average, most projects have one library, but some have multiple libraries per project.4 While RubyForge has far fewer libaries than CPAN, the ratio isn’t nearly as large as I would have thought. Quick aside. I didn’t do any real analysis against Python, but the home page for the Vaults of Parnassus shows 2025 libraries. Fourth, library quality and usefulness (more subjective here). There’s a lot of overlap and, well, cruft on CPAN.5 There are over 300 Acme (joke) modules. There are multiple wrappers for the same underlying library, such as many of the “Tiny” and “Simple” modules. There are libraries that should have been bundled together but weren’t, such as the various Chemistry::PointGroup libs. There are also libraries that have similar or identical functionality to other libraries, such as many of the List and/or Array libraries. On top of that, a healthy chunk of the Perl libraries on CPAN are either unnecessary in Ruby or contain behavior that’s already baked into Ruby itself. Examples include a large collection of OO modules (Class::Accessors and the like), a large number of modules that create various IO, Number, File, Array, String and Hash classes, and related methods, that Ruby has builtin (Array, Array::List, File::chmod, and so on), over 200 “Tie” modules (Ruby doesn’t need ‘tie’), over 90 libraries for interacting with CPAN or the RT backend itself (I only know of one library for RubyForge), and equivalent libraries that are already part of Ruby’s standard library (e.g. libwww). Last, release frequency. Between August 14th and September 14th there were 1133 releases from 690 distinct libraries on CPAN 6. RubyForge, by contrast, had 612 releases in the same date range (although I wasn’t sure how many of them were from distinct libraries at the time of this writing). So, slightly less than half of CPAN at the moment. What do all these numbers mean? Good question. I think, at the very least, it means that the Ruby community is doing very well in terms of library development and releases. I give Tom Copeland a huge amount of credit for that, in that I think the very act of creating RubyForge fostered an atmosphere of development (collaborative or otherwise) and inspired programmers new to Ruby to take the step of releasing their own software. I can’t prove it, of course. It’s just a gut feeling I have after watching the Ruby community grow for seven years. It also means that Perl is still going strong, cruft and all. You can’t really argue too much with their release rate, and some of it is really good stuff, too. I would say that CPAN still has the edge in database interfaces, Apache libraries and wrappers for 3rd party commercial libraries, among a few other things.7 But, we’re catching up, and fast. :) See you next Wednesday.8 1 When I say “CPAN”, I’m generally referring to search.cpan.org plus RT. 2 I scraped the Authors pages to get the total. At the time of this writing it was 6152, although a handful of these appear to be generic logins. 3 CPAN isn’t a collaborative development environment, so there may be multiple users actively associated with a given library, but there’s no way to tell without manually digging through files. 4This number does not include a number of libraries listed on the RAA that are not on RubyForge. I’d make a very rough guess of about 200. (Update: it’s actually over 1000 - see my next post) 5 I should know. I own some of the cruft. 6 There were anywhere from 1 to 10 releases per library in that period. Some had multiple releases in the same day, a curious trend on CPAN. 7 Port a Perl module today! I should mention that I didn’t do any very long term trending, so I guess it’s possible that the releases per month have dropped, but I somehow doubt it. Feel free to prove me wrong (or right). 8Many thanks go to Tom Copeland for providing me with the RubyForge statistics. [Less]