• rails stats – rake tasks to give summary tasks for rails application.  code to test ratio  – use for regular human review
• reek – wiki.github.com/kevinrutherford/reek  – looks for code smells – use for regular human review
• flog -  ruby.sadi.st/flog.html  – complexity checking of ruby code  using ABC Assignments, Branches, Conditionals
• flay-   ruby.sadi.st/flay.html  – structural similiarity.  fine grained duplication checking…
• roodi-  roodi.rubyforge.org – like checkstyle in java and joodi   ‘ruby object oriented design inforomiter’ – looks for deign problems.

A bunch of this is based on parsetree by Ryan davis that only works in 1.8, you need to use the RubyParser implementation for this to work in Ruby 1.9..

I’ve tried to run these against Rails 1.2.6 and 2.3.2 codebases, and it looks like flay needs rubygems 1.3.1 or greater.  Stats, reek, roodi and flog worked just fine for me.  Trying to run the whole of metric_fu hangs for me on churn right now in OSX, I may try to figure out how to remove churn, or hunt around for root cause, top of the stack is below

/opt/local/lib/ruby/gems/1.8/gems/jscruggs-metric_fu-1.0.1/lib/generators/churn.rb:68:in “’
/opt/local/lib/ruby/gems/1.8/gems/jscruggs-metric_fu-1.0.1/lib/generators/churn.rb:68:in `get_logs’
/opt/local/lib/ruby/gems/1.8/gems/jscruggs-metric_fu-1.0.1/lib/generators/churn.rb:37:in `parse_log_for_changes’

To install and run each of the tools by hand you can do the following or just sudo gem install metric_fu which does them all!

• stats   – sudo gem install stats — rake stats
• reek    – sudo gem install reek  — find app -name “*.rb” | xargs reek
• flog    – sudo gem install flog  — flog app  (or whatever directories you want to flog)
• flay    – sudo gem install flog  — flay app  (or whatever directory you want to flay)
• roodi   – sudo gem install roodi — roodi “app/**/*.rb”

This was a fast moving talk, they paired up to turn a few TDD loops with some javascript code using the ‘ping-pong’ methodology (one person writes a test, the other writes the bare minimum of code to make it pass).  We currently use developer and QA eyeball testing to ensure javascript works, which is pretty fragile.  As we dive more into TDD this stack could definitely be helpful.

This plugin uses the screw unit framework and allows you to run javascript tests in the command line.  there is a blueridge textmate bundle which lets you kick off test runs from within textmate.

One of coolest things is the ability to produce an .html file out of a particular test suite run that contains the code to run the tests.  You then are able to launch this html page in a multitude of browsers to make sure your javascript still works.  End to end cross browser testing js is definitely needed and personally would’ve saved us lots and time and money with random IE 6.0.x version bugs.

Lastly they’ve made a runcodedun continuous integration plugin that can work in cruise control, a cherry on top here.

slides for this talk are here (github.com/karnowski/blue-ridge-tmbundle) and some notes by another railsconfer (I think dirty_frank) are here (http://pastie.org/469178)

1. MODELING:

This session began by highlighting that UI is a layer of Software. It’s not an independent property. From a customers point of view, the UI is the entire application. So start with UI first, not the implementation.

The example used throughout the session was a course booking form which included multiple participants, a calendar feature, who goes to the course and on which day. For a simple form, the design is about how it works and not necessarily how flashy or color heavy it is. This concept in my opinion can be translated site wide.

Ryan along with a designer engaged in an open conversation to define key parts of UI that aren’t shown.

Compared to the old form which consisted of about 20-30% text, the new redesign was 70% text. Ryan stressed that terseness is not valued in UI.

By starting with a model that is defined by conversations between developing parties, this allowed for an implementation that makes sense to customers and begins to reflect partials. The result was a distilled and logically consistent design; it makes sense to customer which is reflected in code as well.

One book Ryan recommended was Domain Driven Design, by Eric Evans which covers bringing a more universal language between customer, designer and developer.

2. SCREENS:

REST conventions can apply to UI design when dividing screens and screen content. Customers understand general group categories such as “show all”, “edit” or “submit”. By focusing from inside out, you begin with what matters to the person that is actually using this screen. Err on side of too much on one screen.

Another book Ryan recommended was The Visual Display of Quantitative Information, by the great Edward Tufte.

Edward Tufte takes a very scientific approach to design and promotes the least effective difference for maximum effectiveness

Below are my iterations of some of the examples Ryan provided:

Emphasizing and de-emphasizing elements on page allows for less scanning. Minimal!!!

ex. Table of data – What is the least we could for the information to make sense and visually appealing? Simplicity can make scanning cognitively easier for customers to choose from available options.

Nothing is equal. Define the most and least important elements. Using the least effective differences creates a calming effect allowing the viewer to easily to jump from section to section.

ex. Once again, least effective solution can make for a more visually appealing application.

ex. Contrast is an eye attractor.

ACTIONS:

The main concept Ryan wanted to stress under actions is every action has a beginning, middle and end. Set clear expectations between different steps.

TEMPLATES:

Ryan recommended not using any HTML in your helpers. If you do include html in your helpers, don’t prematurely extract and only extract when you are completely sure(ex. error confirmation txt). Use helpers to reveal intention.

CSS and JS can also follow the same REST-inspired convention. Keeping templates and elements clear and concise.

RECAP:

• Base everything on a model
• Be explicit and use a lot of language
• Break screens out with REST conventions
• Designing screens from inside out
• Use least effective difference to control priority on the screen
• Think of action in three parts
• Keep templates clear

Overall I felt this was a great session to help programmers create more effective and visually pleasing applications that work. Thanks Ryan!

Ryan’s email address is Ryan Singer @ rjs.tumblr.com

What is Sinatra?
Sinatra is built on Rack and simplifies the structure and process of developing web applications. Requests are handled blocks identified by request slug and HTTP verb, fitting nicely into the RESTful model. Each block simply returns a string, which is rendered to the browser. Sinatra allows for hierarchical templates and views, but in general breaks with the MVC paradigm used by Rails and a multitude of other web frameworks.

Is it good for non-trivial applications?
Despite its simplicity, Sinatra proves to be quite extensible, both through the web server stack and at the application level. This is largely thanks to Ruby and Rack. Modifying requests before they reach a Sinatra app, or after a response is returned, is as simple as adding pieces of Rack middleware. Within a Sinatra app, the pattern of adding useful code modules namespaced in a lib directory facilitates extensibility and modularity in without bogging down the framework’s simplicity. Furthermore, this simplicity and less-is-more approach allows for any ORM or Javascript library to be used at will.

When might you use Sinatra?
How many times have you (and I) created a new rails app just to try or demonstrate really simple behavior? It’s a perfect tool for quickly stubbing out projects, letting one naturally build features as needed. Think about how this affects the cognitive process of development – how often do we tarnish ideas by tying them to an opinionated framework? But is Sinatra just a toy – is it production ready? Some have already done this, with good results. Sinatra’s simplicity also means speed – there’s very little you don’t need. Rails was once not thought to be appropriate for important applications. In many ways Sinatra takes Rails’ strengths and pushes them further.

Rails hasn’t changed all that much

DHH has been working with Rails for 5 years now. He’s realized that we’re largely doing the same things now that we were doing 5 years ago – the fundamental principles are basically the same.

• He thinks we should all stop fretting about whether we’re up-to-date with the latest and the greatest. He was looking at some old Rails code a few days ago and found that it’s not that stale.
• Realize that you can still enjoy Rails without knowing every new thing
• You don’t need to rewrite your app every time something new comes out

Supposed Rails-killers

Over the years, there have been several things that were supposedly Rails killers

• Not enterprise-ready
• Opposite criticism – Rails is incredibly relevant – just need to find the components (e.g. scaffolding) that work and clone them (Sails, PHP on Rails, Grails, Monorails)
• High-profile “switch backs”:

1. Derek Sivers (of CD Baby) blog post on why he switched back to PHP from Rails.
2. The “fail whale” (image you see when Twitter goes down)

• Internal struggles – Array first, second, third..forty-two methods debate. Debate wasn’t about that – it was a philosophical debate. Merb brought this to light too.

But Rails is still here and still going strong. Rate of improvement is accelerating but still convening around the same core principles. That doesn’t mean we should learn from these challenges but we need to chill out. Most of these debates aren’t that important – what does matter will come through.

The Fundamentals Principles of Rails

We need to recognize the fundamental philosophies that make us the Rails community and that will persist in Rails 3:

• “We’re going to lock up all the unicorns” – Rails 3 is not a complete re-write, will not solve everyone’s problems. Need to recognize that we can’t get all of those unicorns out of their cages. Don’t get sucked into the world of all the magical possibilities.
• “We’re not going to have holy cows” – Also recognize that nothing is sacred in Rails – everything is up for debate. Your arguments will need to be very persuasive to get us to make big changes, but nothing is set in stone.
• “Have it your way” – Just because we all have minor individual differences, it doesn’t mean we can’t all come together. Most of the time for most of the people, they want to just write web applications. We can allow people to make their individual choices and still be together in one community.

Progress of Rails 3

Goal had been an alpha release at Rails 3. That’s not happening, but there is a lot of code in the repository already. Here are some of the new features:

• New Router – It’s faster. It can route by subdomains, user agents, and other stuff. Working Rack into the routes so that you can mount multiple applications at the same time. Rails’ routing API hasn’t changed in a long time. It was designed in a pre-REST time period for Rails. Router has been re-designed with that in mind (wycats and dkubb both just commented on the #railsconf IRC channel that the new router looks very similar to Merb’s router).
• XSS (Cross-site scripting) protection – This is a type of code injection security attack. Rails 3 is changed to escape everything by default – you have to mark output as ‘raw’ to not escape it. This is something Rails avoided for a while because it seemed cumbersome but then the Django guys did it and it seemed to work well, so Rails is copying that.
• JavaScript goes unobtrusive and agnostic – The notion of unobtrusive javascript bubbled up a couple years ago – idea that javascript should be separated out from HTML. DHH thought this was a good idea in theory but a terrible idea in practice at first because it seemed like a hassle. In Rails 3 they’re adopting the HTML 5 standard of custom attributes. (I kind of missed the rest of what he was saying here)
• More agnosticism – Action ORM – slim proxy wrapper around other ORMs. He also said something about generators I didn’t quite catch.
• The great refactoring – Most of the work is in places that people won’t notice it. A lot of folks have been working on cleaning up the internals:

1. Abstract Controler + Action Dispatch
2. Active Relation underpins Active Record using relational algebra
3. Cherry picking from Active Support
4. Speedy callbacks

The real secret to high productivity

In the early days DHH was able to get a lot done, working on Basecamp alone even though he only had 10 hours a week to spend on it. He doesn’t feel like he’s been as productive since then.

What was the key?

Developers need to renegotiate requirements – most developers treat requirements as holy commandments. Maybe we shouldn’t accept these stone tablets, maybe what the stakeholders are telling us to do isn’t really what you should do. It’s okay to say “let’s do something else instead.” As programmers, we so often want to be loved and thus are unwilling to challenge authority. Everything turned out just right with Basecamp because it needed to be – nobody had enough time to spend on it so it wasn’t engineered to be overly complex. They “cut corners” by simplifying, but ended up with a much better system as a result of less ambitious requirements. Not as flexible, but very fast, very simple, and good enough. The term “programmer” implies some kind of machine that outputs code, “partner” is a better term.

Great session broken into two parts, first section was some intro stuff on OO Design and principals, and some more depth on some topics like Cohesion, SOLID http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx and software connascence.  Jim indicated a cancellation later in the week opened up the spot for him to give a whole talk on degrees of connascence, should be a good one.  Then overviewed some topics from Fowler’s Refactoring book, bad smells, speculative generality, ect.

The second half of the session was spent going through an application Jim and Joe had prepared that was a dice rolling application, with a number of refactorable items.  They handed out the code, complete with suites of fully passing  shoulda and cucumber tests, and after the break told the group to go nuts and refactor it up, using earlier smells if possible.

So of course my unit tests wouldn’t run, neither did anyones around me, luckilly someone discovered you had to install RSpec as a plugin and not as a gem, to make the suite actually run, luckilly I hung out during the break and had the entire 2nd half to mess around with the application.

So Joe wandered around during the session and Jim was helping folks as well, but the real interesting and great part of the session was that you had random people pair programming, there were people asking questions out loud where I was sitting, and people answering with solutions or ideas on how to refactor.

At one point Jim indicated he wanted to de-factor the code, ie make it refactorable, but they really didnt have to.  This was an interesting admission, that if you do Red-Green and skip refactor, you can end up with some smelly code.

I’ve used Test::Unit and RSpec so the Shoulda piece was tractable, but man trying to figure out legal syntax for cucumber without ever having used the DSL was a bit tough.

Highs:

• Jim’s a great speaker, and had great ideas on good OO Design, always fun to watch.  Joe did a nice job as well, and the interplay between the 2 hosts cutting each other off was kinda funny.
• Jim and Joe obviously had put a ton of time into this session.  They built an entire dice rolling application, built up 100+ tests, packaged all the gems needed, ect.  This made the session work, people in the room could discuss a common codebase, a great move.  In other breakouts where you are told ‘well now work on your own code’ you don’t get this community effect of people helping others on a common codebase.

Lows:

• Power problems again, the daisy chaining 89 power strips together’s fatal flaw was revealed when twice the entire right side of the room was killed because someone stepped on the powerstip button, grrrrr.
• Standard configuration problems getting a full working environment.  The nikogiri gem which was native was frozen in.
• It would have been helpful to get a quick 10 minute primer on the syntax of Cucumber and Shoulda.  They really weren’t listed as tools prior to the session, so I spent a bunch of time messing around with them in the blind during the 2nd half of the session.

I’ve never used Chef before (http://wiki.opscode.com/display/chef/Home), but had done some light reading about it.  We’re currently using Capistrano to push code and configurations, and some homegrown ruby scripts integrated with svn to create nightly release candidates (2009-05-rc-1.. ect), push those to staging, and when we’re ready make the ‘release’ branch.

The one piece that I dont control is the kickstart of machines, I need to rely on the ops team for that, and it seems that I could install Apache through Capistrano (haven’t tried it), but Chef’s approach to configuration files seems pretty cool.  You basically make an erb template for various sections of the httpd.conf file (theres a huge library of ‘cookbooks’ http://github.com/opscode/cookbooks to do apache installs, memcached installs, ect.. that you basically override with your own site-cookbook to tweak).  So if you for example want to add a vhost to your 10 different apache machines, you change the template generating the vhost section, add another named host, and have chef repush the apache configs, and it will generate an additional VirtualHosts area with the new information, pretty cool.

Theres a client/server mode as well as chef-solo, and you an run the client as a deamon to check in with the server every hour for changes.  This deamon seems cool but I have to admit it scares the heck out of me, polling and changing production hourly, perhaps its an uncomfort I would learn to live with, but having my servers asking for changes in production and then auto-applying them, seems scary.  I’ll probably start with solo, where you have push-button deploys.

The Web GUI is good for high level overview of components, I fired up webistrano at one point but there were some built in assumptions about how you managed your servers that just didnt work for us, cant remember what they were…  One odd thing about the UI is the fact that to edit parameters you click on the client in question and get a window with a ton of JSON, it works but you really have to know what you’re looking for in there ahead of time, decent learning curve.

Although Edd did not align Chef as competition to Capistrano, he did spend a bunch of time on chef_deploy, which on the surface does a number of the same things as Capistrano.

The Highs:

• Chef seems to have handled the OS qurikiness, ie install apache here on OSX, install there on Debian, install there on Redhat, through the cookbooks and a nice abstraction layer using ohai to poll the OS for info.
• chef-solo and chef_deploy and chef, lots of good options there about how to manage your environment, looks like you can kickstart, deploy an app, config it and startup in one script, pretty cool.
• Cool addons like :
• Knife that supplies a RESTful API to manage remotely ( flashed this url http://gist.github.com/104080) ,
• poolparty (poolpartyrb.com) to help manage in the Cloud
• search feature using ferret that lets you query stuff like ‘hey what IP addresses are running Apache?’
• tons of default cookbooks, if you have a vanilla install or are starting fresh, you may not have much code to write at all.

The Lows:

• No power strips in the room at all!!  WTF, I actually took notes using a pen and paper when my battery flatlined, how analog.
• Edd was kinda tough to understand at times, and was unfortunately plagued with the demo deamons and couldn’t get his VM clients to recognize the network intially so the very simple demo didnt work until the second half burning some time up front.
• As stated above, have a perfectly working Capistrano setup.  We’ll have to see how the community handles Jamis’ departure from Capistrano, I’m sure I’m not the only one facing this.

The CourseAdvisor Site-Dev team is here and we’re trying to fan out as much as possible and post about the sessions attended so we can look back in 6 months and remember what cool tool to get Chef working in the cloud was (poolparty), and so folks that couldn’t make it have session highlights.  Oh and to justify to the bosses that we werent hitting the blackjack tables too hard (to that person who hit on 14 with the dealer showing a 5 and got upset when they got the dealer’s Queen), I am going to find you, and it’s not going to be pretty.

def cookie_set
  cookies['foo'] = 'bar'
  return cookies['foo'] == 'bar'
end

The gem can be found at CourseAdvisor’s RubyForge page.

Today CourseAdvisor has released a simple plugin that adds aspect-oriented programming capabilities to Rails. This plugin enables programmers to:

• define custom events of interest in arbitrary locations
• automatically log these events, if desired
• define behavior relating to cross-concerns in a single place
• untangle program control code to free it of unrelated code belonging to event points of interest
• use the built-in observer mechanism to keep the implementation clean and simple

More information to follow soon, with sample code…