Double Shot #441
Collected a few links yesterday despite being somewhat distracted.
Rails Maturity Model - Appears to be launching just in time for RailsConf. Maybe this will distract from other arguments that have plunged All Of Rails into war.
Meet JetBrains RubyMine 1.0 — a Brand New IDE for Ruby and Rails - Also launched out of beta just in time for RailsConf.
Firefox 3.5 Beta 4 - This is the renumbered 3.1. Behaving very well for me under heavy load so far.
Double Shot #440
Too many distractions made Monday a bad day for finding links.
Support for Rails 2.3 - Now present in edge Hobo.
Paintbrush - Next time someone wants a simple and free paint application for OS X, I know where to point them.
A Painful Decision
There has been some discussion in recent days in the Rails community about appropriate conference presentations, whether women feel welcome in the Rails community, and related issues. I don't intend to review the entire mess here - you can find it if you want it. For what it's worth, I think the original presentation was an inappropriate and regrettable mistake. However, far more disturbing to me are the reactions to the discussion on the part of some of the Rails community.
Folks, the idea that women are disproportionately underrepresented in engineering and software in general, and open source development in particular, should not be new and controversial in 2009 - anyone who cares to look can find such things as the FLOSSpols findings, or any amount of academic literature on the subject. Anyone who cares to take the time to actually talk to the women who are a part of the open source community will have no trouble getting an earful about how challenging it can be to participate.
I don't want to make the mistake of speaking of "the open source community" as some monolithic bloc. People like Audrey Eschright, Aaron Quint, Peter Szinek, and Selena Deckelmann have written about ways to address some of the fundamental problems.
But unfortunately for me, in parallel to the public discussion there have been private ones. I can't reveal details without breaking confidences, but suffice it to say that a significant number of Rails core contributors - with leadership (if that's the right word) from DHH - apparently feel that being unwelcoming and "edgy" is not just acceptable, but laudable. The difference between their opinions and mine is so severe that I cannot in good conscience remain a public spokesman for Rails.
So, effective immediately, I'm resigning my position with the Rails Activists.
I realize that some people will see this as an act of prudery on my part, or a lack of a sense of humor, or some other personal failing. That's OK, I don't mind. Other people (who I have a good deal of respect for) have attempted to convince me that I could do more good by staying involved with the Rails power structure and trying to work from within to change things. At this point, unfortunately, I feel sufficiently outnumbered and unwelcome that that option is no longer open.
This does not mean that I will stop using Rails; on a technical level, it's still a good fit for the projects that I work on. Nor does it mean that I will stop contributing to open source projects. But I'm no longer willing to donate a substantial portion of my free time to this particular project.
Folks, the idea that women are disproportionately underrepresented in engineering and software in general, and open source development in particular, should not be new and controversial in 2009 - anyone who cares to look can find such things as the FLOSSpols findings, or any amount of academic literature on the subject. Anyone who cares to take the time to actually talk to the women who are a part of the open source community will have no trouble getting an earful about how challenging it can be to participate.
I don't want to make the mistake of speaking of "the open source community" as some monolithic bloc. People like Audrey Eschright, Aaron Quint, Peter Szinek, and Selena Deckelmann have written about ways to address some of the fundamental problems.
But unfortunately for me, in parallel to the public discussion there have been private ones. I can't reveal details without breaking confidences, but suffice it to say that a significant number of Rails core contributors - with leadership (if that's the right word) from DHH - apparently feel that being unwelcoming and "edgy" is not just acceptable, but laudable. The difference between their opinions and mine is so severe that I cannot in good conscience remain a public spokesman for Rails.
So, effective immediately, I'm resigning my position with the Rails Activists.
I realize that some people will see this as an act of prudery on my part, or a lack of a sense of humor, or some other personal failing. That's OK, I don't mind. Other people (who I have a good deal of respect for) have attempted to convince me that I could do more good by staying involved with the Rails power structure and trying to work from within to change things. At this point, unfortunately, I feel sufficiently outnumbered and unwelcome that that option is no longer open.
This does not mean that I will stop using Rails; on a technical level, it's still a good fit for the projects that I work on. Nor does it mean that I will stop contributing to open source projects. But I'm no longer willing to donate a substantial portion of my free time to this particular project.
Double Shot #439
Note for future: do not allow all deadlines to match up at month-end.
Heroku Pricing - It's out, for a variety of shared and dedicated servers.
Internbot Chronicles #3 - Nick Quaranto surveys his corner of the testing universe.
Introducing Garb: Access the Google Analytics Data Export API with Ruby - THat didn't take long.
How Rails Works #2: Mime Types & respond_to - Internals analysis from Ryan Bigg.
How the OAuth Security Battle Was Won, Open Web Style - Twitter deserves serious love for their part in handling the situation.
Dear Fellow Rubyists - Audrey Eschright comments on women and marginalization in the Ruby community. I utterly deplore some of the drive-by juvenile comments this discussion gathered. Audrey continues the discussion in So Now What, asking for positive suggestions to improve the situation.
Rack 1.0, a modular Ruby webserver interface - It's shipped. Upgrade with caution, though, as there are early indications that it may not play well with Rails 2.3 release version in some places.
Rails Devs for Data Integrity: How to gracefully handle database key violations Not every Rails developer ignores the database layer.
Phusion Passenger 2.2.2 released - Instant Rack 1.0 compatibility.
Why Rails is Still a Ghetto - Another take on the flap over the "CouchDB: Perform Like a Pr0n Star" talk.
Double Shot #438
Double Shot #437
I guess it's not too early to start the push towards end of the month deadlines.
Welcome to the Anti-Pitch - An attempt to convince development clients that looking at portfolio sites isn't necessarily a good way to judge.
Hobo 1.0 Nears - This extra layer of sugar on top of Rails has been quietly moving along.
gender and sex at gogaruco and Update on the Porn Preso - Put me down as one who thinks that porn metaphors have no place in a conference technical talk, and that the locker-room atmosphere that encourages dismissing such things as just cute fun is a problem.
Double Shot #436
The universe seems to be telling me to shift more towards sales and PM. I'm not sure I want to take the hint.
OSX Leopard sqlite-ruby and sqlite2 - In case you find yourself needing old sqlite, these instructions still work fine.
Oracle Buys Sun Omnibus and The Oracle Predicts a Setting Sun - Thorough analyses of the Oracle/Sun purchase from the RedMonk guys.
Debugging Rails 2.3.2 Apps with Rack::Bug - A good quick look at this new middleware monitoring tool.
New Ruby 1.9 Envycasts Released! - 1.9 learning in video form.
Getting S3 and SWFUpload to Cooperate in Rails - Another take on the issues involved, updated for current Rails.
Double Shot #435
Rainy spring weather says "stay in and code." It's a conspiracy!
peeping into memcached - How to get internal stats about memcached, and what you can do with them.
Installing memcached on OS X 10.5.4 Leopard - Easiest set of instructions I was able to find on short notice.
Ruby on Rails GSoC Projects - The winners for this summer.
Double Shot #434
Busy weekend leads to lots of Monday links.
This Week in Edge Rails - Even if you don't normally read TWIER, this edition has some info on the state of the Rails 3 codebase.
Strongbox - Public key encryption for Active Record attributes. (via Thoughtbot)
Firediff - Firebug extension that tracks real-time changes to the DOM and CSS of a page.
GitHub Developer Site - The new GitHub API appears to be quite comprehensive. There's a start at a ruby interface for it.
backports - Library bringing various bits of Ruby 1.9 to Ruby 1.8.x.
YAAC - Another YAML-based configuration class for Rails.
An overview of modern SQL-free databases - I'm still not feeling compelled to switch to a nonrelational database myself, but lots of people are playing with these things.
Ruby 1.8.7-p160 and 1.8.6-p368 released - Bugfix time. I don't know that anyone has tested Rails with these yet.
Why Programmers Suck at CSS Design - Together with some advice for doing it anyhow.
Touch your Active Record Instances
Now that Rails 2.3 is out and the core team has caught their collective breath, new features are starting to make their way into Rails. The latest: an implementation of
At its simplest,
[sourcecode language='ruby']
@order.touch
[/sourcecode]
But wait, there's more! You can specify a different attribute to touch if you'd like:
[sourcecode language='ruby']
@order.touch(:shipped_at)
[/sourcecode]
You can also specify
[sourcecode language='ruby']
class Order
belongs_to :customer, :touch => true
end
[/sourcecode]
In this case, saving or destroying an order instance will touch the corresponding customer instance. This is useful in cases where, for example, you're caching customers but want them invalidated from the cache when a counter cache changes. You can also specify a particular attribute on the parent model to touch:
[sourcecode language='ruby']
class Order
belongs_to :customer, :touch => :orders_updated_at
end
[/sourcecode]
touch
for Active Record. This is in edge for both 2-3-stable and master (to be 3.0).At its simplest,
touch
is just a bit of syntactic sugar that writes the current time to the updated_at
or updated_on
attribute of an ActiveRecord instance. This does not short-circuit the validation code, so if there are errors in the instance you'll get ActiveRecord::RecordInvalid
raised:[sourcecode language='ruby']
@order.touch
[/sourcecode]
But wait, there's more! You can specify a different attribute to touch if you'd like:
[sourcecode language='ruby']
@order.touch(:shipped_at)
[/sourcecode]
You can also specify
touch
options when defining a belongs_to
relationship:[sourcecode language='ruby']
class Order
belongs_to :customer, :touch => true
end
[/sourcecode]
In this case, saving or destroying an order instance will touch the corresponding customer instance. This is useful in cases where, for example, you're caching customers but want them invalidated from the cache when a counter cache changes. You can also specify a particular attribute on the parent model to touch:
[sourcecode language='ruby']
class Order
belongs_to :customer, :touch => :orders_updated_at
end
[/sourcecode]
Double Shot #433
Gonna be an interesting week to write about edge Rails.
RubyPAN - New searchable gem indexing site.
Phusion Announces Passenger for Nginx - Another interesting twist in the Rails hosting story.
GitHub Issue Tracker! - Not full-featured, but nice for random little bits of code you keep on GitHub.
Double Shot #432
Not having a shortage of things to do is good, right?
JRuby Moves to Git - And joins all the other cool kids.
Rails 2.3.2 upgrade gotchas - Some notes from Thoughtbot.
Mockups 1.6 Release: Linking Mockups, and More! - A nice new feature for the excellent Balsamiq Mockups.
Double Shot #431
Big site launch last night, a few lingering errors this morning but nothing major. Hooray!
Ruby Best Practices - A promising-looking new blog, though I'm always skeptical of "best" practices.
Remarkable 3.0 is out and it's...well..remarkable! - Major new release of this macro and i18n chunk for rspec matchers.
Show Off Your Mockups - Easy integration of HTML mockups into Rails applications.
Double Shot #430
The Rails 3 train may not be leaving the station yet, but it's at least building up a head of steam.
One Giant Leap Forward - Now that Rails 2.3 is safely out in the wild, work on Rails 3.0 is heating up.
The RSpec Book: Beta 4.0 - Another project that's moving right along.
Reuse Java code in your Ruby on Rails applications - Bookmarking this because I may have to do it. Which is different from wanting to do it.
Double Shot #429
Some mornings it is very hard to face a Monday.
On2 Flix Cloud - SAAS web-based media transcoding. Looks useful.
Adobe® Flex™ Builder 3 Professional for unemployed developers - If you're willing to tell them that you're out of work, you can get Flex Builder 3 for free.
acts_against_douchebar - Rails plugin to keep the Digg bar from cluttering up your site.
Mike's Idiosyncratic Rails FAQ - Another side project. Like I needed another one.
Double Shot #428
Hard work and head colds go together like fish and bicycles.
Nominate a Ruby Hero! - Just in case, you know, you can think of someone who ought to be nominated.
ie6-upgrade-warning - Yet another chunk of JavaScript designed to get IE6 users to upgrade.
Double Shot #427
Wee children, wee hours.
JRuby on Rails on Google App Engine - Strikes me as a "dancing bear" right now, but it's worth at least knowing that this is somewhat possible.
Hoptoad now supports GitHub integration! - More goodness in online Rails exception tracking.
Double Shot #426
There's nothing like waking up at 4:30 to discover a mystery bug.
Click to Globalize - Edit-in-place UI globalization for Rails.
How To: Setup RSpec, Cucumber, Webrat, RCov and Autotest on Leopard - If you like a high-ceremony testing environment, this will get you going.
My Improved Rails Development Environment on the Mac - Switching to Passenger + support for subdomains worked for Rob Bazinet.
S3Tools - Open source tools for working with Amazon S3. Their command-line client looks pretty useful.
10 Reasons why PHP is Still Better than Ruby ;-) - I admit it, I laughed.
Simple backups can be simple! - Straightforward open source backup driven by a ruby DSL, with S3 support.
Double Shot #425
April is shaping up to be busy. Just as well, as the IRS wants their metric ton of flesh.
reek - Code-smell detector for ruby, complete with RSpec integration.
CrossBrowserTesting - VNC-based in-browser testing of multiple configurations, with 5 minutes free.
Amazon EC2 + Chef = Mmmmm - How to go from zero to setup for a Rails app quickly.
Rubx: Twitter's Ruby shell - A particularly daft way to call a ruby interpreter.
The Blues Brothers: Allegory for Software Development
Software development knowledge comes in many forms. There are a near-infinite number of blog posts, seminars, books, and charlatans who are more than anxious to explain to you the One True Way to develop software. But few people in the current generation of developer are aware of one of the seminal works that explains agile development via allegory: The Blues Brothers. A look at this film in depth reveals lessons for many consulting firms.
The opening factory shots remind us of the "software construction" metaphor. But the fact that this section fades out quickly is a nice bit of foreshadowing: big design up front is dying out, with something new to come. Considering the movie's age, this introduction of agile methods is near-astounding.
From there, the film quickly switches to the Joliet Correctional Center: certainly a sign that we are dealing with the typical project where the developers feel trapped. And indeed, we quickly meet the lead developer: Jake Blues, who is being released from prison (that is, completing a project and moving on to his next opportunity).
Jake meets up with his partner Elwood in a typical small consultancy. We get a hint early on that Jake and Elwood are not ordinary developers, but super developers, literally able to leap a drawbridge (with the aid of an ex-Mount Prospect police car) in a single bound.
We shortly meet the new client: St. Helen of the Blessed Shroud Orphanage. Like many clients, they have a deceptively simple problem that they want solved. And like many clients, they have no real idea of what solving this problem will entail. The boys try to explain the difficulties in getting $5000, and end up getting beaten with a yardstick and thrown down the stairs. Anyone who has ever had to deal with a difficult client will sympathize.
Jake, as lead developer, is tasked with coming up with the project plan. He is at a complete loss until suddenly a light from the heavens hits him, and in one burst of insight, he sees how it will all come together. This is the architectural phase of the project, and at this point, the promise of the software is limitless.
Of course, as in all projects, the plan does not survive contact with reality. Jake and Elwood get pulled over by the cops for speeding, and given Elwood's record, it seems like the project is doomed from the start. Jake resigns himself to early failure. But insisting "They're not gonna catch us, we're on a mission from God," Elwood leads the cops on a chase through a shopping mall, ultimately escaping. We see here the role that a good pair can have on a programming job: when one half of the pair is temporarily stuck, the other can step in to finish the current code spike.
The next step, of course, is to assemble the development team. Jake and Elwood find their team in unlikely places: a church, a row house, a Holiday Inn, a fancy restaurant, a soul food cafe, a pawn shop. Experienced project managers will understand there is no substitute for talent, wherever it can be found - and that often talent is not associated with college degrees or cleancut young people. Putting solid effort into the hiring phase of the project has substantial benefits down the line, when the whole team comes together seamlessly - just like the Blues Brothers' band.
Every software project seems to have one insurmountable obstacle, and this one is no exception. In the case of the Blues Brothers, the tough bit of coding is represented by Jake's wife, who shows up with heavy ordnance at this point in the movie (and repeatedly thereafter). The developers have multiple tries at implementing the desired feature, but they seem unable to succeed. What developer has not had the experience of a completely intractable bug that defies multiple attempts at a fix?
After assembling the team, it's time for the first coding iteration. In the movie, this is represented by the first gig at a country and western bar - and it's a near-disaster. The team does complete the iteration, but the client is dissatisfied and they slink away to regroup.
Development must go on, though, and the team meets in standup fashion to figure out what to do next. Amusingly enough, the metaphor for the standup meeting has them all sitting down - but in a steambath, which certainly matches the tone of many daily scrums. They come out of the meeting with a new plan, which is followed by lots of hard, routine work - in the film, these successive iterations are telescoped into a montage of scenes promoting the gig at the Palace Hotel Ballroom.
The climactic concert features the development team overcoming a variety of obstacles (angry Nazis, a rival C&W band, the members of the Illinois law enforcement community) to turn out a superior product: a successful final iteration by any measure. The client is happy with the results, as symbolized by the $10,000 advance on a recording contract.
But of course, after the software is finished, it has to be delivered. And, like so many developers before them, the Blues Brothers underestimated the difficulties of deployment. Elwood realizes this in one of the movie's signature lines:
Jake's response? "Hit it." As lead developer, he knows there is no way to get past this problem except to work through it. Deployment is a long slog, with many obstacles. There are dozens of (literal) crashes involved. But, absolutely right at the deadline, the brothers make the property tax payment symbolizing a successful product launch.
And their reward? As shown in the last ten minutes of the film, their next job is back at a prison - very much like the one that Jake thought he had escaped at the beginning. That's the final lesson of The Blues Brothers for software: a developer's job is never done.
The opening factory shots remind us of the "software construction" metaphor. But the fact that this section fades out quickly is a nice bit of foreshadowing: big design up front is dying out, with something new to come. Considering the movie's age, this introduction of agile methods is near-astounding.
From there, the film quickly switches to the Joliet Correctional Center: certainly a sign that we are dealing with the typical project where the developers feel trapped. And indeed, we quickly meet the lead developer: Jake Blues, who is being released from prison (that is, completing a project and moving on to his next opportunity).
Jake meets up with his partner Elwood in a typical small consultancy. We get a hint early on that Jake and Elwood are not ordinary developers, but super developers, literally able to leap a drawbridge (with the aid of an ex-Mount Prospect police car) in a single bound.
We shortly meet the new client: St. Helen of the Blessed Shroud Orphanage. Like many clients, they have a deceptively simple problem that they want solved. And like many clients, they have no real idea of what solving this problem will entail. The boys try to explain the difficulties in getting $5000, and end up getting beaten with a yardstick and thrown down the stairs. Anyone who has ever had to deal with a difficult client will sympathize.
Jake, as lead developer, is tasked with coming up with the project plan. He is at a complete loss until suddenly a light from the heavens hits him, and in one burst of insight, he sees how it will all come together. This is the architectural phase of the project, and at this point, the promise of the software is limitless.
Of course, as in all projects, the plan does not survive contact with reality. Jake and Elwood get pulled over by the cops for speeding, and given Elwood's record, it seems like the project is doomed from the start. Jake resigns himself to early failure. But insisting "They're not gonna catch us, we're on a mission from God," Elwood leads the cops on a chase through a shopping mall, ultimately escaping. We see here the role that a good pair can have on a programming job: when one half of the pair is temporarily stuck, the other can step in to finish the current code spike.
The next step, of course, is to assemble the development team. Jake and Elwood find their team in unlikely places: a church, a row house, a Holiday Inn, a fancy restaurant, a soul food cafe, a pawn shop. Experienced project managers will understand there is no substitute for talent, wherever it can be found - and that often talent is not associated with college degrees or cleancut young people. Putting solid effort into the hiring phase of the project has substantial benefits down the line, when the whole team comes together seamlessly - just like the Blues Brothers' band.
Every software project seems to have one insurmountable obstacle, and this one is no exception. In the case of the Blues Brothers, the tough bit of coding is represented by Jake's wife, who shows up with heavy ordnance at this point in the movie (and repeatedly thereafter). The developers have multiple tries at implementing the desired feature, but they seem unable to succeed. What developer has not had the experience of a completely intractable bug that defies multiple attempts at a fix?
After assembling the team, it's time for the first coding iteration. In the movie, this is represented by the first gig at a country and western bar - and it's a near-disaster. The team does complete the iteration, but the client is dissatisfied and they slink away to regroup.
Development must go on, though, and the team meets in standup fashion to figure out what to do next. Amusingly enough, the metaphor for the standup meeting has them all sitting down - but in a steambath, which certainly matches the tone of many daily scrums. They come out of the meeting with a new plan, which is followed by lots of hard, routine work - in the film, these successive iterations are telescoped into a montage of scenes promoting the gig at the Palace Hotel Ballroom.
The climactic concert features the development team overcoming a variety of obstacles (angry Nazis, a rival C&W band, the members of the Illinois law enforcement community) to turn out a superior product: a successful final iteration by any measure. The client is happy with the results, as symbolized by the $10,000 advance on a recording contract.
But of course, after the software is finished, it has to be delivered. And, like so many developers before them, the Blues Brothers underestimated the difficulties of deployment. Elwood realizes this in one of the movie's signature lines:
"It's 106 miles to Chicago, we've got a full tank of gas, half a pack of cigarettes, it's dark, and we're wearing sunglasses."
Jake's response? "Hit it." As lead developer, he knows there is no way to get past this problem except to work through it. Deployment is a long slog, with many obstacles. There are dozens of (literal) crashes involved. But, absolutely right at the deadline, the brothers make the property tax payment symbolizing a successful product launch.
And their reward? As shown in the last ten minutes of the film, their next job is back at a prison - very much like the one that Jake thought he had escaped at the beginning. That's the final lesson of The Blues Brothers for software: a developer's job is never done.
subscribe via RSS