Dave W. Smith

Tonight was the second session of the Silicon Valley Patterns Group’s Rails track. Last week was setup. By the end of tonight, just about everyone who wanted to was connected to some flavor of database. The group tonight was split 60/35 MySQL/SQLite, with a few outliers on Oracle or PosgreSQL.

Aside from a few specific issues (e.g., transactional fixtures don’t work with the Oracle driver), the problems people had getting Rails installed and configured fell into three clumps:

Missing pieces

People were coming at rails from several directions. Many people use Eclipse, so the Rails plug-in seemed an obvious choice. Two people didn’t realize that they also had to install Rails. Simple to resolve, thanks to a Wi Fi connection. There were a few cases of missing database drivers tonight.

Getting database.yml set up correctly

We had most of the problems with database.yml ironed out last week, but a few persisted. Most of the problems were formatting: Putting # in the wrong column when trying to comment out a line leads to strange failures. Trailing spaces lead to strange failures. Having your editor insert hard tabs leads to strange failures.

Mangled test fixtures

Same issues as above: One or both of hard tabs or trailing spaces bit at least a third of us. A few people didn’t get the idea of fixtures on their first attempt. The recent switch from instantiated to non-instantiated features confused a few people who’d read previous Rails walkthroughs.

Tonight’s session came off well, with lots of good energy in the room. Most folks who wanted to had worked through the single-table tagging exercise by the end of the evening, including the “left as an exercise” and “can you find the latent bug?” parts. (Leaving one failing unit test at the end of an excercise can leave people with with a sense of accomplishment.) Most people paired or trippled up, with a few singletons. Several people headed off toward building UIs, and one worked on ahead towards a many-to-many things-to-tags implementation. It’s normal in this group for folks to head off in whatever direction whim takes them.

Our plan is to take one-to-many and many-to-many relationships next week, and then head into Controller/View land, with an eventual sprinkling of magic AJAX dust.

It’s a little early for New Year’s Resolutions, but I’ve got this little problem that exerts itself whenever I walk through an office supply store. So, except for <loophole>professional needs</ loophole> …

Resolved: I will spend $0 on pads of paper, notebooks, pens, or ink in 2006.

Which leaves a bit over 5 weeks of 2005 to stock up.

Last year at about this time, we tried to do a hand-on Ruby on Rails track at the Silicon Valley Patterns Group. A few of us had been playing with Rails, it was just starting to get buzz, and we like to stay ahead of the curve, so why not?

We gave up. A year ago, Rails wasn’t ready for the kind of “kick it around on a laptop” work that we planned to do. It seemed like every release of Rails broke my development stack, forcing a scramble to either upgrade MySQL or find a new driver. We tried SQLite, but nobody was able to get it to work. It was a mess. We shelved Rails, and moved on to other things.

A year later, we’re back at it. This time things a lot better. Rails has come quite a way. There’s now a Rails book (which helps when you’re in a reading group), and the development environments for Rails have stabilized. The problems we’ve run into getting set up have, for the most part, been easy to work around. (Oddly enough, this time it’s the guy with MySQL 5.0 on OSX who isn’t able to get Rails working.)

A standard practice with Rails is to start scaffolding a screen mockup, fleshing it out until it looks like what you want, and then to work towards an implementation. We’re taking a different approach. In this track we’re going to build a simple tagging system. We’ll work our way up, Test-Driven, from the model layer, and only build controllers and views (also Test-Driven) once we’re satisfied with our model implementation. Whether or not this approach works (it has for me on one project), it’ll be a data point for the Rails experience base.

I’ll post our lesson plan once the group has been through it and the obvious errors are corrected.

My optometrist has a new toy. Embedded in what looks like several thousand dollars worth of “put your head here, focus on the green dot, and try not to move” medical equipment is a digital camera. After dilating my pupils (yuck, but overdue), he snapped pictures of the back each eye, then pulled the pics up on a shiny new 19″ LCD. The focal plane showed where the optic nerve enters each eye, the area offset from the optic nerve where primary focus happens, and various blood vessels and nerve channels. Everything apparently looked good. Nothing waved back.

Technology has advanced quite a bit since my first eye exam. Most of this exam was high tech. I’m pretty sure that the first box I stuck my eyes up against got my correction right within 30 seconds. We still did the reassuring “cover one eye and read the top line” ritual, which I suspect is now mostly used as an excuse to talk about anything else that might be bothering the patient, and to communicate the optician’s equivalent of “remember to floss.” At my age, that means keeping allergies under control.

Business Thinker, Teacher, and Author Peter Drucker passed away last week. Drucker was a Professor at the Claremont Graduate School while I was an undergrad. Then, I had no idea who he was. One evening after class I chanced by a classroom full of graduate students. At the lecturn was a diminutive gentleman (a polite way of saying “a short, older dude”) who held the class in rapt attention as he talked about business and management theory. I stopped in the hall and listened. He was fascinating. An hour passed by in moments. Then again a few nights later, and then the next week. By the end of the semester, I’d “sat in” on a Drucker class from the hallway.

It would be years before I read one of his books and had enough business background to recognize some of the seeds he’d planted. I regret never having shaken his hand.

This is the sixth AYE Conference, and (at the risk of famous last words) we’ve pretty much got the mechanics nailed down, leaving us time to focus on holding great sessions, rather than wresting with time consuming little details like “where’s the nearest office supply store?” or “where can I get good coffee?”

Today is the optional “warm up” tutorial for first-time AYErs, and a chance for the old timers to get together in the lobby. The conference proper starts with a banquet tonight, followed by three days of half-day sessions.

A theme is starting to emerge, and I’m curious to see what comes of it. A number of poeple I’ve talked with this morning–some old friends, some new–have mentioned being involved with Agile projects that have had to deal with legacy systems, including one alarming story of a project where the people with legacy knowledge had been let go six months earlier in a “cost saving” move. The common thread, though, is about the dysfunctions that emerge when management tries an Agile pilot project, likes the results, but then proceeds to try to nail Agile down as a repeatable, command-and-control process. I’m wondering if there is more to this than the typical reaction by organizational antibodies to any new change.

Nobody has mentioned Sarbanes-Oxley yet, but it’s on my private bingo card for the conference.