BUTLER PRESS

This was a panel discussion: Joe O’Brien, Nathaniel Talbott, Justin Gehtland, Geoffrey Grosenbach, Robby Russell, Andre Lewis.

When did you decide to work for yourself?
- When CEO decided it was more important to have his boat instead HR staff
- Job ended
- Wanted to pursue music career (Robbie)
- Wanted to write code, and work with Rails
- Wanted to junk the traveling consultant lifestyle
- Wanted to build things for yourself

“Never do fixed bid.”

Companies come to Planet Argon asking for Rails — they don’t need convincing. Other people bid projects in RoR and Java, and let the customer decide.

How to compete with cheap people? How to talk people out of fixed bid? Tailor response to customer:
- Hourly rate or 2-3 month projects ballpark estimate
- Maybe for a big client, you could double or triple your price and do a fixed bid
Talk to client, and if you don’t convince them, bail on the work. Maybe do first iteration at time and materials, and do a bang-up job. If you measure and refine your process, you can do fixed bid.

Words of wisdom: “Can’t rewrite GMail for $20K.”

How many are thinking of going out and doing consulting o your own? 20% of the audience.

Tips

Do marketing via user groups, etc. Getting leads sucks, but sales is actually fun. Don’t be superficial about it. Give back to community.

You can email for a contract template andre@earthcode.com

Employees cost about the same as contractors, but you get more value because of collaboration
Incorporate, fool! So that your personal bank account is not at risk
- LLC or S Corp
- Talk to a CPA
- Need to build business credit history; fix separate taxes.
- Get a separate bank account
- AMEX card and buy something on it every month
Go to a local bank, where they will take your business seriously
- When that $100K check comes in, the banks will put a 15-day hold on it if they don’t know you

How do you manage to only work 40 hours a week?
- You don’t
- Hard to separate work and home when you work at home
- Have to be firm with yourself
- Find an office space

The last talk was interrupted by what looks like a gay marching band with big drums and batons. Awesome.

There are a couple of Google recruiters here: two cute geeky girls in tight Google T-shirts chatting with guys.

I just saw a “I broke the build” T-shirt with a big pointing finger on it. And based on my last work email, I should be wearing it. Sorry, Paul.

Some good demo-not-working hijinks in this one.

The speaker is from Thoughtbot (Boston Rails consulting). He gets the gold star for a very well-organized talk. He talked about practical lessons learned from developing a LDAP to ActiveRecord gateway daemon.

No standard way to do a daemon in Ruby

def daemonize
# Important
Kernel.fork and Kernel.exit
Process.setsid
Kernel.fork and Kernel.exit

# Less important
File.umask 0
Dir.chdir '/'
# Release any file descriptors
ObjectSpace.each_object(IO) {|io| io.close rescue nil}
STDIN.open('/dev/null')
STDOUT.open('/dev/null', 'a')
STDERR.open('/dev/null', 'a')
end


Or (shoot! now he tells me after I copied down all the code):

require 'daemon'
Daemons.daemonize
loop {
...
}


What you still need after require 'daemon'
- Rails. Include Rails env. Need to set AR concurrency to true
- Start/stop control. Can write Unix init script in Ruby. (Why didn’t I think of that!) In OS X you can use launchd.
- Ensure only one instance. PidFile class
- Config files. YAML
- Logging. Config log file with rollover
- Security. Use Ruby code to switch over to non-root user and group

How do you test a daemon? Spawn it before your test? Complicated, broken daemons might not die, not encapsulated. Use mocking framework.

Alternatives
- Rake tasks or script/runner
- nohup
- inted & xinetd

Final tips
- Daemonize as soon as possible
- Rescue anything that can fail
- logger.debug a lot

I became distracted after the first half of the keynote. Here’s what I remembered.

Cindy from ThoughtWorks led off. She tried really hard to throw in Star Trek references and a few cuss word, but occasional corporate consulting speak slipped in: e.g., synergy. 40% of ThoughtWorks’ new work in in Rails. They are building Rails apps for banks, telecoms, newspaper, media companies.

ThoughtWorks is rolling out RubyWorks
- Ruby prod stack (Mongrel, etc. in a package)
- 24/7 support offering
- 24/7 JRuby support
- dev tools and libraries
And Mingle: Agile project management tool. Rails + JRuby.

Tim Bray from Sun did more polling:
50% of the audience work for start ups; 40% for established companies; 10% for service providers.

Ruby was the first web framework for 1% of the audience.

30% of the audience came from Java
20% from .Net and C#
40% from PHP

I liked this talk. A Vonage architect and a senior developer talked about how they use Rails in Vonage. They use it a lot, which gives those of us chained to an enterprise paycheck great hope. This was a nice practical guide on how to intelligently use Rails in an enterprise. Here are the highlights:

You “must transform legacy app into small programs with transparent interfaces.” Change gradually and consistently because:
- People fear change
- Small projects are low risk
- You can adjust course rapidly
- You can show success early and often

Do small programs and projects; use transparent interfaces.

Hand-raising poll!
How many maintaining J2EE systems? 10%
How many hate it? Same 10%

Don’t rewrite: whole-scale enterprise legacy app replacement tends towards bloat. “Like working on a car while traveling at 60 mph.” So don’t tackle them in very small projects. The Standish Group did a survey: large projects tend to fail.

Write small programs. J2EE transforms small apps into one big app (ain’t that the truth!). Instead of reusing code, create simple programs with flexible interfaces.

Use transparent interfaces like REST
- Design for visibility and consumption, inspection, and debugging
- Interface inputs results in a predictable and dependable output
- This allows for easy re-use

How to rip apart the system
- Wrap features in simple RESTful servers
- Create a functional test suite

There are many systems in prod today that no one understands, so you need to identify a choke point for your feature. Start by creating a RESTful servlet that calls down into your DAO or service classes or whatever. Your new shiny Rails apps can call that. Use functional test suite and JDBC logging to map possible endpoints.

How to cope with bad database design? Databases degrade over time, just like code: no documentation; nonstandard database schema.

The speaker gives examples of eight different ways to represent ‘false’ in the same database column, dates stored as text, comma-separated values. The audience thinks this is funny, odd stuff. Look pretty familiar to me!

Did it work at Vonage? Yes.
- Quick time to market
- Maintainable code
- Now have tests
- Reduced lines of code

Where Does Rails fit?
- Rapid prototype
- Mission-typical tasks when performance and reliability aren’t as critical
- Cost analysis: When developer time in more expensive than hardware

Q & A:
Vonage versions their interfaces in their services — the response include the version number. Vonage is developing a RESTful service for customers, so that you could check your voicemail vi a your Rails app.
How do you manage deployment of many small services instead of one big EAR? JRuby
Real business rules are in the old code. When you ask people how things work, they are often wrong.
Sell speed and control over features to management to win their support.

Dirk, the speaker, is a founder of rackspace managed hosting. They have 1600 employees.

Dirk develops for the enterprise, but he’s not an “enterprise developer.” I.e., Gantt charts, ties, TPS reports.

Three big steps in building an enterprise Rails app:
1. Build a team
2. Build the app
3. Get it to play with others

Build a team

An anchor (someone who knows Rails ) makes it easier.

The Learning Rails Curve
1. Everything is so weird!
2. The “black magic” is annoying. (And scary.)
3. Tasks get done with little code
4. You look up how to do thing in Ruby
5. You realize how much faster they are at building things
6. You stop saying: in Java/Python/PHP, I’d do this …
7. Why didn’t I switch a year ago?
8. On Rails
Payoff is at #8.

More hand-raising polls! Only one person was a Ruby developer before they became a Rails developer.

First rackspace Rails app used to manage Katrina evacuees in San Antonio. Developers always say that we have no time, but they had people getting on evacuation buses before the app was coded. (I think this isn’t the only Rails app that is Katrina-inspired.)

Build the app

“Finish lines are only for consultants and demos.” People depend on your app, and downtime is bad. So you need tests.

50% audience knows what Test-driven Development is. 40% do TDD. The speaker, Dirk, doesn’t actually do it. He recommends rcov to check for test coverage.

He asks: How many of you use IE? Me (Scott) and like two other people raise their hands! News flash from Dirk and me: your users use IE!

Selenium is great, but … if your UI design isn’t set, it will become a huge time sink to keep the Selenium tests running.

Get it to play with others

No app is an island in the enterprise. Integrate early because things that seem easy — are not; and integration takes time to figure these things out. That sure is my experience with Banfield’s WPA project and our integration with Petware 1 and 2.

Integration testing is hard with enterprise systems, and mock objects help here. The rackspace team is arm wrestling over FlexMock versus ‘.

There is nothing that they haven’t been able to integrate with.

Evan, you seem cool: sorry you are my second choice. I had planned on going to the talk on REST, but needed coffee and a couple of other essentials. When I got to the REST talk, all the seats were full and spaces to stand at the wall were rapidly disappearing. Since I was already leaning towards just diving into REST anyway, I turned around and dropped into Going Off Grid.

So Evan works on the ‘bio’ project at the University of Delaware. They “emerge high order properties from raw sequence data.” He also writes all his slides in lowercase.

The actual calculations happen on ‘biowolf,’ a 128 Linux node supercomputer. They send jobs to the cluster using a REST-ful record server using yaml. So that’s cool. Maybe they should have used Merb?

They use Django as the admin interface.

Evan contributed an extenstions to Rails from this project: the has_many_polymorphs plugin. He learned some unpleasant things about ActiveRecord, mainly that the AR code is nasty:
- massive case statements
- SQL strings all over the place
- tightly-coupled classes

Evan says that the project had big integration issues. I can’t help but think that some of those issues were self-imposed.

Now he works at c|net. Their Rails app handles 2 million users/month, and this caused scaling issues. So they junked AR and use a hyper-denormalized model. The essentialy use the database as a hash. They use memcached “like most large Rails apps (Flickr, livejournal).” Really? It’s probably true — I’m just not clued-in.

When do you need a DB? When you really can’t predict what you might want to know. Most of the time, web apps know what the need….

Usually gives this talk to Java developers; converted it to Ruby; talk shrunk in half.

What can we do with bad code?
“Grand Redesign in the Sky” by the “Tiger Team.” Bad idea: takes too long, and the poor fools stuck maintaining the legacy code hates them! Incremental improvement is a better alternative. That means:
- Always check it in a little bit better
- Never let the sun set on bad code
- Test first

The meat of the talk is a refactoring of a command line argument parser. My attention always wanders in these sorts of things. At least Uncle Bob asks us to raise our hands a lot (I don’t know why I am so interested in this exercise). Here are some highlights:
80% of the audiences tests
30% test first
10% measure test coverage
5% use RSpec
60% do metaprogramming
30% former Java programmers
5% former C programmers
5% former .Net programmers

“How many people have trouble maintaining if/else statements?” Maybe 10% of audience. Really? Sign them up to work on Con-way Bill Corrections!

Not too many people have heard of Open/Closed Principle.

No one intends to build a festering pile. But we don’t write the code right the first time.
Here’s a good way to ruin a program: make massive changes. The antidote is to use Test-driven Development (TDD) and keep all tests running 100% with every small change.

Side comment: “You guys still make things private? I don’t know if I still believe in that.”

News flash: RadRails successor (Aptana) can do some simple refactorings in Ruby like extract method.

Bad code: nothing has a more profound and long-term degrading effect
- Bad schedules can be redone
- Bad requirements can be redefined
- Bad team dynamics can be resolved: “Fire the asshole!”
- Bad code rots and ferments
- It becomes an inexorable weight that drags the team down

Professional write tests — first. Professionals clean their code. Professional know that the only way to go fast … is to go well.

You know, I can’t help but think that a lot of this is self-evident to any professional who takes their job seriously. I wonder, too, if it’s wasted on the audience — this is a group of people who choose to attend the Clean Code talk at RailsConf after all. Bob Martin is a good speaker, though. I’d like to send every mid-level developer I might work with some day to this talk.

I just left the keynote. I also found out today that Con-way has some sort of web blog bot thing sniffs out any mention of “Con-way.” So, “Hello, HR!” Con-way. Con-way. Con-way. Paul J. Christopher has been doing a bang-up job and deserves a large raise.

There are 1,600 people at RailsConf — there were like 60 at RailsConf 2005. Show of hands: 80%+ of audience is getting paid to write Rails code.

Our fearless leader, David Heinemeier Hansson talked mostly about Rails 2.0, after a few digs at Java, a couple F-bombs, and a few boasts about Rails book sales.

The Rails release cycle is lengthening. Lots of people are using it, and everything doesn’t need to change all the time any more.

Important information from DHH: Rails 2.0 is not a unicorn! In other words, focuses on REST and other evolutionary improvements. All the features are in Edge (that’s a fancy term for HEAD/trunk) and should work now.

FormBuilder mentioned again.

DHH doesn’t like config files because he doesn’t like being bothered by decisions that he doesn’t care about. You and me both.

Most of DHH’s talk was a demo of how to use REST in an example address book app. Nice to have a keynote that is essentially a developer talking to other developers about coding. DHH starts with one model via scaffolding. “Adding anything new would be a pain in the ass … not!”

There was a cool demo of using the console to work with XML object. Call save() and it makes a HTTP PUT call to update the database.

Nine other things that DHH like about Rails 2
1. Breakpoints are back
2. HTTP Performance. DHH: OK, OK, it does matter. Framework can cache JavaScript files into one bug gzip’ed bundle. Asset_host: allows browsers to open up more simultaneous connections.
3. Query cache.
4. Action.mimetype.renderer. E.g., index.rhtml -> index.html.erb. This fixes mixing of template type and output type. (I like.)
5. Config/initializers: organizes config details into files.
6. Sexy migrations: basically flips column name and column types
7. HTTP authentication: Bad for UI for humans, good for computer clients.
8. The MIT license is the default
9. Spring cleaning: removing a lot of deprecated stuff; moving some thing like in-place editors out of Rails core and into plugins

So, I heard from more than one person that the second half of the morning JavaScript tutorial (which I skipped) was significantly better than the first half. Sorry, Thomas. With that in mind, I resolved to grind through the whole afternoon tutorial no matter what happened. Fortunately, it was pretty good stuff for people like me whole like their UI code all polished up and shiny. I even stayed when someone started drilling through concrete on the other side of the wall.

Bruce started out talking about MVC (Model View Controller). He pointed out that, in Rails, we end up with clean Ruby code in the M and C and crappy V code.

Views are hard to: master, explain, reuse, extend, test, agree on. True enough in my experience.

Bruce’s recommended plan of attack:
1) Choose a templating system that works for you
2) Find common patterns to extract into reusable code
3) Extract, abstract, repeat

There was a review of the major Rails view options. Bruce asked for a show of hands: the great majority of people use Rails’ default ERB-based template system; a few use Haml and Markaby. I’m going to list a summary of the tutorial’s summary — the RailsConf talks are going to be available online if you are dying to get all the details. If my motivation doesn’t flame out, I’ll link to them.

ERB: Like PHP in Ruby. Heavy, ugly, hard to abstract.

Markaby
Pros: concise, easy for Ruby developers
Cons: performance, trickly with layouts and helpers

DRYML (XML):
Pros: Very reusable, complex output from concise input
Cons: Complex, lot to learn, language onto itself

Haml
Pros: Concise and fast to type
Cons: Unusual, strict whitespace, not very reusable?

Liquid:
Pros: Great for user/designer collaboration
Cons: Time to extend filters/drop

Amrita2
Pros: Clean markup, fair WYSIWG
Cons: Conceptually different, tighter data-to-layout coupling

MasterView
Pros: Great for teams that need to support WYSIWG tools
Cons: Complex, requires generation

After the review and the lukewarm endorsement of ERB, we all anticipated the climatic: “Now, let me introduce the best view solution. The one that the Rails ninjas use.”

Turns out that Rails ninjas use the default ERB templates. Oh, well.

Bruce is really focused on finding patterns — standard design elements, controls. I guess that makes sense given that the tutorial is about DRY’ing up views.

View smells:
- Calling find() on a model
- Calling find() on an association
- Conditionals
- Complex inline map, sort, or select statements
- Assigning temp variable

We spent a lot of time talking about blocks to build content and as alternatives to if/else statements, helpers, and partials.

So instead of:
<% if @user.admin? %>

Admins see thislt;/p>
<% end %>

You do this:
<% admin_content do %>

Admins see thislt;/p>
<% end %>
You implement the blocks in Helpers, using the block& parameter and yield.

Rails has moved in this direction, too: <% start_form %> … <% end_form %> tags became <% form do % ... <% end %>.

I am too lazy to give specific code examples, but I’m a believer. Not that these blocks make views dramatically better, but they can help make your views into logical component assemblies instead of bastardized HTML markup, and they’re for sure easier to test. The approach is certainly more Ruby-like. And block helpers, unlike partials, have a programmatic Ruby API.

Bruce says: “approach Rails development like a language designer.”
- When you create an app, you are creating a language
- Everything you write is an API
- Implementation is the easy part, get the API (names) right first.

This advice rings true to me. If you want to work effectively with large teams, and create code that other people can use, you should follow his advice. I’ve never grasped what the Extreme Programming folks meant by “metaphor.” I suspect they should have said: “Use good names.”

Side note: if Ruby and Rails are old news to you, apparently the cool kids are into Haskell, OCaml, and Erlang.

Bruce mentioned FormBuilder. It’s in Rails and poorly documented, but looks handy. That led into his recommendation to read other people’s source code, especially Rails’ source. It’s clear enough that the code is often the direct answer to your questions. And you’ll learn something about coding.

The talk wrapped up with some speculation that our views will all become like Seaside — a bunch of classes that generate their own markup. I don’t know, maybe Bruce’s views will end up that way. It’s true that my UIs generally evolve in that direction. I replace repetitive markup and helper methods with full-fledged OO classes, too. But I really doubt that I’d want to start building my app that way. I’d wait to discover the need for more abstraction and build it in then.

Another side note: Bruce mentioned that one of his apps had (ah, can’t remember exactly) over 100 partials. Other people have mentioned Rails apps with hundreds of controllers, views, models. Are they hacks? Or am I just small-time!