My must-see list from MWRC 2013

Saturday, May 4, 2013

TL;DR

If you watch one talk from Mountain West Ruby 2013, watch Greg Baugues: Devs and Depression.

Talks @ Mountain West Ruby Conference

Mountain West Ruby, was a great conference: lots of content and awesome people. It had one DevOps day and two Ruby days. Its presentations have recently been posted on confreaks.

There were a total of four talks by Pivots, including one by myself (in order of appearance):

Andy Pliszka: Extending CRuby with native Graph data type.
Matt Kocher: Ruby off the Rails: Building a distributed system in Ruby.
Stephan Hagemann: Component-based Architectures in Ruby and Rails.
Sarah Mei: Work, Play & Code.

What follows is the list of talks that I recommend watching.

There is one talk that I want to highlight within my list of highlights: “Devs and Depression”. It is the last one in this list and as you can guess it is not about technology. It’s different, bold, and in my opinion very important. Watch it!

Alright, here we go…

DevOps Day

Gene Kim: Why we need devops? - 30000 feet view of why devops is valuable and how to do it. It’s a 3 trillion market.

Will Farrington: Boxen: How to manage an army of laptops – Some impressive stuff github is doing for machine management.

Lindsay Holmwood: Escalating complexity: DevOps learnings from Air France 447 - Chilling: Case study of an airplane crash. Systems within complex systems. Local vs global rationality.

If you want more:

James Turnbull: Hell has frozen over: DevOps & Security – How security people should change their work and how they talk about it.

Drew Blas: Migrating a live site across the country without downtime – Actionable story on how to move data centers.

Jesse Newland: ChatOps at Github – Using hubot (in campfire chat) to manage puppet (and everything). Documenting, interacting, interfacing among remote teams.

Ruby Day 1

Yukihiro Matsumoto: Ruby 2.0 – History of Ruby and features of Ruby 2.0. Maybe don’t watch if you already know about the new features. Maybe watch it, because its Matz.

Michael Fairley: Immutable Ruby – How immutability can benefit your code.

Daniel Huckstep: Ruby Batteries Included – Don’t require gems: Use the Ruby Standard Library.

Ryan Davis: Trolls of 2013 – Not abut trolls, but implementing an interpreter in Ruby. Talk got cancelled on the first day, due to a fire alarm. Way to deal with it Ryan!

If you want more:

John Pignata: Code Smells: Your Refactoring Cheat Codes – Run through a long list of code smells and refactorings.

Ruby Day 2

Brandon Keepers: Ruby at Github – Musings on Ruby: when to use, why to use. And problems (over time) in a big setup.

Craig Kerstins: Postgres Demystified – Lots of stuff you did not know about Postgres.

Greg Baugues: Devs and Depression – Personal story of mental illness. Talks about depression and why we should be more attentive to our fellow developers.

OpenView conference

Edward Hieatt

Thursday, October 16, 2008

OpenView Venture Partners

Ian McFarland and I attended a 2-day Development Forum hosted by OpenView Venture Partners last week in Boston. It’s the second year that Pivotal Labs has participated in the event. Open View has a portfolio of companies from all over (Europe, Australia, the US), each of which has been working on implementing Scrum over the past year. The engineering staff from 10 portfolio companies attended the event. Jeff Sutherland (amongst other things the co-creator of Scrum) is a Senior Adviser to OpenView; he provides advice and guidance to the portfolio companies as they progress through their Scrum adoption, and he gave a talk at the Forum. Pivotal Labs was invited to speak and lead a discussion of on 2 core topics: Developer Testing and the Principles of Build.

Status & Issues

First, we heard from each company on how they were doing with their adoption of Scrum and on the following two questions on the subject of technical developer practices:

The goal of every sprint is to have fully tested quality software product ready to go live with customers. Where are you now with relation to this and what stands in your way of getting there?
The goal of every development team should be to have one piece of software code globally, and all work and testing is done on this one piece of code, with multiple builds with built-in testing done in a given day. Where is your team in relation to this goal and what stands between you and getting there?

The 10 portfolio companies come from a disparate set of industries and technical domains, so Ian and I were very interested to hear each of their histories with Scrum and the current issues they were facing with respect to these 2 questions on developer practices. Some were at a fairly advanced stage – they had good test coverage and a stable CI setup – and some were just getting started. The most frequently stated barriers to achieving the goals of fully tested software that’s ready to release were:

A perception that the team wasn’t big enough to allow for writing tests
An assumption that ongoing developer testing could potentially slow the team down
An assumption that adding tests to a code base would mean first stopping and covering all the untested code so far with tests, and that therefore it meant stopping for a long period to retrofit tests
A question of whether clients even wanted frequent releases (e.g. once per week) of the software
A perception that the team wasn’t big enough to allow for pairing
A lingering assumption that QA and not Developers should be responsible for generating all test coverage

Pivotal Labs’ talks

Developer testing

Pivotal’s first talk was on developer testing. There were two main points we wanted to make:

The best way we know to get a big jump in quality and to be able to frequently release new versions of software is to rethink who is responsible for testing.

Rather than the traditional model of a QA team being almost solely responsible, consider a shift towards the whole team being responsible, and in particular a much greater emphasis on developers owning quality. For many developers it’s a radical shift.

The most effective way we’ve seen for developers to own quality is through the disciplined and sustained practice of TDD.

During the talk I gave a demo of a simple example of strict TDD, which gave rise to some useful conversations; as expected, the reactions varied from “yes, that’s what we do” to “that makes no sense!”. Having coded solely with strict TDD for almost 9 years now, and being around Pivots who exclusively test-drive also, it’s always interesting to hear reactions of people coming to TDD for the first time. The idea that tests are the center of the development effort, and that code is to some extent expendable, is a radical shift in thinking. We also touched on the benefits TDD brings in addition to reducing regressions. I find that a useful question to ask is what TDD stands for: “Test Driven Development” or “Test Driven Design”. The notion that TDD helps in designing your object model brought up some interesting discussions (for example, mock objects came up).

We also tried to address the barriers to adoption that had been brought up:

When introducing tests to a legacy code base, rather than trying to immediately cover everything with tests right away, we suggested:
“Stop the rot” – from now on, attempt to test-drive everything, including bug fixes
Spend time each iteration/sprint adding some coarse-grained, high-level tests around the legacy code
Once there’s at least a basic safety net in place, spend time refactoring towards unit-testability
Gradually introduce unit tests over time, with the goal being high test coverage at the unit level
Certainly with a small team there may not be bandwidth for an explicit traditional full-time QA role. We pointed out that with developer testing there’s no tester-developer separation: every developer is a tester, so testing isn’t gated by team size at all.

We made two points about speed when doing TDD:

It can certainly take some time to get proficient and achieve the same short-term speed you had before. However, in our experience, if a team has a member who’s done it before, or whose role it is to advocate for constant TDD, the team members start to get the hang of it much faster than you might expect – 3 weeks or less in many cases.
Independent of whether coding a certain feature is faster or slower, the medium- to long-term benefits (catching regressions instantly) are invaluable.
There was an interesting discussion of why we’re so interested in pushing for frequent releasability even on projects whose clients are known not to want frequent releases. The consensus was that even if there’s no actual need or desire to release frequently, the act of trying to get to that point brings lots of benefits. There are fewer surprises when a real release comes due; the “last-mile” problem is often reduced; people integrate their changes with the main trunk of development more frequently, so there’s less merge hell, etc.

Build

Our second talk was on build. As an ideal to shoot for, we promoted what Pivotal Labs does:

Checkins prompt a build (clearly, this helps to identify which changes broke what)
A broken build is an anomaly – teams should immediately stop and fix a broken build
Keeping the build fast is critical, so that it stays relevant
The build must be easily visible to the whole team. At Pivotal we have 2 large TVs on the wall that clearly show the build status of all our projects

There was a good deal of discussion over how to get started with a build. Some ideas that were brought up were:

You don’t need tests to have a build. Compiling and packaging your code with each checkin, and making sure everything works is still very useful information
If your build is flaky (i.e. some tests fail seemingly at random), immediately detach the flaky tests to keep the build stable. Work on the flaky tests in isolation. The team needs to trust the build’s status.
If your build is slow, break out a slower suite of tests and run it in a separate process that runs less frequently. Work towards high coverage with fast unit tests so that the status of your fast build is meaningful.

Hopefully our talks were useful. Certainly they sparked plenty of discussion!

Thanks to Jeff Sutherland, Igor Altman and Steve Rabin of OpenView for inviting Pivotal Labs to speak.

Below are our two presentations.

Pivotal Labs Open View Presentation Quality Assurance And Developer Testing

View SlideShare presentation or Upload your own.

Pivotal Labs Open View Presentation Continuous Build

View SlideShare presentation or Upload your own.

Treetop: Bringing the Elegance of Ruby to Syntactic Analysis

Pivotal Labs

Monday, August 20, 2007

(This is my proposal for this year’s RubyConf. Fingers crossed!)

Treetop is a parsing framework that brings the elegance and simplicity of Ruby to syntactic analysis. Rather than being just another copy of classic LALR/LR based generators like Lex and Yacc, Treetop blends the unique expressive power of Ruby with cutting edge parsing research. Its “packrat” implementation enables recognition of parsing expression grammars, which dispense with the need for lexical scanning and can take advantage Ruby’s mixin and inheritance model for composition.

I will begin with an overview of recursive descent parsing, explaining why the exponential time complexity of backtracking make naive implementations impractical. Packrat parsers solve this problem with memoization, exchanging heap space for linear time performance. In the process, they obviate the look-ahead techniques that have traditionally been used to reign in the time complexity of parsing.

This opens a new world for grammar definitions.

Without lookahead, a compositionality-destroying tokenization process is no longer necessary. Combined with the embrace of backtracking, this results in a grammar definition language that is more intuitive and free of the hidden obstacles that plague more restrictive conceptual frameworks. In the literature, these definitions are called parsing expression grammars. They are free of ambiguity and explicit operator precedence annotations. They can also be freely composed.

Imagine taking the Ruby grammar and the SQL grammar and combining them to yield a grammar for Ruby that recognizes the syntax of SQL statements embedded in strings. A token-free, compositional approach is the key to this sort of reusability.

The rest of the talk explores the manifestation of these expressive advantages in the Treetop framework. Treetop’s grammar definition language is a superset of Ruby, conservatively extending its syntax with two keywords (grammar and rule), along with inline parsing expressions. It blends parsing expression constructs with Ruby method declarations, which are automatically installed on nodes of the syntax tree produced during the parse. I will introduce these fundamental concepts by example, creating a toy parser that recognizes and evaluates arithmetic expressions. Here is a shortened sample:

module RubyConf
  grammar Arithmetic
    rule additive
      number '+' additive {
        def value
          number.value + additive.value
        end
      }
      /
      number
    end

    rule number
      [1-9][0-9]* {
        def value
          text_value.to_i
        end
      }
    end
  end
end

I will then discuss the system’s implementation. Important issues include:

The metagrammar and the system’s metacircular bootstrapping process
The code generator and the mapping of parsing expressions to Ruby code
Riding on Ruby’s semantics for grammar composition, including the use of mixins and the super keyword.

Time permitting, I will explore more advanced usage by writing a simple interpreter for the untyped lambda calculus atop the framework, which I will extend with facilities for arithmetic by mixing in the grammar from the first example.