I’m so not intested in a flame war. I want to start out by saying how much I appreciate Chad Fowler, David A. Black and Rich Kilmer. They continuously do great things for this community and deserve both respect and kindness. I also have respect for O’Reilly as a company… they’re good people over all and those who I worked with during RailsConf 2007 where both professional and capable.

A Little Background

I totally face palmed when I heard the Vegas announcement last year. I grew up in Los Angeles and Las Vegas was right in my back yard… I knew what to expect there and I certainly didn’t think it fit the conference experience I wanted. Originally I had no intention of going. I eventually succumed to peer pressure and submitted a talk. The talk was declined, but by the time it was I kind of felt like I didn’t really want to do it any way. I decided to go and do Caboose Conf because I didn’t want to judge something I didn’t even go see first hand, plus the potential to meet with people that I deal with online all the time seemed like it would have great value. It did.

What the Conference Was

General consensus was 2009 was a major step down from 2008. People seemed to think that many of the talks where duds, though there where some that clearly shined. The power issues during the tutorials where pretty amateur, the fact that they lasted more than one day, ridiculous. Very few people thought Tim Ferris was a good choice… I think the best thought I heard on this was “Whats next? Carrot top?”. Obviously this is all said from my perspective as someone hanging around the Caboose room, chatting with folks in person, on IRC and via Twitter. I did not see a single talk; there where only 4 on the whole schedule that I really would have wanted to attend (Uncle Bob, David A Black, David Chelimski and Obie Fernandes). Given the amount of money involved breakfast and lunch should have been better. I’ve seen better food at Barcamps which had tinny little budgets. I have not seen any blog posts yet from people who’ve gone before, paid for their ticket and said they loved it. Sure several speakers said it was good, but there is a bias there.

What good reports I have seen on Twitter and even some of the blog posts have been all about how great it was to see everyone. I agree with that sentiment, but feel like that was a success inspire of Vegas. A large group of us went out each night of our own volition and we did not once end up in a place with other rubists hanging out. In Portland you couldn’t turn around in town without walking into someone you knew or wanted to know. The disjointedness and size of Vegas had to hamper people who didn’t know a lot of folks.

Some of the fail is not the organizers fault. The vendor fair was kind of pathetic and there where few sponsored after parties. Everything was lower key due to the economy, and that’s understandable. In 2006 and 2007 we where not a mature enough group to have parties or vendor booths and neither of those conferences suffered for that lack.

The City

Like I said above I don’t like Vegas much. It’s a fake city. A thin veneer of glitz over a bunch of money grubbing schemes. That desperate to party attitude definitely infected the conference.

When ever you get a large group together there is a word or phrase that bubbles up again and again. You can learn a lot from looking at that. The one from RailsConf 2009 was ‘cougar’. Compare that to Merbcamps ‘awesome’ or Rubyconf 2008s ‘the community’ and you can see what I mean about the Vegas influence.

What the Conference Could Have Been

I have no expectation of the conference being like it was when it was smaller or taking on the magic of a Merbcamp or Rubyfringe. But the conference could be more. Here’s my proposal for 2010. Move the conference date into the summer. Take us somewhere where there is an awesome University and book the dorms an lecture halls there. On campus means better seating, session recording, kick ass wifi and for God’s sake POWER! There are always nice hotels near big schools, but incourage people to stay on campus. Think of what the atmosphere would be like and how much more productive we could be. Oh and bring back Dave Thomas! I know he runs a rival publishing company, by if you want to be in multiple markets this is exactly the kind of thing you need to suck up. I’d much rather ditch O’Reily if we have to make a trade.

See you thought I was just going to whine without making any suggestions :-) I know this would be a radical change, but I think it is a needed one.

Now I can restart everything when I want, and my login items list is just a little bit shorter.

This is what I came up with:

What do you think?

Issues - Collectively bugs, improvements and new features.  Often called Tickets (see below)

Projects - A individual piece of software.  Maybe a whole that stands on its own or a component that is developed separately from other components.

So what are some ways that we can deal with tracking issues and getting software written.

The “Ticket” system:
I suppose that we inherited this system from back before “computer people” evolved into “IT folk” and “Software folk”.  Most of the IT world works on a ticket based approach, and this is still the predominant model for software as well.  Most issue trackers use tickets that are simple web forms.  Some have way to many fields to be reasonable, some don’t have enough.  If we’re using the IT worlds model, we should probably stop and think about how that’s working out for them.  The short answer is that is sucks… badly.  How often do you have to deal with IT departments that suck?  Or, to get a smaller list, how often have you had IT experiences that did not suck.  I really feel like the ticket model provides a lousy experience for the customer, and I don’t think it really facilitates software development either.

One of the major downfalls to tickets is that we’re forcing the user to put their problem into our terms.  We want them to tell us what is wrong so we can fix it.  But the truth is that they often don’t know what is wrong or what is missing.  Of course they are happy to guess, but that doesn’t make them less wrong ;-)  So when a developer looks at the ticket, he starts of with a wrong impression.  That impression often clouds judgment and leads to poor decisions.  I don’t think that its the customers fault at all.  I think we’re asking the wrong questions.  So what are the right questions?

The “Story” system:
In the story system we ask “what do you want to accomplish?”.  If that is the input then we’re less likely to make assumptions and are more likely to get it right.  Lately XP and Scrums emphasis on stories driving the development process have made story trackers more popular.  Several of these trackers just give a place for the stories.  Or maybe the stories, bugs and tasks all separately.

The “XP” system:
In most XP writings the story is the initial input.  The customer decides each iteration what stories are the most important and then those stories are divided up into tasks.  Or maybe the stories get tasked before the iteration to help improve the story estimation process.  Either way stories are broken up.  In these systems all issues (including bugs) are stories.  It is possible that a story only has one task, or that the story has many tasks.

To me the XP system is where it is at.  The customer’s input on the stories is invaluable, without preventing the developers from having the freedom they need to implement well.  However, I haven’t seen any great implementations of this model yet.  Scrumy.com seems to be really promising, but without an API or the ability to attach files to items, it is just not there yet.

So what is it works for you?

Cerberus doesn’t have a web front end at the moment, but it does do email, Jabber and now Twitter.  If you’re looking for the simplest thing that could possibly work for your CI tool, this is it.

You will still not be up to date! You need to do this instead:

$ sudo gem install rubygems-update
$ sudo update_rubygems

1. Go to tab 1
2. Stop script server
3. Change directory to new project
4. Restart script/server
5. Go to tab 2
6. Stop autotest
7. Change directory to new project
8. Start autotest
9. Go to tab 3
10. Change directory to new project
11. Run sake gitrdone
    1. does svn up or git pull (depending on .git file)
    2. does rake db:migrate
    3. rake db:test:clone
    4. rake spec:db:fixtures:load
    5. rake notes
    6. svn status | grep ? or git status
12. mate .

So yeah, thats a lot. Way to much to do manually (even with the awesome sake script). So I started looking around the web to see what others had done. I found this OnRails article which seems to have met with some serious frustration, and the associated links. The outlook did not look good. So back to iTerm… again. That still wasn’t satisfying. Then I stumbled across something (I don’t remember what) that mentioned screens -X and its -X stuff command. The way it works is this. -X tells screen to do one of its internal commands from the outside, so screen -X next would change the focused window by one, either form inside the screen session or from outside of it. stuff ‘do this’ is the screen command that sends ‘do this’ to the current screen. That got me thinking… what if screen could be used to do all the magic that Apples sucky Applescript in Terminal.app can’t? So I started to fiddle and hack and read. Screen’s documentation is the suck, though I did find this source This led to the creation of the following script

#!/usr/bin/env ruby

def find_or_create_by_id(window_id)
  File.delete('/tmp/current_screen') if File.exists?("/tmp/current_screen")
  `screen -p #{window_id} -X hardcopy /tmp/current_screen`
  sleep(0.1)
  unless File.exists?("/tmp/current_screen") && File.size("/tmp/current_screen") > 0
    `screen -X screen`
    return find_or_create_by_id(window_id)
  end
  return window_id
end

i = 0
find_or_create_by_id(i)
`screen -p #{i} -X stuff ''`
`screen -p #{i} -X stuff 'cd #{ARGV[0]}; ruby script/server --debugger'`
i += 1
find_or_create_by_id(i)
`screen -p #{i} -X stuff ''`
`screen -p #{i} -X stuff ''`
`screen -p #{i} -X stuff 'cd #{ARGV[0]}; sake git_r_done; autotest'`
i += 1
find_or_create_by_id(i)
`screen -p #{i} -X stuff 'cd #{ARGV[0]}; mate .'`

I drop that into my bin dir under the title hack and now as long as screen is running I can do
hack ~/work/project/trunk
and off I go. It is worth noting that since it sends a kill to whatever is running in the first and second screen tabs, you have to run it from either outside screen or from some tab other than the first or second.

I also found this article that showed my some other features of scripting screen and allowed me to write a script I call all which takes whatever you type after it and sends it to all open tabs in a screen session.

I’ve coupled this with my .screenrc file and the new version of Visor lets me have simple drop down terminal with all the power I need.