Roodi stands for Ruby Object Oriented Design Inferometer. It parses your Ruby code and warns you about design issues you have based on the checks that is has configured.
Changes in 2.1.0:
Roodi stands for Ruby Object Oriented Design Inferometer. It parses your Ruby code and warns you about design issues you have based on the checks that is has configured.
Changes in 2.0.1:
Roodi stands for Ruby Object Oriented Design Inferometer. It parses your Ruby code and warns you about design issues you have based on the checks that is has configured.
Changes in 2.0.0:
I've just released GreenScreen. It's a build monitor that aggregates feeds from your build server and publishes them as large as it can on a web page. The idea is that you can set up a monitor somewhere in your workspace running GreenScreen so that everyone can see the current status of the build all the time.
Other tools like CCMenu and CCTray exist so that people can see the current status on their local computers, and they are absolutely useful. Having something in your workspace that is visible to *anyone* that happens to walk past has some powerful implications though. Many teams actually use a build light or lava lamps that change colour when builds pass or break. GreenScreen is a software based equivalent that you can use on any spare computer.
A widely visible build status means the team is completely transparent all of the time to anyone who can see it. For teams I've coached in recent times, managers, project stakeholders and regular visitors would often ask what the monitor meant, and quickly learnt to ask what was wrong if builds were red. It gave the team a strong sense of commitment to keep the build passing.
I hope you find it useful. Have a look at the pics below for some examples of what GreenScreen looks like for projects with various numbers of builds:
Over the last year or so, there's been lots of great tools coming out in the Ruby community that help with static analysis of code. We've now got flay, flog, reek and roodi. metric-fu runs all of these tools (plus more) to generate nice reports.
Generating nice reports is all well and good, but frankly it's not enough. We need to start enforcing code quality, not just reporting on it. The Java community is way ahead on this front, which I find rather embarrassing as a Ruby developer. Fear not though, I'm going to show you exactly how to set it up here.
First of all, you need a continuous integration build. Don't have one? Fail. Go have a good hard look at yourself in the mirror and consider if you really want to be a professional software developer or not.
If you're still here, you need the tools installed. That's pretty easy:
sudo gem install flay sudo gem install flog sudo gem install reek sudo gem install roodi sudo gem sources -a http://gems.github.com sudo gem install jscruggs-metric_fu
What you've just installed is a set of tools that check for duplicate code, complex code, code smells and code problems. The last one (metric-fu) will give you a report to look at if you need to browse for more details.
Next, you need to add some tasks to your rakefile. For my rails applications, I have this in lib/tasks/quality.rake, but you can put it anywhere that gets loaded by your build.
1 2 3 4 5 6 7 desc "Analyze for code complexity" 8 task :flog do 9 flog = Flog.new 10 flog.flog_files ['app'] 11 threshold = 40 12 13 bad_methods = flog.totals.select do |name, score| 14 score > threshold 15 end 16 bad_methods.sort {|a,b| a[1] <=> b[1] }.each do |name, score| 17 puts "%8.1f: %s" % [score, name] 18 end 19 20 raise " methods have a flog complexity > " unless bad_methods.empty? 21 end 22 23 desc "Analyze for code duplication" 24 task :flay do 25 threshold = 25 26 flay = Flay.new({:fuzzy => false, :verbose => false, :mass => threshold}) 27 flay.process(*Flay.expand_dirs_to_files(['app'])) 28 29 flay.report 30 31 raise " chunks of code have a duplicate mass > " unless flay.masses.empty? 32 end 33 34 RoodiTask.new 'roodi', ['app/**/*.rb'], 'roodi.yml' 35 36 task :quality => [:flog, :flay, :roodi, 'metrics:all']
Now, add the quality task to the list of things done in your continuous integration build. That will make sure these things run all the time. Try running rake quality manually. It will almost certainly fail on either flog, flay or roodi. I'll show you how to tweak them one at a time.
When I ran rake flog for the first time, I got something like this:
~/Data/runway $ rake flog
(in /Users/marty/Data/runway)
42.3: Token#parse_incubation_days
60.4: Token#parse_incubation_date
81.7: ActionParser#parse
89.7: ActionFormat#format
rake aborted!
4 methods have a flog complexity > 40
This tells me that I have four methods in my code base that have a flog complexity greater than 40. If you look back at line 11 of quality.rake shown above, you'll see that this threshold is configurable. Set that number to something that is just higher than the most complex method in your application (in my case, I set it to 90) and run rake flog again. It should pass.
What you've just done is create a stop loss for complexity in your application. If anyone checks in a method that is more complex than the configured threshold, your build will fail. In other words, methods are not allowed to get any more complex than the most complex method in your application now.
Unless you're working on a green fields application, I'll bet that the threshold you set was higher than you want it be. That method that was the most complex in your application needs some refactoring. You've got somewhere to focus your refactoring efforts now though. Pick that method, refactor it, and ratchet down the threshold to the next most complex method. Now you're incrementally improving the quality in your app in terms of complexity.
When I ran rake flay for the first time, I got something like this:
~/Data/runway $ rake flay (in /Users/marty/Data/runway) Total score (lower is better) = 164 1) Similar code found in :defn (mass = 60) app/controllers/signups_controller.rb:5 app/controllers/user_sessions_controller.rb:6 2) Similar code found in :if (mass = 54) app/controllers/forgot_passwords_controller.rb:15 app/controllers/signups_controller.rb:16 3) Similar code found in :defn (mass = 50) app/helpers/actions_helper.rb:43 app/helpers/actions_helper.rb:49 rake aborted! 3 chunks of code have a duplicate mass > 25
This tells me that I have two pieces of code with a mass greater than 30 that have been duplicated. If you look back at line 25 of quality.rake shown above, you'll see that this threshold is configurable. Set that number to something that is just higher than the largest mass of duplicated code in your application. This can be a little confusing, because the tool reports a number equal to that mass multiplied by the number of times it appears. In my case, the reported mass of 60 is actually 30 (a mass of 30 found in 2 places). So I set the threshold to 30. Run rake flay again. It should pass.
What you've just done is create a stop loss for duplication in your application. If anyone checks in code that duplicates an existing mass of code larger than the configured threshold, your build will fail. In other words, people can't copy and paste code in a fashion any worse than they already have.
Again, that threshold you set is almost certainly higher than you want it be. That largest mass of code that was duplicated needs some refactoring to make your code more DRY. Find that code, refactor it, and ratchet down the threshold to the next largest mass of code. Now you're incrementally improving the quality in your app in terms of duplication.
When I ran rake roodi for the first time, I got something like this:
~/Data/runway $ rake roodi (in /Users/marty/Data/runway) app/models/action_format.rb:10 - Method name "format" cyclomatic complexity is 12. It should be 10 or less. app/models/action_parser.rb:11 - Method name "attributes" cyclomatic complexity is 12. It should be 10 or less. app/models/action_parser.rb:30 - Method name "parse" cyclomatic complexity is 14. It should be 10 or less. app/models/token.rb:173 - Method name "parse_incubation_date" cyclomatic complexity is 11. It should be 10 or less. app/models/token.rb:226 - Method name "parse_incubation_days" cyclomatic complexity is 12. It should be 10 or less. app/models/action_parser.rb:50 - Block cyclomatic complexity is 11. It should be 8 or less. app/models/token.rb:11 - Block cyclomatic complexity is 10. It should be 8 or less. app/models/action.rb:103 - Method "apply_defaults_from_name" has 23 lines. It should have 20 or less. app/models/action_parser.rb:30 - Method "parse" has 23 lines. It should have 20 or less. rake aborted! Found 9 errors.
This tells me that I have several pieces of code failing Roodi checks. If you look back at line 34 of quality.rake shown above, you'll see a reference to roodi.yml. This is a config file that allows you to configure Roodi. Create that file in the root directory of your application and paste the following contents into it. It's what I have in my config file.
# AssignmentInConditionalCheck: { }
# CaseMissingElseCheck: { }
ClassLineCountCheck: { line_count: 300 }
ClassNameCheck: { pattern: !ruby/regexp /^[A-Z][a-zA-Z0-9]*$/ }
# ClassVariableCheck: { }
# TODO Get block cyclomatic complexity back down to 6 or less
CyclomaticComplexityBlockCheck: { complexity: 12 }
# TODO Get method cyclomatic complexity back down to 8 or less
CyclomaticComplexityMethodCheck: { complexity: 14 }
EmptyRescueBodyCheck: { }
ForLoopCheck: { }
# TODO Get method line count back down to 20 or less
MethodLineCountCheck: { line_count: 27 }
MethodNameCheck: { pattern: !ruby/regexp /^[_a-z<>=\[|+-\/\*`]+[_a-z0-9_<>=~@\[\]]*[=!\?]?$/ }
ModuleLineCountCheck: { line_count: 300 }
ModuleNameCheck: { pattern: !ruby/regexp /^[A-Z][a-zA-Z0-9]*$/ }
ParameterNumberCheck: { parameter_count: 5 }
This config file describes a list of checks that get run by Roodi, and some parameters that are used to initialise those checks. Have a look at http://roodi.rubyforge.org/ for details on each of those checks. Make a call on which checks are appropriate for your project, and then change the configuration on each item so that your build just passes. What you've just done is create a stop loss for these coding problems in your application. If anyone checks in code that doesn't pass these configured checks, your build will fail.
It's possible that you've had to comment out some checks that you really want on, to get the build to pass. For the ones that are still turned on, you've probably had to increase some of the thresholds. You can find that code, refactor it, and turn checks back on or ratchet down the thresholds over time. Now you're incrementally improving the quality in your app in terms of coding checks.
The installation of metric-fu will give you some nice reports to browse and find the next worst problems in your application. Run rake metrics:all to get that report generated. Put some time aside regularly to clean up your code and ratchet down the thresholds as described above until you get them to a point you're happy with.
As far as I'm concerned, these tools are not an optional extra for your project. You must have them tools set up. It's unprofessional of you not to do everything you reasonably can to keep the quality of your code high. I hope this helps.
Kelly Forrister, who goes by the name GTDCoachKelly on twitter recently ran a GTD Tweekly review on twitter. I found it enourmously valuable, and we're in the middle of building support for weekly reviews into Runway, so I wanted to record the transcript of the session somewhere that I could reference it for myself again.
Here's how it went.
#Tweekly #GTD Hello everyone! Ready? We'll do this in 3 parts/11 steps
#Tweekly #GTD PART ONE: GET CLEAR. Collect loose paper and materials. Gather everything that's loose into an Inbox, Tray or folder.
#Tweekly #GTD You have 5 minutes for this step. Go...
#Tweekly #GTD You all have one more minute on step one: Collect loose papers and materials.
#Tweekly #GTD PART ONE-STEP TWO-GET CLEAR: Get In to Zero. Choose the inbox that can good progress on in 5 min--email? paper? VM? Go!
#Tweekly #GTD - a good way to process in is 4D's: Delete it, Do it (under 2 mins), Delegate it, Defer it (onto a list)
#Tweekly #GTD PART ONE-STEP THREE-GET CLEAR: Empty your head. Open a Word doc, or grab and pad and clear your head for 5 minutes. Go.
#Tweekly #GTD - STEP THREE - SOME MINDSWEEP TRIGGERS: Family, health, meetings you've had, meetings you're going to have...
#Tweekly #GTD SOME MORE MINDSWEEP TRIGGERS: Your direct reports, finances, 401k, the dog, your car, health appts you've been putting off...
#Tweekly #GTD PART TWO, STEP FOUR-GET CURRENT: Review your Action lists (or maybe you call them Tasks or To Do's.)5 minutes start now. Go!
#Tweekly #GTD (10:25am) 2 more minutes to review action lists--are they current? anything to mark done? anything trigger you to add?
#Tweekly #GTD (10:28am) PART TWO-STEP 5-Review previous calendar info. Any triggers?
#Tweekly #GTD Many times reviewing your old calendar (go back about 3 wks) catches things you meant to do. 3 more mins left (10:30am)
#Tweekly #GTD PART TWO-STEP 6-REVIEW UPCOMING CALENDAR DATA - anything you should start getting ready for? (10:35am) Go!
#Tweekly #GTD REVIEW UPCOMING CALENDAR TIP: if you find something you need to process, you can add to your mindsweep for now.
#Tweekly #GTD if you don't get anything on reviewing your calendar, try going further out. Recurring Tasks are great for calendar. 10:40am
#Tweekly #GTD PART TWO-STEP 7-REVIEW WAITING FOR - if you've got a list review it. If you don't have one, what are you waiting on? 10:41am
#Tweekly #GTD WAITING FOR TIP: Review your email Sent folder. Usually some waiting for's hiding in there. 10:43am
#Tweekly #GTD - PART TWO-STEP 8-REVIEW PROJECT LISTS. Projects are your outcomes that require more than one action step. 10:47am Go!
#Tweekly #GTD PROJECT TIP: Projects are typically completed within 18 mos. If you can NEVER mark it done, it's likely an Area of Focus.
#Tweekly #GTD PROJECT TIP: Most people we coach have 30-100 current personal & professional projects. Don't be surprised! 10:51am.
#Tweekly #GTD PROJECT TIP: If you are not willing to take any next action on a current project, are you sure it's not Someday/Maybe?
#Tweekly #GTD PART 2-STEP 9 - REVIEW CHECKLISTS - birthday checklists? travel checklists? home mntce? 10:55am Go!
#Tweekly #GTD CHECKLIST TIP: Maybe you want to CREATE a checklist? Anything recurring that would be good? What to always pack for vacation?
#Tweekly #GTD PART 3-GET CREATIVE!-STEP 10-REVIEW SOMEDAY/MAYBE: If you have one, update it. If you don't have one, create it! 11:00am
#Tweekly #GTD SOMEDAY /MAYBE TIP: S/M is not just a "fantasy wish" list. It can be a fantastic place to stage "not yet" projects. 11:02am
#Tweekly #GTD SOMEDAY TIP: You'll trust S/M list(s) more if you know you're actually going to review them again. Otherwise they'll die.
#Tweekly #GTD PART 3-STEP 11-BE CREATIVE & COURAGEOUS! Any new thought-provoking, creative, risk taking ideas to add to your system? 11:07a
#Tweekly #GTD CREATIVE & COURAGEOUS TIP: What's REALLY got your attention in your job, family, environment? This is the last step! 11:09am
#Tweekly #GTD Thanks everyone. Hope you got value! Please post comments here: http://bit.ly/VZbP5 Let me know if you want me to do again.
Thanks for a great review Kelly, I really enjoyed it.
At Cogent Consulting, we've had a goal of building our own products in house for some time. What better product to build than something you know about and will use every day. We're geeks, and we use the process of Getting Things Done™ (GTD) on a daily basis to help plan our own work. None of the products on the market seem to understand the way we want to work though.
To define an action in GTD, you need to give it a name, context, time & energy. It might also be associated with a person and have some tags. The average bit of software out there thinks this is 4 - 6 different fields. You click in one, type, click in the next, type, and so on.
Enter Runway. Getting Things Done™ (GTD) for geeks
In Runway, there's only one input box that understands a simple structured language to parse all of the information needed. So I can type all of that in without clicking around.
When I'm done putting that information in, I end up with this. You can see that action listed, with the context, time, energy and tags all listed separately underneath it.
Runway gets out of my way and lets me worry about managing my actions, rather than managing it. I can navigate around the whole application just using the keyboard, and it gives me clues along the way about how to do it.
It's still early days for Runway, and we're in the process of adding lots more. We'd love you feedback though, so please have a play and let us know what you think.
A couple of days ago, Uncle Bob blogged about the CRAP in FitNesse. That prompted a few people in the Twitterverse to ponder about whether it would be possible to build such a tool for Ruby. In particular, Jim Weirich and Kevin Rutherford considered it.
Kevin and I have both built code quality tools for Ruby already (Reek and Roodi respectively), so I pinged him to suggest we could have a go. The CRAP (Change Risk Analysis and Predictions) metric is a function of cyclomatic complexity and coverage. I already knew how to calculate cyclomatic complexity from Roodi, and Rcov was an obvious choice to get coverage information from.
After a couple of hours, we came up with crap4r. It's pretty rough, but it basically works. Here's what it looks like:
~/Data/roodi $ ruby -Ilib ../crap4r/bin/crap4r 1.0 ./lib/roodi/core/visitable_sexp.rb#accept 1.0 ./lib/roodi/core/visitable_sexp.rb#node_type 1.0 ./lib/roodi/core/visitable_sexp.rb#children [snip] 2.0625 /Users/marty/Data/roodi/lib/roodi/checks/name_check.rb#evaluate 2.0625 /Users/marty/Data/roodi/lib/roodi/checks/line_count_check.rb#evaluate 3.0 /Users/marty/Data/roodi/lib/roodi/checks/abc_metric_method_check.rb#branch? 3.04166666666667 /Users/marty/Data/roodi/lib/roodi/checks/check.rb#evaluate_node 3.04166666666667 /Users/marty/Data/roodi/lib/roodi/checks/assignment_in_conditional_check.rb#has_assignment? 3.04166666666667 /Users/marty/Data/roodi/lib/roodi/checks/parameter_number_check.rb#evaluate 3.140625 /Users/marty/Data/roodi/lib/roodi/core/runner.rb#parse 3.33333333333333 /Users/marty/Data/roodi/lib/roodi/core/iterator_visitor.rb#visit 4.128 /Users/marty/Data/roodi/lib/roodi/checks/empty_rescue_body_check.rb#has_statement? 6.0 /Users/marty/Data/roodi/lib/roodi/core/runner.rb#load_checks
Kevin and I will clean it up over the next few weeks and see if we can publish it somewhere in a more usable fashion.
I released version 1.4.0 of Roodi while I was a RailsConf last week. It changes the underlying engine from ParseTree to ruby_parser because of ParseTree reaching end of life. That means Roodi should now work on Ruby 1.9.
I did my talk at RailsConf today, which I thought went pretty well. I'm always keen to get some feedback though, so I slurped up the rating information from the RailsConf web site to see how I compared to the other speakers. I ended up 6th out of 61 talks, which I'm happy with. The Rails Envy guys were speaking at the same time as me and came second. I suspect that means I got less people attending and voting as a result. That might not have affected my position in the list though.
Here's the full list for those who are interested. This might still be changing over time as people review the sessions, but it should be reasonably indicative.
UPDATE: It's about seven hours since the conference finished now and some more reviews have come in. They must have been positive for me, because now I've moved up to second. I'll check again in a couple of days to see if anything else dribbles in.
UPDATE: It's a week later now, so I'm assuming the votes have stabilised. There's actually been quite a bit of movement. Here's the list from now. It may stil be changing, but I won't bother updating again. I've moved down to 6th, but I'm still amazed that I'm even that high.
| Posn. | Rating | Reviews | Speaker | Topic |
|---|---|---|---|---|
| 1 | 4.65 | 105 | Ryan Singer | UI Fundamentals for Programmers |
| 2 | 4.64 | 25 | David Bock | Modeling Workflow in Ruby and Rails |
| 3 | 4.56 | 39 | Matthew Deiters | When to Tell Your Kids About Client Caching |
| 4 | 4.51 | 43 | Obie Fernandez | Blood, Sweat and Rails |
| 5 | 4.50 | 14 | Fernand Galiana | R-House - Rails for Home Automation |
| 6 | 4.48 | 25 | Marty Andrews | Automated Code Quality Checking In Ruby And Rails |
| 7 | 4.45 | 55 | Charles Nutter, Evan Phoenix | What Makes Ruby Go: An Implementation Primer |
| 8 | 4.44 | 64 | Bryan Helmkamp | Webrat: Rails Acceptance Testing Evolved |
| 9 | 4.42 | 43 | Ben Scofield | And the Greatest of These Is ... Rack Support |
| 10 | 4.36 | 39 | Gregg Pollack, Jason Seifer | Rails: A Year of Innovation |
| 11 | 4.31 | 35 | Jake Scruggs | Using metric_fu to Make Your Rails Code Better |
| 12 | 4.31 | 16 | Michael Bleigh | Twitter on Rails |
| 13 | 4.30 | 30 | Charles Nutter, Thomas Enebo | JRuby: State of the Art |
| 14 | 4.27 | 90 | Scott Chacon | Smacking Git Around - Advanced Git Tricks |
| 15 | 4.24 | 58 | Ezra Zygmuntowicz | Rube Goldberg Contraptions, Building Scalable Decoupled Web Apps and Infrastructure with Ruby |
| 16 | 4.19 | 59 | Jim Weirich | Writing Modular Applications |
| 17 | 4.14 | 69 | Larry Karnowski, Jason Rudolph | JavaScript Testing in Rails: Fast, Headless, In-Browser. Pick Any Three. |
| 18 | 4.08 | 24 | Ilya Grigorik | Art of the Ruby Proxy for Scale, Performance, and Monitoring |
| 19 | 4.00 | 14 | Jeff Dean | Advanced Views with Erector |
| 20 | 4.00 | 10 | Scott Raymond | Confessions of a PackRat |
| 21 | 4.00 | 10 | David Czarnecki, Ola Mork, Eric Torrey | Guitar Hero®: Behind the Music |
| 22 | 4.00 | 10 | Matt Wood | Orchestrating the Cloud |
| 23 | 3.98 | 45 | Ilya Grigorik | Building a Mini-Google: High-Performance Computing in Ruby |
| 24 | 3.93 | 44 | Scott Penberthy, Michael Bryzek, Geir Magnusson Jr, Yonatan Feldman | The Gilt Effect: Handling 1000 Shopping Cart Updates per second in Rails |
| 25 | 3.91 | 87 | Aslak Hellesoy | Quality Code with Cucumber |
| 26 | 3.91 | 11 | Daniel Lathrop, Eric Mill, Wynn Netherland | Gov 2.0: Transparency, Collaboration, and Participation in Practice |
| 27 | 3.89 | 18 | Pat Maddox, BJ Clark | Working Effectively with Legacy Rails Code |
| 28 | 3.85 | 40 | David A. Black | Getting to Know Ruby 1.9 |
| 29 | 3.81 | 26 | Blythe Dunham | Integrating SMS Messaging with your Rails Application |
| 30 | 3.77 | 40 | Davis W. Frank | I Rock, I Suck, I am - Jumpstart Your Journey to Agile |
| 31 | 3.74 | 27 | Neal Ford, Paul Gross | Rails in the Large:How We're Developing the Largest Rails Project in the World |
| 32 | 3.71 | 21 | Jonathan Dahl | Five Musical Patterns for Programmers |
| 33 | 3.71 | 17 | Jay Phillips | Call into your Ruby code! Writing voice-enabled apps in Ruby with Adhearsion |
| 34 | 3.66 | 70 | Alexander Dymo | Advanced Performance Optimization of Rails Applications |
| 35 | 3.65 | 31 | Michael Koziarski | Are You Taking Things Too Far? |
| 36 | 3.65 | 43 | Ryan Tomayko | HTTP's Best-Kept Secret: Caching |
| 37 | 3.64 | 14 | Brian Hogan | Rails and Legacy Databases |
| 38 | 3.62 | 34 | Chris Wanstrath, Tom Preston-Werner, PJ Hyett, Scott Chacon, Jon Maddox | The GitHub Panel |
| 39 | 3.61 | 18 | Mike Subelsky | It's Not Always Sunny In the Clouds: Lessons Learned |
| 40 | 3.60 | 10 | Greg Borenstein | Giving Rails the Big 'F': Surviving Facebook Integration Unscarred |
| 41 | 3.59 | 37 | Noel Rappin | Below and Beneath TDD: Test Last Development and Other Real-World Test Patterns |
| 42 | 3.57 | 77 | Adam Wiggins | Rails Metal, Rack, and Sinatra |
| 43 | 3.56 | 57 | Paolo Negri | %w(map reduce).first - A Tale About Rabbits, Latency, and Slim Crontabs |
| 44 | 3.56 | 59 | Matt Aimonetti | Rails3: Step Off of the Golden Path |
| 45 | 3.56 | 9 | Jeremy Hinegardner | Crate: Packaging Standalone Ruby Applications |
| 46 | 3.54 | 80 | David Chelimsky | Don't Mock Yourself Out |
| 47 | 3.52 | 63 | Yehuda Katz, Carl Lerche | The Russian Doll Pattern: Mountable apps in Rails 3 |
| 48 | 3.50 | 18 | Desi McAdam, Sarah Mei, Lori Olson | Discussion Panel: Women In Rails |
| 49 | 3.38 | 69 | James Adam | The Even-Darker Art of Rails Engines |
| 50 | 3.29 | 59 | Ninh Bui, Hongli Lai | Scaling Rails |
| 51 | 3.27 | 11 | Wynn Netherland, Jim Mulholl, Bradley Joyce | Build an App, Start a Movement |
| 52 | 3.14 | 7 | Jimmy Schementi | IronRuby on Rails |
| 53 | 3.09 | 11 | John Woodell, Ryan Brown | JRuby on Google App Engine |
| 54 | 2.92 | 25 | Erik Kastner | Interfaces are Dumb (and that's a Very Good Thing) |
| 55 | 2.91 | 34 | Jason LaPorte | PWN Your Infrastructure: Behind Call of Duty: World at War |
| 56 | 2.87 | 23 | Rein Henrichs | Rails Is from Mars, Ruby Is from Venus |
| 57 | 2.83 | 18 | Ed Laczynski, Nathaniel Bibler | Building a Video Portal in Rails - Or How the Teenage Mutant Ninja Turtles Started Streaming |
| 58 | 2.73 | 15 | Tony Hillerson | Integrating Flex and Rails with RubyAMF |
| 59 | 2.69 | 29 | Nick Plante, Joe Fiorini, Ben Scofield, Chris Saylor, James Golick | Starting Up Fast: Lessons from the Rails Rumble |
| 60 | 2.54 | 28 | Marc-Andre Cournoyer, Christian Neukirchen, Blake Mizerany, Ryan Tomayko, Adam Wiggins, James Lindenbaum | The Future of Deployment: A Killer Panel |
| 61 | 1.87 | 46 | Kevin Barnes | In Praise of Non-Fixtured Data |
I've had a proposal accepted to speak at RailsConf 2009. The title of my talk is "Automated Code Quality Checking In Ruby And Rails"". It's a natural follow on form my work on Roodi, but I will also discuss the other code quality tools appearing that are useful to help maintain a high level of quality in your code.
You can find out more about the session on the RailsConf 2009 site. If you're attending, come along to my session and say hi.
I've just released version 1.3.2 of Roodi. It contains a couple of patches submitted by Xavier Shay and Chris Leishman. Both of them were around the EmptyRescueBodyCheck, so it should be more stable now.
