OnRails.org

Day Two got off to a good start. Engine Yard did a promotional pitch—the speakers could have been a bit more polished, but it was interesting stuff about their one-button-deployment, and overall not bad for an advertisement.

Next up was Chris Wanstrath. He started with a lead in regarding how to become a famous Rails developer—focusing on yourself, your blog readership numbers, your twitter follower count, etc. Later, he talked about how he went from being an unemployed college dropout to co-founder of the very successful GitHub, due to sharing code. His point was that in his eyes, it’s better to focus more on the community: share code, contribute to open source projects, even write documentation for existing projects. Being a good developer trumps being a famous developer. The complete text of the talk is online here .

For the first session of the day, it was a tough call between Rack/Sinatra and Metric Fu. I finally went with:

Using metric_fu to Make Your Rails Code Better – Jake Scruggs

The central theme of this talk was how to use automated code analysis to direct you on where to spend your refactoring cycles. He used Carlin’s law (Anyone going slower than me is stupid; anyone going faster than me is crazy), but applied to programming. As your programming skills change over time, you see the same code differently.

He touched on coverage as a baseline that you should be doing as a part of your code analysis, then went on to complexity analysis, reviewing two tools available to analyze the “complexity” of your code: Flog and Saikuro. Flog examines your code (flog -g app for a Rails app) and gives you a (somewhat arbitrary) numeric range measuring the relative complexity of your code. Basically, 0-10 is awesome (and practically unatainable), 11-20 is okay for real world methods, and it goes downhill from there. If you have 200+ complexity scores, refactor immediately! Flog is somewhat opinionated about what is good/bad or more/less complex, but generally does a good job in helping you avoid the “icebergs”.

Saikuro gives a more concrete result—the “score” is the number of branches through a method, including tertiary operators, foo if/unless bar, etc. This is a plus over Flog, and usually indicates about how many tests you should have (one per branch). The downside to Saikuro is that it does not pick up on dynamically defined methods, where Flog does.

Next, we walked through a refactoring example, where Jake showed using high Flog scores as a hit list of where to refactor next. He also mentioned that better readability trumps lower complexity scores, one thing to keep in mind—as being generated by automated tools, the scores should be taken as a guide, not a law. A good point was brought up during Q&A: there is currently no way to “flag” a high-scoring method as acceptable, so if you have a justifiably complex method that you choose to live with (e.g. for readability), then you’ll have to live with the flogging you will receive. I’m sure patches would be welcome if someone wanted to fix this!

On to code smell and Reek and Roodi, tools to identify smells (overly large methods, etc.) Reek tends to warn over smaller issues than Roodi, and can indicate false positives. Roodi generally tends to have fewer complaints—if it warns about something, it should probably be fixed!

Next up was Flay, which detects non-DRY-ness in code, anything from strict copy-n-paste to functionally identical blocks with different variable names to do..end blocks matching curly-brace blocks.

Also covered was a way to track source control churn. At this point, you’re probably thinking “How can I keep up with all this?” Luckily, there’s metric_fu, a way to wrap all this up into one package and get all this code analysis goodness in your project. Install the gem, then run rake metrics:all. For more info, installation instructions, etc., see: http://metric-fu.rubyforge.org/ Looking forward to adding this bag of tricks to our CI toolset.

Rails 3: Step off of the Golden Path – Matt Aimonetti

Matt started off with a history of programming languages and how Ruby came to be, including some of Matz’ core philosophies embodied in the language. Moving along to Rails, he talked about the growth of Rails and the desire for increased performance and options that led to the split between Rails and Merb. This led us in to the discussion of the current and future state of affairs for Rails 3.

• improved performance
• increased modularity
• agnosticism
• public api
• mountable apps

Matt emphasized that there will be no drastic changes, and by default, rails app will generate a very similar application to what you would get today under 2.x. However, there will no longer be the idea of “the one true Rails way” of building an app—the framework will be less opinionated. However, you should go through a process of justification to see if you really need something different than the default stack.

• JavaScript frameworks, including jQuery, YUI, ExtJS, MooTools, Prototype, or the ability to write your own, and plug it in.
• Different templating engines: HAML, ERb (this is already doable in Rails)
• Different ORMs: ActiveRecord, DataMapper, SEQUEL, Hibernate, non-RDBMS stores like CouchDB, Tokyo Cabinet, etc.

• DataMapper re-uses existing Ruby object for both sides of a has_many / belongs_to relationship. In other words, if I load parent and child records from the database, and look at parent.object_id as compared to child.parent.object_id, under DataMapper, these will point to the same object automatically, while with ActiveRecord, these will be separate objects. (Note that inverse_of was recently checked into rails, which enables this in ActiveRecord as well )
• DataMapper does automatic lazy loading as well as strategic eager loading, so in this scenario:

@parent = Parent.find(12345)
@parent.children.each do |child|
  puts child.name
end

• The ability to have multiple repositories (which looks like it means databases), and a copy method on models to clone data from one database to another—one use case would be an automatic archive or backup process that copies data generated within the last week to a backup database.
• Query Path, allowing more flexibility in SQL condition generation (WHERE name LIKE ‘foo‘)
• one potential gotcha that was mentioned: DataMapper does not support STI and Polymorphic associations as well as ActiveRecord does

• file structure
• router DSL
• request handling But he voiced the opinion that the vast majority of Rails apps will not need anything like this—make sure your need justifies coloring outside the lines.

All in all a good presentation, maybe a bit much focus on DataMapper specifically. However, I personally enjoyed the DataMapper bits, and might have to try it out on a project, if it’s a fit.

Art of the Ruby Proxy for Scale, Performance, and Monitoring – Ilya Grigorik

I skipped out on the afternoon sessions, so my next talk was Ilya’s—never disappointing. Ilya spoke about EM-Proxy, his event machine based proxy. He gave good example code of how EM proxy could be used to implement transparent and intercepting proxies.

It started with an itch at PostRank, Ilya’s blog aggregation solution. An effective staging environment should closely resemble the production environment—the problem was that their production environment spanned nearly 80 (virtual) servers on EC2’s cloud. Spinning up that many servers just as a staging environment was an expensive proposition. Also, simulating production traffic then becomes a challenge, as you end up trying to store production logs and “replay” them into the staging environment. The way that they chose to solve the problem was to separate a group of the servers into a staging app server pool, set up a proxy that would transparently (to the end user) intercept incoming requests, send them to both the production and staging pools simultaneously, then return only the production response to the user, using the staging response internally for benchmarking, testing output, etc. With this strategy, the more static parts of the system (web servers, load balancers, etc.) can be shared across environments, and the staging environment is testing the part that actually changes (the application servers).

The first example code was a transparent proxy that simply forwarded a request from one port to another. Ilya built on this to show how you could dynamically alter request/response data on the fly. Finally, he built up to the original scenario: duplexing a single request across two (or multiple) backend servers, but returning only a specific response. As he mentioned in the talk, one strategy for servicing a specific request as fast as possible might be to send the request to all machines in your pool, then respond with whichever request completed first.

These examples were centered around HTTP requests, but he went on to show some other examples of how this is not protocol-specific: you are just dealing with data over a socket connection, so as long as you understand the underlying protocol, EM-Proxy could be useful. His examples showed SMTP proxies for accepting/rejecting incoming mail by email address and implementing a spam filter by forwarding the incoming mail to Defensio before passing it along to your real SMTP server. The final example was pretty clever: an implementation of EM-Proxy to reduce the memory overhead of beanstalkd by selectively delaying queue inserts based on the scheduled execution time—basically buffering far future jobs into the database instead of immediately inserting into the work queue.

Slides are available here: http://bit.ly/ruby-proxy

Another packed day at RailsConf 09, one more to go!

I’ve just finished my first day of RailsConf 09. Things have gotten started well—I’ve met several interesting people, found some interesting people to follow on twitter. I’ll try to post as much as I can in the way of reviews for those of you attending by blog.

Starting with the DHH Keynote. David’s talk was entitled “Rails 3 and the Real Secret to High Productivity”.

• It was deemed as not enterprise-ready, just a lot of hucksters trying to generate interest in Ruby to sell their own books, etc.
• it encountered an “attack of the clones” in which several other languages/frameworks tried to duplicate (what they felt was) the one “key” feature that was the root cause of Rails’ explosion in success and popularity
• some early adopters switched back (Derek Sivers, CD Baby)
• some early adopters encountered serious problems (Twitter), which may or may not have been Rails-specific issues, but were perceived as such
• some people complained about “feature bloat” (Array#fourteenth, etc.)

The takeaway from this review: There is no one best tool for every job—it’s okay if not everyone chooses Rails. Rails can’t be distilled down to a single feature, it must be viewed as a sum of its components. Emotions or reactions can be quite strong, but are usually not all that important/long-lasting.

• Lock up all the unicorns: This is not a complete rewrite. Many people might look at Rails 3 and be disappointed, expecting more radical changes.
• No “Sacred Cows” allowed: Everything is on the table for possible change in Rails 3. That being said, it’s important to note that any changes causing backward compatibility issues will need a very good justification to be accepted/implemented.
• “Have it your way”: The default application generated under Rails 3 will rock, but you can ask for things to be done a different way and override the defaults. This seems like a natural extension of the templates now available in Rails 2.

He also covered some of the progress made to date in Rails 3. It sounds like things are not going as fast as was hoped, but there is code available now in GitHub—just no officially tagged release.

• a new router, with the ability to route requests by subdomains, user-agent strings, etc. also able to route to other rack machinery
• XSS protection, in which any text output will be html-escaped by default, requiring you to explicitly request raw output if/when you need it.
• JS will be unobtrusive and framework-agnostic. This is one of the more exciting plans for me. tags will be generated with the HTML 5 validating data-* attributes, which can be used as unobtrusive javascript hooks:

  <a href="/person/1" data-remote="true" data-method="delete">Delete This Person</a>

  $(document.body).observe("click", function(event) { 
    var element = event.findElement("a['data-remote']"); 
    if (element) { 
      var method = element.readAttribute("data-method") || "get"; 
      new Ajax.Request(element.readAttribute("href"), { method: method }); 
      event.stop(); 
    } 
  });

Then, near the end, he got to the “secret to high productivity” part. In a nutshell—don’t view the requirements as carved in stone. If you are able to make (slight) changes to the requirements as originally communicated by the business, it may serve their purposes just as well as the original requirements but be drastically easier to implement. As cool as Rails is, no framework is going to match the performance boost this can bring.

Don’t Mock Yourself Out – David Chelimsky

I went to David Chelimsky’s talk on Mocks, but it was a bit too introductory-level. He basically explained good reasons to use mocks—from the title, I was expecting ways to determine if your mocks are becoming too heavy-handed, preventing you from actually testing any of your implementation!

Here are the highlights:

David Started with a review of the difference between mocks and stubs—basically, mock objects care about which methods are or aren’t called during the test, stubs are “dumb” containers to give canned responses to methods. See Martin Fowler’s explanation for more information.

Here are examples of when stubs might be useful:

• isolation from non-determinism: when dealing with any randomly generated values, your tests face brittleness from non-determinism. Similar for timestamps, date ranges, etc.
• isolation from external dependencies: Anything that connects to an external resource (e.g. network/db) can benefit from (smart) mocking. You should still test the “real” operation, but for adding permutations/edge case tests, mocks can speed up your test suite by multiple orders of magnitude.
• polymorphic collaborators : (strategies / mixins/plugins) calling a method on the “main” object ends up delegating to a method somewhere else

Here are examples of when mocks might be useful:

• testing side effects (e.g. something gets logged)
• testing caching / memoization—ensure an expensive method gets called exactly once.
• interface discovery : “outside-in” development : build a mock of something before it exists, use to discover the “ideal” interface, how you will be using this in the real world.

At this point, we started getting to Rails-specific content. David pointed out that if you are doing traditional Unit/Functional/Integration tests, it’s not DRY-some parts of your app (e.g. model validations) are being tested multiple times across your test suite. He recommends to split tests instead into business-facing / developer-facing specs, even using different frameworks where appropriate-for example, RSpec stories are more suited for business-facing specs, since they are close to the natural language of the domain experts. For lower-level, developer-facing tests (e.g. database-level), it probably doesn’t make sense to invest time writing stories—the developer is the domain expert.

A couple of helpful tips—if you care about which template gets rendered, but not necessarily the content (which could change!), you can stub the call to render, and set an expectation that it receives the correct partial name when called. When doing Rails functional testing, you need to set up valid/invalid data to make sure both sides of create/update actions are executed. Instead, you could stub the new/save/etc methods on the object to force the branch you want to test.

Upcoming “stubble” project helps with this.

UI Fundamentals For Programmers – Ryan Singer

Next, I saw Ryan Singer (37 Signals) talk about UI design concepts for developers. This was a high-level talk to help developers with the approach to take to UI/design, not a how-to, recipe style talk.

First of all, Ryan advocates taking a BDD, outside-in approach—including the UI. The UI is the closest thing to the user, so start there and work your way in, implementing backend functionality as you need.

Next, overcome your natural tendency (as a developer) to be terse—you should add ample text to guide your end user through the flow of your site/screens. Don’t rely on implicit meaning in forms/layouts as a guide, be explicit and explain what is expected of the user.

You should form a model (conceptual model, not ActiveRecord model) of the domain problem that makes sense to the customer and is implementable (feasable). Recommended reading: Domain-Driven Design by Eric Evans. (also Tufte for information display in general)

Designers tend to think in “Screens” as the atomic unit of work. This plays nicely into REST/Resource conventions, mapping e.g. displaying a particular object to the “show” action of your resource controller. For multiple related objects, break the screen into multiple areas that each represent a resource.

Be careful with contrast-make sure that you emphasize the most important elements on the page. Watch colors, sizes, etc. Don’t present a visual “buffet line”—aim more for a “gourmet meal”. Less is more.

Every action a user can take on your site has three distinct parts, a beginning, a middle, and an end. Think about where the user is when they need/want to take the action (where they are linked from). For the middle, collect the data for the action, then consider what the user will want/need to do next.

Some rules of thumb: helpers should not generate blocks of HTML (although generating an HTML element is probably ok—think image_tag); Organize your CSS/JS around REST conventions for your application; Treat ERb partials that generate HTML just as you would an image tag; Use helpers to reveal intention.

Smacking Git Around – Scott Chacon

Scott’s talk (aka the Git Firehose) was just as awesome (and fast-paced) as last year. Much too quick to take good notes, but I was able to capture a couple of useful tips & tricks:

First, on the concept of reachability: every commit that is an ancestor of your current commit. Git uses this in the dot-dot syntax for git-log and subtracts the first from the second. So git log origin/master..master gives you everything in your local master not already pushed to the remote repo. Or, after a fetch, reversing it (git log master..origin/master) gives you all commits you just pulled down that haven’t been merged into local master. Handy! A couple of alternate syntaxes: git log branch_a --not branch_b, or git log branch_a ^branch_b. This is also extensible to more than two branches: git log origin/master master ^experiment would give you all commits on origin/master and/or master that are not in experiment.

Second, he illustrated a common problem with diffing between branches in Git. If you imagine a file existing in two branches, in which lines have been added on both branches, and you ask git for a diff, most often you want to know what has been added to the other branch that you don’t have. By default, though, the question git is answering is “how do I make this file look like the other file?”, which includes deleting the lines you have added on the current branch—probably not what you want. In this instance, you can use the triple-dot syntax: git diff master...topic (asking git “what would happen if I merged the two branches?”)

He talked about subtree merging as an alternative to submodules. Basically, the process is:

git remote add rails_remote git@github.com:myfork/rails
git fetch rails_remote

git checkout -b rails_branch rails_remote/master

git checkout master
git read-tree --prefix=vendor/rails -u rails_branch
git add vendor/rails
git commit

This keeps your ability to make changes to the remote project and submit them back upstream:

git checkout rails_branch

git merge -s subtree --no-commit --squash master

This obviates the need for braid/piston! See http://tinyurl.com/braidgit for more info.

Also mentioned was patch staging—simple, but incredibly useful! Say you’ve made multiple changes to the same file, and you want to commit some, but not all. With patch staging (git add -p), you can select the hunks you want to stage for commit — awesome!

More useful info, including how to give Git the ability to diff binary files (kinda, but it can work). Slides are posted at http://tinyurl.com/gitrailsconf09

Quality Code with Cucumber – Alsak Hellesøy

For the last session, I saw Alsak Hellesøy’s most excellent talk on Cucumber. I was totally drained at this point, and took no notes. He gave an example of how to get started with Cucumber, working through a sample scenario, doing outside-in development. So far, I haven’t used RSpec / BDD in anything serious, but I’m looking forward to trying this out—looks pretty interesting.

Ruby Heros / Evening Keynote

The day ended with the Ruby Hero awards, and then the DHH / Tim Ferriss (4 hour workweek) interview/keynote. I think there was probably good content to be had in the keynote about refactoring your lifestyle. Unfortunately, the sound was bad—very muffled/echoy from where I was sitting. Also, the pace was so much different from the firehose of information presented by the technical talks that it was like a panic stop in a formula one racer.

Overall, a good but exhausting day here in Vegas. If you’re here, look me up and say hi, or give me a follow (rubysolo on Twitter).

Slides of the presentations can be found here as they are released

Follow “official” news on Twitter.

DHH Keynote notes and slides. The video is here on blip.tv

Video on the tutorials day from the Railsenvy team.

More videos on blip.tv.

And lots of pictures.

Some good notes from day1.

Please tweet links to @danielwanja for any good blog articles that does live coverage. I’ll post the links here.

We have Solomon White that regularly blogs on http://onrails.org covering the conference…let’s see the note he takes ;-)

Ruby Heroes:

• Bryan Helmkamp http://www.brynary.com/
• Aman Gupta http://github.com/tmm1
• Luis Lavena http://blog.mmediasys.com/
• Pat Allan http://freelancing-gods.com/
• Dan Kubb http://github.com/dkubb/
• John Nunemaker http://railstips.org/

I was trying to figure out how to use the new AvtiveRecord accepts_nested_attributes_for functionality that enables saving nested active records. In fact I will try to use that functionality from a Flex application using the RestfulX framework.

The cool thing about trying to understand Rails or ActiveRecord is that there are many tests available part of the source code which describe really well the framework. The functionality is provided by the NestedAttributes module defined in /activerecord-2.3.2/lib/active_record/nested_attributes.rb.

I just generated a basic specs from the associated test case which I included here after and this give a good idea of what the accepts_nested_attributes_for method supports:

• Base should have an empty reject new nested attributes procs
• Should add a proc to reject new nested attributes procs
• Should raise an argumenterror for non existing associations
• Should disable allow destroy by default
• A model should respond to underscore delete and return if it is marked for destruction

• Should define an attribute writer method for the association
• Should build a new record if there is no
• Should not build a new record if there is no id and delete is truthy
• Should not build a new record if a reject if proc returns false
• Should replace an existing record if there is no
• Should not replace an existing record if there is no id and delete is truthy
• Should modify an existing record if there is a matching
• Should take a hash with string keys and update the associated model
• Should modify an existing record if there is a matching composite
• Should delete an existing record if there is a matching id and delete is truthy
• Should not delete an existing record if delete is not truthy
• Should not delete an existing record if allow destroy is false
• Should also work with a hashwithindifferentaccess
• Should work with update attributes as well
• Should not destroy the associated model until the parent is saved
• Should automatically enable autosave on the association

• Should define an attribute writer method for the association
• Should build a new record if there is no
• Should not build a new record if there is no id and delete is truthy
• Should not build a new record if a reject if proc returns false
• Should replace an existing record if there is no
• Should not replace an existing record if there is no id and delete is truthy
• Should modify an existing record if there is a matching
• Should take a hash with string keys and update the associated model
• Should modify an existing record if there is a matching composite
• Should delete an existing record if there is a matching id and delete is truthy
• Should not delete an existing record if delete is not truthy
• Should not delete an existing record if allow destroy is false
• Should work with update attributes as well
• Should not destroy the associated model until the parent is saved
• Should automatically enable autosave on the association

• Should define an attribute writer method for the association
• Should take a hash with string keys and assign the attributes to the associated models
• Should take an array and assign the attributes to the associated models
• Should also work with a hashwithindifferentaccess
• Should take a hash and assign the attributes to the associated models
• Should take a hash with composite id keys and assign the attributes to the associated models
• Should automatically build new associated models for each entry in a hash where the id is missing
• Should not assign delete key to a record
• Should ignore new associated records with truthy delete attribute
• Should ignore new associated records if a reject if proc returns false
• Should sort the hash by the keys before building new associated models
• Should raise an argument error if something else than a hash is passed
• Should work with update attributes as well
• Should update existing records and add new ones that have no id
• Should be possible to destroy a record
• Should not destroy the associated model with a non truthy argument
• Should not destroy the associated model until the parent is saved
• Should automatically enable autosave on the association

The Confreaks guys did setup their cameras, sound and lights, so you will certainly be able to see all the talks in a few weeks.

The conference takes place in Salt Lake City, the scenery is impressive as the city is surrounded by high mountains…even for someone living in Denver. The picture above was taken just before the conference starts and shows the atrium we gonna spend the next two days in. The talks looks really cool and tonight the Engine Yard’s Hackfest 2.0 in suite next to mine at the Hilton Salt Lake City Center.