Rails Conf Day 2, 3, 4 (Portland, OR)

Day 2, 3, 4 of Rails Conf notes . . .

Key Note(s)
The keynote started with a mac-like commercial parody from http://www.railsenvy.com

Some interesting stats on Ruby/Rails:

• RubyConf 2001 had 40 attendees.
  
• RubyConf 2007 had 1600 attendees.
• 600 Rails plugins
• 10,000 people on rubyonrails (list)
  

More and more ruby/rails books, in both english and other languages. Mkt. share of books on shelves has surpassed ruby/sql/python.

Tools support is growing: Netbeans, Codegear, Apt___, JetBrains IntelliJ Ruby Plugin

Rails 2.0 improvements were shared.

David Heinemeier Hansson (one of the Rails authors) showed a Job posting requiring 3 year of Rails experience (which DHH found ironic because he didn't have 3 years).

I missed the much acclaimed evening KeyNote from Ze Frank (of 'The Show') - doh!

Sat. Keynote
Thoughtworks involvment w/Ruby/Rails (Cyndi Mitchell)

• Lots of new projects in Rails
• company now offering 24x7 support for Rails/Ruby Dev.
• Rubyworks new division of Thoughtworks studios focused entirely on Rails.
  

Sun's involvemnt w/Ruby/Rails (Tim Bray - VP at Sun)

• Donating hardware
• JRuby and Netbeans
  

Full stack testing with Selenium and Rails
Ruby selenium in process, can test through browser, and verify database (open db connection in same process)

Clean Code (Robert Martin of Object Mentor)
Excellent presentation on TDD, incremental development and regularly running tests.
http://www.objectmentor.com/resources/articles/Clean_Code_Args.pdf

Fixtures Friend or Foe - Tom Preston-Werner (rubyisawesome.com) of Chronic fame

Tom introduced FixtureScenarios which appears to address many of the complaints against fixtures in Ruby, and provide a more clear way to show intent when declaring and using fixtures in tests.

Spam I have known - Jim Weirich (author of Rake)

Jim shared several interesting techniques they tried for reducing spam on the Ruby wiki. Things like using reverse dns, roles, a tarpit database, tuning the rejection notice, show spammer their spam, show the world no spam, show google no spam...

MemCaching Rails (Chris Wensworth -- http://errfree.com)

The Dark Art of Developing Plugins (James Adam -- http://lazyatom.com/plugins)

Ruby Tooling State of the Art (Netbeans)

• Hotkeys that use knowledge of conventions (cool!) i.e. - hot key that switches to the view for the action you are currently editing
• Runs with native Ruby or JRuby
  

Data Warehousing with ActiveWarehouse

Great presentation. Mile-a-minute information. I have lots of notes on this one which I 'm choosing not to retype here at the moment.
http://activewarehouse.rubyforge.net

JRuby on Rails (Charles Nutter - Sun)

• is close to Ruby 1.8
• is shipping with RSpec, Rake, Ruby

Things I took away....

1. One JRuby Thread = One System Thread (since java uses native threads)
   
2. Easy to call java api's from Ruby code.
3. Unicode support in Java is better.
   
4. Yes, you can use JDBC drivers. (though an adapter has to be written to handle quotes, lack of schema mgmt API [which ActiveRecord does have], and missing features in some DB's)
   
5. No native extensions (except those which are already working: mongrel, Hpricot, RMagick, DB Support)
6. Command-line performance (compared to Ruby in C). Java is generally faster, except on startup, so the CLI tools start a little slower.
7. Goldspike can generate a war to deploy on a java app server.
8. Glassfish is available as a Ruy gem.
   

Open Mic Session

1. Masterview template/plugin -- a way to keep the ruby code from invading the html
2. revolutiononrails.blogspot.com
3. configuration library - reloads any config file changes into class instances on the fly
4. cruisecontrolrb - instant cruisecontrol for Ruby/rails project
   
5. Group discussion tool based on OpenID (http://pibb.com)
6. devinecaroline - distributed page caching plugin
7. mywaves.com
8. The Mole plugin - live monitoring of user activity http://liquidrail.com. Presentator was hilarious.
9. Bountysource.com showed real time hits on a google map mashup

Testing and expressing intent seemed to be a common theme through a few talks. Some tools mentioned: RSpec, rcov, heckle.

Lots of jazz about Capistrano and Monit.

Local Ruby Conferences to look into: Rubyhoedown.com lonestarrubyconf.com

Lots of good buzz about peepcode screencasts.

DevX Article on Semantics in Applications

Rails Conf Day 1 (Portland, OR)

Rails Conf Day 1

Portland is a beautiful place to fly into. I've never seen so many trees. The plane flew right by Mt. Hood (a spectacular view).

Today I attended the Rails Guidebook Tutorial session. The hosts (Dave Thomas and Mike Clark) donated their time in exchange for the attendees making a donation to charity. Thus far they have raised around $12,000 for charity. The url to donate (which they'll keep open until the end of the conference) is here

The guidebook session was divided into 2 parts. The first half of the day covered Ruby. The second half covered Rails. Dave made it clear that, logically, it should be called "Rails on Ruby", but Ruby on Rails sounds sexier, so there you go.

Points of interest / things I did not know before today:

• Innovation happening around the VM (Yarv, JRuby, Rubinius, RubyCLR, Cardinal, IronRuby)
• Lots of comparisons and references to java. Interestingly, most of the people I have met so far (as of day 1) come from a non-java background (perl/php/etc).
• Ruby's method of marking a version as 'stable' is not the same as Rails. In Ruby, experimental releases have odd numbering, where more stable releases have even numbering. In Rails, released Gems are more stable, and experimental work is done in the source control trunk ('RailsEdge').
• Big emphasis on Rails MVC, the benefits of a cohesive MVC framework (which doesn't require lots of xml plumbing) and putting the right code in the right place (business logic vs. presentation logic) when developing Rails applications
• Watch out for code debt. Basically, because it is easy to create so much code, so quickly in rails, that means it is easy to accumulate design debt quickly too!
• Scaffolding is considered passe, but a good way to learn REST
• The crowd seemed interested in some of the finer points of how DB migrations worked.
• Sam Stephenson (Prototype ajax lib) and Thomas Fuchs (Scriptaculous AJAX lib) are members of the core Rails team.
• REST is a hot topic at this conference
• Rails is a single threaded framework. The current approach to scaling (a "share-nothing" architecture) relies on pushing state into a scalable database (and presumably, adding 'worker' servers behind an IP sprayer).
• When asked what he hoped to see in next years conference, Dave Thomas mentioned wanting to hear integration stories (around vm's, other languages, and pre-existing applications).
• Most people doing Ruby/Rails like to do it with Textmate.

Personally, I'd like to see some better tooling: IDE, Code Coverage, and Complexity measurement tools. Hopefully I'll found out more about the state of that over the course of the rest of the conference. Looking forward to the BOF's tonight.

Continuous Integration And Testing Conference (CITCONF) - Day 2

Disclaimer: These are just my notes -- by no means thorough, guaranteed to be accurate, or containing anything I can take much credit for. Lots of talented individuals participated in group discussions at the conference.

What happened on CITCONF day 2?

I saw the OpenSpaces concept work -- in person -- better than I could have imagined or predicted. I attended sessions with varying levels of focus, but all with passion-filled participants with valuable insights. All the sessions were topics proposed by attendees the prior day and organized into an ad-hoc conference spread across 5 conference rooms and several hours.

Here are my notes (from memory) of a few of the sessions I attended, some of the questions we discussed and where I have a decent recall, some of the points raised in answer to those questions.

Session 1: "100% code coverage + functional tests, what's next?"

I proposed this topic because the team I'm currently on is consistently trying to find ways to push the bar higher. We currently have an extremely high code coverage level (100%), and functional tests driven by a tool called Greenpepper. This session's discussion jumped around between a lot of different areas, such as:

• How do you know you're testing the right thing?

1. correlate complex areas of code (based on metrics and empirical data) to areas which need more tests.
2. record real usage of the application to determine what code is actual hit in production.
3. use real data from production.
4. use real data from day 1 of your development (the idea being that real data is never as 'clean' as data you fabricate).

• Sometimes when people talk purely about 'code coverage' levels, it's a smell.

• How can tests express the expectations of what they are expected to cover (so coincidental coverage doesn't count)?

• Sometimes a high hit-count of coverage on a give line of code is a smell.

• Running test coverage measurements with...
  

1. just unit tests
2. just functional tests
3. just integration tests.

• Keeping code performant, pro-actively, re-actively, or predictively?

1. express expectations up front, code to them, test with unit/functional tests
2. pro-actively measure performance deviations over time (any known tools? nope)
3. optimize after the fact -- when you need to.
4. measuring performance with and without tests.

Session 2 - "What is the one true language for writing tests?"

The language of the testers? The language of the developers? A cross-over language?

The group brainstormed qualities we would look for in a testing language, and came up with a decent list which I thought looked a lot like a list of qualities I'd look for in a regular programming language. There was some brief mention of the possibilities of JetBrains Meta Programming System, and domain specific languages, Ruby and what it brings to testing, etc. The discussion then meandered into how to get teams to adopt best testing practices.

Session 3 - What is the future of build languages?

• What's wrong with ANT?
• Why has ANT been so successful?
• Rake?
• What about Maven?
• Procedural vs. Declarative? Specifying the how vs. what you want and what it needs.

Overall notes from the conference

• Several attendees with an impressive amount of experience (authors of build tools, well known book authors, authors of open source testing projects, and experienced technologists).
• Lots of 'Ruby, Ruby, Ruby'.
• I found the smaller sessions more engaging.