ThoughtWorker Blogs

On Saturday I attended the Hong Kong BarCamp.  This was the first Barcamp I have attended and it blew me away.  Here were 200-odd people, brought together on their own volition to share and learn.  On-line communities are easy to subscribe to, requiring minimal effort to participate.  Being physically present requires more commitment and effort.  The content, as typical of Barcamps, was generally technical.  It asks the question, is there something inherently social and altruistic about being a geek?  Do other industry horizontals have such a rich picking of community events?  Could there be an accountancy barcamp, or a marketing barcamp?  And what about the verticals?  Could there be a banking barcamp? And what about collaboration on projects for the common good?  Geeks get together to opensource.  When will the (to pick on a vertical) accountants get together to build an opensource offering?  

Ola Bini gets it right, as usual, in Evil Hook Methods?, but I think you can actually take the idea a bit further.DataMapper allows you to gain it's methods simply by an include statement.class Category include DataMapper::Resource # ...endOla points out that the include method should not add class methods. At least, that's not what it was designed to do. Include should (by way of append_features) add the constants, methods, and module variables of this module to the class or module that called include.The problem for me is: Should DataMapper add it's methods to your class when you use Ruby methods as they were originally intended, or when you use DataMapper's Domain Specific Language (DSL).If DataMapper is a framework and should be used traditionally then you should add it's methods in the following way.class Category include DataMapper::Resource extend DataMapper::Resource::ClassMethods # ...endHowever, you can't blame DataMapper for following the pattern that's been around since long before DataMapper. At this point I would consider the trick to definitely be an idiom even if it is an anti-pattern. The reality is that include has been stolen by those that prefer the simplest possible Domain Specific Language for adding their behavior.Martin Fowler describes how a framework can have a traditional API as well as a thin veneer that allows you to use the framework in a more fluent way.Unfortunately, in the Ruby world we've designed our veneer in a way that doesn't allow for traditional usage.The other day I noticed something that I thought was equally interesting in the Java world. I was working on a test that used JMock and IntelliJ formatted my code as shown below. 1 class PublisherTest extends TestCase { 2 Mockery mockery = new Mockery(); 3 4 public void testNamesAreAnnoying() { 5 final Subscriber subscriber = context.mock(Subscriber.class); 6 7 mockery.checking(new Expectations() { 8 { 9 one (subscriber).receive(message); 10 } 11 }); 12 13 // ... 14 } 15 }Unimpressed by lines 8 and 10, I changed the code to look like the following snippet.class PublisherTest extends TestCase { Mockery mockery = new Mockery(); public void testNamesAreAnnoying() { final Subscriber subscriber = context.mock(Subscriber.class); mockery.checking(new Expectations() {{ one (subscriber).receive(message); }}); // ... }}Mike Ward said I shouldn't do that because the IntelliJ formatting properly shows an initializer for an anonymous class. Which is absolutely correct, but I don't want an anonymous class with an initializer, I want to use JMock's DSL for defining expectations. And, while the second version might not highlight how those expectations are set, that's not what I care about. When I write the code I want to create expectations in the easiest way possible, and when I read the code I want the fact that they are expectations to be obvious. I don't think removing lines 8 and 10 reduces readability, in fact it may improve it. Truthfully, I don't care what tricks JMock uses to define it's DSL (okay, within reason), I only care that the result is the most readable option possible.Back to DataMapper, I believe there's a superior option that allows them to have both a clean DSL and a traditional API. The following code would allow you to add methods as Ola desires (traditionally) and it would allow you to get everything with one method invocation for those that prefer DSL syntax.class Object def data_mapper_resource include DataMapper::Resource extend DataMapper::Resource::ClassMethods endendclass Category include DataMapper::Resource extend DataMapper::Resource::ClassMethods # ...endclass Entry data_mapper_resource # ...endThe obvious drawback is if everyone starts adding methods to Object we may start to see method collision madness. Of course, if the method names are given decent names it shouldn't be an issue. It's not likely that someone else is going to want to define a method named data_mapper_resource.Don't worry. For those of you who prefer complexity "just in case", I have a solution for you also.module DataMapper; endmodule DataMapper::Resource def self.instance_behaviors DataMapper::Resource::InstanceMethods end def self.class_behaviors DataMapper::Resource::ClassMethods endendmodule DataMapper::Resource::InstanceMethods def instance_method "instance method" endendmodule DataMapper::Resource::ClassMethods def class_method "class method" endendclass Object def become(mod) include mod.instance_behaviors extend mod.class_behaviors endendclass Category include DataMapper::Resource::InstanceMethods extend DataMapper::Resource::ClassMethods # ...endclass Entry become DataMapper::ResourceendEntry.class_method # => "class method"Entry.new.instance_method # => "instance method"Category.class_method # => "class method"Category.new.instance_method # => "instance method"© Jay Fields - www.jayfields.com

The problem isn't intelligence; the problem is initiative. I know this because I can't really systematically destroy people's intelligence but I can systematically destroy their initiative.

While checking out at the hotel I ran into Coby from confreaks.com They are recording the conference so you'll be able to see the talks online sometime soon. They're not cheap, but their videos are very good (they capture the output of the presenters computer and display it side by side with video of the presentation -- you seriously need to check out their site), and they offer a discount if the conference is willing to CreativeCommons license the talks.

Starting off the morning was "Ruby: A Year of Innovation" with Gregg Pollack & Jason Seifer. They had a lot to cover so it went pretty fast. I tried to keep up as best I could.

Jason Seifer was up first:

• HPricot - awesome for scraping websites
• Juggernaut - server push with rails -- keeps a connection open
• Ambition - write your SQL statements in Ruby
• Prawn - Ruby based PDF generation
• Capistrano
• Ruby VMs
• roo - spreadsheets Excel, google docs
• Dtrace and Ruby -- memory stack live
• Skynet - map reduce for Ruby
• Data Fabric - easily shard your db with rails
• Merb - the non-opinionated framework
• Mack - Framework
• Sinatra - good for restful
• Webby - good for static websites
• Shoes - dsl for gui apps
• Hackety Hack - coding for kids

Gregg Pollack took over and talked about:

• Redmine - Trac replacement in Rails
• Pool Party - cloud computing config and maintenance in Ruby
• Rad - robot control
• Adhearsion - Voip
• Rack - if you have a Ruby process you want to run on Mongrel, Thin, or whatever you just write one handler for Rack.
• Phusion Passenger - servers up anything that supports Rack (including Rails)
• Github - source control where you can see what others have done with your code and merge it back in without the modifier having to submit a patch (as they often forget)
• make_resourceful and resource_controller - are two ways to puts resource handling in your controller
• Starling - lightweight reliable message passing
• EventMachine - Executes processes in one thread instead of trying to slice everything up. Works great for short tasks.
• NeverBlock - can run SQL in parallel
• Screencasts - Railscasts, PeepCode, PragProgrammers, EnvyCast

"Using jQuery with Ruby Web Frameworks" with Yehuda Katz

Yehuda used screwunit (a BDD javascript test framework) to BDD an implementation of a live updater in JQuery (which is an alternate Javascript framework). He had trouble with getting his tests to fail (some sort of caching problem). That's rough in front of a 100 people. JQuery and screwunit look interesting, but I found it hard to focus on what he was doing ignore the difficulties of getting specs to pass. He finished his presentation with a declaration that you should never attempt to do a live coding presentation.


I thought it might be nice to step out of my comfort zone and take a look at "Resource-Driven Web Development With Waves" presented by Dan Yoder. Alternate title: "When Functional Programming Meets HTTP"

So, why use waves? Well, you can have more control over your app, use functional programming, and be very RESTful. Waves has Functor as much of its processing. It helps matching requests to response actions. You can have some pretty spare code that defines a bunch of restful paths.

Things that don't fit anyone else:

• I heard that there's such a thing as Chicken Fried Bacon. Where the hell has this been all my life?
• Joe O'Brien's wife likes to say "Holy wow"
• It was freezing in the conference center and 97 degrees outside. This is very Texas.
• There was this clearing throat guy who would loudly clear his throat during every presentation. It totally caught me off guard when I was talking as I thought I had just said something terribly stupid. After my talk I noticed all the other presenters had the same reaction.
• Where are all the ThoughtWorkers? I saw lots of ex-ThoughtWorkers but no current ones. All the cool kids must have gone to Rails Conf Europe, I suppose.

And now for Lunch. Which is Chicken fried Chicken.

Via Clarke Ching,

There's a Harvard Business Review article where Ed Catmull, president of Pixar, talks about how things work at Pixar:

Talent is rare. Management’s job is not to prevent risk but to build the capability to recover when failures occur. It must be safe to tell the truth.

An entry at the Web Form Design book blog points to a thread at the IxDA discussion forum about whether to use an explicit "optional" or a more subtle visual indicator in a web form:

That said, we recently did similar prototype testing on several search forms with a mixture of required and optional fields. On the team we were split on the best approach, so we tried to distinct methods: one with optional spelled out, the other with those fields having a different visual indicator. Though the sample size was limited, the "Optional" won hands-down. Remarkably, some participants even commented on how much they liked that it said "optional right there".


I know our UI team was not thrilled, but it was extremely advantageous to spell it out rather than use an icon or other visual indicators.

Utility comes first... and then after a few other things, take a look at appearance.

(or the second day if you count the tutorials)

To start things off Jim Freeze got up and announced that there are 282 attendees and seats for 280 -- So make friends. The the first talk of the day was "The Next Ruby" by Bruce Williams and he (of course) discussed the difference between Ruby 1.8.6 and 1.9

Bruce recommended a good test suite if you're planning to move to 1.9 and I have to agree. Tests are good for lots of reasons (including design) but they pay for themselves 100 times over when you need to do a big tech migration.

Because of changes to string, anything string heavy (such as parsers) is gonna need some love. On the plus side:
"ruby"[0] => 114 in Ruby 1.8.6
"ruby"[0] => "r" in Ruby 1.9
Yep, I've been burned by that and I'm glad to see sanity carry the day.

In other news:

• Hash.select now returns a hash
• Hashes will maintain order
• :this === "this" #true
• Because of Multinationalization Strings now have each_chr or each_line not each (gotta support those Japanese, Chinese, etc. characters)
• Threads are moving to native threading model
• Fibers introduced: lightweight user threads (Check out NeverBlock)

But there's a Huge Problem:
There exists a monstrous pile of unmaintained gems out there that everyone uses which need to be migrated to 1.9. So how are we going to get there? Bruce didn't have any solutions. Last night at dinner Dave Thomas suggested that Rails will need to have some sort of killer feature that relies on Ruby 1.9 to get people to switch. He might just be right.


The next talk was "Hidden Gems" by James Edward Gray II and it featured lots of Battlestar Galactica photos whilst James talked about some of his favorite underused Ruby Gems.

NArray is high on his list because it borrows C's numbers for speed. He had an array, used for an image, which was taking a few seconds to compute. When he switched to NArray he got hundredth of a second times. Nice.

James also likes SQLite for data processing. It's surprisingly fast to load a bunch of data into SQLite and then use db power to search and process said data. You can even run it in-memory for even faster results.

And of course he talked about Rinda. Rinda is a fairly easy way to farm your tasks out to many different computers. And we all like more power.


Rein Henrichs then talked about "Ruby Best Practice Patterns." He started out with a talk about how to De-factor your code for increased job security. Pretty funny stuff. He did some line by line examples of how to make code worse (example: use Pig Latin to name your methods). Then he segued into his real talk about how to write good Ruby code. His main point seemed to be that patterns are not just huge things that define architecture, they are an everyday practice. I totally agree with that and it's kinda of cool that I get to follow his talk. I sort of pick up where he left off.

Then was lunch and a bunch of me getting nervous while looking over my slides. I had already given my talk in front of two different small groups of programmers, so I felt pretty good about it in the rational part of my brain. However, I had been scheduled to talk in the big room on the same stage Matz himself would later occupy -- which is a bit of pressure. About a half hour before my talk I ran into Gregg Pollack and he shot a video of me summing up my presentation in 30 seconds. I was a bit keyed up so I have no idea how that came out. But now I get to be a part of his "#{whatever} Conference in #{some} minutes" series -- a series I really enjoy. A few minutes before I was to get up and talk I heard some guys right next to me talking about how they were gonna ditch this metrics talk to go hear about javascript. Damn their black hearts.

I was pretty keyed up and the body mic was behaving weirdly, but I settled in after a few slides and I feel it went fairly well.


Next up in the main room was "Care and Feeding of Ruby Developers" by Steve Sanderson.
Steve comes from old school programming culture so this talk started off with some observations on these crazy young developers:

• Aesthetics matter
• Collaboration is important
• Physical location is not that important (I disagree)
• The doing is close to the planning
• Programmer as Stars
• Maybe you give away the code, but that doesn't mean you don't make money

And his advice for businesses employing Ruby devs was:

• Be out there in the community
• Empower the developers to make changes or at least have access to those who can make changes
• Plan for people who blend technical and aesthetics

After that I headed over to the alternate room for "Creating Desktop Applications With Ruby on Mac OS X" by Brian Cooke

He started out by extolling the virtues of Cocoa. He loves and wants to marry Cocoa because it lets you create commercial grade apps without a ton of training. Then he talked about using Xcode and Interface Builder with Ruby Cocoa. Ruby Cocoa is a way to write slick looking Macish apps without having to learn Objective C. However the syntax looks a bit unlike Ruby because it has to be converted into Objective C.

It's hard for me to follow these presentations about Interface Builder because the Object-Cish syntax gets in the way. Also the drag and drop stuff kinda freaks me out. To wire up a button you drag a blue cube somewhere, tell it what class to use, then you drag a blue line to somewhere else. Does that skeeve anyone else out?

He used the Faker gem to generate fake names. I saw Gregg use it in his ActiveRecord talk and I like the idea of having real-looking data in my tests. I'll have to check that out.

Brian finished up by saying you really need to learn Objective-C because Ruby Cocoa is not fast, its files are available to anyone who gets the app, and debugging is no good.

Huh.

He then went on to say that MacRuby is going to be much better because it's Ruby in the OSX runtime (kinda like JRuby). So you should get all the benefits of writing in Objective-C. When will it be out? No one knows 'cause Apple is writing it and they're all about the secrets.


Hey did I mention there was a "green room" for speakers? And that when I went in there no one yelled at me and told me to get out? Excellent. Also they had Coke Zero instead of the oppressive ice tea or water choices everywhere else. Although I do have to say that the food was pretty good. Excellent even, if you consider that it was conference food. I just don't like ice tea.

I returned to the main room for "Ruby in the Cloud" by Mike Subelsky:
Mike had his start-up running on a single server when he realized he was running out of space. Faced with the choice of more servers, managed hosting, or the new and exciting "cloud" of EC2 he chose the cloud. Mike claims that it only took a few hours to build the server images and then only 20 minutes to migrate the code to be able to run all cloudy style. In case you don't know, EC2 is a service offered by Amazon that lets you rent servers by the hour. You create a virtual image and fire one up as needed. They can bust at any time, and won't be repaired, so plan for redundancy. Why would anyone put up with that? Because it's crazy cheap and very scalable (Need more servers? Just fire up more and get a bill)

They made decision to use Ruby for all their server management. They used: Capistrano, Rufus-scheduler, God, FileUtils, Rush, Rake and a bunch of plain old ruby scripts.

Mike spent some time talking about how cool and readable rufus-scheduler can make your scheduling. Think of the last cron you wrote and compare it to this:

scheduler.every "10m10s" do
#stuff
end

Nice.

The big win of using Ruby everywhere is decreased context switching, leveraging of knowledge in Ruby, and OS portability.

Dinner was brisket. This would be the second night in a row I've had brisket. With any luck I can go 3 for 3.

The first keynote was given by Evan Phoenix and it was about memes in the Ruby community. Apparently, the Ruby community loves a good meme.

Dependency injection was a rash in 2004 caused by Java developers. DI wasn't needed, sez Evan, because of the very nature of Ruby (as you can define stuff as late as you like).

Another meme: What's this called:
class << self; self; end;
metaclass, singleton-class, or eigenclass?

Then he discussed the Singleton Pattern which he claimed was almost always a bad idea (more blaming of the Java folks for bring it up) and always bad for testing

Aspect Oriented Programming was a big topic for awhile. (He said that alias_method_chain is all the AOP you really need)

Evan discussed _why the lucky stiff as a meme. There's so many rumors about _why. Who is he and what he does he do when he's not dropping off excellent Ruby code in the middle of the night?

"Chunky Bacon" is a meme in its own right.

Here's a somewhat exhaustive list of other memes he talked about:

• Zed Shaw
• git
• Ruby is too slow
• Macintoshes
• TextMate
• Rails can't scale
• Pixaxe
• Ruby CPAN
• rubygems vs rpa
• ARGV parsers
• DSLs
• BDD
• RSpec Backlash
• Metaprogramming is cool

Evan's take on all this was that the Ruby community loves to have fun. It's a very light on its feet community. This can scare a lot of enterprisey people, but he finds it awesome.


The second keynote of the night was given by Matz on Ruby's "Past, present, future"

I always find it hard to sum up Matz's presentations. They are funny, inspirational, and touching in a way that doesn't lend it self to summary. You come away with the feeling that this man really wants to write a language that will make you a happier person.

Topics he discussed include:

• Why Ruby is simple, but not too simple (or Ruby vs Lisp)
• Interpreters
• 1.9 features
• 2.0 notions
• The primary goal of Ruby is to enjoy programming

Then he graciously answered questions for 30 minutes. And got a standing ovation.

First, I'd to extend a big thanks to Joe and Jim for giving me a ride to the conference today.

The two tutorials I decided to attend today were:
"The Advanced ActiveRecord Workshop" with Gregg Pollack & Jason Seifer (the Rails Envy Guys) and "The Ins and Outs of Ruby I/O" with James Edward Gray II and Gregory Brown. Both of which were excellent.

The Advanced ActiveRecord Workshop covered:

• Loading large data sets (the 'ar-extensions' gem helps lots).
• A gentle reminder to properly index your freakin' database.
• How Rails optimizes multiple :includes in finds and how that goes to hell if you combine lots of :includes with :conditions
• The super awesome Named Scopes (which you need to look up right now, if you haven't already because it's not just about defining custom finders -- it's about defining custom finders that you can chain together and get optimized queries)
• Polymorphic Associations, Single Table Inheritance, Dirty Fields, Association Proxies, Callbacks, and creating AR plugins.

I was really impressed by the smoothness of their presentation. It was a great balance of funny/informative/challenges. The challenges were a good way to make the audience think about what had just been presented. If I had one criticism it would be that the later challenges seemed too hard for the time allowed. I found that if I made one stupid mistake (which I then had to track down) I would not finish by the time they gave out the answers. I suspect they were rushing to finish on time. Overall it was great stuff and they say that this talk was an elongated version of their recent EnvyCast on ActiveRecord so I would say that it is definitely worth your 9 bucks.

The Ins and Outs of Ruby I/O was also very informative. Since Ruby has such easy file IO it's easy to forget about the underlining structures and the problems that can crop up. Topics include:

• The most efficient way to read in a file (generally foreach)
• Random access inside a file
• Overcoming buffering problems with file.fsync || file.flush (fsync returns nil if it doesn't work)
• A resonably through regex explanation
• A compare and contrast of how to handle unicode on Ruby 1.8 vs Ruby 1.9
• How to use Marshall or Yaml to serialize your objects.

The talk was being video taped so I assume it will show up on confreaks which, btw, is my new favorite site. You can see the whole freakin Ruby Hoedown on there. And you really should check out Rick Bradley's "flog << Test.new" talk. He takes Flog, forks it into a new project called Flame, puts it under spec, and refactors it to be less complex (nice bit O' irony there).

Later we had some excellent Bar-B-Q at Rudy's and discussed how the hell the Ruby world is going to migrate from 1.8.x to 1.9. We had no good solutions. The Bar-B-Q was excellent, however, so we left in good spirits.

Tomorrow I'll be speaking at 1:30 on "Using Metrics to Take a Hard Look at Your Code" so I'm pretty excited as this will be the first mass presentation of this talk and I think its turned out nicely.

下面链接是我8月30日在Beijing Open Party的Session录像

http://v.ku6.com/special/show_2595040/CPZyfRwmkG6DlsPb.html

http://v.ku6.com/special/show_2595040/SiHN2uI2YAaTPkaI.html

The <enter time period> ends and a retrospective is held.  The team writes on Post-It notes things that are important to them and they get stuck up on the wall.  And maybe they get grouped into similar topics or themes.  And then the team vote on them; the topic that has the most votes is the one the group talks about first…. and they talk about that topic at length.  (If you were to analyse the signal to noise ratio of the first topic discussed compared with the last topic discussed, you’d find significantly more noise when you start).  Actions to resolve the issues are finally addressed and identified.  The team then move on to the next topic and so on until all the topics that had votes against them are done.  And it’s been a marathon session and we are done.

But what about the topics that no-one voted on?  What about the post-it that sits alone?  It was important enough for someone to have written it.  No votes, no priority,  no discussion, no action.  Yet mining it might have  delivered a diamond action.

I don’t care much for voting in retrospectives.  It’s not a particularly efficient way of doing things.  For one because the actual process of voting takes up valuable time.  Then by the time the issue with the fewest votes comes up, the energy in the room is drained and the discussion is rushed.  So why not do away with the voting, and introduce strict time management to the retrospective discussion.  Allow five minutes to each topic.  Use a stop watch to enforce this.  This will allow all the issues that were of importance to someone to be aired.  When the five minutes is up, if there is still heat in the discussion, park it and return to it later in the retrospective.  Such an approach is more incremental, and dare I say it, Lean.