has_many :thoughts: Tag RailsConf

My RailsConf 2008 picks

Colin A. Bartlett — Wed, 28 May 2008 21:16:00 -0400

Here are my tentative selections for RailsConf 2008. Looking forward to everything!

Thursday:

Refactoring Your Rails Application
Developer Testing Tricks

Friday:

Entrepreneurs On Rails
Hosting and the Woes
Faster, Better, ORM with DataMapper
“Design Patterns” in Ruby
UI Design on Rails

Saturday:

Optimizing Rails
Asynchronous Processing with Ruby on Rails
Fast, Sexy, and Svelte: Our Kind of Rails Testing
Integration Testing with RSpec’s Story Runner
Metaprogramming and Ruby Internals for Rails Programmers

Sunday:

De-Railing: Smashing the Rails Stack
Oh the Fail I’ve Known
Building an app in 48 hours – A Rails Rumble Case Study

RailsConf 2008 - Justin's Schedule

Justin Reagor — Wed, 28 May 2008 20:52:00 -0400

Below is the schedule I came up with when going over the sessions available this year at RailsConf… Going to try to make these, if not switch with Colin so we cover the conference well… very glad to see some advanced classes! Would have loved a REAL advanced Rspec session though.

8:30am Thursday, 05/29/2008
Meta-programming Ruby for Fun & Profit Portland Ballroom 252
Neal Ford (ThoughtWorks), Patrick Farley (ThoughtWorks) Ruby is the revenge of the Smalltalkers. Not since Smalltalk has a language had such powerful meta-programming facilities. While this may seem like a minor feature, it turns out that surgical meta-programming allows solutions to problems that are clearer, more concise, more maintainable, and take orders of magnitudes fewer lines of code. Read more.

1:30pm Thursday, 05/29/2008
Powering AIR Applications with Rails Portland Ballroom 252 Tony Hillerson (EffectiveUI), Daniel Wanja (Nouvelles Solutions, Inc.) Adobe’s AIR platform offers developers familiar with web technology the tools to create desktop applications. Come and learn how to drive an HTML and a Flex AIR application with Rails using RubyAMF. Read more.

10:45am Friday, 05/30/2008
Entrepreneurs On Rails Portland Ballroom 251
Dan Benjamin (Rails Machine) Many of the people working with Rails are independent developers, doing freelance work or running small development shops. This makes sense – Rails provides a great framework for an indy developer, making it easy to work with with designers and other developers. Read more.

11:45am Friday, 05/30/2008
Hosting and the Woes Portland Ballroom 255
Ezra Zygmuntowicz (EngineYard), Jamie van Dyke (Engine Yard), Tom Mornini (Engine Yard) What are the day to day issues with Rails hosting. How can they be solved, and what are the best practise methods of avoiding them. Engine Yard have extensive experience with high volume Rails applications and would like to talk about what we’ve learned and what our customers have learnt. Read more.

1:50pm Friday, 05/30/2008
Faster, Better, ORM with DataMapper Portland Ballroom 256
Yehuda Katz (EngineYard) This session will cover using the DataMapper ORM with Ruby on Rails, and go in-depth into its code. It will focus on integration with Ruby on Rails and provide an advanced-level overview of the codebase and design philosophy. Read more.

2:50pm Friday, 05/30/2008
Rubinius – Under the Hood and Behind the Curtain D135-136
Evan Phoenix (Engine Yard), Brian Ford (Engine Yard), Wilson Bilkovich (Engine Yard) Rubinius is a virtual machine built from the ground up to provide a robust, high-performance runtime for Ruby code. The Rubinius team is guiding the development of 20,000+ specifications that define the Ruby language. Read more.

4:25pm Friday, 05/30/2008
The Launch: Dos and Don’ts of Real Life Deploys Portland Ballroom 255
Chris Wanstrath (Err Free) There’s more to launching an app than “cap deploy”—the process is as much a psychological challenge as a technical one. So, what does it take to launch an app you can depend on and be proud of? With a handful of production launches under his belt, Chris will talk about the big picture and little details of bringing your site to life. Read more.

10:45am Saturday, 05/31/2008
Assembling Pages Last: Edge Caching, ESI & Rails Portland Ballroom 256
Aaron Batalion (Hungry Machine LLC) When working on scaling Rails to millions of users/day with complex personalization, caching becomes essential. This talk will cover edge caching, edge side includes (ESI) in Rails, and partial page caching higher in the stack. It will also cover ESI as a fabric for assembling heterogeneous applications into a single, cacheable web experience. Read more.

11:45am Saturday, 05/31/2008
Advanced RESTful Rails Portland Ballroom 252
Ben Scofield (Viget Labs) Designing RESTful systems in Rails carries many benefits. It is not a problem-free approach, however; there are accessibility issues with the standard conventions, and some functions are more difficult to map to resources than others. In this session, we’ll look at solutions for these (and other) problems that arise when you take REST beyond the standard examples. Read more.

1:50pm Saturday, 05/31/2008
Build Your Own Distributed, Self-Configuring Rails Cluster Portland Ballroom 251
Dave Fayram (Powerset, Inc), Tom Preston-Werner (Powerset, Inc.) Fuzed is a Rails server stack written in Erlang that can replace standard mongrel/reverse proxy architectures. It focuses on reliability and ease of deployment in distributed environments. Read more.

2:50pm Saturday, 05/31/2008
Custom Nginx Modules: Accelerate Rails, HTTP Tricks General Portland Ballroom 251
Adam Wiggins (Heroku) Got a Rails app that needs even more speed? Adam Wiggins of Heroku will show you how to write a custom Nginx module to bring blinding speed to critical code paths (and do HTTP tricks that can’t be done with Rails and Mongrel alone), using examples from Heroku’s own authentication module ngx_heroku_gate. Dust off your C compiler and prepare to push the limits of nginx, Rails, and HTTP. Read more.

4:25pm Saturday, 05/31/2008
Metaprogramming and Ruby Internals for Rails Programmers Portland Ballroom 256
Patrick Farley (ThoughtWorks) Rails programmers are Ruby programmers. In this session we’ll cover some useful Ruby metaprogramming techniques as used in real world Rails applications and extensions. Then we’ll dig deep into MRI and JRuby source to gain a nuanced understanding of the implementation details of Singletons, Mixins and the Ruby Object model. Read more.

10:45am Sunday, 06/01/2008
Scaling Ruby from the Inside Out Portland Ballroom 252
Ezra Zygmuntowicz (EngineYard) This is a talk about what it takes to really scale Ruby applications. We will not only examine all the aspects of hardware and web server configurations, we will also look at scaling the ruby interpreter itself. Including performance quirks of MRI and how Rubinius is set to fix a lot of these problems. Read more.

11:45am Sunday, 06/01/2008
Everyday DTrace on OSX: A Guide To Using DTrace for Your Full Application Stack Portland Ballroom 251
Scott Barron (EdgeCase), Chad Humphries (EdgeCase) Have you ever wanted to know why a part of your application is slow? How about how long that query takes? Wouldn’t it be nice if you could get this type of information for ruby, rails, and the database server in one place? You can now with DTrace on OSX 10.5. We’ll show you how to best use this tool-chain to debug, profile, and gather more information about your application. Read more.

1:50pm Sunday, 06/01/2008
Building an app in 48 hours – A Rails Rumble Case Study Portland Ballroom 251
Josh Owens (Intridea, Inc/Web 2.0 Show Podcast), Chris Selmer (Intridea, Inc.) So you want to build a Rails app quickly? Competitors in the Rails Rumble had 48 hours to design, develop, and deploy a complete application. Weâ€™ll take you through the development processes of the winning four-man Tasty Planner team, and compare it with those of the one-man Your Pet Records team. Weâ€™ll discuss techniques, short-cuts, helpers, and Rails plugins that helped speed development. Read more.

Registered for RailsConf 08

Colin A. Bartlett — Thu, 31 Jan 2008 07:02:00 -0500

Justin and I registered for RailsConf just the other day. I’m excited of course. Last year was a great time. I learned a ton… I hadn’t even been using Ruby/Rails that much before then. So I think this year I’ll get even more out of it. And having another team member along with me means we can double the sessions—last year I was often disappointed that I had to choose between two equally decent sounding talks.

I again signed up for the first day of tutorials this year. Last year I ended up sleeping on a bench in O’Hare and therefore missed my first tutorial. I’m hoping on a better flying experience this year.

I picked:

Justin picked:

4 months, today, until the conf…

Skinny Controller, Fat Model

Colin A. Bartlett — Fri, 01 Jun 2007 21:07:00 -0400

One of my favorite talks from RailsConf was by the team behind The Rails Way. Now back from the road trip and settled in, they have updated their site with some more details about one of the ideas they pushed: Controllers should be simple, basic, and generally have a lot less code then most of us use now. Most of your logic should end up in the model.

There’s many reasons for this but the three I like the most:

It forces you to write code that more easily reused. Limits your temptation to copy/paste from one controller action to another.
Your templates can become more details. @order.total instead of @total (which would have to be mapped to something logic in the controller.)
The code is more easily tested. You can programmatically access the results of the methods in your model without having to munge HTML output from a controller.

Their post has all the details and code samples.

RailsConf Wrap Up

Colin A. Bartlett — Tue, 22 May 2007 07:24:00 -0400

Here’s a wrap up of all my posts from RailsConf 2007. (The ones with actual useful substance, that is.)

All in all, it was a fantastic convention. As can be expected, some presentations were better then others. Suggestions for next year include:

Better descriptions of the sessions and of the speaker’s experience.
Perhaps repeating some sessions at multiple times.
Better planning of expected attendance at each session so proper room size could be selected.

There’s a number of talks I didn’t get to see that I really wanted to. In the coming days, I hope to find their presenting materials online to see if there’s anything I can glean.

The Rails Way

Colin A. Bartlett — Mon, 21 May 2007 11:01:00 -0400

Sunday’s morning keynote at RailsConf was by Jamis Buck and Michael Koziarrski, both committers to the Rails core. The format was quite useful: a series of short code reviews from a variety of submitters to their website, The Rails Way.

Jamis asked for a show of hands for who had read his “Skinny Controller / Fat Model” article. I, ashamedly, have not, but I intend to. I’ve heard the “fat model” concept more and have been trying to emphasize putting as much as makes sense into the Model, and less into the controller.

They mentioned how you can override the #to_param method on an ActiveRecorded descendant in order to control what is used as the “id” string when building a URL in Rails. This would work perfectly with the pretty URLs I have been trying to use more and more.

Jamis stresses how we should all strive to make our code “intention revealing”. One of the beauties of Ruby is the flexibility and expressiveness it allows you. Wherever possible, we should structure our code to be readable and even self-documenting. And where our code does not clearly reveal our intentions, we should document liberally with comments.

#with_options seems to be a pretty slick little method that I have to try. It’s a method on Object that allows you to prevent repeating the same options on a series of method calls.

Many people forget to actually use the ActiveRecord associations they setup. For instance, instead of People.find(:all, :conditions => [“company_id = ?”, 99]) one can do something like @company.people which can make your code much more readable and DRYer, too.

And finally, they showed a code example that used the #returning method wrapped around several lines of code in a method that was to return something. Even after an explanation, I didn’t quite get how this worked. So that’s something to investigate.

Javascript Fu

Colin A. Bartlett — Mon, 21 May 2007 10:56:00 -0400

Londoner Dan Webb, creator of the UJS4Rails.com website with plugins for Unobtrusive Javascript, presented about some tips and tricks for dealing with Javascript in Rails. He revealed that he’s not maintaining the Unobtrusive Javascript plugin but instead has been focusing his free cycles on an extension to Prototype called LowPro.

I actually had a bit of a hard time following much of the technical nitty gritty of this talk. Mostly because my Javascript skillz are lacking. But also because it was packed as hell and pretty uncomfortable to sit still.

Dan did stress that we should all do a better job of making sure our Rails apps at least still function when Javascript is not available. He presented an example of an acquaintance who was unable to use any site using the standard AJAX frameworks because they all used the eval function of Javascript which the corporate security nazis frown upon.

His recommendation was to think about how your app can work, albeit with reduced functionality, when Javascript is not available to the user. One should build their app without any AJAXishy features at first, and then layer on the Javascript, AJAX, and “interface sheen” as he called it. I agree, although I think a decision about how much functionality to provide fo non-javascript-enabled browsers needs to be carefully considered in the context of the project at hand.

Dealing with Designers

Colin A. Bartlett — Mon, 21 May 2007 10:54:00 -0400

Well known blogger Amy Hoy presented about interaction between designers and developers. She claims to be both a designer and a developer and chatted about the processes that she and others use to successfully integrate the work of coders and artists. My take-away points:

Teaching your designer about Rails, even just a little bit, can go a long way to a successful working relationship. Get them comfortable with what they will expect to see in View templates when reviewing erb (or haml, etc.) templates created by the Rails developers.
Have the designer use subversion (or CVS, in our case…. for now). If the designer is using OS X (as most are), it won’t take more than a half hour lesson to educate them as to the virtues of source code control and the how-to of checking out, checking in, updating, etc.
Design cannot be an afterthought. Get the designer involved early in the process so that their perspective can be incorporated into the decision making process as much as possible.
Use wireframes to mock up the pages of your site. The wireframes can start as simple as napkin sketches, but should ultimately be fleshed out in some kind of box/text format. This is far quicker then any kind of direct-to-Photoshop process.
There are several “hand off” points that can be utilized to switch the process from designer to developer. This was sort of a no-brainer. Obviously, some designers can handle HTML, others can’t, and the process of cutting Photoshop files down to HTML and CSS can either be handled by the developers or designers. I would love to find a really good designer that embraces XHTML/CSS as much as I’d like them to. But until that point, I think we’ll stick to doing the HTMLification ourselves.