Whether it’s Agile Software Development or Test Driven Development, every year new systems of code and project management spring up like tullips. Each one comes with loyal devotees who swear by it and denounce all the other heathen religions.

Scott Berkun feels that none of the current models accurately describe the way software development actually happens. Sure, you may be aspiring to adhere to the tenants of the Rational Unified Process (RUP), but isn’t Asshole Driven Development (ADD) a more accurate description? Or maybe Cover Your Ass Engineering (CYAE)?

Check out Scott’s full list and be sure to read the user submitted additions.

The dearth of women in math and science has been discussed frequently. Computer science and programming is part of that same picture. It is obvious to everyone that the ratio is seriously lop-sided. But determining exactly why and what, if anything, we can do about it is not as obvious.

A few months ago, I followed with interest a thread started by Jason Kottke about the poor ratio of female to male speakers at web conferences. Later posts on this thread are here, here, here, here and here. (There were many others…)

I have helped to plan many conferences over the last ten years, and the editorial teams I’ve been on have always taken into account gender when considering the session line-up. And we have always asked “Where are all the women? How can we get more women speakers?” Jeffrey Zeldman sums up my conclusion well when he writes “The problem is visible at the top because it exists at the bottom.”

One of my other conclusions is that women have to be very involved in any discussion of the problems and solutions. No, scratch that—women need to lead the discussion about this topic. They know better than any man what the barriers are for women. If we want answers and solutions, I think we have to start there. (Plus men don’t always do a good job of it on their own.) Exactly this kind of discussion took place between a group of women developers at RailsConf 2007 and it’s now a podcast so we can all listen in.

Ruby on Rails Podcast — Roundtable: Women in Development

• Part I (MP3, 26 minutes)
• Part II (MP3, 20 minutes)

The podcast is a round-table discussion on the state of women in open source programming. It features Jen May Wu, Dr. Ana Nelson, Liz Summerfield, Sandy Metz, Carmelyne Thompson, Cynthia Kaiser, and Desi McAdam, and it is moderated by Geoffrey Grosenbach. To share just one insightful tidbit from their discussion: they mention how many technology companies only give out men’s t-shirts and how much they appreciate companies that bother to stock both men and women’s t-shirts. A great point.

And if you are planning a conference, event or featuring people who work in technology, be sure to check out the “List of Women Speakers for Your Conference” compiled by Jen Bekman.

Working with Rails will be holding a Rails Hackfest every month during 2007. It is a chance for developers to be rewarded for contributing source code to Ruby on Rails.

Submit bug fixes, patches, features, enhancements, or documentaion improvements and you will automatically accumulate Hackfest points. You get some points for each submission; you get more points for each accepted improvement. The contributors with the most points at the end of each month wins prizes. This month’s prizes include a ticket to RailsConf Europe, books from O’Reilly and O’Reilly-branded USB Mini Hubs.

Last week, I posted that David Black has released a guide to using and configuring routes in Ruby on Rails and commented that Rails routing has not been documented well enough before now. It seems someone else feels the same way.

Today, Ryan Bates has posted a screencast at Railscasts illustrating how to create a “catch-all route”. It’s not just a way to catching routes that don’t match your configured routes, it is a powerful technique for adding complex and dynamic routes. It’s ideal once you understand the basics of Rails routing and you feel ready to graduate to more advanced techniques. I use something like this to redirect legacy URLs and requests from spiders trolling for security holes.

RailsConf Europe 2007, the three-day Ruby on Rails conference co-produced by Ruby Central and O’Reilly, will be held on September 17-19, 2007 in Berlin, Germany. This week they started taking registrations. Until August 6, the early price is €745, after that it goes up to €895.

David Black, author of the popular Ruby for Rails, has released a guide to using and configuring routes in Ruby on Rails. It’s titled Rails Routing and it is part of Addison-Wesley’s Digital Shortcut series.

In their words:

In this short cut, you’ll learn techniques for writing custom routing rules, how to tap into the convenience and power of named routes, and the workings of the RESTful routing that’s had such an impact on Rails development. Along with a thorough introduction to routing syntax and semantics, you’ll find techniques for testing and troubleshooting routes, and tips on the use of this important part of your Rails skill set.

While I’m personally looking forward to learning about RESTful routing, the best part about this guide is how it can help beginners get a handle on what routes are, how they work and how to write them. Even though it is an essential concept in Rails, routing has been poorly documented in the past and often comes across as voodoo to beginners who stumble through it with trial-and-error.

There are two ways to get the PDF of Rails Routing. If you are an Addison-Wesley Safari member (or want to be) you can view or download it ($39.99/month) as well as preview portions of the guide. If you’d rather get just the single PDF instead, you can purchase it through their store ($14.99).

You probably already know how to write if-then statements in PHP and Ruby.

<?php // a simple PHP example
  if (condition) {
    statement1;
  } else {
    statement2;
  }
?>

But have you discovered the usefulness of ternary operators yet?

(more…)

RailsEnvy has posted a long and really excellent article (filled with their trademark wit) on how to use Rake in Ruby on Rails. They give a history of Make and Rake, then walk you through the concepts and steps of creating your own Rake tasks. After their tutorial, you’ll be using Rake all the time. I know I will.

Here are a few of the built-in Rake tasks that might ease some development pain. (A full list is available by typing rake ––tasks from inside the root directory of your Rails application.

• rake log:clear # Truncates all *.log files in log/ to zero bytes
• rake tmp:clear # Clear session, cache, and socket files from tmp/
• rake tmp:cache:clear # Clears all files and directories in tmp/cache
• rake tmp:pids:clear # Clears all files in tmp/pids
• rake tmp:sockets:clear # Clears all files in tmp/sockets
• rake tmp:sessions:clear # Clears all files in tmp/sessions
• rake db:sessions:clear # Clear the sessions table

Make sure you check out the links at the bottom of their article to see some of the custom Rake tasks that are already out there just waiting for you to take advantage of them.

Don’t worry, classic pagination isn’t gone yet. In this case, R.I.P. stands for “rest in plug-in”.

Ryan Daigle has the news: classic pagination has been removed from Edge Rails and, as I mentioned in a previous post, classic pagination will now become a plug-in. If you are currently using Rails version 1.2.3 or earlier, of course you still have it built-in, but the next time you upgrade Rails, it will disappear and you’ll need to remember to download the plug-in (or choose another “flavor” of pagination). If you are the sort to run on Edge Rails, then you’ll need to make the change now.

Every programmer is familiar with some kind of testing. You click on your application or web pages to see if it does what you expect. You fill out your forms with fake data and see if it gets stored successfully in the database. But that type of testing becomes a tedious and repetitive task. You know who is really good at tedious and repetitive tasks? Computers. That’s why it’s much better to program tests the computer can perform for you and save yourself all that clicking. When it comes to testing, computers are faster, more accurate, more comprehensive and don’t complain nearly as much. And Ruby on Rails makes testing easy to add to any project.

Gregory Brown at O’Reilly has just posted a primer, “Rails Testing: Not Just for the Paranoid”, on implementing testing (Unit, Functional, and Integration) in Ruby on Rails.

If you are looking for more on testing, the Rails manual also gives a good guide to testing in Chapter 9 and nubyonrails.com has a Testing Cheat Sheet that’s helpful for remembering the testing syntax.