chris blogs

RailsConf Europe wrapup

Tue Sep 19 18:47:35 CEST 2006

Writing another general and full review of RailsConf Europe would not only fail to be complete, but also repeat a lot of work others already did very well. I’d recommend you to read Planet RubyOnRails and will continue with my personal remarks now.

My last dabbling with Rails already has been over a half year ago, and in the mean time a lot of things changed. Not only Rails overall got better—especially the changes in the development trunk and the new RESTful stuff as presented in DHH’s keynote give me a warm and cozy feeling—, I also got a far better understanding of Rails. It appears as if I’m converging to Rails, and Rails converges to me; but I can’t tell how fast this happens or when we are near enough for both of us to stay comfortable. I think it will happen earlier than I think. (If you ever plan to hire me for writing English, please forget about this paragraph.)

In the end, it comes down to this: There are decisions done in Rails that I don’t agree with. But if I just suck it down, the reward will be far bigger than the price: You get a great community that contains a lot of top-notch people involved around building the web. You get a lot of convenience, you’ll never have to redo the same boring stuff again. (Even if I’d write my own framework, I’d at least have to do them once.) And, when you understood the relevant parts, due to the power of Ruby, you still can fix what you want, then. Dave Thomas told in his keynote the paradox of “You can’t possibly use something before it’s being used.” My problem is more along “You can’t possibly grok something before you grok it.” Or “You can’t possibly fix something before you know how it’s broken it.” But can taste be “broken”? Is it even taste, or is it a well-informed design decision?

I’ll be using Rails for my next web project; parts of it already are done and I think they can be integrated easily. I want to use it. And I know I probably won’t get it right the first time. And I’ll retry. And I’ll see how I get along with Rails, and if it (still?) doesn’t work for me, I’ll just do it my way. That will be quite some more work, in the end, so I’d really like to avoid that happening.

Last, but not the least, I’d like to thank all the people that made RailsConf possible and as great as it was—not only the people that organized the conf or gave excellent talks; but also everyone I talked to, let me stay in their flat or even actually invited me to come there. They know who they are, and I’m really very thankful for everything they did.

There is one more index card I’d like to post last, even if it’s actually been written first.

Interesting things you see when taking the coach:

• a Polish car
• a dead bird
• another, 1, 2, 3
• the coach actually takes longer than the flight
• a gluestick
• a banana skin
• an orange skin
• arcane camera logos

NP: Johnny Cash—Highwayman

RailsConf Europe on index cards, part II

Sun Sep 17 16:30:00 CEST 2006

A note to the interested reader: These are the raw notes I jotted down at RailsConf Europe 2006. They are probably misleading, out-of-context and not particularly useful if you didn’t attend the sessions. Nevertheless, enjoy.

Jim Weirich: Playing it safe

• Are open classes a poor fit for large projects?
• The Chainsaw Infanticide Logger Maneuver
• Leeroy Jenkins
• “Guard against Murphy, not Machiavelli” —Damian Conway
• use namespaces
• 10 Node classes on his disk
• Choose project name carefully.
• Avoid toplevel functions and constants.
• lessons from Rake
• Avoid modifying existing classes.
• Prefer adding over modifying.
• When adding, use project-scoped namespace.
• When adding public methods, ask first.
• Chain into the next hook.
• Only handle your special cases.
• Limit the scope of your hook.
• Preserve the original behavior.
• Understand and respect contacts.
• Require no more—promise no less.
• Replaced behavior must be duck-type compatible.
• All in all:
  • Be polite with global resources.
  • Preserve essential behavior.

Why The Lucky Stiff

• Remove your moustaches
• Ilias, anywhere?
• sandbox demo

(unreproducible on index cards)

Hussein Morsy: Database Optimization Techniques

• 1.5 years Rails experience, PHP before
• works on a German Rails book
• overview of his workplace
• optimizing:
  • Rails code
  • Indices
  • DBMS
  • OS
• optimize:
  • number of connections
  • transmitted data
  • DB itself
• read the AR source!
• AR strangeness (proxying)
• selecting only what you need
• preloading children
• preloading and selecting
• counting
• …

Dan Webb: Unobtrusive AJAX with Rails

• History
  • Dark age of DHTML
  • Fixed resolution
  • Web standards arrived
• Benefits of Web standards
• Behaviour: View layer among CSS and XHTML
  • enhancing a working app
  • graceful degradation
• not the Rails way
• Don’t use <a> with onclick= only
• http://www.ujs4rails.com
• Links should not have side-effects
  • use button_to
• Form.serialize
• Demo, sneakr.com

Hamton Catlin: HAML

• “My other computer is open source.”
• HTML Abstraction Markup Language
• templating sucks in Rails, compared to the other stuff.
• Principles
  1. Code should be beautiful
  2. XHTML is prone to errors when done manually
  3. XHTML structure matters
  4. Diet soda can help you lose weight.
  5. Common markup is good.
  6. DIVs are building blocks.
• Demo
  • indentation matters (ugh?!)
• no control structures (use partials, arrays)
• partials are properly indented
• http://unspace.ca/discover/haml

James Duncan Davidson: The web is a pipe, and more

• Unexpected things tell us lessons.
• Cigarette smoke is useful for finding cracks in airplanes.
• didn’t expect that Ant will turn into a language
• In the early days, we used FastCGI to deploy.
• FastCGI turned out to be weak sauce.
• HTTP is the real thing, stick to it.
• You learn how stuff works best when you look how it breaks.
• the simpler, the better
• Flatten storage and memory
• Amazon
  • S3, they use it themselves
  • EC2
• Google: BigTable
• MobileFS
• CPU cycles *do* matter
  • more power
  • more energy
  • help save the environment

Dave Thomas

• This conf had highest four-letter words concentration.
• thinking about terrorism
  • not about killing, but leveraging fear, making people afraid
  • overreaction
  • fear is wasteful
• lessons
  • assess risk
  • FUD
  • lately(?), FUD has started about Rails
  • Java is dynamically typed too (e.g. Collections, casts before 1.5)
  • “You can’t possibly use something before it’s being used.”
  • “Every publisher has Ruby books coming out—they’re all copycats.”
  • The opposite of risk is not safety—it’s stagnation.

NP: The Byrds—Glory, Glory

RailsConf Europe on index cards, part I

Sun Sep 17 16:09:36 CEST 2006

A note to the interested reader: These are the raw notes I jotted down at RailsConf Europe 2006. They are probably misleading, out-of-context and not particularly useful if you didn’t attend the sessions. Nevertheless, enjoy.

David Heinemeier Hansson

• Textmate as a presentation tool
• Later on 1.2.0rc1
• REST, SimplyRestful
• 5 months since last release
• next release after 1.2: 2.0(!)
• Rails is not about inventing your own style
• Demonstration of SimplyRestful
• ActiveResource
• SimplyHelpful: clearing up the view
• assumptions about partial names
• new development happens on plugins
• Flower?

Kathy Sierra: Creating Passionate Users

• Passion
• Passion is not rational
• High-resolution experience
• Don’t focus on the tool, but what to do with it
• Conversational beats formal
• Flow
• If you want them to RTFM, write a better FM.

Evan Henshaw-Plath: Integrating Asterisk and Rails

• PHP of telephony: ugly and hackable
• Evil apps: “To enlarge your penis, press three.”
• call routing and transcoding platform
• configuring Asterisk—sendmail.cf
• RAGI bridges Asterisk and Ruby
• RAI is a RAGI fork under active development
• http://rai.idapted.com

Jamis Buck: Cutting Edge Capistrano

• What is Capistrano
• the need to manage/deploy a cluster
• Version 1.2 this morning
• Restricting scope to single machines, roles
• remote execution (invoke, shell tasks)
• capistrano-ext
  • watch_load
  • uptime
• Future
  • third-party extensions

Marcel Molina, Jr.: Sharing RJS: Reuse at application level

• Introduction
• David has and belongs to many Hanssons
• Refactoring RJS code to avoid duplication
• various approaches
  • refactor to helper… DON’T
  • monkeypatch… DON’T
• History of RJS
• conclusio: Reuse RJS snippets with <<, made for JavaScript inclusion.
• Bonus: reuse RJS elsewhere
• Don’t use DOM if CSS is enough

David A. Black: Relational Database Engineering and Rails

• Are Rails databases well engineered?
• Lessons from REST and CRUD
• Return to the protocol is not a step back
• Normalization is good
  • never heard of with respect to ActiveRecord
  • good
• ActiveRecord databases are application databases
• REST and CRUD converge
• 80%-baked database engineering
  • first normalize, then AR-ify

Thomas Fuchs: Adventures in JavaScript testing

• http://mir.aculo.us
• use alert() only when appropriate
• unit-testing JavaScript
• using Rake to automate tests with the javascript_test plugin
  • uses WEBrick
• BDD, rspec-like API, too
• Tools:
  • Firebug
  • Venkman (can profile)
  • Safari Web Inspector
  • Drosera
• test on all browsers you want to support
• #prototype on freenode.net

NP: The Byrds—My Back Pages

Off to RailsConf Europe 2006

Tue Sep 12 21:08:23 CEST 2006

Tomorrow I’ll fly to London to attend RailsConf Europe 2006. Since I don’t want to travel with my iBook, I won’t have mail, IRC and can’t live blog. But I wont be angry at non-working WLANs, either.

I have a hipster PDA with me, and an (albeit digital) camera, so don’t feel too safe. I like the idea of attending a conference were many are gazing over of Web-2.0-iness and AJAX with some pens and paper. I’ll note everything.

If you’d like to meet me beforehand or on Saturday noon, feel free to contact me.

I’ll also be at the PizzaOnRails pre-RailsConf event, yum.

chris blogs and Anarchaia will resume publishing on Sunday, September 17.

Have a good time.

NP: The Byrds—Turn! Turn! Turn! (To Everything There Is A Season)