Nick Sieger

House for Sale

Posted by Nick Sieger Mon, 07 Aug 2006 22:02:00 GMT

When we moved into our modest home 6 years ago we thought we were done moving. Flannery’s aunt, who has been working on her new business as an independent realtor, encouraged us to see what else was out there, so we started looking about two months ago. Originally I thought we’d just be getting an idea of what was on the market, but soon we became pretty wrapped up in the idea of moving.

Just two weeks ago today, we found a house in a great neighborhood that just felt like home to us, so suddenly we’re talking about selling! 10 days later, last Thursday, our current house went on the market. Whew! Getting the house ready for sale in 10 days is not something I thought was possible!

So, if you know anyone in Minneapolis in search of a well-kept, charming, early 20th century house with access to parks and the light rail, please call Rebecca at 612-703-8975.

Here’s the MLS entry page, here’s the craigslist post, and below are some photos for your perusal. Now back to your usual programming!

no comments | no trackbacks

Why does an array index start at 0, not 1

Posted by Nick Sieger Thu, 27 Jul 2006 14:57:00 GMT

If you were looking for an answer to this question, you apparently cannot get a straight one in the java forums. Just one of many choice quotes:

Anyway, any logically counting would start at 0.

I tried that once. I referred to my son as “Number Zero Son”. Got a definitely negative response.

Posted in random, qotd, java | 5 comments | no trackbacks

My version of MetaRails

Posted by Nick Sieger Wed, 26 Jul 2006 19:42:00 GMT

I gave my own version of a talk on MetaRails based on Stuart Holloway’s talk at RailsConf at the Ruby Users of Minnesota meeting last night. It was originally planned to be a regurgitation/sharing session, but since Stuart’s slides broke pretty badly shortly after he gave the talk, I created my own slides, which are available for download. I did pilfer some of Stuart’s content, specifically the theme/example tables, which I especially liked for their concise summary of various patterns you can see in the Rails codebase.

The slides aren’t quite as interesting without my narration, but maybe some of the pretty pictures in it will help with understanding singleton classes.

The first part of the talk did a slow buildup of the need for singleton classes in Ruby. I tried to do this by showing first the language syntax for doing various simple operations (e.g., defining classes and methods), followed by an equivalent programmatic approach to the same.

I’m pretty happy with how the talk went, but if I were to develop it further, I’d probably try to find a way to deepen the connections between the introductory material and uses of those in the Rails codebase. As it stands, the slides show several neat examples of metaprogramming in Rails along the same lines as what Stuart presented at RailsConf.

Thanks to Stuart for a great talk, and I hope you get some use out of my variation on the subject!

Posted in ruby, rails | Tags metarails | no comments | no trackbacks

Metaprogramming Pattern No. 1: Self-specialize

Posted by Nick Sieger Tue, 11 Jul 2006 03:48:00 GMT

One of the biggest aspects of Ruby that I’ve been digging are the metaprogramming facilities, many of which draw from the “code as data” philosophy that comes from Lisp. Metaprogramming has become somewhat of a buzzword in the Ruby community, about as popular as “domain specific language” in terms of its presence in the titles of conference presentations and the like.

So it seems to me that, while a good many smart people are talking and writing about metaprogramming, that we haven’t yet started cataloguing all the different techniques in a shareable way. Is it time to start writing a catalog of metaprogramming patterns? Or do I risk being taken to trial for attempting to unveil the rubyist’s magic tricks?

No, what I am really looking for is the metaprogramming ubiquitous language. Ruby has a lot of language-level features that facilitate metaprogramming, but without a strong jargon to describe what’s going on. Sorry, but module_eval, instance_eval, metaclass vs. singleton class vs. eigenclass, method_missing etc. just don’t cut it. So here’s a first shot at re-invigorating the conversation and taking it to the “HNL” (‘hole nuther level). So herewith begins Metaprogramming Pattern No. 1: Self-specialize.

Why is this one number 1? No reason, pretty arbitrary. I haven’t taken the time to document any more yet. This will be an ongoing project for me.

Self-specialize

You have an algorithm or a “method object” that you wish to make flexible by parameterizing with additional code and/or data that isn’t known at the time you wrote the original class definition.

Therefore, write a method that redefines itself in the singleton class of the currently instantiated object, then re-sends the message to the customized method. In a way, this is simply memoizing the method body itself as a speed-up.

Trivial example:

class Foo
  def initialize(p)
    @prefix = p
  end

  def result(val)
    specialize_result
    result val # send the message again
  end

  private
  def specialize_result
    method_decl = "def result(val); "#{@prefix}: #{val}"; end"
    instance_eval method_decl, "generated code (#{__FILE__}:#{__LINE__})"
  end
end

f = Foo.new("foo")
f.result("hi") # => "foo: hi"
g = Foo.new("bar")
g.result("hi") # => "bar: hi"

Why would you do this rather than writing the logic into the original method? It’s hard to justify use of the technique in the example above. But it could be used to DRY up tedious, redundant code that for performance reasons you would prefer to have inlined rather than invoking an additional instance method.

OK, so honestly I can’t come up with a decent reason to do this yet; I haven’t done enough metaprogramming to have had the need for it. Still, it seems like a nifty enough trick and maybe it will come in handy for you. This does show you just how dynamic Ruby’s method resolution is, that you can suddenly define and call a different method implementation inside of the method itself!

This technique was spotted in the rewritten routes implementation for Rails 1.2 (currently on the trunk) -- see the #write_generate and #write_recognize methods.

Update: Good timing. _why just posted much more succinct description of the same phenomenon, with better examples.

Posted in ruby, rails | Tags metaprogramming, pattern | no comments | no trackbacks

RailsConf Wrapup

Posted by Nick Sieger Thu, 29 Jun 2006 17:02:00 GMT

RailsConf has been over for three four days, and I’m just now flushing out my wrap-up? Better late than...whatever.

Keynotes

All the keynotes were exceptionally good. I had heard Paul Graham speak at OSCON last year so while the theme of his new talk was good, the controversy wasn’t that controversial to me.

Taking notes during keynote sessions is tough! With the exception of Dave Thomas, all the keynotes were in the evening, just when you’re ready to kick back with a beer (which we did on Saturday night during David’s talk). After a day full of sessions, your brain’s done and the best you can do is osmosis, or wait for the video! That said, here are a couple of points and quotes I managed to snag.

Martin Fowler’s talk

• Rails does things a lot differently than many of the frameworks that were trying to become fashionable in enterprise application design
• Opinionated software -- Rails does not claim to be the right framework for everything
• Even if Rails doesn’t succeed or become ubiquitous, it has made an impact on the way applications are designed and built.
• If you do something quick, it has to be dirty, and if you do something well, it has to take a long time. Rails breaks this dichotomy -- quick doesn’t have to be dirty.
• Iterations and cycle time -- the faster a feature gets into production, the more engaged the customer is in future cycles. It introduces a conversational style of software development.
• “I’m not saying Ruby is that much better than Python, it just suited me more.”
• “This conference is a failure, really, because if Rails had succeeded it would be so simple that there would be nothing to talk about.”

David’s talk

David’s talk was subtitled “How I Learned to Stop Worrying and Love the CRUD” (slides now online). During the talk David describes the thought process he arrived at while attempting to boil down most operations in a Rails app to the simplest possible level of Create, Read, Update, and Delete. The table below illustrates the thinking:

But! CRUD is not a goal, it’s an aspiration, a design technique (quoted from the slides). I was reminded greatly of Eric Evans’ superb book Domain Driven Design as David implorded us to model relationships, events, and closures in addition to tangible nouns, as this makes relationship-building a CRUD operation as well. Adding a User to a Group is made simpler by simply creating a Membership rather than hanging additional non-CRUD operations off of both User and Group, which makes for DRY-er code as well.

As others have remarked, we need better jargon for CRUD.

Add to the conversation the newly unveiled ActiveResource, and suddenly Rails is an exciting integration platform!

Others

• Stu Halloway’s MetaRails talk was a well-paced progression through some of the metaprogramming techniques, and hurt the brain less that Bill Katz’s talk. Stu mentioned how he runs the presentation slides in a Rails app that pulls snippets directly from the Rails codebase. Except now it appears that it will be broken without some intervention now that the Reloadable module has gone away.
• Duncan’s talk on deployment introduced a not necessarily new, but great metaphor of the web as pipe and why we should kick our FCGI habit.

Summary

• There is a lot of energy to be harnessed in the Rails community. This thing is just getting started.
• There are a ton of smart people working out the few remaining kinks in Rails. Deployment is about to get ten times easier.
• Mongrel is a mad pup. Don’t mess with him.
• Rails will soon be a killer service platform. There are going to be Rails apps deployed all over the place that will be well integrated through REST interfaces while all the SOA people still argue about what SOA means.

Posted in ruby, rails | Tags railsconf | no comments | no trackbacks

RailsConf: Mike Pence - Laszlo on Rails

Posted by Nick Sieger Wed, 28 Jun 2006 15:00:00 GMT

Mike Pence, professional web surfer, and Java free since March 15, talked about Sex, drugs, rock and roll or Laszlo on Rails.

Where are we going on the web?

• Google Maps, Yahoo Music Engine, Google Spreadsheets -- the web is looking more and more like a desktop application.
• “Web two oh” -- attention to design and more attractive interfaces
• User customization a.k.a. “Pimp my site”
• Use of rich media on the web, e.g., YouTube. It’s an expectation of the next generation of users that the web will be content-rich and an entertainment experience.
• The Holy Grail! Applications that require no downloads, are instant/automatically updated, are distributed.

Open Laszlo

• Pandora cited as an introductory example
• Mike gave a 10 minute overview of Laszlo using the Open Laszlo Explorer.
• Laszlo explorer shows you standard widgetry -- canvas, text, buttons, windows, forms
• The power of Laszlo starts to show with data sets, with convenient data binding utilities, an extensible object model, and a declarative style. Mike showed 10 lines of code with a checkbox that controlled the visibility of a window, without having to attach an event handler to the checkbox.
• http://www.openlaszlo.org/ has the 10 minute overview (explorer) and many other demos including LZPIX, which Mike demoed.
• The newest version of Laszlo has DHTML support that allows a flash app to be served as DHTML instead, with little difference. Laszlo gives you the power of one runtime that rises above browser incompatibilities.

Laszlo on Rails

• Install # install laszlo gem install ropenlaszlo rails laszlo-app && cd laszlo-app ./script/plugin install svn://rubyforge.org/var/svn/laszlo-plugin/tags/openlaszlo
• More info at http://laszlo-plugin.rubyforge.org/

Pros & Cons

• Pro: Rich possibilities
  • Blogbox -- cross-site window
  • Publish and subscribe for chat and collaboration, event-driven updates
• Pro: deep API
• Pro: in-browser development, like Seaside
• Con: Consumes resources
• Con: Accessibility, printability and searchability are not its strengths
• Con: mature, yet requires experimentation
• Con: performance can be an issue, especially on some older platforms

Store it away -- Laszlo is a promising technology, it’s free and open source it’s here today, and it appears to be getting good at serving standards-based interfaces. When combined with Rails’ increasing support for RESTian interfaces, the task of building compatible, dynamic applications should only get easier.

Posted in ruby, rails | Tags railsconf | no comments | no trackbacks

ActiveRecord JDBC adapter as Rails plugin

Posted by Nick Sieger Mon, 26 Jun 2006 17:53:00 GMT

I’ve got things set up in my svn repo such that you pull down my ActiveRecord JDBC adapter as a Rails plugin. Although it appears that using ‘script/plugin’ inside of JRuby may have some issues. So for now, use C Ruby. Inside your Rails app, do:

ruby script/plugin install http://svn.caldersphere.net/svn/main/activerecord-jdbc/trunk/activerecord_jdbc/

This should pull down and configure the JDBC adapter for you with no additional setup. If it doesn’t, let me know and we’ll work through it. I haven’t yet tried running a Rails app inside of JRuby yet but I hope to in the next couple of days.

I am also starting to investigate testing with another database, hsqldb. I think the driver could benefit from attempting to use some additional databases, if we’re ever going to fulfill the promise of leveraging any JDBC data source, and also I think it would be cool to use an embedded database in the spirit of SQLite which has become popular with smaller Rails apps in C Ruby-based Rails land.

Update: it turns out you can’t easily install a new ActiveRecord adapter as a Rails plugin at this point with out some extra finagling, because of the way Rails::Initializer initializes the database before any of the plugins. For now, I’ve got the plugin set up to re-initialize all of the ActiveRecord infrastructure, so in order to use the JDBC adapter plugin, you’ll need to add the following to your config/environment.rb. Note that you’re not “skipping” ActiveRecord, just initializing it later.

  # Skip frameworks you're not going to use
  config.frameworks -= [:active_record]

Posted in ruby, rails, java | 3 comments | no trackbacks

RailsConf: Ezra Zygmuntowicz - Rails Deployment

Posted by Nick Sieger Sat, 24 Jun 2006 19:18:00 GMT

Ezra: Programming in Ruby for 3 years, Rails for 2. Just another Ruby hacker, he says. Right!

Yakima Herald

• http://yakimaherald.com -- Local newspaper website
• CMS
• Lots of non-SQL content
• Classified and obituary workflow
• Internal credit card transaction

Data Aggregation

• Mysql
• XML feeds from AP
• RSS and Atom feeds from parent newspaper
• Proprietary database for articles
  • Yucky Vendorscript
  • Crusty OS 9 server!
  • Wrote DSL to emit script over a socket to remote machine

Deployment

• Apache? Seems to be the industry standard...

class ApacheWithFCGI < ActiveRecord::Base
  has_many :random_500_errors
end

• Lighttpd
  • Better FCGI support
  • More stable
• Switched to standalone, external FCGIs with capistrano spinner/spawner/reaper tasks, and finally got stable.

Tuning

• Cache, cache, cache
• Got RAM?
• Hot spot/profiling/benchmarking
• Use httperf not ab
• See Zed Shaw’s rant on statistics (Programmers Need To Learn Statistics Or I Will Kill Them All)

Shared hosting

• Apache with ProxyPass/ProxyPassReverse talking to multiple lighty instances is about as good as it gets.
• But let’s face it...shared hosting + Rails suck.
• Only as reliable as the worst application on the server
• Not always good neighbors
• Resource constraints
• Free-for-all

Ezra recommends a Xen VPS for Rails deployment. I’ve followed his advice; this blog is hosted on a Xen VPS at http://rimuhosting.com.

Deployment models

• Starting point, web, app and db on the same server.
• Next, move database to a separate server. Use the more powerful hardware to the db.
• Third, split each role to a separate server. But now you need an NFS to serve static and cached contents. Ezra states you can go a long way with this setup

class FutureOfRailsDeployment < ActiveRecord::Base
  belongs_to :mongrel
end

Mongrel

• Speaks plain old HTTP, so you can take advantage of existing tools for load balancing, proxying or caching
• You can use frontends: Pound, Pen, Balance, Haproxy, Lighttpd (although mod_proxy needs to be fixed), or Apache 2.2 modproxybalancer
• Mongrel cluster gem allows easy management of multiple mongrel processes. It’s straightforward to integrate with capistrano too.

Engine Yard

Ezra describes a new hosting service he’s been working on that will give you a greatly simplified but powerful and performant hosting environment for your Rails applications, including a web admin console and deployment directly from SVN revisions and tags.

Go to Engine Yard for a beta signup email now!

BackgroundDrb

• Distributed Ruby server that manages long runnng tasks.
• Uses a MiddleMan proxy/stub class that allows the Rails process to connect to the background server.
• Can use it as a worker queue, (e.g. for sending email) or as a distributed memory cache.
• You can even query for progress on the background workers and push the result all the way to the browser with an ajax progress bar.
• The code for BackgroundDrb looks really clean! Go to http://backgroundrb.rubyforge.org/ for the nitty gritty.

Posted in ruby, rails | Tags railsconf | no comments | no trackbacks

RailsConf: Bill Katz - Metaprogramming Writertopia

Posted by Nick Sieger Sat, 24 Jun 2006 17:27:00 GMT

Bill Katz took a code-focused approach to explaining metaprogramming and DSLs.

Resources

• http://www.writertopia.com/developers has an authorization plugin used in writertopia, which is the main focus of this talk.
• http://www.simbiome.org and https://wimtk.org/svn/simbiome contain code for physics based simulation resources.

Bill applies Paul Graham’s quote on bottom-up design and lisp as justification for using Ruby to program DSLs.

Authorization plugin

In search of a better authorization scheme, Bill wanted an elegant syntax using blocks to delineate sections of code that require specific permissions, and a more intuitive way of managing the data surrounding access controls.

current_user.has_role? "moderator"
current_user.has_role? "member", workshop
workshop.accepts_role? "member", user

current_user.is_moderator_of workshop
user.is_eligible_for? campbell_award

Implementing permit

class MeetingController < ApplicationController
  permit "rubyists and wanna_be_rubyists", :except => :public_text

We need a class method. Where to put it? How does this work? (Insert pretty diagram of instance, singleton class and superclass here.) Metaclassees are “anonymous”, you don’t see them by looking at class ancestors.

ActionController::Base.send(:include, Authorization::Base)
ActionView::Base.send(:include, Authorization::Base::ControllerInstanceMethods)

Singleton methods from the point of view of the object are the same as instance methods in the metaclass. See slides on “How do we permit?” for details. Bill chose to tuck the DSL-related methods into modules and used self.included, class_eval and other goodies to set up the methods in the correct places. There is more than way to do this but I suspect Bill chose to do it for purposes of cleanly separating concerns along the lines of where in the class hierarchy the methods live.

ActiveRecord::Base.send(:include,
  Authorization::ObjectRolesTable::UserExtensions,
  Authorization::ObjectRolesTable::ModelExtensions)

This loads an acts_as_authorizable plugin which, when used in a model, inserts an accepts_role family of methods for querying and setting user roles.

Bill blazed through a whole lot of pretty-looking code here for how to set up the DSL infrastructure. You’ll have to go over to the writertopia developer link to see it. Bill has said he’ll post his slides online as well.

Questions

• Use of method_missing -- does that clash with ActiveRecord::Base usage of method_missing? No, as long as you use super to invoke the next method in the chain, you’re ok. Ruby module inclusion semantics handle this for you.
• How to insert the class methods? A discussion started around ActionController::Base.send(:include, ...) and There is More Than One Way to Do It.

ActionController::Base.send(:include, Authorization::Base)

class ActionController::Base; include Authorization::Base; end

ActionController::Base.class_eval { include Authorization::Base }

• Question about the class inheritance chain. There are actually two inheritance chains, one for the classes and one for the metaclasses. Resolution at method invocation time travels first to the object’s metaclass, then to the object’s class, then to the superclass of the singleton class, then the class’s superclass, etc. Blech, that makes no sense. Instead, go read Seeing Metaclasses Early.

Posted in ruby, rails | Tags railsconf | no comments | no trackbacks

RailsConf: Steven Hammond - DSLs and Rails Plugins

Posted by Nick Sieger Sat, 24 Jun 2006 16:18:00 GMT

Intro

Steven talks on the whats and whys of domain specific languages.

Steven’s background is is as a java developer and more recently, a project manager, or “sith lord” as he put it.

Some early exposure to DSLs for him involved the use of something called Program Composition Notation that was used to describe a weather modeling program to be run on massively-parallel supercomputers.

Features of DSLs

• Usually a partial programming language focused on a single problem domain.
• Replicate syntax/structure that is common to users of that domain.
• Tries to be as elegant, concise and expressive as possible in that domain.

Horizontal vs. Vertical

• Horizontal -- programming problems (e.g., Rails migrations)
• Vertical -- business domain problems (e.g., a game DSL, insurance product definition, circuit board specification)

Recipe example

Steve contrasted a procedural, C-style recipe vs. a Ruby-based DSL that used blocks to delineate ingredients from procedures. The differentiating point was “which one could your mom translate into meatloaf”? I suppose neither if you don’t like your mom’s meatloaf.

Rails DSLs

• The framework itself (“is the whale shark a fish?”)
• Migrations
• RJS templates
• Plugins
  • acts_as_state_machine
  • RESTful Rails
  • game_dsl

When to create a DSL

• established syntax or vertical domain
• soemthing that’s inelegant in normal imperative or object-oriented style
• abstract implementation details so that you don’t depend on them (e.g., migrations does this for database DDL)
• reuse

DSLs and Reuse

• “Reuse is vastly overrated” -- DHH in 1/2006
  • Business logic is very application specific and is difficult to reuse across projects
  • Level of reuse is at a lower lever where there is an information barrier to understanding the component (e.g., LINPACK)

Designing a DSL

• Be careful to balance forward-looking with extraction. In other words, DSLs should be extracted or driven by need just like anything else.
• Layout a domain syntax (not necessarily in Ruby)
• Extract and evolve over time
• Translate business requirements/statements into succinct programming fragments. (e.g., rolling dice and assigning attributes)

# extending Integer to deal with die-rolling
3.d6
3.d6 :keep_best => 3

# Deck-dealing example
class Tile < AciveRecord::Base
  acts_as_deck
end

class Player < ActiveRecord::Base
  acts_as_player
end

class DeckController < ApplicationController
  def deal_cards
    @deck = Tile.find :all
    @deck.shuffle
    @card = @deck.draw
    @deck.deal :cards => 6, :to => @players
  end
end

There was a discussion at this point about whether it was necessary to use a DSL in this case, and Obie Fernandez piped in that if you’re aiming for reuse or as an API, DSLs give a readable, understandable representation that makes reuse and sharing easier.

Another comment was regarding namespace collisions, and Steven replied honestly that there is not a good answer. If you combine a game-playing DSL with a home-building DSL, are you randomizing your porch?

YAML provides another good medium for succinct data layout (e.g., database.yml). Steven’s example followed the same pattern to apply to selecting different sources for a random number generator.

Pitfalls

• DSLs should not necessarily be the first solution -- the domain could be too narrow or too broad.
• Too many DSLs (or even plugin bloat) could end up compromising the readability of the code. Namespacing comes in here. Which DSL/plugin provided the given functionality?
• Interaction side-effects -- it’s not clear how mixing metaphors can make the solution clearer.
• Vertical DSLs additionally suffer from the problem that it’s still programming, and there are syntax issues to overcome, even though the DSL can faciliate interactions with the customer.

A comment came from Aslak Hellesoy about the use of external DSLs (i.e., built using parser generators). Steven replied that it is appropriate in some cases, but the complexity will be higher.

It seems to me that in the case of external DSLs, the freedom (lack of constraints) can actually be a burden. You can design syntax however you want but you need to be sure that it makes sense to the people who will be using it. Unless you’re really good with language and interface design it can be easy to create a custom, niche language that nobody knows anything about and is inflexible. In my experience it’s hard to use parser generators like yacc to build flexible parsers. Ruby turns out to be really good for DSLs because you can omit details (parentheses and hash curly braces) and it still does what you want.

Posted in ruby, rails | Tags railsconf | no comments | no trackbacks