Patrick Farley on Ruby Internals

Elegance in Action
Enlightening talk on how Ruby handles class hierarchies:

http://mwrc2008.confreaks.com/11farley.html

Patrick reveals an important simplicity: method dispatch happens the same way, all the time.

"Elegance is the simplicity found on the far side of complexity" [1]

That is: you find a mathematical beauty from slogging your way through the various details and extracting from that an essential common concept.

Back to Farley... just two data structures and then this simplifying singular algorithm for method dispatch.  Simplistically:

• A Ruby object has two primary data members: its values for its instance variables and a pointer to its type (what class it is)
• A Ruby class is has two distinguishing data members: a list of methods and a pointer to its super class.

here's the algorithm for method dispatch:

1. for the object being send the "message"/"method call", dereference its Class
2. look for the method in that Class' list of methods.  If found, you're done; otherwise continue.
3. dereference this Class' super class and repeat step 2 (unless you're already at the "Object" class, in that case, you've got the "method_missing" event.

Given this algorithm, you can understand how Ruby implements:

• per-instance methods ("plain ol'" singleton class)
• class methods (a metaclass)
• include class (a singleton class created for each time the module is included)

Per-Instance Methods

These are methods added not to a class, but to an object:

1  class Foo

2   def defined_in_the_class

3     puts "Foo you!"

4   end

5  end

6

7  bar = Foo.new

8  baz = Foo.new

9  

10 def bar.only_works_on_bar

11   puts "I'm a bar!"

12 end

13

14 bar.only_works_on_bar

15 baz.only_works_on_bar

which outputs:

I'm a bar!
NoMethodError: undefined method `only_works_on_bar' for #
from (irb):15
from :0

On line 10, under the covers, Ruby is actually creating a secret class, known as a singleton class.  I'll follow Farley's example and use the prime notation: Foo'.  Foo' is the actual direct class of the object "bar".  Foo' 's super class is Foo.

That secret class creation occurs only on the first time a method is defined on an object.  It's the "purest" form of a "singleton class" -- it's a class which will only ever have one instance (here, Foo' has exactly on instance... that referenced by "bar").

Class Methods

It turns out, that each time you define a class, Ruby actually creates the object that is the class AND a "metaclass" (which is the singleton class of that object).

class Foo
  def self.im_a_class_method
    puts "this impl is stored in Foo's metaclass"
  end
end

Here, we are defining a class, Foo.  An object (of type "Class") is created and given the name of "Foo".  That instance of Class is immediately given a singleton class whereon class methods will be stored.  Remember, a class is an object (an instance of Class) and therefore, this is just per-instance behavior of instances of Class.  It's literally the exact same mechanism providing both class methods and per-instance method behavior.

[1] - http://www.amazon.com/dp/0743290178

Zotero -- Collaborate Web-based Researching

I'm on the hunt for a good bookmarking tool I can use across my computers and my iPhone.

Along the way found an interesting "research" tool: Zotero

• http://www.zotero.org/

Basically, it's a personal "Library" with social media tools.  The idea is that you can capture and organize online and library resources.  But then you can also use the site to find others who are potentially researching the same topic you are.

While I don't have a use for it, right this moment, seems like a cool tool and a fine example of how social media can be used for positive/constructive purposes.

Automated Testing Patterns and Smells

Gerard Meszaros gave a good talk at Goople on how to properly design unit tests:

http://www.youtube.com/watch?v=Pq6LHFM4JvE

His tome (and at 900+ pages, that's a fitting term) covers the unit testing topic from the perspective of identifying smells to help inch in the direction of well-structured tests and patterns that codify the structure that yields quality tests.

Good quality tests

1. bring confidence that the software under test (SUT) works as expected -- "verification"
2. are easy to read and understand -- "maintainability by way of discoverability"
3. are relatively inexpensive to maintain (and write new ones).

Why Poorly Design Tests are Worse Than No Tests

Gerard Meszaros gives a good case for why you should care: namely that just writing tests isn't good enough because you can quickly increase the carry cost of the software if you don't design your tests.  In that case, it would be better not to have written the tests in the first place.

Contributions

Meszaros identifies three categories of testing smells:

1. code smells
2. behavior smells
3. project smells

(of which he spoke of the first two in his talk)

In his book, xUnit Test Patterns: Refactoring Test Code, Meszaros identifies a number of categories of patterns:

Chapter 18 Test Strategy Patterns 

Chapter 19 xUnit Basics Patterns 

Chapter 20 Fixture Setup Patterns 

Chapter 21 Result Verification Patterns 

Chapter 22 Fixture Teardown Patterns 

Chapter 23 Test Double Patterns 

Chapter 24 Test Organization Patterns 

Chapter 25 Database Patterns 

Chapter 26 Design-for-Testability Patterns 

Chapter 27 Value Patterns

---

I'm purchasing this book and expecting to get the following benefits:

• develop a more academic understanding of the design of tests;  having patterns in mind while coding are excellent guides -- if you don't know the core patterns, you're swinging blind, relatively speaking.
• improve the quality of my tests by developing a sense for how they can go wrong and why.  This means getting a grasp of the dynamic complexity of making a "mistake" in test design and knowing the cost that incurs later.  This is the essence of informed design decisions.
• also this is a handy skill for tackling legacy code.

Whom are they talking about now? (TCPI)

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

A 30,000 foot data point to be sure, but here's an index of the most talked about languages on the web.  This is something to check in on every 6 to 12 months to see what "that kids are talking about".

Architexa -- Visualizing for Understanding

Here's a tool that's a diagramming plugin for Eclipse:
http://www.architexa.com/learn-more/videos/intro/video

It's not like your other diagrammers which simply aim to generate UML for generation's sake.  The difference is that this is meant to support exploration of the code.  The tool does this by showing the smallest amount of information and having the user "add" or "include" additional elements.

Looks slick!

Vagrant -- Promising to Reshape Configuration

At Tacit, like many software shops, we've been long in the pursuit of the ability to create a repeatable from-bare-metal one-step build for entire environments.

Vagrant is a recent tool (at the time of writing, it's claimed to be beta software) that aims to achieve just that.  Vagrant seems to be the configuration glue between a virtualization technology (Oracle's VirtualBox) and the newest up-and-coming configuration management tool: Chef.

You create and manage "box"es from the command-line running commands like:

$ vagrant add converse-endeca.box https://...
$ vagrant init converse-endeca.box
$ vagrant up

Where the first command points to a pre-built box, the second initializes it locally (e.g. to set-up port forwarding) and the third starts-up the virtual machine.

I love what I see:

• simple, script based (Ruby) configuration
• a powerful built-in DSL for configuring and controlling targets (known as "box"es).
• Chef is apparently this shizzle for tool configuration and I sense a large community following -- it's time for generalists to adapt.
• VirtualBox has been rumored to out-perform competitors (namely VMware) and at a zero-cost price-point, it's hard to beat.

---

7:40

silver:vagrant$ sudo gem install vagrant

Password:

Building native extensions.  This could take a while...

Building native extensions.  This could take a while...

Successfully installed archive-tar-minitar-0.5.2

Successfully installed abstract-1.0.0

Successfully installed erubis-2.6.6

Successfully installed json-1.4.6

Successfully installed mario-0.0.6

Successfully installed net-ssh-2.0.23

Successfully installed net-scp-1.0.4

Successfully installed i18n-0.4.2

Successfully installed thor-0.14.6

Successfully installed ffi-0.6.3

Successfully installed virtualbox-0.7.5

Successfully installed vagrant-0.6.7

12 gems installed


silver:vagrant$ vagrant box add base http://files.vagrantup.com/lucid32.box

Vagrant could not detect VirtualBox! Make sure VirtualBox is properly installed.
If VirtualBox is installed, it may be an incorrect version. Vagrant currently
requires VirtualBox 3.2.x. Please install the proper version to continue.

Wow, really?  If I follow the instructions on the home page, it doesn't work "out of the box". :-/

I'm not so sure this is beta software... more like pre-alpha.  Great idea, I'll give 'em another go, later.

Spring Roo

Part of RoR's appeal is how a little bit of tooling can generate the boilerplate code that's typical in most web applications.

Spring has developed a tool/framework called Roo as a kind of response to Rails.

There are two parts to Roo: a shell, where in you type commands to modify your projects; and the resulting code it generates into your project.

They get away from the problem of generating and somehow syncing code by using Aspects. Roo generates .aj files with the associated code that it wants to add to your classes. For example, an Entity class should have accessors for each field in the class as well as a finders. Roo adds this code to your class by generating Aspects on your class.

You can inline those aspects using Eclipse's refactoring (Push In..., I believe is what it's called).

Aspects seem to be a nice sweet spot for Java: it allows the side-by-side coding (programmer maintains one code base and the tooling adds to it) while allowing you the flexibility to jump away from them.

http://www.springsource.org/roo