Second Sacramento Ruby User Group Meeting
Sacramento’s Ruby community is beginning to organize for regular meetings. Our first meeting about three months ago was more of a introduction and chat session. Several members had been to Rails Conf 2007 and had plenty to talk about.
We met again at Invision in Old Sacramento and talked about some organizational items:
- Ryan is acting as our organizer and we’re glad to have his energy in the role.
- Starting up regular monthly meetings. Looks like we’ll vote on the Google groups mailing list and the first Tuesday or Thursday of the month will be the candidates.
- Meetings will be held at Invision as Old Sacramento is reasonably central to where everyone comes from.
- We should have some short talks next time. One on the newer version of Capistrano and one on RSpec by myself. There was also a Django developer there who may do a talk on comparing current Rails and Django.
- People were interested in hearing from Mike Culver on Amazon web services so I’ll try to contact him about scheduling a talk.
We also grew our second meeting from four to five people so we’re a bustling community.
Learning In Tests
I was testing a method that did some validation of a 2 character state. It’s legacy code, very few tests so I’m learning about how the code really works as I go along. I was writing a test for the following line:
I wrote a test set the state property to “AA” and asserted that the validation failed. Problem was the validation passed and the test failed. OK, I found a weird defect. I took a bit of digging through layers until I got to the EJB layer where I found my answer:
Turns out “AA” is a valid state code defined by the US Post Office.
Average Developers and Agile
When you do Agile development you really need good people otherwise things won’t work. And my answer is have you ever seen a waterfall project delivering good software by putting baboons on it and giving them bananas.
This average thing is completely wrong. To produce software you anyway need good developers no matter what. You choose whatever methodology you want you are not going to deliver anything.
Scrum – Getting Started without Getting Burned
At the end of the day the best predictor of any project success is the people. Scrum can help good people work better, but you actually need the good people or you need to grow them.
Future of FIT/Fitnesse
We’re still using Fitnesse and its coming in quite handy for testing over 100 edits on some code we inherited. I still wonder how much it will catch on. Jeremey Miller has been thinking along the same lines:
Long term, all the testing gurus I know of seem to be driving towards scripting tests in Ruby and I’m thinking of moving in that direction in the future. I’ll still use Fit tests for set-based logic where it excels, but otherwise it just seems, I don’t know, clunky.
What do you guys think? Does Fit have a future, or is it just a little blip that’s never really going to take off?
I think FIT/Fitnesse gets a lot less use than your average JUnit framework, but the download numbers suggest Fitnesse is catching on:
- fitnesse20070619.zip 2551
- fitnesse20060719.zip 78608
- fitnesse20050731.zip 17551
The numbers for the 2006 version show some real promise. Hopefully the idea of automating acceptance tests is becoming a more widespread practice.
Are BugTrackers Agile
Every QA person uses a bug tracker. I had thought all our teams used bug trackers religiously. Turns out some of our QA people have adopted the idea that they should just walk over and talk to the developers and show them when they find a bug. Often those bugs get fixed quickly and never enter the bug tracker. If it’s going to be a significant effort to research and fix only then does it go into the bug tracker.
Another sign that our Agile adoption is taking a deeper hold. The point of QA is to improve the quality of the code. Fixing a bug when you find it is a better practice. Bug trackers can still be handy, but for a collocated team they’re less important.