Kent Beck gave a great ‘story-driven’ talk at RailsConf 2008 regarding Patterns, Test Driven Development, and XP/Agile/Responsible development. Go see it now at Blip.tv along with all the other big presentations from RailsConf.
Yeah, yeah. This was posted ages ago, but I just made it around to watching it tonight.
Two great quotes. First, re: TDD
Testing really isn’t the point. The point here is about responsibility. When you say it’s done, is it done. Can you go to sleep at night, do you know that the software you finished today . . . works. And will help. And isn’t going to take anything away from people.
Second, more generally about ideas:
Smart ideas are useless. Nobody else is going to be dumb enough not to try them – or rather, Everybody’s going to try them if it’s a smart idea. Ideas with punch are the ones that are really ridiculous…until you try them.
Like Mole. Mole sauce. Chocolate? Chicken? Phbbblblltt! HahahaHA!
If you want to send SMTP mail via localhost on Mac OSX Leopard (for example, from ActiveRecord/Rails/CruiseControl.rb/etc), you need to run postfix at boot. This took me a quite a while to figure out, so here is what worked for me on a work-imaged box and my personal box. YMMV.
And that was it! CruiseControl.rb was now sending email from OSX, which was all I really wanted in the first place…
- As suggested in 09/03, one project switched to using Solr for search indexing. We were warned that wide range queries might be slow (looking for a value between 1… 10000) could be very slow, but it is not, at least with 400K indexed documents. We’ll watch out for slowdowns as the number of indexes increases.
Ask for Help
“JSUnit tests do not show line numbers for assertion failures, which makes it hard to know which assertion failed. Suggestions?”
Have fewer assertions per test, or use the message argument, such as
assertEquals(foo, bar, 'foo should be the same as bar.').
“Is there any way to see test failure stack traces as soon as a test fails or errors? This would be especially nice for slow-running Selenium tests.”
A few Pivots remember hacking on
Test::Unit and Rspec to display failure details immediately, but more research is needed. Perhaps there’s a plugin?
“Design Adam’s beard!”
Pivot Adam is shaving is beard and is looking for facial hair suggestions. Over the years he has displayed many of the “standard” beards and mustaches, so it’s time to get creative. Look to The Quest For Every Beard Type for inspiration. Here is your canvas:
Ask for Help
“Is there something wrong with Net::SSH in the latest versions of Capistrano? I can’t deploy to localhost…”
Not that anyone knows of. Have you tried turning it off and on again? The power button… it’s the little glowing button on the front… the button on the front… Are you from the PAST?
“Is there a good ruby Gem or Plugin for working with the Google Charts API?”
One pair used gchartrb but abandoned it almost immediately. So far, it’s string << string << string.
Unfortunately not. Desert plugins should have an
I posted a few weeks ago gathering small tips from you regarding how you get and/or stay more Agile.
The goal is a list of short, pithy, sticky aphorisms to help both newbies get Agile and us stay that way. Think Agile Andy’s Almanack (or something).
I’ve thrown everything I got (a lot in person & email) together and categorized a bit. Please comment, add, delete, etc. As I said, I’m working on a presentation around this data and welcome your feedback.
Stick to Conventions
- Follow the local ground rules (indenting, naming, structure, etc.)
- Always take the next story (don’t let ‘fun’ or ‘hard’ get in the way of business priority)
Use the right tools
- Keep your hand on the manual (Keep browser tabs open for your language & API doc sites)
- Make mini actionable task lists for your story (Get inspired by GTD)
- Index cards are mini whiteboards
- Hardware, hardware, hardware (Big and/or dual monitors, 2 keyboards & 2 mice is better than 1 & 1)
Pair Programming Works
- Expect to Pair
- Pair appropriately
- When you’re not sure how to implement a story, pair with someone more senior
- When a task feels obvious, pair with someone more junior or new to the project
- Let the rookie type, give the wookie a toy (so he doesn’t)
- Rotate your pairs as often as practical
- 2 pairs are better than 1 on a project
- Always pair interview
Take a test drive
- Writers’ block? BEWS (Blank Editor Window Syndrome)? Write a test
- Find some untested code? Write a test.
- Find something you don’t understand? Write a test.
- Keep your tests as fast as is practical, or you’ll wait for CI to run them
- Write enough tests so that you can sleep at night
- Do the simplest thing that could possibly work – no architecture astronauts
- Check-in multiple times before a story is done (try for every hour or so)
- Kill dead code, commented out code, or write tests to cover it
- Make it green, then make it clean
- Tackle code debt with extreme prejudice
- Leave the code cleaner than when you got there (think o2 canisters on Everest)
- Every failing test is sacred
- Red builds are project cancer – fix first, figure out why, then blame (when appropriate)
Stay in sync
- Don’t stop talking – to your pair, your team or your customer
- Go to lunch together
Pivotal Labs is teaming up with Outside.In in New York City to co-host the monthly Ruby Happy Hour, on the first Wednesday of every month, starting Sep 3.
There will be pizza, beer and wii-based entertainment for everyone. Apparently these happy hours are getting quite popular, so please RSVP either in the comments here, or on Outside.In’s blog.
Where: Outside.in, 20 Jay St Suite 1019 (10th Fl), Brooklyn, NY
When: 7-9PM, Wednesday September 3rd
Who: If you’re a developer who uses Ruby and would like to meet some other Ruby folks, toss around ideas, or just have a few beers, we welcome you with open arms!
Outside.in (www.outside.in) is the web’s leading platform for neighborhood news and conversation. Outside.in’s technology dynamically maps web content to offline locations, which enables hyperlocal news discovery and sharing for consumers. The company also recently released GeoToolkit (www.outside.in/toolkit), which provides powerful tools for content creators of all sizes to optimize, promote and monetize their local content. Outside.in is supported by leading investors including Union Square Ventures, Milestone Venture Partners, Betaworks and the New York City Investment Fund. For more information, visit www.outside.in or the companyís blog at http://blog.outside.in.
As some of you may have heard, Rails 2.2 is going to be thread safe. This was pretty exciting for us as we’ve been struggling lately with memory issues running Mongrel clusters in virtualized environments, where memory is scarce and those Mongrel processes are pretty big.
While some have pointed out limitations of MRI due to green threads and certain commonly used libraries, and others are super-excited about what this means for JRuby, we were very curious about how Mongrel would perform serving Rails requests concurrently on MRI, which is very close to our/the standard Rails deployment.
As it turned out, Mongrel was pretty easy to work with, and initial tests suggest we were able to see a huge drop in memory usage while getting comparable performance to a Mongrel cluster. I haven’t included numbers as this was really more of a proof-of-concept spike and others will no doubt run with that, but we’re happy enough that we’ll be moving an app or two to edge shortly to see how well they perform.
A patch for Mongrel is pending feedback from the Mongrel team, but for now if you’re curious you can grab the source and run your own threaded Mongrel (on edge Rails) like so:
mongrel_rails -N X -n Y
where X is the number of concurrent requests Rails should process (active Rails threads) and Y is the number of concurrent requests before Mongrel starts refusing connections (standard Mongrel num-processes). Note: run one process per-core or turn off a core if you want to compare performance to a Mongrel cluster.
Feel free to provide feedback in comments, or on the mongrel-users mailing list.
Bruno Miranda posted a review of various agile project management tools including Mingle, VersionOne, TargetProcess, and Tracker. Check it out here.
We’ve let Bruno know that Tracker is actually under active development. One of the first new features that we’ll be rolling out soon is a REST API, followed by various usability improvements that will make it easier to work with larger projects.
We’re also looking for more suggestions on how to make Tracker better, especially in the area of higher level planning. Send your ideas to firstname.lastname@example.org, or post them on Satisfaction.
And if you haven’t tried it yet, the Tracker beta is fully open to the public, feel free to sign up.