Friday Rubyconf Notes

Keynote

DHH delivered a passionate, amusing diatribe against the development culture that demands that the programmer must be controlled. Hence the likes of strictly-typed languages, waterfall, throwing code over the wall, and all the resulting demoralization that goes along with it.

David asserted that freedom carries with it the potential to do great good as well as great evil.

I suddenly appreciate how special this Ruby community and culture is: because of our freedom, we all aspire to very high moral standards of opportunity, fair play, and nurture. Because this freedom to express yourself is a precious freedom indeed, I see many people in this community joyously giving themselves to preserve it. My church makes the same entreaties in its community, yet at this time they don't seem to come even close to this community's results.

RubyConf has been a refuge from the greater American atmosphere of distrust, cynicism, spinning, and unhappiness. Thank you all, I am very grateful.

LDAP, the Original No-SQL

My main takeaway from this talk is that LDAP has some special strengths that make it a good choice for some applications:

• Distributed
• Mature
• Asynchronous
• High-Performance

If the application has a high read-to-write ratio, the case for using LDAP as opposed to other "No-SQL" solutions is very good indeed.

Rubinius - What Have You Done for me Today?

The main goal for this Ruby variant is to leverage the Ruby language itself to implement the Ruby engine as much as possible.

Evan Phoenix has made a lot of progress since I last saw his presentation at Railsconf. Development has continued to take advantage of the "Ruby-ness": better than average benchmarking and profiling tools.

They are now working to be compatible with version 1.9.2. The future includes a Windows version and full concurrency.

MacRuby - why and how

Matt Aimonetti showed the latest version of the Ruby that can directly access the OS X objects in Cocoa. This make MacRuby a strong contender for implementing Mac applications.

To the question: when will it be available for iOS, Matt could only say that, aside from having to implement a garbage collector, there are no other technical issues. The real issue is whether Apple wants to support that capability.

Having used Smalltalk to learn the Windows API in the 1990's, I can only hope that Apple enables the same capability using MacRuby.

pie: the making of a DSL for simple games

I was tired of technical presentations and wanted to see what other Ruby efforts were going on. Here Sarah Allen testimonied about using Ruby to develop a simple DSL for an adventure game. What was interesting was her thought process and how checking out her early design ideas with others caused all of the "rewriting" to take place in the beginning when it was easy.

By taking it to children early, she gained valuable insight on what held their attention and what didn't. As expected, the childrens' ages mattered a lot.

I learned a lot about distributing early versions to the customer and how to benefit from their feedback.

Socalist Software Development

CJ Kihlbom is from Sweden and he admits he has a "socialist" point of view about developing i the Agile Ruby environment. Both amusing and insightful, he illustrated how seeing the opportunity glass "half-full" makes the Ruby community much more joyous and supportive. Among the software practices that are "socialist":

• Open source
• Pair programming
• Collaboration

The results of these practices are a large number of benefits:

* Flow

* Lessons distractions

* Camaraderie

* Helps w/ morale

* Work w/ people you like

* Better morale

* Stability

* Immunity from a developer hit by a bus ("bus number")

* Learning

* Apprenticeship

* Formal apprenticeship programs

* "Apprenticeship Patterns Guidance for the Aspiring Software Craftsman" O Reilly

* Mentoring

* Find someone we can inspire

* The teacher benefits as well as the student. Building the community strengthens us.

* Competition

* We're competing for the same talent and sometimes project. But really we're collaborating.

* See life as more than half full.

* Craftsman swap - competing consulting companies swapped developers for a week. They learned a lot from each other. This has been catching on.

* Obie: we are competing against consulting shops outside our community.

* Solidarity - So we can all grow and all improve.

One question was raised: how can we influence other software communities. For example, how could be influence a badly-run Java shop?

CJ makes me want to move to Sweden. ;-)

Automated Acceptance Testing, The Vietnam of Test Driven Development

Paul Wilson discussed how being unclear about the role and intent of different test strategies can get your development efforts bogged down in a never-ending slog of developing tests that don't really do you any good.

He focused on acceptance testing, which I realized I had confused w/ end-to-end testing, system testing or integration testing. They are not the same.

Acceptance specifications are a tool to flesh out unclear business requirements, and acceptance tests verify that the acceptance specifications are implemented. Hence, the acceptance test is built for the stake-holder and the terminology should reflect his vocabulary. Phrasing it in UI terms is unnecessary unless the UI is part of the acceptance specification itself; many times it's business rules. Hence test wherever the acceptance criteria are specified.

Matz's Keynote

I didn't take notes on Matz's presentation; rather I just listened. He talked about some upcoming features in Ruby 2.0: mainly features to reduce risk in monkey patching.

He also talked about "Rite" (Ruby Light) for embedded systems.

Thursday Rubyconf Notes

w00t! My first Rubyconf! My testimony of this great event. Today: Rubyconf's first day:

Opening Keynote by Dave Thomas

I didn't take notes on this; just listened. Dave went thru the history of his involvement w/ Ruby, the books and how it grew beyond his wildest expectations.

His last part touched me the most: find someone and mentor them into the Ruby community. His comments would have more meaning to me as the conference unfolded.

Debugging Ruby Systems by Aman Gupta

Aman described all the "heavy hitting" tools to use when the problem lies outside of using console or irb to figure out what's going on:

• lsof
• strace - linux only - trace system calls and signals
• tcpdump - dump traffic on a network - use wireshark for decomposing results
• perftools - google's performance tools
• cpuprofiler
• perftools.rb (available on github)
• rack-perftools - rack middleware for prftools.rb
• ltrace - trace library calls. Is presently unable to trace into shared libraries; ltrace/libdl will fix this.
• gdb - the GNU debugger

What I would find out later is the attempt to integrate what these tools do in one application. But these were good; sometimes I've used one or another but it was helpful to have the entire selection explained again.

The Polite Programmer's Guide to Ruby Etiquette

by Jim Weirich, Chris Nelson, and Ed Sumerfield

Basically, how to not break others' code when you use 'method_missing' and similar powerful Ruby features.

1. When using method_missing, delegate what you don't handle to super.
2. Beware there are several "hook" methods:
   
   1. method_missing
   2. constant_missing
   3. etc
3. When using method_missing, don't forget to handle responds_to as well.
4. When publishing a gem, don't forget to put that gem's dependencies in the gem description file. There is now a feature in the description file to also specify additional gems depended upon only during development.

MetricFu, a code analysis tool

A static checking toolset.

There are quite a few independent software packages covering different metrics:

• Flog reports. Measures complexity. Also top 5% complex ones.
• RCov. code coverage. What lines in your code has been executed by tests.
• Reek: bad naming
• Play: copy-paste detection. Is fairly good at
• Saikuro - cyclosomatic complexity. Covers branching complexity
• Source - Source Control Churn.
• Roodi: Tries to find definite code design.

That's quite a few different outputs to wade through. MetricFu organizes all output in one graph per method. Hence, MetricFu is based upon Caliper and accomplishes the "unification" of static metric output on a per method basis.

ZOMG - Why Is This Code So Slow?

Aaron Patterson put on a performance that will be a classic video to watch in coming years. In a very humorous way, he explored a Rails 3 anomaly that we experienced ourselves, a mysterious and significant ActiveRecord performance slowdown.

In telling it like a detective story, Aaron walks us through his motivations and thinking in

1. Discovering the problem
2. Deciding that it's worth his time to fix it.
3. Understanding the problem
4. Fixing the problem

Of course it was not that straightforward. Aaron realizes that understanding the problem will probably take MUCH more time than he wants to invest, so he goes through all the "standard optimization" stuff and gets some benefit. But, the fundamental problem remains the same: the speed slows down as the square of the number of terms in the query.

Finally, he breaks down and decides to work to understand the problem.

He spends 3 weeks (or was it 6) in just this exercise. An extensive part of his education comes from automated benchmarking; don't leave home without one. Once Aaron truly understands the code, he realizes some design that will have to be changed. I.e. a rewrite. So he does. At the end, all of the lost time is recovered and then some.

Along the way I "relearned" some computer engineering fundamentals and had was thoroughly entertained as well: Benchmarking. Diagrams that describe how the code is organized.

My takeaway is that Aaron reminded me that tough problems require a plan of action that almost always requires an extensive time period to study and understand the code causing the problem. This can be hard to choose when you're in a tough constrained time box. I have to continually "check my footing" before I jump to conclusions about the cause of a problem and attempt a solution before I really understand the problem.

Oh, and checkout graphviz.org for a great free diagramming tool.

It's Time for a Ruby Editor

This talk introduces RedCar, a recent Ruby-implemented editor. Why?

• Integration - Syntax analysis is easier
• Convenient - Can extend easier
• Fun - Not as much a language curve
• Power - API not limited by

A demo showed examples of the above.

Takeaway: very interesting. I'm still fantasizing about pairing RedCar with Rubinious as the foundation of a truly impressive Ruby IDE. ;-)

Maintaining Balance While Reducing Duplication

David Chelimsky cited chapter-and-verse about the evils of duplication code. That being said, he showed how to remove duplication thoughtfully, that is, without breaking it or making it hard to read.

The guiding principal is that removing duplication should improve code clarity, not obscure it. It therefore helps to remember that DRY calls for the removal of duplicated functionality, not just the minimization of keystrokes. This is so that functionality can be changed in once place.

Another way to look at it is that every piece of knowledge should have a signle unambiguous authoritative representation. Always consider purpose and intention.

Improving DRY means adding levels of indirection. Always make sure that the code depends on other code that is not likely to change.

Suggestions for Making your "DRY-improvements" better:

1. Depend on things that are less likely to change.
2. The problem is not that you have to change code in two places. The real problem is that you don't know you need to change it in two places.
3. Duplication is not always obvious. This is especially pernicious in rspec.
4. Duplication often results from "feature envy".

Knocking Ruby's Date and DateTime Performance Out of the Park with home_run

Jeremy Evans discusses how the real problem with Date and DateTime performance os the powerful but slow date parsing for date strings. You can improve this if you limit the parsing options.