Lone Star Ruby Conf 2009 Day One

I have to admit that this morning I was not looking forward to seeing another day of presentations after 3 days of Agile 2009 and 1 of Software Craftsmanship North America, but almost immediately upon entering the Norris Conference Center I felt welcomed. Part of this is that Jim Freeze, the LSRC head organizer, is a heck of a nice guy who recognized me in the hallway and said hello but also that when I sat down I noticed that every table had plenty of power for computers. Awesome. At Agile there was no power in any of the rooms and very limited access anywhere else. I type up my notes on the presentations as they happen (and I notice a lot of others do the same) so I spent much of my time at Agile glancing at my diminishing power and hoping I could make it through the next session. I know a lot of people hate open laptops at conferences but studies have shown that if you give some people something to do with their hands while they listen to a presentation they consume it more effectively. I know it can seem annoying to have the person next to you furiously IM-ing all his friends but that may just be his or her way of listening.


Something interesting - Dave Thomas

Ah to be so famous that don't have to bother to title your talks. Despite what seemed like a lack of preparation, once he got up there his talk seemed quite polished and interesting.

Dave mentioned early on that it's his tenth year using Ruby which is amazing for a man who has "the attention span of a gnat."

Why?

First of all, Ruby is a Multi-paradigm language. Ruby can do procedural, prototypes, objects, and even a passible interpretations of functional all in one somewhat unified whole. They idea is to let you, the programmer, do what you like.

"Ruby thinks the way I think" - which means it's imperfect. "It's gloriously imperfect."

Dave then showed a bunch of quotes from famous people talking about how the sterility of perfection can hinder creativeness. He ultimately concluded that if their is no ambiguity, there is no room for you.

An example of Ruby's ambiguity:
def foo x
puts x
end

foo { :e => 2 } # Syntax error!
foo :e => 2 # Totally fine

Ruby's interpreter has some quirks - there are heuristics that make your code read naturally and work 99% of the time. So, Dave concluded, some ambiguity is worth it.

Ruby keywords are loose. For example, is 'begin' is a keyword? Check this out:

>> c = Object.new
=> #
>> def c.begin
>> puts "hello"
>> end
=> nil
>> c.begin
hello
=> nil

Wacky.

Ruby's view is there is no right way.

The progress in Ruby is Messy. The size of the Ruby tarball is going going up exponentially while the number of methods is going up linearly. And Ruby 1.9 is very different from 1.8x. The benefit to breaking some backwards compatibility is new and powerful features keep entering the language.

The People are Messy.

Ruby was the wild west in the beginning with a small true community. But then someone found Gold in them thar hills. Rails came in and all of a sudden the group grew by leaps and bounds.

Dave was physically sick reading Zed's rant (in which Zed Shaw said some none too nice things about Dave). It was 9 months before he slept properly again. Dave thought he was part of the Ruby community. But Ruby is not a singular community anymore. To say Ruby is a community now would be like claiming there was a screwdriver community. Ruby is a resource around which communities gather.

In conclusion: Messy can be fun.


Programming Intuition - Glenn Vanderburg

Last year Glenn gave a talk called 'Tactical Design' in which he advocated focusing on three things for the beginning programmer:

• Do One Thing
• DRY
• SLAP (Single Level of Abstraction Principle)

Last year's talk was all about what you can do. This talk was about how you think.

What makes a programmer good is not a command of the syntax, it's more like art. Great programmers all talk about code as if they can touch and smell it. Large portions of human brains are designed to use 5 senses.

Glenn showed Bobby McFerrin at the world science festival teaching the audience the Pentatonic scale. Then he showed a visualization of Frederic Chopin nocturne opus 27 #2. The point being that music/computation/thinking are all would up together.

At one of Paul Graham's shops they had some mechanical gauges to tracking networks traffic. He could hear the gauges moving and knew when there is a problem without ever having to get up and look at the display.

Glenn was saying that we need to cultivate a sense of code. The best programers seem to use all the parts of their brain including the 5 senses. Quick feedback is essential to this.


Module Magic - James Edward Gray II

So when confreaks post this talk online go check it out. There was way too much code on the screen for me to even attempt to copy it all down. James showed off some pretty cool things you can do with modules. Check out his slides or the full talks and meditate on the code. What I really like about James' presentations is that he knows how to start off slow. He has a real teacher's gift for bringing an audience along.

Towards the end of the talk James said that he feels that modules can replace a lot of what we use inheritance to do now and without inheritance's side effects.

Update, he's posted the slides.

Succeeding with Rails - Chad Pytel

Chad is one of the founders of Thoughtbot and he went through some Thoughtbot's values and strategies that have guided them.

Hiring process:
1. Initial Resume and code review
2. Initial phone call - high level (who you are, what your goals are)
3. Second techincal interview.
4. Week long immersive trial. Payed.

Core hiring principles:

• Look for the best Skill and Attitude at a Salary you can afford.
• They hire all technicians (coders)
• No subcontractors or outsourcing

Clients:

• Do the best you can for the client
• Be proactive (over communicate). Have the hard conversations early.
• Set expectations and keep setting them. See above
• Be nice. And fire the not nice customers.
• Work the way they want or no deal.

Client interaction:

• Their project planning form is online.
• They use highrise for managing client information.
• Use master services agreement (how we work and how much you pay us) and set out the first several iterations
• Appoint a project lead (PM/CP)

Development values:

• Practice sustainable development - 40 hour work week
• Design first (build the user interface)
• TDD
• Iterative development - use Pivotal Tracker
• Focus on time instead of money
• People should do what they enjoy
• Always at least 2 developers
• Rotate people in and out of projects

Everything you do is marketing

Open Source:

• A part of their culture
• Payback for all the open source they use
• It Legitimizes what they do
• Gives them crowd-sourcing support
• They keep the quality of their open source high by using it internally before it goes out

Why did they get into products?:

• Consulting scales with people - but they don't want lots of people.
• Products scale without large groups of people

They focus on solving problems that they have and products they enjoy building


Checking under the Hood: A Guide to Rails Engines - Mike Perham

This was interesting talk where Mike went over Rails Engines, which are basically like a plugin that can have views and controllers.

Note: The real application code always wins over the engine in cases of name or file collision. You can use this to your advantage with a view you need to change.

There are no way to add migrations

To avoid model name collisions use name-spacing (Foo::User instead of User).

'helpers :all' will not load engine helpers

Static assets need to be copied over from the engine to the app


Dataflow: Declarative concurrency in Ruby - Larry Diehl

Dataflow is a ruby gem that handles some interesting concurrency problems in Ruby.

In your model:

class Foo
declare :my_var
def initialize
unify my_var, 1
unify my_var, 3 # kaboom
end
end

the second time you try to change my_var, it blows up.

local do | x, y |
Thread.new { unify x, "blah"}
Thread.new { unify y, "argh #{x}"}
y.should == "argh blah"
end

No mater how long the threads take a call to y will work in the above code.

There is a need_later method that will go off and do it's thing. If you try to call a method on the object returned by need_later it will either wait (if its not done) or return it (if the thread has finished).

FutureQueue, may come in at some point. With FutureQueue you can pop from it before you push to it.

Larry made inspect not block for debugging purposes.