Interesting Things

• Pivot Davis is soliciting Agile tips, tricks, anecdotes, and anti-patterns in his two articles Tips for being more Agile and Open Thread: Which Practices Make You More Agile? Please feel free to contribute.

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.

"How do you use Javascript included in a Desert plugin? Is it included automatically with Desert-magic?"

Unfortunately not. Desert plugins should have an install.rb that copies the Javascript to the public/javascripts directory in your project, but few actually have this (at least at Pivotal.) For now you have to copy any Javascript into that directory yourself.

Interesting Things

• MySql only allows indexes on 64 columns per table. This is a hard limit, set in the header file, and therefore can't even be changed at compile time without editing that file first. It was suggested that anyone who wants more than 64 indexes should not be using a database for searches anyway -- use something like Solr instead.

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.

Here goes:

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

Code simply

• 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)

CI

• 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

Comment away...

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 tracker@pivotallabs.com, 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.

I just released cinabox. It is intended to be The Simplest Thing That Could Possibly Work to set up a Continuous Integration (CI) server, using cruisecontrolrb (CCRB).

Watch the Screencast!

In addition to being a (hopefully) useful tool to help people easily set up CI systems for various platforms and languages, it is also an experiment in simplicity and minimalism:

• The project consists of only two simple scripts, one shell script to bootstrap ruby, and one ruby script to set up cruisecontrolrb.
• In the script, readability and simplicity are favored over clever abstractions and DRYness. Hopefully, even people who don't know shell scripting or Ruby can read the scripts and easily understand the commands it is executing.
• A standardized environment is assumed: A dedicated Ubuntu 8.04 system, Ruby 1.8.6, and latest dependencies via aptitude. PCs and Virtual Machines are cheap, and Linux and CCRB are free. There's really no reason you shouldn't be able to run a dedicated CI box. If this environment doesn't work for you for some reason, the scripts should be self-explanatory enough that you can easily hack it up to work for your environment (and contribute your version back to to the project!).
• I use the magic fairy dust of GitHub to eliminate build scripts, release scripts, packaging, versions, and pretty much all the regular boring overhead of a project. The README.txt is my only documentation. The GitHub "Download Tarball" link automatically provides packaging and uniquely-named packages (by the git hex commit id) for each "release".

I'm pretty pleased with how this turned out. I hope it will lower the barrier for people to start trying out Continuous Integration, as well as provoke some thought about simplicity and minimalism. I've tried it out on a few flavors of Ubuntu VMs and my personal box, and it works for me. Please let me know what you think, and feel free to offer any suggestions for improvement.

Interesting Things

• APIdock.com is a web app that provides a rich and usable interface for searching, perusing and improving the documentation of projects that are included in the app.

Ask for Help

"We are getting 504 Gateway errors and we thing it is because our mongrels are freezing up do to inability to allocate memory, what to do?"

Without more info on the problem a few possibilities were suggested, such as the OS might be swap thrashing or the OS has no more memory to allocate.

One suggestion is to cut down your swap space to 0 in an attempt to verify that your mongrels are asking for too much, basically remove to OS swapping memory to disk from the equation.

Another suggestion is to boost your swap up to some insane size, also to take it out of the equation, the theory being that we know mongrel can leak memory, we trust the OS to keep the used memory in RAM, and we have plenty of disk space, so why put your OS in the position of not grating a mongrel what it is asking for.

Both solutions above don't seem ideal but, whatever, we are pragmatists, and if we combine those with periodic monitoring of the system using top/ps/vmstat, at least your mongrel can keep running and this may give you time to figure out why mongrel may be so memory hungry

Interesting Things

• If your wanting better out-of-the-box error messaging you can use one or both of the following plugins:
  • active_record_full_messages_should_be_nicer
  • validates_associated_displaying_associated_errors

If you choose to use both however ORDER DOES MATTER (use the order specified above) otherwise the validates_associated one just doesn't seem to work.

• Hash Iterations is very expensive (this includes my_hash.keys and my_hash.to_a etc...). We think this is related to the way hashes are stored in large, sparsely populated hashtables. If you can, avoid iterating over a hash, and if you must, try using a SequencedHash (which is provided by the collections gem) which solves this by storing hashes as both traditional hashtables and arrays, allowing for fast random access (the hashtable) as well as fast iteration (the array).

Ask for Help

"We want to load a different set of libraries for our selenium test than our regular tests. We tried to create a 'selenium' environment and pass that to the rake:test task but that didn't work, anyone know why?"

You cannot run in non 'test' environment with the rake tasks as the 'test' environment is hard coded into the test task, and passing a different RAILS_ENV seems to only have the effect of telling the 'test' environment what database to base it's schema off of.

Proposed work around - pass a second environment variable e.g. selenium=true and switch on that. (it's not ideal so we are still open to better solutions)

Interesting Things

• If you have a "target" method on your model, things will get a bit weird when you try to access this method through an association. Since associations have their own "target" method, you actually need to call assocation.target.target, or probably better, don't create methods called "target".
• Since Time.now always returns the time for the local timezone, if you use it in your fixtures, but then have your app running under a different time zone, the times in your fixtures will be incorrect. Use the active support helpers such as 0.days.ago instead, or if you have a timezone configured in your environment, you can use Time.zone.now

Ask for Help

"How can I test the route helpers in RSpec? If I'm passing a complex set of options to a helper I'd like to test that it's giving me what I expect."

Nobody had any serious suggestions, although many humorous testing scenarios were mentioned.

Interesting Things

• When using time zones in Rails 2.1, if you specify a zone, any datetime ActiveRecord attributes will be returned in that zone. E.g. if you specify Eastern Time, and then later request changed_at from an ActiveRecord, it will be returned in ET. However, if you ask for Time.now it is always returned in the local time zone, regardless of TZ settings. This isn't necessarily bad or unexpected behavior, but it can lead to test failures if you save a time to an ActiveRecord, get it back, and then compare the values. One workaround is to use Time.zone.now, which will always respect the current time zone, although this doesn't help with large existing codebases.

Ask for Help

"We're FlexMock for some of our Test::Unit unit tests, and recently added some new tests; nothing that is exercising new parts of the code or creating new mocks. However, for some reason when we call previously existing mocks we get errors from Rspec. These are not exceptions or assertion failures, but full-stop errors as if there were a syntax error. Turns out Rspec reopens the Test::Unit::TestCase class and overwrites some behavior, although the cause of the errors remain entirely unclear. Anyone know why it would do that and how to prevent it in the future?"

A few people mumbled about Rspec magic, but actual help was not immediately forthcoming.