At RailsConf, Chad Fowler opened and offered one observation that I found particularly profound. He admitted that he doesn’t do particularly well in a classroom setting — and implied that conference talks are like a classroom environment.

That struck me to the core. That’s me.

At Ruby conferences, I see few people voting with their feet. However, I see many people who barely pay attention to the speaker. Instead, they are on IRC discussing how disappointed they are in the speaker, writing a Rails app or Ruby gem, or just surfing the net.

So why even go to the talks at conferences? Why have the talks? Obviously, most Ruby conference attendees would rather be doing something on or computer, social or otherwise.

Beteween games of Werewolf at Ruby East last year (my humble apologies to Charlie Nutter), Giles and I were yakking away. Somewhat randomly, he says something like, “Man, you and I… we’re just scenesters.”

That’s exactly what I’d become. I didn’t realize it until that moment. That had never ever been me but it sure is now. And I bet that’s you too.

You go for the scenius.

That’s a Brian Eno-ism. It’s “the emergent genius of a colocated culture”. It’s that spark you get, that inspiration, that makes you feel smarter just because you’re working near and talking with the poeple that you are where you are.

I don’t see much exchange when there is a talking head, even a brilliant one, at the front of the room with an audience full of mostly silent people. Why is a group of such seemingly independently-minded people as the Ruby community willingly enslaving themselves to the words of one person after another for 45 minutes a pop? Just how educational does this really turn out to be?

“This town needs an enema” - The Joker, Batman (1990)

Why should Ruby conferences be traditional conferences? Just because everyone else does it that way? Odd. I don’t see this community (communities?) as followers.

Giles asserts that we’re a weird bunch of people. Hell, I thrive on it — just as much as I gag on the lack of weird when I return to my day job from a conference.

So why not just be weird instead of being like every other conference out there with their clearly delineated speakers, audiences, and Nascar-like corporate branding?

No I don’t mean Ruby Fringe (although I am going).

Let’s invert the process. More discussion. More hacking. Less talking heads.

Let’s make some awesome Stone Soup.

I’ve discussed this with some people around the community. The often conservative and stodgy DC Metropolitan Area may hold the first Ruby BarCamp. Does someone want to beat us to the punch? I triple-dog dare you.

Update 6/29/08: Bryan Liles pointed me at an article by Dave Winer about the “early days” of unconferences. His timing is serendipitous. Come on, people! Let’s make something happen!

Also, Mocha suddenly jumped from v0.5.6 to v0.9?!

So jrsplenda broke when I tried to demo it on my wife’s spiffy new Macbook Air — as I was foolish enough to just ’sudo gem install mocha’.

Who the hell has a public release at 0.5.6 and then another at 0.9? I am so integrating FlexMock into jrsplenda in the next release. I can’t see Jim Weirich doing anything like that.

I’m halfway tempted to redo and give my BDD with RSpec talk to NoVaJUG as a JRuby-Java BDD talk. More people should be doing BDD and not merely those of us working in dynamic languages. Were it so, I imagine that I would encounter far more testable and maintainable code in the Java community.

Slides from the presentation are available here

ERubycon is August 15-17 in Columbus, Ohio. I hope to see you there.

One week and one RailsConf later, I’ll call this “tomorrow”.

In the previous article, I listed a handful of commons Java idioms that reduce testability. Three out of four of the issues may be rolled up into a higher level of abstraction: encapsulation kills. The remaining point may be summarized as Spring XML == code that most developers don’t test. Encapsulation prevents developers from injecting mock objects into their code. Without mocks, the unit under test lacks isolation. Without isolation, your unit test is an integration test at best and a massive FAIL at worse.

If you endured a Computer Science curriculum in college, I’m reasonably sure that the professor of your second or third CS class repeatedly hammered home: encapsulation is a key tenet of good object-oriented design. However, many dynamic languages only provide a brief nod, if any, to the encapsulation gods. For instance, Python does not support private or protected members. While Ruby does, it is trivial to route around those protections. What some may not realize is that, in this respect, Java is little different than Ruby.

Yes, that’s right. Java can be a bit on the promiscuous side of things too.

I’m not sure what you’re “java.policy” file allows in your Java installation but, on OS X, the default allows for Java reflection to route around field and method access privileges. Don’t believe me? Take a gander at the java.lang.reflect.AccessibleObject class that is the parent of Field, Method, and Constructor reflection objects.

With this, you could write/generate a lot of code to act as wrappers for Java objects to expose private, protected, and package scoped Fields, Methods, and Constructors. While this is somewhat interesting, we can do better.

So why bother using Spring for object creation and dependency injection? No, seriously, think about it. Do you test your Spring XML? I would bet every Java developer who reads this article that, as of the authoring date, that you don’t. Ruby is extremely testable. So why are you writing all of that glue code in XML and not testing it? Write it in a Turing Complete programming language and test it, for crying out loud!

But I digress (however only slightly)…

Ruby excels at DSL creation. This has been demonstrated with awesome effect in the unit testing/specifciation domain. But did you know that Ruby’s testing and specification DSLs (i.e., RSpec) can be used to test Java? Oh, yes, it’s true. And Ruby’s mocking libraries (i.e., Mocha, Flexmock, and RSpec mocking), with their ability to create mocks at runtime with just a line of code simply blow Java away.

So what if we put our chocolate in our peanut butter? JRuby, as of v1.1.2, provides workable Java integration such that a JRuby mock object, generated by Mocha, may be injected into a Java object instantiated in JRuby.

Next we write some java.lang.reflect calls, in JRuby (!!), to wrap each non-public field and method for a given Java object with a JRuby method. Yes, a JRuby method. The generated JRuby method takes advantage of the java.lang.reflect.AccessibleObject’s features to provide setters (JRuby already provides getters) for Fields and to provide direct access to Methods.

Now we can inject these JRuby-created mocks from Test::Unit or RSPec into almost any part (well, ok, except for final members and local variables) of our Java objects. Suddenly, we’re writing test code that’s a whole lot more readable and we’re writing a lot less of it!

Splenda

I call the field and method wrappers “Splenda” or “jrsplenda” for JRuby Splenda — to sweeten up Mocha. While there are still some minor limitations as of v0.1.1 (see the README provided in the github project), I’ve already re-written some of the JRuby RSpec from my current project to use Splenda. It works like a champ.

Working sample code has been supplied with jrsplenda in the github project. Nonetheless, it bears mentioning describing it in brief.

Splenda is made up of three helper modules: a MockHelper, FieldHelper, and MethodHelper.

MockHelper

The MockHelper, predictably, supplies mock objects but also provides a facility for generating a mock of a Java class and storing the mock in a member attr named after the Java class

Example

  # inside a spec or test....
  require 'rubygems'
  require 'jrsplenda'


include JRSplenda::MockHelper

splendamockattr ‘javax.ejb.SessionContext’

# => Creates a @session_context containing a mock for a SessionContext in one line

FieldHelper

The FieldHelper wraps all non-public (and non-final) fields for a given Java object. This is awfully handy for injecting your mocks.

Example

  #inside a spec or test
  require 'rubygems'
  require 'jrsplenda'


include JRSplenda::FieldHelper

import ‘my.fake.TestClass’

t = TestClass.new
  wrapjavafields t

# => Generates setters for all non-public non-final fields of the TestClass instance pointed to by t

MethodHelper

The MethodHelper wraps all non-public methods for a given Java object. This one is nice for white box testing of internal methods.

Example

  #inside a spec or test
  require 'rubygems'
  require 'jrsplenda'


include JRSplenda::MethodHelper

import ‘my.fake.TestClass’

t = TestClass.new
  wrapjavamethods t

# => Generates setters for all non-public non-final fields of the TestClass instance pointed to by t

Take away

1. Java may work in isolation but it is better still with the assistance of a dynamic language
2. JRuby, as of v1.1.2, can integrate well with Java
3. JRuby + RSpec can test Java code
4. Mocha + Splenda make this not only ridiculously easy but ridiculously readable
5. Question whether you really need Spring. Dynamic languages running in the Java VM can accommodate your dependency injection needs; they’re far more testable than your Spring XML

The latest version is available on github. Clone the repository and ‘rake install_gem’ to get the gem.

Oh, and Splenda may cause diarhea and bloating. Just sayin’.

Update: Incidentally, Flexmock actually plays very nicely with JRuby. I’ll be adding support for it in Splenda in the next release.

There, I said it.

Come on, it does. I know, 8 years ago, JUnit was the bees knees. But let’s face it: when you’re working on a project, you’re behind schedule for whatever reason, and you have a deadline looming, where’s the first place that you cut corners?

Unit tests. Always.

Why?

1. Lack of perceived value of testing (in other words: I see the happy path works so what’s your big problem?)
2. No one is going to ever touch this code again after this release
3. Java is just difficult to test

Let’s talk about these….

Why You Don’t Test (a.k.a., why you’re brain damaged)

Lack of perceived value of testing

If that’s the way you feel, then you shouldn’t ever call yourself an engineer. You’re just a hack. Still, I’ll assume that there’s hope for you yet because you’re reading this article in the first place.

The “Somebody Else’s Problem” Field

You’re leaving the project soon. Or you honestly believe that your shit doesn’t stink. Or you’re just going to leave it for the next guy. It’s somebody else’s problem. There’s one response to this: in this business, frequently, that somebody is you. If you can’t maintain your own code then you’ve just shot yourself in the foot. Congratulations.

But, now, to the heart of the matter.

Java is just difficult to test Now I know that I’m not the first one to say this. However, in my opinion, what makes difficult to test are the idioms and practices that developers have acquired over the 13 years that Java has been around. Many of these idioms and practices fly almost completely counter to testing — for in order to be able to test effectively, we must be able to isolate the unit under test. How do we do this in Java? Dependency injection. Come on, you knew I was going to say that, right?

Evil/Brain-Damaged/Detrimental Idioms/Practices

• Enterprise Java Beans. Come on, already. Private variables mutated by the container based on an XML deployment descriptor (so we’re coding in XML now )? Are you testing your deployment descriptor? You probably should be. Have I ever done it. Not yet….
• Spring. Yes, POJOs are good. Actually, I’ll amend that. POJOs are fucking awesome — especially when every member variable is exposed via a getter and a setter. Unfortunately, you’re now effectively writing code in XML. So are you going to write tests just to exercise your XML? If you aren’t, you should be. That XML creates and links objects together. As soon as you start coupling things dynamically, you have a relationship that could break and therefore warrants testing.
• private/protected member variables. We need these, don’t we? Sometimes, yes, actually, we do. However, if they aren’t wrapped (see Spring above) then Houston we have a problem.
• static final used for non-primtive/String constants. This is simply everywhere in the Java universe: developers statically initializing constants with Objects. This is awful. Why, you ask? Because how the hell are you ever going to be able to inject a value for that static final Object? It’s assigned at classloading time. So, basically, grab your ankles and BOHICA.

Unfortunately…

• Some of these hurtful practices are necessary
  • Encapsulation
  • Spring XML (if you’re stuck coding Java in the first place)
• Sometimes we’re working in legacy code
  • Limited ability to change existing code; stuck with bad practices
  • Existing unit tests are sometimes lacking

How do we get better?

Come back tomorrow. We’ll talk. Seriously.

Aside: They brew insanely strong coffee at the Sheraton…

Domain Specific Language

• Discussions comparing DSLs to expressive DSLs
  • Me: I don’t believe that there’s a difference but Ruby brings us closer to English in our DSLs
  • DT: Which causes a whole new level of confusion because while it reads easily it’s hard to write
  • DSLs, to him, represent a domain-specific form of abstraction
• Rake
  • CF: Dependency-oriented DSL
  • Me: Now that is a nifty abstraction to capture the purpose of Rake
• Dhaka

• JDWP DSL CF: cites an example of a Java Debugger Wire Protocol implementation that Rich Kilmer wrote by copying the documentation into a Ruby file and simply reformatting the docs into valid Ruby code.

  • Readable to SUN developers
  • DT: DSL is retargetable — specifies intent, not implementation

• Implementation tricks

  • method_missing

• CF: Most DSLs are block based

• To instance_eval or not to instance_eval
  • instance_eval is constraining because it redefines self
  • DT: The DSL is a promise (Me: a contract? interface…) that should be consistent
• Consider context: who will use the DSL?

This is a good discussion.

• DSL anti-patterns
  • False familiarity
  • method_missing and respond_to> together
  • If you support one then you should support the other
  • Cluttering namespaces (flexibility)

break & exercise (write a morse code generator for a given pattern

  class MorseEncoder
    CHARS = {
      :a => "._",
      :b => "_...",
      :c => "_._.",
      :d => "_..",
      :e => "."
    }

    def initialize
      @msg = []
    end

    def encode(&block)
      instance_eval(&block).reverse.join(” “)
    end

    def method_missing(name, *args)
      @msg << CHARS[name]
    end
  end

  morse = MorseEncoder.new
  puts morse.encode { b e a d }

Extremely pleased how much more comfortable I’ve become with my use of blocks and closures over the period of this class. This course has provided some good brain strengthening exercises.

Exotic Control Flow

• DT: “I don’t know what BASIC is. The dribbling old fool of programming langauages”
  • Likens exception handling to “goto on steroids”
  • Implies that goto is not necessarily harmful
  • It’s up to the individual programmer
• DT: “Experts know when to break the rules”
• LOL: Don’t not use positive logic

• throw and catch

  • This is not Java’s throw/catch — almost the opposite (that’s raise and rescue)
  • catch takes a label and executes a block
  • throw takes a label and optional arguments
  • Causes Ruby to unwind the call stack to the first catch that matches
    • The optional parameter is the return value to provide from the catch
  • Real use: open-uri
  • Me: This would elminate so much code from my current project in the office — if they hadn’t already writen it in Java…

• Continuations

  • callcc
  • requires a block with one parameter (the conitnuation)
  • Executes the block
  • When a continuation is called, execution resumes immediately after the continuation’s block
  • All control structures can be implemented via continuations

Lunch and Exercise

# Write the methods start_loop and end_loop so that the following does what you'd expect:

i = 0

again = start_loop

puts i
i += 1

end_loop(again) unless i > 5

… which is solved by:

def start_loop
  callcc { |cont| cont }
end


def end_loop(continuation)
  continuation.call(continuation)
end

I won a gold star for niftiest continuation implementatio for this exercise. Yay, me!

Debugging & Profiling

• ruby -d
  • Sets $DEBUG
  • caller: call stack, file names, and line numbers (Me: handy stuff!!)
• ruby-debug gem
  • Insert a debugger call into Ruby code to dump into the debugger from the runtime
  • Also requires requiring the gem (duh)
  • Inside the debugger, can launch into irb in the current context

• gdb

  • Attach to the running Ruby VM
  • gdb gdb_path_to_Ruby_bin Ruby_VM_PID

• Ruby ‘profile’ library

  • Me: Woops, didn’t know about this library!
  • ruby -r profile my_program_name
  • Profiling specific parts of code
  • Profiler__::start_profile
  • Profiler__::stop_profile
  • Profiler__::print_profile
• Question about memory profiling
  • No known available tools
  • ObjectSpace — roll your own
  • DT: modified new to add a timestamp to every Object to add a timestamp to allow searching for super-stale objects
• Exploring how objects are interacted with
  • Slide 329
  • Undef all of the methods on an object and then see what errors occur

JRuby

• Java garbage collection
• Hotspot
• Java threads (native)
• rake war:standalone:create
• IronRuby promises Ruby in the browser

Distributed Programming

• DRb (Me: cake)
• Rinda (Me: been there done that)
  • UDP broadcasts
• Custom Protocol Implementation
  • Transport mechanism
  • Encoding mechanism
• GServer
• NetSSH
• Slide 396 for Multicast in Ruby
  • IPs 224.0.0.0 to 239.255.255.255 are multicast reserved addresses
• Slide 398 shows a simple proc running on a WEBRick server: 7 lines of code.
• Rack
  • Sits on top of any web server and provides a WEBRick-like API
• open-uri
  • rest-open-uri — patches open-uri to support other HTTP methods

I suspect that my less enthusiastic response to this class vice the Rails class has more to do with my significantly greater experience with Ruby the language than Rails the framework.

That said, I am still finding this class worthwhile to fill in the gaps in my understanding of Ruby to date.

Notes after the jump.

Ruby Object Model

NOTE: Parts of this portion of the class were presented to NoVaRUG in April by DT.

• self is the only way to access member variables.
• Changing self is key to Ruby
  • On a method call
  • self gets set to the receiver then the method is looked up
  • When defining a class
  • This is universal to all implementations of Ruby
• Methods are stored on classes, data in objects. (Me: Nothing new there but important to note for below)
• When defining a method on an instance of a class, Ruby creates an anonymous class (aka “singleton class”, “eigenclass”, “virtual class”, and “metaclass”) to contain the new method and has it inherit from the original parent class.
• If reader == Java.WEENIE
  • Ruby classes are executable code
  • Ruby classes are Ruby Objects
  • Me: Imagining your brain ’sploding.

Classes are executable code

puts "foo"


class Stuff
  puts “bar”
end

puts “blech”

… outputs:

  foo
  bar
  blech

Classes are objects

puts "foo"


class Stuff
  @v = 123
  def self.get_v
    @v
  end
end

puts Stuff.get_v
puts “bar”

… outputs:

  foo
  123
  bar

Matz says “don’t use @@ vars” and DT agrees.

• Instance variables looked up in self

• Methods looked up in self’s class

• Method definition is different than method lookup

  • def foo is defined in the current class
  • def obj.foo is defined in obj’s singleton class

And the lightbulb goes off over my head

So this idiom that I’ve seen Giles use in his code somewhere doesn’t hurt my brain anymore:

  something = "42"
  class << something
    def say_something
      puts self
    end
  end
  something.say_something

… will output 42. class << something changes the current Class to the singleton class of something.

Although the below example behaves the same way, it is less explicit in that it obscures what’s happening under the covers. The below example seems to define a method on something; it’s actually defining the method on something’s singleton class.

  something = "42"
  def something.say_something
    puts self
  end
  something.say_something

Intrestingly, clone copies a singleton class as well but dup doesn’t.

Cute but not hugely relevant:

  class Person < Struct.new(:name, :state)
    # do stuff
  end

… is legal — and a nifty way to save lines of code if you want to add methods to a Struct (or other expression that evals to a Class).

• include

  • Points this object’s singleton class to the referred to module
  • Does not copy methods from a module into a class
  • So modules are actually shared

• extend

  • includes into this object’s class’ singleton class.

Metaprogramming

• instance_eval
  • Changes self to the receiver of instance_eval
  • Me: Cheeky way to call private methods on objects

• class_eval

  • Changes self to the receiver (a class) of class_eval
  • WTF is the current class? Still not clear on this — and DT was getting confused too! Oy vey!

• “Top level” methods are defined on a singleton instance of Object

  • to_s is redefined here as well to return “main”
  • Slide 167 explains the toplevel environment (although you’re not really in instance_eval)

• Me: I actually found the Object Model discussion far more intense than playing with define_method — probably because I’m already pretty comfortable with meta/reflective programming from Java and having already used a fair bit of define_method and eval.

• DT: Use of method_missing involves two method calls so it’s a bit slower.

• initialize_copy
  • Define this to override the behavior of dup — to possibly provide a deep copy
• const_missing
  • Rails uses this to require files at runtime
  • const_getCan only call on one class at a time.

  class Foo
    class Bar
      class Blech
      end
    end
  end


c = self.class.constget “Foo”
  c = c.constget “Bar”
  c = c.const_get “Blech”

puts c
  # >> Foo::Bar::Blech

The below example was in the Rails class but makes even more sense today thanks to our discussions of include and extend:

Hooks

• included

Mixin a Module containing both instance methods and “class” methods

module Foo
  def self.included(klass)
    klass.extend ClassMethods
  end


def foo
    puts “foo”
  end

module ClassMethods
    def class_foo
      puts “class foo”
    end
  end
end

class Person
  include Foo
end

Person.new.foo
Person.class_foo

• inherited

• Explain why garbage collection in MRI ’sucks’ (Me: Certain individuals I know, who shall remain nameless, *cough*Toby DiPasquale*cough* have commented on this)

  • DT
  • Typically not a problem
  • However, if you have a LOT of loose objects (100s of thousands… try creating a String by concat’ing lots of Strings together).
    • Had a program that did this. Instead of concat’ing several times, accumulated the Strings in an Array and created it at the end
    • Performance went from two minutes to one second
  • JRuby uses the JVM garbage collector (GOOD)
  • Rubinius is better
  • 1.9 is better

… make it fast

• CF rant about maintainability. No argument here.
• benchmark.rb
  • Benchmark#bmbm (great name) does a rehersal run first and then a real run
• For socket code
  • Socket::do_not_reverse_lookup = true
• YAML
  • YAML#dump == slow

• update_page in Rails

  • Calling in more than 15 times for a single page will cause a noticeable slowdown

• ObjectSpace

  • Iterate through objects and ue Marshal#dump to determine amount of memory taken up by a certain class

• To speed things up

  • C (and other) extensions
  • DL (dynamic linking) — link a library at runtime and use it directly
  • Requires mapping C function calls (and structs if used) to Ruby objects
    • Slide 115-6

• Some lecture on good ol’ fashioned CS: O(n), O(n^2), and avoiding stupid loops

  • Wow, DT cites Sedgewick (Me: I learned wth Corman)
• Now CF is talking about eager loading and caching as a way of optimizing runtime.
• This afternoon just seems like… common sense programming/software engineering/computer science that every student in here ought to have.
• “Memoization”
  • Caching values of expensive operations for later re-use
  • There are some gems/libraries out there to keep code cleaner
  • Basically just the use of the ||= idiom

Exercise Playing with memoization Fibonacci to run super-fast

Library Organization

• Discussion of setup.rb and RubyGems
• Having written a few gems and installed who knows how many, this section of the class is mind-numbing
  • Dr. Nic’s NewGem gem essentially obviates much of this section of the class. Just use NewGem, write your own little gem, play with it, and that will teach you plenty.

Review of the day: Morning session was excellent and intense. This afternoon has been theory. As of 3:45pm, it hasn’t felt so “advanced”.

Blocks, Procs, and Closures

• “Brace” form of block always associates it self with the nearest method call. Not true of do ... end
• break
  • break takes an optional parameter — which becomes the return value of the block.
  • So it’s behaving like a typical Proc return value except we’re jumping the call stack
  • Freaky that we’re all getting so bent out of shape on like the first slide or two of the real content.
• next
  • Just return from the block early
  • Similarly, has an optional parameter that is the return value of the Proc
• redo
  • Me: I’ve never used it
  • DT: Used it maybe 3 times in 8 yars of Ruby
• Ooooh, I have softcopy of all of the code samples from the class (but almost certainly can’t redistribute, sorry)
• retry
  • Ok, didn’t know this one…
  • Like redo except that it reevaluates the CALL to the proc so the below example could be implemented with retry

  i = 0
  loop_until i == 3 do
    i += 1
  end

… because retry will reevaluate the loop_write call which reevaluates the i < 3 call. And this is getting removed from Ruby 1.9 (but will still be available for exception handling)

Hrmph. Blocks aren’t Procs in MRI unless you pass a & on the param to the method.
DT: There are two kinds of Proc objects differentiated by a hidden flag

• Using lambda, behaves like an anonymous method
• Using Proc.new, get an object that behaves like an inline block
• proc changed from an alias to lambda to

• Me: Glad that I’ve always just used lambda

• Bindings

  • Ruby stack frames point to Binding objects
  • Me: Used in the common Ruby implementations under the cover?
  • DT: They must
• Closures
  • Whenever a block is creating, it automatically gets a Binding to the current stackframe
  • Me: So that’s how we get closures. Cool. Follows like 1 + 2 = 3
  • Blocks need the local Binding in order to be able to implement loop constructs
  • CF: Multiple calls to binding return different wrappers to the stack frame’s Binding — so they can’t be compared at runtime.
  • Methods are not closures

We were given a fun little exercise to write a counter method using a Proc. Below is my Java-ish solution initializing a counter to nil.

def counter(start = 0, increment = 1)
  count = nil
  lambda {
    count += increment if count
    count ||= start
  }
end

c = counter(10, 2)
p c.call
p c.call
p c.call

My neighbor today, Jimmy Baker, tried something that I liked. He passed a added a third parameter on the counter method and used that instead of defining a local variable in the method impl. I thought this was cute because the arguments to the method are also part of the Binding and so could save another line of code.

Ruby Internals

• Ruby C extensions are running in the same runtime
  • So ParseTree, for instance, can walk the parse tree
  • Me: I’ve read about ParseTree (and Ruby2Ruby). Cool stuff.
• Now we’re poking a little through Ruby 1.8.6’s parse.y (written in yacc) looking at the definition of stmt and compstmt. Uf da!
• eval.c
  • eval_node is how Ruby walks it’s internal parsed tree of instructions

Design in a Dynamic Language

• DT: ranting about OO programming really being about classes and not objects.
• Experienced Ruby programmers prefer composition and rarely use inheritance
  • Me: At least I’m on the right track
• Long argument about whether inheritance hierarchies (and static typing) are all that necessary.
• DT: Cites how infrequently Java developers run into ClassCastExceptions when extracting Objects from collections (zero or one times per year) and how this problem was “fixed” with Java 1.5.
• CF: Interesting minimalist view of the advantage of composition over inheritance: you only implement the methods that you need and can avoid exposing those that you don’t.
• DT: Forwardable in std lib
  • Declarative delegation, i.e., def_delegator :@member, :member_method, :exposed_method is clearer than:

  def exposedmethod
    @member.membermethod
  end

• Logical delegation via method_missing (simple stuff)
• Duck typing
• DT gave an example of prototype-based programming in Ruby: defining Objects and having Objects inherit from other Objects by use of clone
• CF: Why never to use kind_of?: because objects can have methods remove at runtime just as easily as they can be added; it’s more important to know if an object can respond_to? a particular message.
  • Knew this already but I love this explanation.
• CF: Points out how the Martin Fowler Refactoring book really turned him on to OO with “Handle Conditions with Polymorphism”. With Ruby, just reopen the class, add different impls to each possible object with the same method name, remove the conditional, and just invoke the method outright in the code.
• Mixins
  • Look for “-able” descriptions (i.e., Loggable, Enumerable, Printable, etc.) and sometimes “-ing”
  • CF on splitting methods up: When I have comments in a method, that’s a big hint
  • Me: Yup. And, wow, do I see a lot of code like that (No, I usually didn’t write it!)
  • Minimize interaction between Mixin and including class — otherwise coupling the including Class to the Mixin

Messin’ With Types

• to_x conversion methods just make a “best guess”
• Coercion
  • Not supposed to be lossy
  • DT: Representation of one type in another type
• Symbol.to_proc
• coerce
  • DT: You’ll probably never need it
  • DT: Good example of double-dispatch

“Homework”

• Use coerce to write 1 + “123″ to return 124

And the results in order are:

1. AJAX
2. File Uploads
3. Perf & Scalability
4. Deployment
5. AR with unsupported DBs
6. Debugging

Notes after the jump:

AJAX & RJS

• Motherhood and apple pie describing RJS, Prototype, and Script.aculo.us at a high level
• DT: Believes that fewer web developers (well, he said “Rails”) are trying to emlate desktop applications with AJAX
  • Me: Or those few that are do a better job? (i.e., Meebo)

ruby -e "self.javascript_guru?"
=> false

• Hopefully this doesn’t surprise anyone (again, motherhood and apple pie here) but: RJS generates JavaScript server side and sends the JS back to Prototype which evals the generated JavaScript which updates the DOM.
• For custom JS:
  • page << "raw javascript here" and it concatenates the JS in order with the other calls to page.
• Interesting to me: the “Old Way” involves generating DOM IDs in the calling view and the RJS — been there done that
  • In Rails 2.0: the “simply_helpful” plugin provides a div_for and tag_for that generate the IDs for you. Sweet!
  • From the audience: JRails is a plugin that monkey-patches Rails to support JQuery. From toying with JQuery a little, I <3 it.
• page.select takes a CSS selector and generates appropriate GS

  page.select("div.queston").each do |q|
    q.visual_effect ....
  end

• I dig it.
• DT: Refactor into a helper if you’re going to reuse this (yup yup)
  • page[:an_element].reload seeks out a partial “_an_element.erb” and updates the element
  • update_page { |p| p.alert("Hello!") } just generates a String
  • Can be called from controller, helper, or view
  • CF: puts his RJS in the controller! His RJS code tends to be very short. If you’re doing more than that, then you’re probably making a busy page. (This is a handy take away)

Example:

  render :update do |page|
    page[:foo].your_rjs_operation
  end

• To ‘easily’ support AJAX and synchronous:

  respond_to do |format|
    format.html { do something }  # handles text/html http requests
    format.js                     # causes lookup of RJS if making an AJAX request
  end

• CF: Can call update_page as often as you want unlike render
  • Makes it easy to mix JS, HTML, and Ruby in the view — but could get ugly
  • So write helpers to be called via link_to_function (Slide 205 and 206)

• Audience remark: Testing a page that can respond to text/html and a JS request seems as though it can be brittle/hard to test

  • CF: Yes, it’s harder to test a site that does AJAX than one that does not
  • DT: Triple good point!: With AJAX, you have to consider how friendly your website is to screen readers. I hope that my current colleagues are reading this….

• Writing your own RJS extensions:

  • The JS generators uses method_missing so page.lightbox.dosomething would invoke Lightbox.dosomething in JS.
  • Be careful of the page size resulting from all of the code generated into the HTML

break

File Uploads

• Two basic solutions:

  • attachment_fu plugin
  • paperclip
  • Biggest recipe in the Advanced Recipes book and freely available on the book site

• Topics interesting to audience

  • Performance (my question)
  • Custom Mongrel handler
    • CF: Should be about 10 lines of code
    • MC: Code should be out there somewhere
  • Merb (obvious solution but thicker than it used to be?) — started as a custom Mongrel handler
  • Multiple concurrent uploads (also of interest)
  • Me: See Ezra’s talk on this
  • Progress bars

• attachment_fu (yes, I’ve never used it. Shoot me.)

  • In events_final web app:
  • User has a Portrait
  • Portrait has_attachment is monkey-patched into AR (See code sample in events_final)
  • Some columns in the DB are required by attachment_fu
    • parent_id
    • width
    • height
    • content_type
    • filename
    • thumbnail (can have several)
  • Interesting notion of creating a logical model (in that it is not represented by a table in the DB) “PortraitService” (crappy name) delegate to:
  • create a transaction to handle the tasks of:
    • destroying an existing portrait
    • assigning the portrait to a user
    • saving the portrait
  • handle updates to the portrait

• Little disappointed that the PragProg guys weren’t prepared to discuss custom Mongrel handlers due to Rails single-threaded limitation. Mentioned it to Chad as a future add for the course. Merb wouldn’t even exist if this wasn’t a severe limitation with Rails; Ezra started it as just a simple custom Mongrel handler.

• And, given my input, Chad is digging it into a little now.

  • mongrel_cluster.yml
  • config_script option allows specification of custom Mongrel handler

require 'mongrel'
class MyHandler < Mongrel::HttpHandler
  def process(req, res)
    res.start do |out|
      out.write something     # do something useful here
    end
  end
end


uri “/myuploadhandler”, MyHandler, :in_front => true

• And just post to the URI specified in the custom handler.
• This will run in a separate thread (which is the point)

Performance and Scaling

Really only have conceptual knowledge of this myself so the nitty gritty examples here were really handy.

• Key points
  • Measure performance often
  • Identify hotspots
  • Change one thing at a time
  • Iterate
• This jibes with Ezra’s remarks about performance optimization when he first started talking about custom Mongrel handlers and led into Merb.
• Corollary: Guessing at performance bottlenecks is a waste of time.
• MC quoting Ezra: “Post-mature optimizations are the cost of most hosting bills”
• Optimizing AR
  • Look at the log files
  • Obviously, AR-generated queries could be ugly — so look at log files early
  • DT: Requests/second is the most useless statistic in the log file
  • DT: AR makes life simple — and sometimes simple is stupid
  • Selective Columns
  • Custom finders:
    • Use the :select option to specify the columns to pull.
    • Pull the ID column to avoid possible silent DB failure (DB specific)
  • Preloading Child Rows
  • For N + 1 queries (i.e. has_many :line_items that may have products itself)
    • Use of :include => :product
    • MC mentioned yesterday, take care with use of :include
    • DT: Please, please, measure when using :include. It may not help performance.
    • MC: suggests having separate associations for explicitness (readability and performance)

  has_many line_items
  has_many line_items_with_products :include => product

• Assigning query results to a constant in an AR class that will load the results at startup and cache the results in the object model
  • Great for things that don’t change such as countries, states, etc.
• ActiveRecord Query Cache
  • Based in identical SQL
  • Cleared on CUD

  Event.cache do |e|
    e.find(1) # DB
    e.find(1) # Cache
    e.update
    e.find(1) # DB
  end

• Cache Store (Rails 2.1 — so still Edge)
  • API for configuring default store
    • Supports memory, file system, DRb (WTF?), memcache
    • So I ask: For memcache, this means a shared cache for a Mongrel cluster?
    • MC: yes
    • Sweet! (Yes, I loved Dude, Where’s My Car)

  store = ActionController::Base.cache_store
  store.write(key, value)


stuff = store.fetch(key) do
    ARClass.stuff(key)
  end

• Note that this is not just for ActiveRecord
• Allows for caching across requests
• Even more complex examples on slide 309

lunch

• Page Caching
  • Pages that don’t take any parameters
  • Pages that don’t change
  • Cron job for cleaning up cache
  • Can’t cache
    • Personalized pages, pages w/ params, pages w/ content changes, time-based content
      • Although, for the latter, you could cache and force a refresh by destroying the cache periodically…

class SomethingsController < ApplicationController
  caches_page :index, :show
end

• Fragment Caching
  • Cache small parts of templates
  • cache can be further parameterized to cache per user, etc.
  • Expiring specification is available in 2.1
    • But also via plugin: (see Karen Gillison)

  <% cache('some label') do -%>
    Your HTML goes here
  <% end -%>

• Expiring caches

  • expire_page
  • expire_action
  • expire_fragment

• Sweepers

  • For cleaning up caches
  • Observes models
  • Lifecycle actions on Sweeper get invoked when the lifecycle actions on the observed Model get invoked
  • Slide 319
  • In the controller, have to specify the Sweeper (see below)
  • To avoid having observers impact performance of transactions, put the expirey on a queue and operate on it later.
    • Me: If this were J2EE, shove it into a JMS queue — but J2EE…. ick.

DT: Complaining about the number of moving parts that are now being integrated into Rails: memcached, Starling, multiple Mongrels, Ferret, etc. Deployment is more painful than J2EE (Sadly, agree violently). Waiting for a backlash to occur at the complexity of it. Look at Twitter and how often it fails due to some SPOF (single point of failure). People writing many of the tools/plugins do not have enterprise experience and so are not taking external dependencies into account.

class MyController....
  cachesweeper :mysweeper
end

• Memcache

  • Basically an in-memory hash (that you do not always need to use depending on your app)
  • cache_fu at the model level
    • supports TTL
    • Probably less relevant as of Rails 2.1

• HTTP Performance

  • javascript_include_tag(:all, :cache => true)
    • Combines (and possibly compresses) JS files
  • ActionController:Base.asset_host = 'asssets%d.example.com'
    • Allows for federating assets across servers to avoid browser-limited number of connections per server
  • Yslow Firebug plugin (Andrew Willis mentioned this to me at lunch on Monday)
  • Tools
    • httperf
    • Siege
    • Profiler

• General Points

  • Don’t use file-based sessions
  • Don’t forget indices
  • Watch the log
  • Cache where useful

• DT: Consider adding some automated monitoring tools to determine when the system is beginning to perform badly

break

• Worth noting that AOL Photos uses Rails — if you’re looking for another example of a large company relying on Rails.

Deploying

• Deploy early
  • Me: It was personal development, but I was impatient to deploy the first (and only so far) time that I’ve used Capistrano. Better if I had tried to deploy earlier to forego that. Similar to TDD/BDD: makes the behavior less painful.
• How many Mongrels in a cluster?
  • MC: Varies but fewer than you think
• Question about not needing Mongrels
  • CF/DT: mod_rails — still in beta
  • Ruby processes that Apache comunicates with via *NIX sockets
  • Forking a process — so as some point out its similar to FastCGI
  • MC: There’s also Thin, Ezra’s work tying Rack and Rails together
• MC: They started by using Apache 2.2.x
  • mod_rewrite
  • mod_proxy_balancer
• Nginx
  • Small memory footprint
  • Easier to configure than Apache
  • MC: unless you have a damn good reason, pick Nginx (I need to use this beast — been hearing about it for over a year…)
• “Heartbeat”
  • Custom Mongrel handler excellent for this

Metaprogramming Rails

• How to write “magic” (ha!) such as belongs_to
• “Is there a way to track down the file where a modification was made to a class?”
  • DT: Cause it to raise an error. Otherwise, no.
  • OUCH
• DT whips up a little example showing how Rails implements Numeric.kilobytes

class Numeric
  def kilobytes
    self * 1024
  end
end

• Of course, ActiveSupport just includes a definition that does something similar.
• Question: does it speed up start up time to cherry pick what you want to load?
  • DT: It’s pretty trivial to load active_support in the grand scheme of loading Rails
• DT describing how a class definition is executable code (recap of NoVaRUG presentation from April)
  • Just reopening ActiveRecord::Base and adding class methods. Waiting for the Adv Ruby class.
  • More simple metaprogramming examples. Goofing off while waiting for the harder core stuff.
• They should’ve called this section ‘Ruby eye for the PHP guy’. Boooooring……
  • But, in the meantime, I have Markdown working in WordPress now. Yay.
• Ok, ok, the “lib” directory in Rails is in the LOAD_PATH. Not a huge surprise but there ya go.
• Adding methods dynamically at the class level
  • DT is describing the use of Object#extend. Honestly, I haven’t used that in anger before; I’ve always been a class << self; do_stuff; send guy. But, yeah, definitely simpler if you just want to add methods to the singleton object on a Class.
• Decent question: What if you have a module with both class and instance methods?
  • Don’t use Object#extend (makes sense)
  • Have to use Module#include
  • In the implementing Module, Rails will look for a method called included that contains the methods that should be put in the class.

Module Foo
  def self.include(base)
    base.extend(ClassMethods)
  end


module ClassMethods
    def methodthatwillbeaclassmethod_shortly
    end
  end
end

• Where the hell is Module#included called from?
  • Awesome question: Why is foo.__send__ :include, module used in some places instead of include module?
• Because the former doesn’t cause a class to load if it isn’t already loaded. Fucking cool! If only it was a little more obvious…

Break

• DT: “Kernel#eval is the work of the devil.”
• Didn’t realize: Kernel#eval accepts an optional Binding (Kernel#binding)…
• DT is giving some examples of Bindings. Surprised that this came up in a Rails class.
  • And just as I was starting to ask “What’s the difference between Bindings and Continuations?” (other than having a stack…), DT mentions that a “Continuation is a Binding on steroids” and will be discussed in the Adv Ruby Studio later this week. Bring on the pain!
• And now Object#instance_eval
• DT is giving a nice simple example of closures:

def twice
  yield
  yield
end

name = "Evan"
twice do
  puts "Hello #{name}"
end

• name is defined outside the block before twice is invoked. The yield call is evaluating name based on it’s definition at the time of the twice call.

Another example:

def hello(name)
  lambda {
    puts "hello #{name}"
  }
end


c = hello “Evan”
c.call

name is out of scope at the time of the call but name is stil referenced by the block’s Binding.

And….

  def hello(name)
    count = 0
    lambda {
      puts "Hello, #{name} with count #{count}"
      count += 1
    }
  end

  c = hello "Evan"

  c.call
  c.call
  c.call
  c.call
  c.call

…returns:

  Hello, Evan with count 0
  Hello, Evan with count 1
  Hello, Evan with count 2
  Hello, Evan with count 3
  Hello, Evan with count 4

… because count is referenced by the block’s Binding

DT mentions later: blocks are evaluated only when they are called

• Module#define_method

Take 1:

  def definer
    def hello
      puts "I've defined a method inside of the execution of another method"
    end
  end


definer
  hello

Or the better way of doing it…

  class Definer
    def self.define
      define_method(:hello) do
        puts "I've defined a method inside of the execution of another method"
      end
    end
  end


Definer.define
  Definer.new.hello

The above example invokes Module#define_method inside of a class because it’s a Module method; you can’t access it unless you’re inside of a Module (or Class because Class extends Module).

And here we use a closure within the example:

  class Definer
    def self.define(name)
      define_method(name) do |p|
        puts "I've defined a method called #{name} that was passed an arg #{p}"
      end
    end
  end

  Definer.define("hello")
  d = Definer.new
  d.hello "Evan"
  d.hello "Spock"

Nifty. The string that we’re writing gets evaluated when hello is called.

DT says “I use define_method all over the place”. Ok, ok, no more Object#eval for me. “This is a closer to God way of doing Ruby duplication”. Nice.

Note to self: Slide 129 in the slide package has the Module#define_method example.

DT: Ruby is slower than most scripting languages because (1) it’s not written for speed and (2) it’s completely OO and classes are open. DT: The overhead of definemethod versus def is “microscopic”. Question: When would you use definemethod? It’s a little different than code generation. * Will be discussed more in the Adv Ruby Studio (GOOD!)

Lunch

ActiveRecord

• Joining Models
  • Discussing notion of creating relational objects to handle a many-to-many
  • has_many :through on both sides (simple-ish stuff so far)
  • Simple example of Magazine with Readers joined via Subscriptions.
  • Note to self: Slide 137
  • Question: “Is there anything forcing you to “has many :through” on both sides of a relationship?
  • Honest question but nope. Although the DB may expose a bi-directional relationship, the code doesn’t have to represent it.
  • Worth noting: adding a Magazine to the Reader will automatically create a Subscription because of the has_many :through
  • Most people in the room aren’t using HABTM often
  • Join Model or HABTM?
  • Users and Groups
  • Attendees and Events
  • None of the above sell me on HABTM
  • Products and Tags
    • Tagging?
  • Products and Related Products
    • HABTM? Maybe….
  • HABTM if there isn’t a good name? I don’t know… I shun HABTM. Besides, there’s almost always qualitative and/or quantitive information that’s associated with the relationship. That warrants a join model.
  • CF mentions using :include => [:registrations => :event] to eager load all of the events assocaited with each registration
  • MC believes that the use of :include generally causes more problems than it solves
  • Self-referential HABTM
  • Example with Person and having friends
  • FUGLY (sixs hash entries to supply to HABTM to add and remove bidirectional relationships automatically — see slide 141)
  • I suggested a Join Model approach with Friendship
  • DT: enforced bi-directional relationships should be maintained by triggers.
    • In the context where the data may persist indefinitely (i.e., enterprise), enforcing the data constraints exclusively within the application is nonsense.
    • No one in the class pointed this one out. I know that I, for one, lose sight of this.
  • DT, MC, and CF: Don’t put raw finds in your controller. Tightly couples controller to model implementation. BAD.
    
    • Good sense if you want to possibly swap out ORM implementations — which is quite possile if you’re using ActiveRecord.
  • CF: Shows the Friendship example which is better but still doesn’t let the DB be responsible for the relationship.
    • MC example:

class Person
  has_many :friendships, :dependent => :destroy

will call destroy on the the Friendship when the Person object is destroyed.

  * Again, triggers would handle it better....

* Polymorphic Associations

class Person < ActiveRecord::Base
  has_many :addresses, :as => :addressable
end


class Company < ActiveRecord::Base
  has_many :addresses, :as => :addressable
en

class Address < ActiveRecord::Base
  belongs_to :addressable, :polymorphic => true
end

• The addresses table then needs “addressableid” and “addressabletype” columns to indicate which row in which table (persons or companies) is related.
• I’ve used these before and, really, polymorphic associations, in Rails, hurt!
  
  • I hate them.
• Someone else mentions single table inheritance as an option. I’m not keen on that either but it is far less ugly than PA.

• CF: If you use PA, you have to index the type field because you’re going to be querying it often.

  • Single-Table Inheritance
• When you want to have an AR object inherit from another
• Type field in the DB which contains the constant name of the type
• Has all shared and distinct fields must be in the table
• MC: Your STI table can get very wide if the classes in the family have little commonality…
• CF: if you change the class name, you have to update the DB
• CF: Ideally, prefer composition over inheritance
  • STI makes a strong case for composition — because STI can get very ugly…
• CF: Don’t use a column called “type” in AR — ever; bizarre-ass error messages.

break

Refactorings

• Starting with an example controller action with a couple of raw finds
• Interesting use of a code block on the AssociationProxy.
  • Below example seems reasonable if this query (i.e., recent) is only valuable on this relationship

  has_many :visits do
    def recent(limit = 5)
      find(:all, ...)
    end
  end

• Someone just pointed out that this doesn’t return an AssociationProxy (see here and find “proxy”)
  • For example, it’s easy to believe that event.registrations is an Array (if both represent AR::Base objects)
  • It even says it’s an Array when you call event.registrations.class
  • Calling event.registrations.ancestors reveals more
  • It’s actually an AssociationProxy
  • See AR association_proxy.rb
    • Delegates everything to method_missing and from there to a wrapped target
  • To extend an AssociationProxy with a module (in the example, called RecentFinder):

class User < ActiveRecord::Base
  has_many :vists, :extend => RecentFinder
end

… which makes the former code sample, where we define a method to the AssociationProxy, much cleaner.

Active Record Scoping

• ActiveRecord::Base#with_scope creates a block where all contained finder calls on the class use the specified scope
  • Slides 154 and 155 — want to review this more later
• Named Associations

  has_many :registrations
  
  has_many :preregistrations,
           :class_name => "Registration"
           :conditions => "pre_register is true"

• These are cached (slightly evil that this is implicit — but a handy feature)
• So a cool use is to nest scopes to and conditions together (but this isn’t cached — could suck performance wise for complex access control)
  • How many queries would we be performing? One per scope?
  • __Nested calls to withscope accumulate a single SQL query_ so could be super awesome for complex access control (depending upon the SQL)
    • To be useful, this would have to be FAST!
• Slides 159-160 lend themselves awesomely to access control (except need to know how to mark the cache dirty to force a refresh)

break

Custom Form Builders

• Delegating the markup generation cleans up form code
• FormHelper#form_for takes a :builder argument.
• Subclass of ActionView::Helpers::FormBuilder
• When we call formfor :builder => MyBuilder, formfor yields with an instance of our builder as the argument.
• Slide 177 contains the sample code for a simple LabelFormBuilder that dynamically generates methods that overrides much of the behavior o the DefaultFormBuilder but with our custom implementation.
  • That’s it. Unless I need a form with a lot of unique formatting (which I can’t see happening often), I’m writing a customer FormBuilder.
• MC/CF: I asked how often these guys write custom FormBuilders.
  • Both use a custom FormBuilder in every project; they just may get someone who generates better UIs than they do to write it.
  • Unless I need a form with bizarre/unusual formatting, I’m going to be using one of these in the future.
• They also suggest writing a helper to wrap form_for to factor out the :builder option.

• ActionView:Base.defaultformbuilder=: Go assign your own default.

• content_for

  • Page-specific content
  • JS
  • CSS includes
  • Contributing content (HTML) to the layout or any other template.
  • Smacks a little of goto…. so mighty but take care!