Bruce Williams

Living without send(), or trying to

2009-03-13T00:00:00-07:00

Object#send (or __send__) is a scrappy little tool we Rubyists pull out to ever-so-casually ignore method private and protected visibility, and to call methods dynamically.

Maybe we’ve gotten into the habit of using it a little too often. Let’s play with alternatives.

An evaluation

Here’s an example from practically every monkeypatching Rails plugin init.rb you’ve ever seen:

SomeRailsConstant.send(:include, MagicSauce)

Okay, so include is a private method, and we’re breaking through indiscriminately by using send. If you wanted to do away with send because it seems weird, you might try something like this:

class SomeRailsConstant
  include MagicSauce
end

Seems nice and simple; basic Ruby, right? Yes. But if you do this in Rails, you’ll likely ensure the real SomeRailsConstant, provided by Rails, never gets loaded – since Rails autoloading is lazy. What you’ve done here isn’t to reopen the class; you’ve just defined it. Bad, bad. You need to try to use the constant to kick the autoloading into gear for you. Here’s another approach that does just that.

SomeRailsConstant.instance_eval { include MagicSauce }

What’s this instance_eval nonsense – and why is it named “instance?” Isn’t SomeRailsConstant a class? Yes, yes it is. Which also means it’s an instance of class Class. Neat (and confusing), right? You can see this easily in irb:

>> class MyClass
>> end
>> MyClass.class
=> Class

But, stepping away from the foibles of Ruby object hierarchy for a moment, let’s address this approach; instance_eval. This method allows you to temporarily change scope; it lets you get inside an object and call whatever you’d like.

Okay, that’s fine– but is instance_eval really better than send? No, probably not in the strictest sense. It’s even more typing. But to my purist brain, send is for calling methods dynamically – and I know exactly what I want. instance_eval is also more flexible, since I can do multiple operations in the block, access instance variables, etc… which means I get to use it more consistently. Consistency keeps code readable, even in the presence of insane metaprogramming.

I like instance_eval. I also like how it’s not a normal dictionary word that’s in common use. Want to call send on a Message instance? Get ready to use the lamer __send__ name, since the developer of Message quite reasonably appropriated the name for actual message sending. It’s exactly this kind of inconsistent application that drives me up the wall.

Okay, and next.

Method acting

So, we’ve gone down the road of glossary consistency for plain, non-dynamic invocations. Let’s go further. Here’s another send; this one for dynamic reasons.

1 # `format` is defined somewhere else. Example: 'pdf'
2 File.open("#{report.name}.#{format}", 'w') do |file|
3   file.write report.send("to_#{format}")
4 end

What are we really doing here? Let’s convert how the business part of line #3 reads into plain English:

Tell the report to “to_#{format}”

Does that sound right? Let’s try to make this sound clearer:

Invoke a method called “to_#{format}” on the report

There’s a simple way to put this into code:

report.method("to_#{format}").call

So, here we’re using the arcane Object#method method to get a Method instance. These suckers are flexible. You can reuse Method objects, pass them around, unbind and rebind their UnboundMethod counterparts, check their arity, see where they come from using to_s, and invoke them. That’s what we do with call. Simple.

Is this good practice? Maybe not. It’s certainly slower than send, invocation-to-invocation (though not greatly). It’s kind of fun, though, and maybe a bit easier to read & document.

class Report
  def formatter(name)
    method("to_#{name}")
  end
end

report = Report.new
report.formatter(:pdf).call

Do I use this frequently? No. But it’s a nice tool to have in the kit. Kind of functional, which always makes me happy.

Summary

I’m not telling you to stop using send. It’s a great little method that’s easy to grasp, simple to use, and rarely causes any problems. I’m just telling you to think about the rough edges a little. Don’t say yes just because you see it everywhere.

Just use it critically.

A GitHubby config.gem hack

2009-02-07T00:00:00-08:00

I love using gems from my Rails apps, and have been an outspoken proponent for gem plugins from the beginning (you won’t find any vendor/plugins in my newer apps at all).

I also love GitHub, but lines like this, over and over in my environment files, just annoy me:

config.gem 'username-foo', :lib => 'foo',
                           :source => 'http://gems.github.com'
config.gem 'username-bar', :lib => 'bar',
                           :source => 'http://gems.github.com'

So, here’s a quick little hack. It could be smarter, but it works.

module GitHubbyGems

  def gem(name, options = {})
    if options[:github]
      default_options = {:lib => name.split('-', 2).last,
                         :source => 'http://gems.github.com'}
      options = default_options.merge(options)
    end
    super(name, options)
  end

end

Rails::Initializer.run do |config|
  # ...
  config.extend GitHubbyGems
  config.gem 'haml'
  config.gem 'right_aws'
  config.gem 'thoughtbot-paperclip', :github => true
  config.gem 'mojombo-god', :github => true
  # ...
end

Enjoy.

Updates

James Bebbington likes an API that supports something like:

config.gem_source :github => 'http://gems.github.com'
config.gem 'foo', :source => :github

… and I agree that’s far less of a special-case hack.

Since what we really want to do is affect the configured Rails::Gem::Dependency (Configuration#gem just passes on the options to initialize one), that’s probably what we would really want to modify — and of course an old with_options-style approach would work, too.

Let’s keep in mind though, that in reality GitHub is a very special case (specifically, the gem naming scheme is), and since we’re talking about a handful of lines per configuration, it’s probably not worth it (write a text editor snippet instead, or just copy-paste).

But it’s a fun little hack.

A sleep hack

2009-01-09T00:00:00-08:00

A quick aside. I’m experimenting with the Everyman polyphasic sleep schedule for the next 3+ weeks.

Update: The experiment ended early, but was still very successful. Feel free to contact me if you’re interested in this sort of thing.

More on super-and-extend

2009-01-07T00:00:00-08:00

A few days ago I posted an article on method wrapping, and I thought I’d touch a bit more on the super-and-extend technique; I’ve had a few questions on it that warrant some clarification.

Multiple Wrappers

Yes, the technique works with multiple wrappers on a single class; when the class is extended with additional modules, they stack and super works as expected (wrappers are applied on the “outside,” so invocations occur in LIFO order).

You can see a full example of this as a Gist. Here is a sample irb session showing that the multiple wrappers are applied correctly:

>> (class << Widget; self; end).ancestors
=> [BazWrapper, BarWrapper, FooWrapper, Class,
    Module, Object, Kernel]
>> widget = Widget.new
>> (class << widget; self; end).ancestors
=> [BazWrapper::WrappingB, BazWrapper::WrappingA,
    BarWrapper::Wrapping, FooWrapper::Wrapping,
Widget, Object, Kernel]
>> widget.render_on(nil)
BazWrapper::WrappingB
BazWrapper::WrappingA
BarWrapper::Wrapping
FooWrapper::Wrapping
Original

Wrapped Class Inheritance

If you wrap a class, you wrap inherited classes as well, regardless of whether the classes were defined before or after the point the wrapping is applied.

Given the following class definitions and placement of the wrapping, all three

classes would be wrapped as expected.

class Widget
end

class WidgetSubclassDefinedBeforeWrapping < Widget
end

Widget.extend YourWrapperModule

class WidgetSubclassDefinedAfterWrapping < Widget
end

There’s no special sauce here, just the normal laws of inheritance.

The Vagaries of Overriding `new`

As Eric Anderson pointed out in comments, super-and-extend will not work if the new class method is defined on the wrapped class… but only if super isn’t called. It’s not all dire straights; here are the three scenarios for a wrapped class:

The class’ new method is not defined, and the wrapper works as expected. This is the normal case.
The class’ new method is defined, and super it used (ostensibly to reach Class#new for an instance… and our wrapper intercepts it first). Since we don’t care about the order that the wrapper’s new(just a hook to extend the instance) fires, the wrapper works as expected. This is an unusual case. For an example of the scenario, see this gist.
The class’ new method is defined, and does not call super (likely to block instantiation). In this case, the internal wrapping module must be applied manually to an instance.

Luckily, since you’re likely blocking instantiation to make use of the singleton pattern, the single instance may be easily accessed anyhow (conventionally, as ClassName.instance), and something like this may be enough:

ClassName.instance.extend(YourWrapper::InternalWrapping)

Keep in mind that defining new is generally considered verboten or at least in poor taste. Ask yourself if you actually need

to use a strict, enforced singleton pattern by sabotaging new; in my opinion it’s often an unnecessary formal constraint.

Wrapping a Method in Ruby

2009-01-03T00:00:00-08:00

Let’s say you have a Ruby class with a method you’d like to wrap—for debugging or performance timing—and, since you don’t control where the class is instantiated (think overriding a method in Rails’ ActionPack), just creating a subclass and using super isn’t going to work.

Let’s take a look at two mixin patterns; one a ubiquitous naming hack and one a bit of esoteric Ruby inheritance trickery.

First, let’s set the scene. Let’s say we have a method, Widget#render_on:

class Widget
  # Wrap this one
  def render_on(document, options = {})
    # ...
  end
  # ...
end

What we want is for each wrapper we write to call a method, which we’ll call snapshot, that will output some information about the method invocation. Don’t worry about the implementation too much here; it just takes a block and times the yield:

def snapshot
  start = Time.now
  result = yield
  # You could store these values somewhere
  # for averaging, track the caller, etc
  puts Time.now - start
end

So, we’re going to do this two ways…

Technique #1: `alias_method_chain`

ActiveSupport makes this easy. Though arguably a bit of a messy naming hack, it does the job and is a bit self-documenting, forcing you to name a feature. If you’re using Rails, this is happening all over the place.

module AliasMethodChainWrapper

  def self.included(base)
    base.send(:include, InstanceMethods)
    base.alias_method_chain :render_on, :wrapping
  end

  module InstanceMethods

    def render_on_with_wrapping(*args, &block)
      snapshot { render_on_without_wrapping(*args, &block) }
    end

  end

end

Now, let’s mix this baby in.

class Widget
  include AliasMethodChainWrapper
end

What happens when we do this?

In the included hook, AliasMethodChainWrapper::InstanceMethods is included into Widget (meaning Widget instances now have access to render_on_with_wrapping)

alias_method_chain aliases the original render_on to render_on_without_wrapping and aliases the just-added render_on_with_wrapping to render_on, overriding the original implementation.

Here’s an illustration of what the object hierarchy looks like, and how the method invocation works in this technique.

This allows you to call the original implementation of a method from your wrapper code, if desired (we do, invoking it inside a block that’s passed to snapshot for reporting).

You can see the API documentation for alias_method_chain here for more information. There’s plenty of examples of this common pattern in Rails plugins and the framework itself.

On we go to purer Ruby pastures.

Technique #2: super and extend

So now let’s talk a bit about a technique that relies on Ruby’s extend and super capabilities to simplify things a bit and get rid of the need for explicit naming. Here’s the wrapper in question:

module SuperExtendWrapper

  def new(*args, &block)
    super.extend Wrapping
  end

  module Wrapping

    def render_on(*args, &block)
      snapshot { super }
    end

  end

end

Okay, that’s a fair bit shorter, isn’t it? Deceptively simple. Now, let’s hook it into our Widget…

Widget.extend SuperExtendWrapper

So, we use Object#extend this time, which, according to ri, “Adds to the object the instance methods from each module given as a parameter.” How this happens is a bit tricky, and involves shoehorning the module into the instance’s metaclass — singleton class, if you prefer — ancestry. Let’s see how this happens with our wrapper.

Widget is extended with SuperExtendWrapper (which defines the new method). We can see that SuperExtendWrapper is now below Widget in the class metaclass using irb:

>> (class << Widget; self; end).ancestors
=> [SuperExtendWrapper, Class, Module, Object, Kernel]

What this means is we can use super to call the vanilla Class#new. Handy, since we need it to get an instance! We then immediately extend the instance with another module, SuperExtendWrapper::Wrapping, our real payload.

As you might guess, extending the Widget instance with SuperExtendWrapper::Wrapping gave us a similar hierarchy in the instance’s metaclass. Let’s take a peek:

>> widget = Widget.new >> (class << widget; self; end).ancestors
=> [SuperExtendWrapper::Wrapping, Widget, Object, Kernel]

This makes invoking the vanilla Widget#render_on just as easy as Class#new; it’s a mere super away. No naming hacks required. Here’s an illustration showing how the method invocation works using the super-and-extend technique.

Keep in mind we’ve only covered instance methods here; things get substantially more hairy using the super-and-extend approach to wrap class methods — whereas alias_method_chain tackles the problem fairly handily.

Performance Note

You may have noticed that the alias_method_chain magic only needs to be executed one time, whereas the super-and-extend trick needs to extend every instance.

The performance characteristics turn out to be a bit tricky here, considering—at least in MRI—while extend adds overhead, method invocation via super is a good bit snappier than calling arbitrary methods (ie, alias_method_chain’s with and without chaining).

What this means is that if you’re keeping an instance around and calling a wrapped method multiple times, it’s very easy to get better performance from super-and-extend than alias_method_chain, but if you’re instantiating a lot of single-use instances, results will be in alias_method_chain’s favor. Obviously we’re talking tiny performance differences stacking up in either case.

Revisiting Python

2008-12-26T00:00:00-08:00

I used to be an avid Pythonista. I poured over Python books, read huge swathes of Python code (including the source of Twisted, which, as its name might imply, I think of as quite a personal accomplishment), and soaked up as much material as I could find. I had survived the relative chaos of Perl, and was relieved to find a more orderly, seemingly sane language to work with. I dove in, and I loved it.

I learned a huge amount during those years; Python was my first OOP language, and cemented what has become my obsession with dynamic, “lightweight” languages. I’ve never studied CS formally (having opted for languages and linguistics instead) so Python’s more draconian rules and academic bent helped temper my more artistic tendencies and pushed me far enough into the land of algorithms, data structures, and big O notation so not to be seen as a complete dilettante by later CS nerd colleagues.

One day, I stumbled across a lone copy of Programming Ruby by chance at at bookstore (back when you just didn’t find Ruby books). At the time, I thought of Ruby as merely “a Japanese Perl,” so I only picked it up on a whim — but only a few chapters in, I was completely hooked.

Although I continued to use Python (and PHP) professionally for the next couple of years, and very successfully — I spent my spare time on Ruby, and became very active in the community. In 2004 I fully switched, and became a professional Ruby developer.

I haven’t looked back.

Okay, looking back

Recently I’ve had the need to do a proof-of-concept across multiple “production quality” OO languages, so it seemed only natural to dig back into Python a bit.

I discovered a language that had matured significantly with a smart community — that now included some “younger” blood and a fair bit of excitement.

So, some specifics, maybe?

First of all, let me add a disclaimer.

As I’ve stated, I haven’t touched the language in years, and I’m many a code kata from anywhere near full competency, let alone best-practices. The following may be completely unadulterated bullshit, and since it’s largely based on Python 2.6 vs 3.0, may be a bit outdated as well. I heartily welcome comments from people who care deeply about Python and can point out better ways to approach things, or simple flaws in my judgment.

Random feelings

So here you go, the bad in with the good.

Python feels clean. I know I’m writing something for a computer, and I seem to focus on the implementation vs the API first when coding Python. This is kind of satisfying. I’m not sure if this is good or bad.

I can’t help but love packages. Although they can be a horrific, academic mess (ie, Java), in many cases a file-based approach removes a lot of complexity. The Ruby community adheres to a lot of different ephemeral “standards” on how to split code between files, and it can be exhausting worrying about it— as a perfectionist I’m a constant fiddler, and worrying about how to split up a module is simply too trivial to be productive.

I love list comprehensions. Python has them, Ruby doesn’t. This still burns me. I blame Haskell for getting me addicted.

People tend to focus on little details like whitespace sensitivity when they complain about Python. Especially Rubyists — we tend to look on strict, seemingly “arbitrary” rules with a jaundiced eye — but this is a red herring in my opinion. A good developer is going to indent correctly and consistently anyway. If you don’t have a standard way of indenting your code— or if, God forfend, you use tabs— someone should shake the crap out of you.

But… I’m sorry, I love my end keyword. Lose it, and if you have to re-indent code manually it’s a serious pain in the ass. The fluttering, anchor-less statements of Python rely on a single colon to indicate an upcoming indentation, and that’s not enough for my poor eyes (I like a nice sturdy end to indicate the end of an indentation). It is a bit nice to lose an extra line every time, but I’ll happily refer to it as the Clarity Tax. Obviously this is a personal preference.

I love my blocks; the stunted lambda Python supports seems a pittance. I do think the new with keyword is an interesting approach towards “cleanup blocks” (eg, File.open), though they feel a bit like hidden magic and a bit hackish to implement. I know, I know, a Rubyist complaining about magic!

Stating what I think about explicit returns would be too explicit for this blog.

Python doesn’t feel “fluent” to me— in terms of flow, it’s the stuttering Tarzan of programming languages— staccato phrases, prolific underscores, colons and parenthesis galore. Granted, this is a matter of taste (and I happily code in Erlang, which is far worse), and it is a programming language, but I would consider Python far more functional (in the utility sense) than elegant.

Multiple inheritance is still more of a pain than it’s worth, super() is pretty lame, and the fact self still needs to be a parameter in method definitions makes me scratch my head in befuddlement.

Python threads are far better than Ruby 1.8 threads, plain and simple. They’re strict (you ask them politely to exit, on their own time) and competent.

setuptools is kind of cool, and eggs are also neat; Rubygems seems simpler and more cohesive, however.

Frankly, properties and generators are still a bit missing in my education; they’re not features that “pop out” or seem to be explained in clear terms. This is probably my failing, and may have prevented me from seeing Python in a clear light in some cases.

The Python executable being a REPL is just plain awesome. I still don’t know why IRB is separate from the Ruby executable (and don’t even try to read it, it’s a shark attack). My good friend David Black, even older Ruby salt than I, commiserated on this recently.

So, I think that’s enough for now. I’ve also been playing with Django a fair bit, so I may post something on it soon.

Updates

I’ve removed my previous statement on Pythonistas not finding closures useful, as it was confusing and seemed to indicate a lack of support in the language rather than discussions I’ve had with Python developers on their utility in day-to-day development. I’m aware Ruby developers complaining about missing language feature X in Python is probably as annoying as Python developers complaining about VM speed in Ruby, and based on just as outdated information. Python’s “lack of closures” is a common straw man, and I apologize for the confusion.

There seems to be a lot of contention on the tabs vs spaces comment. It’s a personal view, largely based on code portability (including copy and paste to a browser) and modern editors. Lots of people on either side of this issue; feel free to debate amongst yourselves.

I wasn’t overstating the fact Ruby developers complain about Python’s importance of whitespace. It’s often one of the first criticisms leveled against the language (and as I indicate above, a fairly petty one), and is easy to find on the web via google.

To add something else that I think is awesome about Python: docstrings. In comparison, Ruby’s tools-only approach (ie ri for retrieval and rdoc for generation) is pretty weak. It’s amazingly handy to access documentation via the console; wouldn’t it be neat if we could do something like the following in Ruby? It would make building new documentation tools (not to mention casual investigation) so much easier.

puts some_object.documentation # or `doc` or `__doc__`, etc

# For methods
puts some_object.method(:method_name).documentation

A note for commenters: whenever possible, please include code or references. I’m quite happy to own up to and add an update here if I’m wrong on a point, but I’d like references available for readers, especially if it’s a common misconception.

Front Row to History

2008-11-09T00:00:00-08:00

I had to tell this story several dozen times at RubyConf, so I thought I’d wrap it up for posterity.

It all started with an email. The campaign was running a contest entitled “Front Row to History,” and would select 5 first-time and 5 repeat donators to attend the rally in Chicago– what would later become a massive victory celebration.

I had donated to the campaign before and had, like many of you, become more and more fervent in my support of Obama as election day approached. I’m an independent voter, but my support was won after researching policies and watching the tone of the campaigns as they progressed.

So, I did a bit of early voting with my wallet. Again.

The Barack blog calleth

Halloween night was fantastic. I spent the evening with my wife, Melissa, and sons Braedyn and Jamis (Peter Pan and Captain Hook, respectively) in the Hyde Park neighborhood in Austin, guests of my generous boss, Steve Sanderson, and his lovely family. We had a blast; with well over a thousand kids and blocked- off roads, this was the place to be.

Then, unexpectedly, the Barack Obama blog called, wanting an interview. They had read the little blurb I had added on the donation form as a cathartic gesture, detailing my support in light of the fact I was an Arabic Linguist in the USAF for 6 years, before 9/11 and through the first couple years of the war. As they explained it, they were just looking for material for a blog entry. I expected a cross-section of donors would be detailed on the blog, and that in essence I would just be a part of a campaign funding post-mortem, or something equally mundane.

But something about the interview struck me: it was deep. It seemed like more than the material for a pedestrian blurb and picture. Did they really have the time to invest so much energy in a long list of interviews, mere days before the election?

I joked with my wife that maybe they needed to prep press decks ahead of time for “Front Row to History,” since they’d want to announce the winners as late as possible, but they’d need to gather the material for the release as quietly as possible. We laughed; me a little more uneasily.

But stuff like this doesn’t happen to people like us, right?

The narrowly avoided heart-attack

Around noon on the 3rd I was sitting at work, furiously trying to track down a bug in a piece of software I was writing when I received a call from the friendly Obama blogger. My side of the conversation probably went something like this:

Oh, hi Molly, how are you doing today? Great, great. Doing very well… umm.. what? WHAT? ARE YOU SERIOUS? REALLY? Yeah, I think I can do that. No, really. Yeah. takes breath Okay, I can’t believe this, this is insane! Okay, I’ll wait for the call from travel…

I went home early. I’ll get to that software bug eventually.

Off I go

The next day, off I flew to Chicago, taking my friend Damon (who was probably even more surprised, considering he was visiting family in Tulsa, and didn’t see this coming at all).

More on the election night party itself soon.

Update: I didn’t get a chance to post about the election night party in any decent amount of time, so I’ll leave it to your imagination. Suffice it to say, it was surreal to stand just a couple dozen yards away from now-President Obama as he gave his victory speech.

Boston.rb Slides

2008-09-09T00:00:00-07:00

The material for the talk is fairly similar to the Lone Star 1.9 talk I did a few days prior, but re-tooled for a smaller group.

Thanks to my employer, FiveRuns, for bankrolling the trip, and to the guys out at Thoughtbot and the Boston.rb group for their hospitality.

Arrow Lambdas, a Ruby 1.9 Vignette

2008-08-17T00:00:00-07:00

Proc, the object-y twin of the syntax-level block, is the subject of a controversial change in Ruby 1.9: the addition of a new literal.

It’s here to stay. Let’s play a bit, shall we?

While we still have Kernel#lambda, in Ruby 1.9 the parser now accepts a literal that looks like the following (to support some great new features such as default arguments and associated blocks):

-> { } # the basic form
->(x) { x * 2 } # with an argument
-> x { x * 2} # (without parenthesis, too)
->(x, y) { x * y } # multiple arguments
->(x, y = 2) { x * y } # default arguments
->(x, y, &z) { x * y * z.call } # take a block

These are being called arrow (or pointy) lambdas. It’s just a Proc literal.

Although many people dislike this new syntax, it’s come to grow on me. Having lambdas at the syntax level strikes me as a good functional feature, and functional programming is a hard drug to come off of. I do wish a slightly different format had been used — Erlang makes me want the arguments first, and Haskell makes me want a λ-like backslash (as it does Dave Thomas) — but I can live with it.

Calling them

You can call lambdas using a bit of new syntax, too.

times = ->(x, y) { x * y } times.(2, 3)

This outputs:

Make sure you use a dot before the opening parenthesis. If you forget it, you’ll get a NameError when Ruby looks around for a method by that name:

times(2, 3) # BAD!

It raises:

NoMethodError: undefined method `times' for main:Object

I remember this shortend call feature under the moniker dot call (which is reminiscent of regular expression //s dotall, so it works for me, text- processing nerd that I am).

With a block, no less

Let’s try defining a lambda that accepts an associated block when called, since we can these days:

say_hello = ->(n, &name) { n.times { puts "Hello, %s" % name.() } }

Here we assign a lambda to the variable say_hello that takes two arguments; the first a number of times to say something, and the second a block to call to retrieve a name (which will be converted to a lambda with & and assigned to the name block variable).

Now let’s invoke it:

say_hello.(4) do 
  "Bruce"
end

This outputs:

Hello, Bruce
Hello, Bruce
Hello, Bruce

So, here we call the lambda, sending it 4 as the first argument (which is assigned to n), and a block (which is converted and assigned to name). The sayhello lambda does its work, invoking the name lambda (with no arguments) in turn.

Note we can’t just use yield in the say_hello lambda to call name; yield in this context would make Ruby look for a block passed to the enclosing scope (ie, the method where say_hello is being defined), and that’s not what we want.

It can get really ugly

These new lambda literals can be a bit odd in some syntactic contexts. Here’s one.

As hash values (in old-style hash literals)

Not that this would generally be done anyhow, but boy are the double arrows here ugly:

strategies = {'mult' => ->(x, y = 2) { x * y }}
p strategies['mult'].(3)

Outputs:

It’s even worse without parenthesis (it’s a good idea to use parenthesis in any but the most trivial arrow lambda):

{'mult' => -> x, y = 2 { x * y }}

It’s a bit better using the new hash syntax (using a Symbol for a key this time):

{mult: ->(x, y = 2) { x * y}}

Strung out or wrung out

The parser’s pretty good at figuring out what the boundaries of these new lambdas are, and with new possibilities like default arguments, mandatory arguments after default arguments, not to mention block arguments, things can get pretty long and nasty.

The following is a completely legal single lambda being immediately invoked:

-> a = 1, b = 2, c, &d ; e { e = d.(a * b * c); e + 1 }.(3) { |p| p * 4 }

Yeah, I know this lambda is useless. But even if it was useful it’d be too ugly to foist on another human being.

Ruby is not Perl. Say it with me.

Who are we? Who will we be?

Issues like the addition of a new literal really get people riled up (well, as riled up as nerdy backseat language designers get, I guess). This is a language many of us became interested in because of its elegance (perceived or otherwise; it really doesn’t matter), and I think it’s only natural that we try to avoid adding to the language at such a basic level as syntax.

Lambdas are such a basic building block of Ruby, however, that I think a real, flexible literal has been long overdue, and I’m very happy it’s here, especially since it’s in a form I don’t consider completely off-putting.

Hopefully the community will self-regulate a little on convention and continue to consider elegance, not obfuscation, as the defining characteristic of a kickass Rubyist. That’s all any of us can ask for.

ViewGem, a Little Script

2008-08-10T00:00:00-07:00

What do you do when you need figure out what’s going on inside a gem, or just get a feel for its API?

I don’t use generated documentation to help me solve problems — often the library’s author and I disagree about what’s important to mention, and/or the documentation is fairly non-existent. Hey, I can’t whine… this stuff is free.

While I don’t necessarily agree with my esteemed colleague Adam Keys on his hypothesis that comments are a bad smell, I can definitely state that many smell bad. The fact they get generated into a prettier format also doesn’t help much… and well, we all know how often User’s Manuals and the like get updated.

Just get me to the code already!

Here’s a little script

Update 2008-12-23: Just use the gemedit gem :-)

Rails BootUp, Austin TX

2008-08-06T00:00:00-07:00

A couple of months ago when Damon Clinkscales asked if I’d participate in a local training session for new Rails developers, I jumped at the opportunity. I really enjoyed my time as a speaker for the Rails Edge conferences, and, regardless of how stressful it is, there’s few things as satisfying as watching someone get Ruby and Rails right in front of your eyes.

Rails BootUp was born, and this last Saturday Damon, Edward, Mike, Rob, myself, and a class of 11 spent the day at Datran Media’s offices talking about Ruby and Rails. It was fun… and there was some mighty fine catering, courtesy of Damon’s excellent taste in local restaurants.

Why we did it

So, backing up a bit… why teach a small Rails course here in Austin?

To put it plain and simple, it was to help build up the local Ruby community. While Austin is a pretty fair sized IT corridor, our Ruby and Rails groups are still in the fledgling stage; there seem to be a large number of local developers (many of them working with Java) that seem poised on the fence, interested in Ruby but without the skills or understanding they feel necessary to take the leap.

This course, from my perspective, was designed in part to introduce a new group of developers to the language— and to test the waters to see if a demand for Ruby training exists in the local area. As fast as the event sold out, I think we have our answer.

We also donated over $400 to Austin Children’s Shelter, which isn’t half- bad!

It went pretty well

I think we had a solid progression of lessons throughout the day; from Rob’s thorough introduction to the Ruby language itself all the way to Damon’s talk on Capistrano (where attendees actually deployed their own code to separate Dreamhost configurations).

My talk on ActionPack— explaining how requests become responses and how views are structured— seemed to go off well, though this is definitely a set of topics that should be broken out to several focused talks in later manifestations of the Rails BootUp. As with any training course— especially one being done for the very first time— there is plenty of room for improvement in future events.

Salutations

We sure did meet a great group of inquisitive, bright developers. Welcome, and keep in touch!

RTeX 2.0 Released

2008-05-20T00:00:00-07:00

I’m happy to finally release RTeX v2.0.

RTeX is a Ruby library for generating PDFs via the LaTeX typesetting system, and can be used as a standalone executable or Rails plugin for pdf.rtex files. If you need to generate complex (and well- typeset) documents dynamically, this might be the ticket.

This updated version of RTeX offers a number of improvements over previous versions, and has been a long time in making. For more details on the library, start here.

RTeX on Lighthouse

2008-05-17T00:00:00-07:00

I’ve just opened up a Lighthouse project for RTeX here. This fills out the RTeX family of pages to be:

* Documentation

* Development

* Issue tracking

RTex Webby Filter

2008-04-29T00:00:00-07:00

Good news today. Webby, my favorite little

static website generator that could, is now being developed on GitHub. This will make contributing to the project easier for those of a git persuasion, and hopefully take a bit of pressure off Tim’s shoulders in the long-term.

I really enjoy playing with Webby, and my recent work with RTeX has tweaked my interest in integrating PDF generation. Here’s a walkthrough on how to add a quick filter to do just that.

Installing the Goods

First of all, some prerequisites:

1. Get started on Webby, and create a project.

2. Install RTeX

3. Brush up on your LaTeX (see the RTeX FAQ for a pointer on resources).

If you’ve done all this, you’re ready… if you haven’t, you’re just skimming to see if this is interesting and/or simple, and that’s okay, too.

Creating a Document

Let’s create a file in your Webby content/ directory called example.tex and put the following in it:

  ---
  extension: pdf
  created_at: 2008-04-29 08:12:58.135564 -05:00
  layout: false
  filter: rtex
  ---
  \documentclass[12pt]{article}
  \begin{document}
  \title{A simple RTeX-generated PDF}
  \author{You \\ your-address@your-site.com}
  \maketitle
  \newpage
  See, it's simple\ldots
  \end{document}

Okay, LaTeX content aside (it can be a bit much to take in if you’re not used to it), this is a simple document.

The first portion of the file (the part that looks suspiciously like a YAML document) is the metadata. The first thing you should notice is the rtex filter we’re assigning, which we’ll work on shortly.

We also set some other bits; the extension so that the generated document is named correctly (ie, example.pdf), and layout, which we unset (you could use a nice, reusable LaTeX layout, but let’s skip that for this example).

A Simple Filter

Creating the filter for Webby is easy; it’s just the bit of glue that sticks RTeX and Webby together.

In your Webby project’s lib/ directory (create it if needed), add a file. You can call it whatever you like, but let’s use rtex_filter.rb for now.

Here’s the contents of the file:

require 'rtex'
Webby::Filters.register :rtex do |input, cursor|
  RTeX::Document.new(input).to_pdf
end

Not exactly rocket science, is it?

The Results

Now, regenerate your site. I commonly keep this running, as you can read about in the Webby documentation:

  rake autobuild

You should find example.pdf in the corresponding location under output/. Just link it from your normal Webby pages.

With very few changes to the filter (eg, looking for additional processing options in a page’s metadata), arbitrarily complex documents can be created directly from Webby.

Not bad for a “runt with a special knack for transforming text” and a gem that’s a poor man’s binding.

RTeX 2 Preview 1 Released

2008-04-28T00:00:00-07:00

I’m happy to release RTeX 2 Preview 1 (v1.99.0), now available as a gem from RubyForge. RTeX can be used as a plugin with Rails 2.0.1+.

History

In 2006 I released a Rails plugin, Rtex, used to generate PDFs via the LaTeX typesetting system. It became a popular choice for people looking for a more advanced alternative to PDF::Writer, especially for larger documents.

Wiebe Cazemier joined the project in 2007, helping to improve the plugin and fielding patches and bug reports.

RTeX 2

RTeX 2 isn’t just a Rails plugin; it’s distributed as a gem and includes a standalone executable that can be used to process documents outside a Rails process (for delayed processing or use in some other type of application) through a series of custom filters (eg, Textile).

For more details…

* Documentation and Manual

* RubyForge for gem distribution and GitHub for development.

RubyLearning Interview

2008-04-18T00:00:00-07:00

Satish Talim of RubyLearning.com just posted my responses to several questions he posed on Ruby as a language and my tips on mastering it.

It was a fun interview, and around a topic I really enjoy speaking about; Thanks Satish!

of-fiveruns/

Introduction to Ruby

2008-04-14T00:00:00-07:00

Here are the slides for the talk I gave at the Scotland on Rails charity workshop on April 3rd … to a group of very forgiving attendees who had graciously donated money only to see the first speaker arrive late and out-of- breath!

As you might imagine, the content of the talk is fairly elementary – but if you’re looking for a brief, code-centric overview of Ruby’s language features and syntax this might be the ticket.

Migrating to Ruby 1.9

2008-04-14T00:00:00-07:00

Here’s the slides for the other talk I gave at Scotland on Rails, going over the syntax and language feature changes between Ruby 1.8 and Ruby 1.9.

This is a significantly updated and expanded version of a similar talk I gave at the Austin on Rails meeting in February.

Playing Catch-Up

2008-04-13T00:00:00-07:00

It’s been a busy month, finishing up a big release at work and then escaping to hang out in the UK for a bit. Not that it’s an excuse to go dark, of course, but I have been preoccupied!

Scotland on Rails was a really excellent conference. A smallish regional event (even the regional conferences are getting big these days), it was a largely single-track event and had a very cohesive feel. I was lucky to be able to present twice during the conference; “Introduction to Ruby” for the charity workshop and a “Migrating to Ruby 1.9” plenary session (slides for both of these to be posted soon).

The conference covered a wide range of material; a good bit of pure Ruby (which always makes me happy), a suitable amount of Rails-centric sessions (it is Scotland on Rails, after all), and even an Erlang talk for good measure.

From an adoption standpoint, Scotland felt very US-in-late-2006 to me; a lot of individual passion and interest in the technology, a number of smaller companies actively using it, some large company/academic interest. It seems like there’s a lot of opportunity for growth, given the number of smart people around. It will be interesting to see what happens in the coming year or two; I definitely plan on returning to see for myself!

Thanks again to Alan, Paul, Abdel, and Graeme for all their hard work putting the conference together. This sort of thing is not a trivial undertaking!

To those I met over Ruby or a pint – let’s keep in touch!

Scotland on Rails, April 4th-5th

2008-02-23T00:00:00-08:00

I love Ruby (and Rails) conferences. I attend as many as I can each year, and I’m especially excited about Scotland on Rails coming up in early April. Sure, part of it might be that I haven’t been back to the UK since I was a teenager (and I plan to cool my heels in Edinburgh for a few extra days), but more than anything else, it’s about meeting new people and reconnecting with old friends. It looks like there will be a wide range of both present at Scotland on Rails, and hopefully plenty of hacking, too!

I’ll be speaking at about Ruby 1.9 at the conference, and there’s a great lineup of other talks about a wide range of subjects. If you can make it to Edinburgh April 4th-5th, register away … hope to see you there!

Advice for a Java Developer

2008-02-17T00:00:00-08:00

Over the last two years or so there’s definitely been an influx of people from Java, and that seems to be accelerating. Two of the developers I work with, in fact (Brian and Mike), are somewhat recent converts from Java; you’re definitely not alone.

With as much Java experience as you have, you probably don’t need a lot of hand-holding; but there are some concepts in Ruby might be somewhat foreign to you (depending on the rest of your background) – specifically concepts like block closures and the level of dynamicism present in the language. If you’re looking for books, I’d recommend you familiarize yourself with:

* Programming Ruby

* The Ruby Way

* The Ruby Cookbook

I think it’s important you get a firm grounding in the language before the framework, but here are some Rails (framework-level) books:

* Agile Web Development with Rails

* The Rails Way

* Rails Recipes (I like this better than “Rails Cookbook”); an up-to- date “Advanced Rails Recipes” is coming out soon.

* Ruby for Rails

Make sure you’re spending time:

* Reading code that highlights “best practices” (The Ruby Cookbook and Rails Recipes books above illustrate some examples); obviously like any community there are differences on opinion on what constitutes good, idiomatic Ruby, but I can give you some recommendations on specific projects

* Spending some time with Ruby developers (Austin on Rails is certainly a good place to start if you’re in the Austin, TX area); collaborate on an actual project if you can, but there’s value in just chatting, as well

* Following what’s going on in the Ruby community; there are a number of websites, mailing lists, and IRC channels that can help

I consider these steps far more important than a full bookshelf.

Second/dp/0974514055

Professional/dp/0672328844/ref=pdsimbimg4

Carlson/dp/0596523696/ref=pdsimbimg2

2nd/dp/0977616630/ref=pdbbssr1?ie=UTF8&s=books&qid=1202238870&sr=1-1

Ruby/dp/0321445619/ref=pdbbssr2?ie=UTF8&s=books&qid=1202238899&sr=1-2

Fowler/dp/0977616606/ref=sr14?ie=UTF8&s=books&qid=1202238946&sr=1-4

Developers/dp/1932394699/ref=pdbbssr1?ie=UTF8&s=books&qid=1202239113&sr=1-1

The Statesman on Rails

2008-01-28T00:00:00-08:00

At the January meeting of Austin on Rails, we had a couple visitors from the Austin American-Statesman newspaper (which everyone around here just calls “The Statesman”), covering Rails’ mindshare and market penetration in the city for an article published today.

The first thing you’ll probably notice, looking at the page, is the huge Rails logo; you can even enlarge it, if you’d like. Beyond that, there’s a fairly even-handed article to read, and even a couple pictures (thankfully, the one with me hunched over my MBP hastily cobbling together the last few slides on my presentation has disappeared). If you’re interested in Ruby/Rails from either a development or a business standpoint, it’s probably worth a read.

Crazy how this little language grew up.

Austin on Rails

A lot of credit needs to go to Damon Clinkscales and the others who were around when the group first started. There’s a lot of value in actual, face- to-face, cross-company technical and social interaction for developers, and I’ve been really happy to hang around with these guys this year. This type of thing makes for a tighter knit community, a better support network, and opportunities for collaboration. If you’re a developer and you’re not taking a couple hours out of every month (or every week, with a Cafe Bedouin or ARCTAN style meeting) getting to know like-minded developers in your community, you’re shooting yourself in the foot, period.

Anyhow, a bit of code and beer never hurt anyone. Theoretically.

01/28/0128ruby.html

http://www.statesman.com/business/content/business/stories/technology/01/28 /Ruby-on-Rails-logo.html

Welcome Back, Codefluency

2008-01-27T00:00:00-08:00

A couple weeks ago I moved hosts, and while doing so put up a parking page. Life interceded,

and I was down a bit longer than I would have liked, but codefluency is back up and running.

Some temporary shortcomings at the moment are, in order of importance:

1. –The atom feed (which seems to be the way a good percentage of people pick this up)– This should be working now; it’s up at its old location.

2. –The need to rewrite incoming links (tag articles/ on the front of those old links at the moment)– This should also be working. Let me know if you run into any bad links.

Notably, and possibly permanently missing are:

1. Search. Most browser-based readers come here directly for a specific article, and search has been essentially unused. Google does a better job of indexing the site in any case, so if it’s needed just tack site:codefluency.com onto the front of your query, and voila .

2. Comments. I love an active community just as much as the next guy (likely more, in fact), but I’ve always found the best type of communication of a more active (live, if possible) nature. I’ve had some great comments in the past, but the signal-to-noise ratio hasn’t been very compelling, even counting out spam. I’ve had a much better experience with those people who send a direct email, tweet, or IM (even if it’s just to say ‘hi’). If something’s said that’s worth an update to an article, it’ll happen. I’ve wrestled a bit with this, but that’s my conclusion; at least for the time being.

Now the obligatory comments on the current incarnation. Those of you that have known me for any length of time know how I feel about this website; it’s a playground, and it changes often. I had the previous design up for well over six months, which is likely a record for me. I’ll probably keep it that way.

So this time, a bit darker and content-focused. I’ve added a bit of vector art… which I’ve alternately heard called Rock Star and Maoist this time; an interesting stylistic overlap, I suppose. I’d heard comments that my old artwork looked dated, especially as it related to my hair (I’m growing it out for charity, so it’s obviously not short and spiky anymore), so this is a bit more accurate.

A quick note on the technologies used this go. I’ve opted for static pages, which is pretty refreshing for a guy who’s been up to his eyeballs in web frameworks, most notably Rails, for the past few years. I’m using Webby for generation; Tim Pease is both a good friend and a wickedly smart guy, and I really like what he’s put together. It’s built in Ruby, of course, and reminds me of the type of generation framework I wanted to write coming off of bloxsom years ago, but could never get quite right; Tim has done a much better job than I ever could. Webby comes with a rake autobuild task, which integrated with Jeremy Hinegardner’s heel and launchy projects makes on-the-fly generation a snap. Use Webby for static pages if you want something simple and straightforward.

Git and Nginx make up the rest of the toolkit; the website is actually a master repo that gets reset on update (thanks to ReinH’s suggestion and this script called in a post-update hook).

So, quick and simple is the callword for this version.

Okay, enough meta for now.

Taming Your Views

2007-12-18T00:00:00-08:00

Here’s a note I should have posted a couple weeks ago..

The Taming Your Views talk I gave at the Charity Workshop for the Lone Star Ruby Conference is available at MindBites (along with the other talks filmed that night), with proceeds going to charity.

MindBites has some interesting videos (and you get some free credits when you sign up), so go have a look. Many thanks to Damon Clinkscales for putting the workshop together and handing video QA.

10 Minutes with Factor

2007-12-17T00:00:00-08:00

Factor is a stack-oriented language, similar in that respect to Forth and Joy. I’ve played with both at one point or another, so when I recently ran across a reference to Factor in a recent interview with Zed Shaw, I thought I’d take a look. I’m always on the prowl for little esoteric languages, hoping to harvest new (or newly revised) approaches to software development.

First of all, some caveats. I don’t know much about Factor yet, and I’ve never been successful at implementing anything worthwhile in any stack-oriented language (not that I’ve tried); my strengths mainly lie along the OOP and functional fronts, and I haven’t really hit the “Aha!” moment yet with stacks. I do, however, appreciate the syntactic simplicity and extensibility of the idea, and hope to get there soon.

Let’s get started.

Installing Factor

You can grab binary and source copies of Factor from the website here. Make sure you download an image file as well if you’re building from source.

You can also clone the Factor repository using git, with the standard disclaimers on stability.

The GUI

As crazy little esoteric languages go, Factor comes well-dressed… with a relatively simple, but powerful GUI for interactive hacking, debugging, and code/documentation browsing. It completely puts irb to shame, of course; though there has been some work in this direction in Ruby, it sure would be nice if something similar would come standard with the language. I’m not a big fan of big IDEs that do enough work for you that you forget how to do things yourself, but give me a little hacking console any day.

Basic Concepts

The basic concept of stack-oriented programming centers around manipulation of one or more stacks. In Factor this manipulation is done via words (that sit in vocabularies), and generally a single stack is used. Let’s try a simple example using the ”+” word.

1 2 + .

The first thing you might notice is that ’+’ comes at the end. This is called Reverse Polish Notation (RPN), and though it might seem a bit weird to those of us with infix operator leanings (and backwards to PN Schemers), it makes complete sense when you’re dealing with a stack.

Let’s break the example down, bit by bit.

1 is recognized as a number literal. It’s pushed onto the stack. Stack looks like: 1
2 is recognized as a number literal. It’s pushed onto the stack. Stack looks like: 1 2
+ isn’t recognized as a literal; it’s a word that’s found and executed. It pops off two items from the stack, adds them (just pretend how that happens is unimportant for the moment), and pushes the result on the stack. Stack looks like: 3
A single period pops off an item from the stack. Think of it as returning a value. Stack is now empty.

Gem

2007-12-15T00:00:00-08:00

Rails plugins have been a great tool to have around; just look at the amazing number of plugins that have popped up over the last couple of years; great ideas from all over the place. Plugins are so easy to put together and distribute that many people who’ve never released software before

They also have some pretty serious flaws. There’s no built-in versioning or Rails version requirements. There’s no dependency resolution. There’s no real metadata or built-in search functionality.

Syntax Changes in 1.9

2007-12-03T00:00:00-08:00

I think one of the more interesting conversations that’s going to occur in the Ruby community once 1.9 is released is how we integrate the syntax (and behavioral) changes coming into the language in as elegant form as possible. Over time, the consensus (or at least conventional usage) will drive what we label Rubyesque (that is, idiomatically Ruby); what is accepted, what is absurd, what is clean, what is over-engineered, and what is far more clever than it is smart. We’ll be reforming the feel and taste of Ruby using new artistic tools.

Over time, we’re sure to see a lot of forms pop up and then slowly fade away (remember the days of def ClassName.methodname and :: method invocations?), we’ll see casual groups form (eg, the collectionists, the mappers, the private indenters, etc), and entirely new dialects pop out of the ether (Rails, anyone?) and seed the ground with fresh ideas.

This is nothing new. It’s how languages grow. Regardless of how you feel about it, Ruby is no exception.

Over the next few weeks I’m going to be switching the focus of this blog (wait, there was a focus?) to the Ruby 1.9 release, especially as it relates to the syntax changes.. since Ruby’s syntax is largely what drew me to the language, and something that continues to enthrall. This is definitely the most radical release I’ve seen so far (though it needs to be said that many of the changes are experimental), so I’m really going to dig in.

Let’s start with a few examples of experimental lambda and hash features currently in 1.9. I’ll be showing a few examples of some variants, it’s up to you to decide on the forms you like most. You might want to bone up on the changes first.

The Strategy Hash

Example: Assigning a hash of symbol keys and lambda values as various strategies to process a string.

Flavors to choose from:

Traditional ‘lambda’ (let’s skip ‘proc’)
Experimental arrow lambda, parameters outside (parenthesized)
Experimental arrow lambda, parameters outside (bare)

strategies = { :simple => lambda { |item| item.capitalize } } strategies = { :simple => ->(item) { item.capitalize } } strategies = { :simple => -> item { item.capitalize } }

The arrow variants look at least a little less ridiculous with the special symbol-key syntax:

strategies = { simple: lambda { |item| item.capitalize } }
strategies = { simple: ->(item) { item.capitalize } }
strategies = { simple: -> item { item.capitalize } }

The Filter List

Example: Now let’s toss some text filtering lambdas into an Array, using the various flavors.

filters << lambda { |item| item.capitalize }
filters << ->(item) { item.capitalize }
filters << -> item { item.capitalize }

Whoa, love the opposing directions there.

Let’s push multiple arguments now:

filters.push lambda { |item| item.capitalize }, lambda { |item| item.reverse }
filters.push ->(item) { item.capitalize }, ->(item) { item.reverse }
filters.push -> item { item.capitalize }, -> item { item.reverse }

These filters would be fun with inject & the new experimental .() version of call/[]:

filters.inject('hey!') { |res, filter| filter.(res) }

In parting, a bit of clever code (note Enumerator, Lambda syntax, single block parameter, alternate call syntax).

3.times.inject(-> { -> { -> { "Hello, #{RUBY_VERSION} World!" } } }){ |_| _.() }

There’s a lot more to cover, obviously, but that’s enough for now.

It's time to play with 1.9

2007-12-02T00:00:00-08:00

With Ruby 1.9 just around the corner, it’s time for you to start playing with it. While you’ll want to keep any production apps you have chugging away happily on 1.8, don’t shoot yourself in the foot by not keeping up.

Read the CHANGELOG, so you know what to expect (or read the overview at eigenclass).

Install it alongside 1.8; here’s my method:

svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby1.9
cd ruby1.9
autoconf
./configure --prefix=/usr/local --program-suffix=1.9
make
sudo make install

Try something ridiculous, just because you can:

ruby1.9 -e '->(t){ puts t }.("This is Ruby 1.9!")'

Build something with it, post some examples (I certainly plan to), and see what other people have to say

svn up, rebuild, and reinstall as we approach the Christmas release

There’s a lot of great features and syntax changes in this release; I expect we’ll see a lot of patterns (and anti-patterns) pop up as the community plays with 1.9. This is the first release with significant syntax changes since Ruby became popular – in the past the number of people using Ruby was smaller by several orders of magnitude… so it will be interesting to see how, or if, a general consensus can be reached.

Ruby.framework

2007-11-03T00:00:00-07:00

A few articles ago I talked about re-building Ruby on Leopard (instead of using the provided Ruby.framework).

A couple days ago, I switched back to the framework to play around and have been using it instead – and after Laurent’s talk tonight I’m 100% certain it was the right decision.

Absolutely amazing.

Drinks at RubyConf

2007-10-31T00:00:00-07:00

My employer and BlueBox Group are graciously holding the bar open at Arpa after the RubyConf keynote. Obviously they’ll cap us at some point… but let’s make that happen, shall we?

No agenda + free drinks. See the official announcement and réservez s ‘il-vous-plaît if you have a moment (so I can gauge my planned intake).

Stackalicious

2007-10-27T00:00:00-07:00

So, at the risk of making entirely too many posts about Leopard today, I’m going to toss another out.

Uses for Stacks:

* Clean up messes: Within a week I can turn a nice, clean desktop into a morass of inane downloads, screenshots, and documents. A Stack of ~/Downloads makes things a lot cleaner. If I can only figure out how to get screenshots to go into a separate Stack…

* Little discrete groupings: I usually have a logical grouping of files on the desktop that I want quick access to, ie TextMake Project files. Having a single Stack might be a good approach for this.

Some Leopard + Ruby Notes

2007-10-27T00:00:00-07:00

Ruby developers may want to keep the following bits of information in mind when they install Leopard.

1. If you replaced Tiger’s horribly broken /usr/bin/ruby with your own custom build (most of you did), be aware Leopard will overwrite it (now it points to the 1.8.6 Ruby.framework in /System that comes bundled). The same issue exists for the gem and rails executable. Not a big deal; re-overwrite as you see fit (or use the framework version and reinstall some gems and libraries).

2. You’ll probably need to reinstall Xcode, as well (at least if you want a compiler!). Throw your Leopard disk back in, go to Optional Installs -> Xcode Tools and install XcodeTools.mpkg. Same process as with Tiger.

3. I needed to reinstall MacPorts as well.

As you might expect, YMMV. More as I run across it.

Leopard, Off the Cuff

2007-10-26T00:00:00-07:00

So, today was Leopard release day. Showing up at work this morning and seeing a shrink-wrapped copy on my desk was a nice surprise.

Some initial reactions:

* It’s snappier. I’m sure cleaning out my 10.4 cruft helped, but it sure is faster than I expected.

* Spaces is a big deal. Multiple desktops are something I really missed from my days as a Linux junkie (Virtue Desktops didn’t perform well enough for my tastes)

* Cleaner UI. Very happy to get rid of the clunkier brushed-metal look. The window shadowing is definitely better in this release as well.

* Web Clips are sweet. I do wonder, however, how this will affect ad-driven sites who rely on people coming to view changing content (which now can be docked ad-free on Dashboard).

* Cover Flow in Finder is neat, at least for some types of media (especially with video Quick Look); it’s useless with text, of course. The default blue folder image is disappointingly drab.

* Lots of small features to find (tabbed windows and better Google Talk support in iChats, an improved Spotlight, etc); some of these might reduce my currently fanatical need for applications like Quicksilver and Chax.

I think the thing that most excites me about Leopard is the fact new applications are sure to come out that will leverage technologies like Core Animation (and various nifty XCode improvements). The next version of TextMate, which will be Leopard-only, for instance, is something I can’t wait to get my hands on.

All in all, very happy with this release so far.

KeywordSearch 1.3.1

2007-10-09T00:00:00-07:00

KeywordSearch is a small library I wrote earlier this year to add support for GMail-style keyword/value searches via a DSL. It’s a parser pet project that I tweak from time-to-time.

Here’s an example, albeit a little hackish:

# Some variables to build up
clauses = []
arguments = []
# Search a string, defining the supported keywords and building up
# the variables in the associated closures
KeywordSearch.search('account has:attachment since:2006-12-03') do |with|
  with.default_keyword :title # values without keywords get assigned to this
  with.keyword :title do |values|
    # keyword blocks are yielded an array of values
    clauses << "title like ?"
    arguments << "%#{values.join(' ')}%"
  end
  with.keyword :has do |values|
    clauses << 'has_attachment = true' if values.include?('attachment')
  end
  with.keyword :since do |values|
    date = Date.parse(values.first) # only support one
    clauses << 'created_on >= ?'
    arguments << date.to_s
  end
end

# Do our search with clauses and arguments

conditions = [clauses.map{|c| "(#{c})"}.join(' AND ')), *arguments] # simplistic example
results = Message.find(:all, :conditions => conditions)

KeywordSearch is available from RubyForge and can be installed via:

sudo gem install keyword_search

Comments, as always, are welcome.

Changes in this release:

* Conversion to a Ragel parser as a performance tweak (not to mention less code). (I still love Dhaka, though).

* More advanced parsing with better character set support

* Test suite now uses “test/spec”: and has been added to significantly

* Keywords/values are now case sensitive; downcase the input manually if you want the old behavior.

Rewrite Woes (Take Two)

2007-09-24T00:00:00-07:00

There seems to be quite a furor over Derek Siver’s recent post on CDBaby’s failed rewrite to Rails.

Of course, this is fodder for the Rails anti-hype engine; which isn’t a bad thing, at least when it comes down to having logical, well-reasoned, and realistic discussion about when Rails is and isn’t the right platform choice. I tend to think that, for the most part, Derek’s points center around his own personal tastes vs strong technical reasons – which is not to say they’re less important; just less portable.

On top of the platform choice… to those who are jumping on this and screaming “Thinking about a rewrite to Rails? Think again!” I say “Thinking about a rewrite? Think again!” Chad covered those issues back in December (read bottom-up), earned after we spilled our own blood and tears on a failed PHP -> Rails rewrite.

Not to say that a rewrite never makes sense; just that you’d better be ready to tackle it.

Lone Star Ruby Conference Starting

2007-09-05T00:00:00-07:00

So, the Lone Star Ruby Conference starts here in a couple days, with the Charity Workshop getting the ball rolling tomorrow afternoon. I’ll be doing one of the 30-minute talks (talking about my old stand in, tips and tricks Rails views – or at least what I can fit into half an hour), and then it’s two days of near-relaxation listening to other people speak – and looking for local developers to hire.

A lot of great people are coming into town, so I’m really looking forward to the next few days. Hope to see you there (well, here)!

Some of us are getting together to see Wayne’s World at the Alamo Drafthouse

(Lake Creek) for the special midnight showing on Friday. If you’re interested (Austin has a lot to do), look here for more info. What’s the Alamo Drafthouse? Why, the best movie theater there is, of course!

Off Topic, FiveRuns is Hiring

2007-08-29T00:00:00-07:00

Live near Austin, TX? Want to work at a small, Rails-focused company? Not completely put off by the idea of having to work with me on a day-to-day basis? Really, think about that last one…

We’re gearing up to hire several Rails developers with varying levels of experience from the local area. If you’re sincerely passionate about Rails, Ruby, the community that’s grown up around it, and fit the bill, drop me a line (bruce at fiveruns).

Paginator 1.1.0

2007-08-12T00:00:00-07:00

I just released an update of the paginator gem; the full range of Enumerable methods are now available on Paginator and Page instances. This was a long overdue feature – like many releases, this one was for largely selfish reasons … not having inject available was really getting on my nerves.

Paginator is a simple library that can be used to add pagination to any Ruby not just Rails application. The original release notice is here.

Forward and Delegate, A Simple Pattern

2007-08-11T00:00:00-07:00

Here’s a simple example showing how to:

Forward all missing method invocations on to some object
Dynamically add delegation of that method to that object for future invocation.

def methodmissing(meth, args, &block) #:nodoc: returning @object.send(meth,args, &block) do self.class.classeval %{delegate :#{meth}, :to => :@object} end end

Note this example uses two bits from ActiveSupport:

returning to avoid explicitly setting a temporary variable for the return value (stylistic choice of mine)
delegate to generate the delegation code (because it’s dull to do it yourself)

Enjoy!

Using Warehouse

2007-08-09T00:00:00-07:00

A few weeks ago, the guys at ActiveReload released Warehouse, a web- based Subversion repository management and browsing tool. You may know ActiveReload for the Lighthouse bug tracking system, which has been out for several months, or from the fact it’s a small company made up of Rick Olson (rails-core member and prolific purveyor of plugins) and Josh Goebel (who generously gave us Pastie).

I love both of these tools, for several reasons. First off, they’ve been built with integration in mind. They both have APIs (especially Lighthouse), and hooking them into tools like Campfire is trivial (and

My Thanks; An Aside

2007-08-07T00:00:00-07:00

I’d like to offer my sincere thanks to those of you who have contacted me this week offering your condolences for the sudden and unexpected death of my youngest brother, Tristan.

As you might imagine, this came as an unbelievably hard blow to my family – but the outpouring of support received the last few days has helped me more than I can say (in the very least, offering a bit of human interaction).

My very sincere thanks to all of you. Don’t take anything for granted.

Bruce

PS. Now, back to the regularly scheduled and considerably more cheery program…

Finding Stale Tables

2007-08-01T00:00:00-07:00

Here’s a simple rake task to help you find unused db tables lying around in your application. Keep in mind it’s just a guess, showing any table that doesn’t constantize; if you’re using habtm tables, unconventional table names, or other such things, expect to see them show up as well.

namespace :app do
  namespace :stale do
    task :tables => :environment do
      tables = ActiveRecord::Base.connection.tables.reject do |table|
        table.classify.camelize.constantize rescue nil
      end - %w(schema_info)
      if tables.any?
        $stderr.puts "The following may be stale:"
        puts tables
      else
        $stderr.puts "No stale tables found"
      end
    end
  end
end

acts_as_texan :bruce

2007-07-18T00:00:00-07:00

Okay, so I totally stole that from Adam Keys and the crowd up at Dallas.rb – but it’s true … I’ve just “finished” my move to Austin, TX, finally ending months of planning, hair pulling, and various other acts of torture that revolve around getting a family with two small children across several states.

By “finished,” of course I really mean I’m sitting in a hotel awaiting keys to the new house and the arrival of everything I own – but you get the point. I’m here, at least in body, and trying to come to grips with living in a completely new place.

So, if you’re around Austin, drop me a note; I’m lucky in that I already know a few people, but development is a social pursuit … so bring on the contacts :-)

Pownce, off the cuff

2007-07-06T00:00:00-07:00

A few days ago I started to play around with Pownce, a recent new player in the ever expanding social webapp scene, roughly similar to Twitter.

I was a bit sceptical starting out, for three reasons.

1. The word “social” can easily mean “recycled crap” at this point in the game

2. It’s hard for me to think of Kevin Rose (part of the Pownce team) without thinking of the huge volume of vapid script kiddies that hang on his every word, or the general quality of Digg comments (not directly his fault, of course)

3. To be truthful, it’s built on Django, and as an ex-Pythonista and passionate Rubyist we know what framework I prefer.

Now, on to reality and a few days later…

The featureset is pretty compelling. With finer grained dissemination controls, a first class “reply” feature, and the obvious benefits of having message types like Event and File, Pownce is already far less of a “toy” application than Twitter feels after several months of regular use. The fact Pownce offers a Flickr-like pro subscription is also nice, since it shows some forethought occurred as to monetization – which will hopefully stave off some scalability issues through generous use of hardware/staffing as well as limit advertising.

The design, in my opinion, is certainly better than Twitter’s. Twitter’s tiny hairline-bordered sidebar with the kitschy palette of friends is habitually annoying and not particularly intuitive, whereas Pownce’s interface, while certainly not perfect, seems reasonably put together.

Of course everything isn’t rosy; I ran into a few small issues, including it inexplicably not being able to handle PNG profile images – but it seems to be pretty stable for what’s most certainly a newly released application. I’d like to see some further development – like a published and open API with integration with other services, but as a developer I understand these things take time.

So, to wrap up, let’s address my initial concerns:

1. On social sites: although these are commonly used elements on social sites, this seems to integrate them in what feels like a very cohesive interface, and keeps things simple without making them too stupid.

2. On Kevin: he’s just a part of a team, and thanks to the friend controls, I can insulate myself from the aforementioned hangers-on and comment message trolls.

3. On Django: liking or not liking an application for the underlying framework is pretty stupid; understanding when you’re the developer and when you’re the user is smart, so I’ll step back and see Pownce for what it is; a pretty clever use of a framework I don’t prefer but can appreciate.

You can find me at Twitter here and Pownce here. If you’d like a Pownce invitation, contact me – there’s a chance I have one handy.

Locking down The Move

2007-06-21T00:00:00-07:00

So, after a couple months of trying to figure it out, it looks as if my move to the Austin area is finally starting to take shape.

A week or so into July, we start the exciting trip southeast – this time trading in the normal drive through thrill-a-minute Kansas for the post- apocolypsesque terrain of West Texas.

We’ve secured a nice 4 bedroom house near the office, several coffeeshops, and Lake Travis, thereby meeting my laziness, caffeination, and occasional-periods-of-sunshine needs.

rillo,+tx+to%3A+san+angelo,+tx+to%3A+austin,+tx&sll=36.776292,-104.412689&sspn

&ie=UTF8&z=12&om=1

Best Garlic Press

2007-06-04T00:00:00-07:00

I love garlic, and so does my wife (which I suppose is lucky for both of us), and together we go through a vast amount of it every month. For the past few years I’ve been hand-mincing my garlic with a chef’s knife or santoku because of mixed results I’ve gotten from number of garlic presses – hard to clean, hard to use, not durable, etc.

I’m a fair hand with a knife, so mincing manually isn’t a huge problem, but due to the volume of garlic I have to process (since we eat largely mediterranean meals) it got a bit tiring.

So… I decided to give garlic presses another try, purchasing a Rösle. This is by far the best press I’ve ever used, and I highly recommend it to fellow garlic eaters.

folder_for, A Controller DSL

2007-06-02T00:00:00-07:00

Over the last year or so, I’ve spoken at a number of meetings and conferences (including The Rails Edge and RailsConf) about view layer concerns, and on several occasions have given a folder interface example when speaking about controller domain specific languages. Since I’ve received several requests, here’s some information on the example.

First of all, here’s the source (Sorry, this file has gone missing since this article was written).

The Slimy Used Car Salesman App (beta)

For our example, let’s pretend for a moment that we’re developing an application that will serve as a local listing of used cars for sale. After talking with the client, we’ve determined that in makes sense that a folder- style interface to be used on a few pages, most notably when viewing the information for a specific car. Folder interfaces aren’t hard, but they can be tedious – so we’re going to employ a DSL so we can easily create them with a minimum of hassle. We could do this purely in the view layer, but we’d like the flexibility to add custom code for individual tabs in the controller, and don’t want to have to remember a series of helpers that we’ll need in views.

Using this plugin, we can do something like the following:

  class CarsController < ActionController::Base
    # ...
    folder_for :show do
      tab "General Information" do
        @score = current_user.score_for_car(@car)
      end
      tab "History"
      tab "Photos"
    end
    # ...
  end

What we’re doing here is defining a folder to be displayed for the show action, with 3 tabs. On the first tab, General Information, we’d also like to calculate a score for the car, based on the currently signed-in user’s preferences.

So, what happens now?

We have to define the content of each tab. In the past, we would have one view template to work with:

  cars/
    show.html.erb

and would have had to manually render the partial for the currently selected tab, based on a parameter, and handled setting the default tab, not to mention the mechanics of switching tabs. Perhaps, if we were exceedingly lazy, we would have just had a big, ugly if, elsif statement in our template as well, conditionally rendering content for tabs. Ick.

How this works now, by convention, is that we break up our templates/partials like:

  cars/
    show.html.erb
    show/
      _general_information.html.erb
      _history.html.erb
      _photos.html.erb

and our show.html.erb might look something like:

  <h1><%= @car.title %></h1>
  <p><%= @car.summary %></p>
  <%= folder %>
  <p>Some information below the folder...</p>

The folder helper essentially says “put the folder here,” and the content that’s inserted consists of:

* A set of easily-styleable, functional tabs (a ul), with the current tab selected (through a CSS class)

* The content from the appropriate tab partial inserted in a div within the folder

The concerns of the folder system – the fact that it involves the use of params[:tab], the first tab is the default, and links need to be generated to switch from tab to tab – is not something you need to care about; these are mundane details that this level of abstraction allows you to ignore.

Another thing you may have noticed is the fact that car is available for use – both within the tab definitions in the controller (where, in our example, we set score) and in views. How is this handled? Using REST conventions (the fact we’re doing this within CarsController), the folder knows that there should be a Car model, and that it should set @car using Car.find(params[:id]). Once again, a mundane detail that remains beneath your notice.

Caveat Emptor

It’s important that I point out a few details on the limitations of this plugin – and very unapologetically, since it’s an example and not a release.

1. Cases where a record need not be queried (ie, we don’t need @car), or multiple records are needed (ie, if we were setting up a folder on index) are not handled by this implementation – but could easily if an options hash argument was handled by folder_for. I sacrificed completeness for some semblance of clarity.

2. There is no support for multiple folders-per-view (though there is support for multiple folders per controller), since I think that’s a fairly stupid interface decision, so adding support for it is stupid, too.

3. The code may or may not work with Rails versions prior to support for .html.erb template extensions (ie, the old .rhtml days)

4. There’s probably a number of other limitations; feel free to extend as you see fit.

In My Defense

There are likely several of you reading this that are disturbed to see a folder reference within a controller, as this amounts to level type of MVC “separation of concerns” blasphemy in your very strict, very well-worn book of religious morals.

I’m here to tell you it’s okay, and you’ll recover in time.

Let’s keep in mind here that the MVC separation of concerns, while a great rule of thumb – is just that – and is not an ivory tower to be left unassailed in times of dire need. At times, it makes sense to allow abstractions to cross these boundaries for the sake of reducing our own overhead, and in the cause of developing your own app-wide domain specific language – something, that in my book, is the principal sign of a good Rails developer (for what it’s worth).

Malleable Fun (or, the Moral of the Story)

An important thing to remember when using Rails is that it sits on top of Ruby – something that’s so obvious that it’s moronic, but nonetheless something people seem to forget.

What this means is that you have this amazingly dynamic, expressive language at your fingertips, and you’re free to extemporize as you see fit, creating your own mini languages in a flash.

Think something sucks to do every time manually? Don’t. Write code to do it, or write code to write code to do it. You’re language crappiness quotient is remarkably low – are you taking advantage of that, or have you fallen into old patterns of suck-it-up-and-bear-it self-pity?

And that’s the Public Service Announcement of the day, thank you.

Donate through Pragmatic Studio

2007-05-18T00:00:00-07:00

This morning at the RailsConf welcome talk, Chad gave an impassioned speech urging conference attendees to help “change the world” by donating to charity through Pragmatic Studio. Pragmatic Studio, known for their excellent commercial tutorials, raised over $10k through donations by attendees of their Guidebook yesterday.

This is something anyone can participate in, whether you have the opportunity to attend RailsConf or not. How much money can the community, as a whole, raise?

Donate at http://pragmaticstudio.com/donate/

fast_forward 1.0.0

2007-05-14T00:00:00-07:00

Just a note that I recently released a new gem, fast_forward, which adds support for delegation of all missing methods to another object, and does a bit of dynamic method generation to reduce overhead for subsequent calls. The API looks something like:

  class Foo
    def some_foo_method
      "Hello"
    end
  end
  class Bar
    fast_forward_to :@foo
    def initialize
      @foo = Foo.new
    end
  end

(Note I could have used fast_forward_to :foo if there was an attr_reader for it)

Now, if I create a Bar instance, I can call Foo#some_foo_method transparently using Bar#some_foo_method:

  bar = Bar.new
  bar.some_foo_method
  => "Hello"

What’s cool with this setup is the fact that methods are added automatically to the delegating object when they’re invoked for the first time – future invocations don’t need to check up the object hierarchy and resort to method_missing:

  bar = Bar.new
  bar.respond_to?(:some_foo_method)
  => false
  bar.some_foo_method
  => "Hello"
  bar.respond_to?(:some_foo_method)
  => true

fast_forward is a small library – but the concepts rolled into it have been pretty handy for me in recent projects.

An tv Aside

2007-04-20T00:00:00-07:00

I love my tv, but here’s a tip: use the Photo screensaver option very carefully.

Recently, when I was in Texas, I took a day trip out to the graveyard where some of my family is buried (4-5 generations back), and took a few pictures for relatives.

Seeing the gravestone of your Great-Great-Great Grandfather float by (though very prettily) in the midst of a particularly rockin’ song totally kills the mood, I promise.

Another Day, Another Language

2007-04-20T00:00:00-07:00

The smart folks over at Pragmatic Programmers have done it yet again… I’ve bought another book from them; this time it’s Programming Erlang in the wonderful Beta Book format – how wonderful is it that we developers, mostly an impatient lot to begin with, now don’t even have to wait for a book to be published to start reading?.

Back a few years ago (2002, it seems), I took part in the Language of the Year project, and it really changed my feelings about language learning. Someone that had always been interested in languages, be they natural or … unnatural, I’d already been bouncing around from one programming language to another, but I had this slightly erking feeling that it was a bad idea and that it made me a bad developer. After all, couldn’t I just stick with anything? Was I destined to be a mere dilettante, completely without “professional” focus?

After LOTY, I felt completely vindicated. Through the experience, I came to fully appreciate the reason I love to learn new languages, and how valuable allowing myself to try them out can be. It’s made me a much better developer than if I had just put my head down and let Ruby fill my entire universe – what a shame it would have been without Haskell, Erlang, Smalltalk, OCaml, Io, Lua, Self, et al to help me see the different approaches, new possibilities, and beautiful variations in technique that I’ve been able to incorporate into my problem solving process, code, and outlook!

So, it’s time to revisit Erlang for a bit (along with several others I’ve spoken to recently and read), and nothing makes me more happy at this moment than finding the perfect book to help.

iStalkr

2007-04-02T00:00:00-07:00

An interesting web application that recently popped up into beta is iStalkr, a “social feed aggregator” which allows you to add your RSS feeds to your profile (ie, for me that would be this blog, twitter, flickr, last.fm, delicious, and others), and follow your friends’ without the need for manual intervention (since they manage their own lists). Shareable, personal aggregation, I suppose.

Has anyone seen a similar concept? I think it’s pretty neat.

Hotkey Plugin

2007-03-27T00:00:00-07:00

Rails Plugin Name RubyForge Project

hotkey

Rails plugin to allow javascript-based hotkey assignments to remote and client-side actions.

Badger

2007-03-27T00:00:00-07:00

Current Version Gem Name Documentation

badger

View

A library used to generate badge sheets for events, given a PDF template and data for the badges. Uses pdftk.

With FiveRuns

2007-03-27T00:00:00-07:00

This is a bit overdue, but I’ve been remiss in posting the last month or so (has it been that obvious?)

I just wanted to mention, off the cuff, that I recently signed with FiveRuns, an enthusiastic supporter of the Rails community working in the systems management space, and based out of Austin, TX. I’m lucky enough to be joined at FiveRuns by the venerable Marcel Molina, Jr. of rails-core fame, and working with a talented, visionary group of developers (not to mention all the other smart folks making things tick at the office).

So, I’ve got my nose to the grindstone, as it were – deep in new code, fresh APIs, a unfamiliar domain, and some really exciting work – but I’ll try to catch up, I promise.

Germany in September

2007-02-24T00:00:00-08:00

So, I’ll definitely be attending RailsConf Europe this year (in addition to a slew of other conferences), and I’ve decided that this is the perfect opportunity to look around. I’ve never been to Germany, though it’s always been on my list.

What makes it even better is that I’ll be bringing along my wife, Melissa, for a few days away from our two lovely, but exhausting sons. Melissa’s father was adopted from Berlin as a child, so she’s always had an interest in visiting.

So, here’s the part where having this site really has some advantages. Ideas.

Given a few extra days (let’s say a week total, conference and vacation; I can only saddle my mother-in-law with two small children for so long) and a wife that deserves a quiet, romantic vacation, where would you go? I’ve, of course, heard S. Germany (and Romantische Stra�e), but is there somewhere specific that really pops out in your mind? A few nights in a small village, some area that just must be seen?

Travel by train preferred, but renting a car is an option. Suggestions by real, live Germans (!!!) a bonus.

Gem List

2007-02-20T00:00:00-08:00

Since Mike and Chad have already posted theirs, here’s my gem list:

actionmailer (1.3.1, 1.2.5, 1.2.3, 1.2.1, 1.0.1)
actionpack (1.13.1, 1.12.5, 1.12.3, 1.12.1, 1.9.1)
actionwebservice (1.2.1, 1.1.6, 1.1.4, 1.1.2, 0.8.1)
activerecord (1.15.1, 1.14.4, 1.14.3, 1.14.2, 1.11.1)
activesupport (1.4.0, 1.3.1, 1.1.1)
audioscrobbler (0.0.1)
badger (1.0.0)
barcode (0.2)
BlueCloth (1.0.0)
builder (2.0.0)
capistrano (1.2.0, 1.1.0)
capistrano-ext (1.1.0, 1.0.1)
cgi_multipart_eof_fix (2.0.2)
cocoa_dialog (0.0.2)
color-tools (1.3.0)
cooloptions (1.1.0)
daemons (1.0.4, 1.0.2, 0.4.4)
dhaka (0.0.6, 0.0.5)
diff-lcs (1.1.2)
fastercsv (1.0.0)
fastthread (0.6.2)
fcgi (0.8.7, 0.8.6.1)
gem_plugin (0.2.2, 0.2.1)
greenbar (1.0.1, 0.2.1)
gruff (0.2.8, 0.2.4, 0.1.2)
hoe (1.1.6, 1.1.2)
hpricot (0.4)
instiki (0.10.2)
json (0.4.2)
keybox (1.0.0)
keyword_search (1.0.2)
libxml-ruby (0.3.8)
madeleine (0.7.3, 0.7.1)
mailfactory (1.2.3)
memcache-client (1.2.0, 1.0.3)
mime-types (1.15)
mongrel (1.0.1, 0.3.13.4, 0.3.13.3, 0.3.12.4)
mongrel_cluster (0.2.1, 0.2.0)
mysql (2.7)
needle (1.3.0)
net-sftp (1.1.0)
net-ssh (1.0.10, 1.0.9, 1.0.8)
open4 (0.9.1)
paginator (1.0.8, 1.0.7, 1.0.5, 1.0.0)
pdf-writer (1.1.3)
peggy (0.1.0)
piston (1.2.0, 1.1.1)
radiant (0.5.2)
radius (0.5.1)
rails (1.2.1, 1.1.6, 1.1.4, 1.1.2, 0.13.1)
rails_gem_plugin_shim (1.0.0)
rake (0.7.1)
rcov (0.7.0.1)
RedCloth (3.0.4, 3.0.3)
rmagick (1.14.1, 1.11.1, 1.10.1)
rspec (0.6.4, 0.5.13)
rubyforge (0.3.2, 0.3.0)
rubygems-update (0.9.0)
rubyosa (0.1.0)
rubyzip (0.9.1, 0.5.8)
ruport (0.6.1)
scruffy (0.2.2)
sources (0.0.1)
spacesuit (1.2.0)
syntax (1.0.0)
tattle (1.0.3, 1.0.2, 1.0.0)
termios (0.9.4)
Text (1.1.0)
transaction-simple (1.3.0)
twfy (1.0.0)
twitter (0.0.2)
tzinfo (0.3.2, 0.3.1)
xhtmldiff (1.0.0)
ZenTest (3.4.1, 3.2.0)

After Rails Edge Reston

2007-01-29T00:00:00-08:00

Well, one more Rails Edge conference came to a close yesterday. This was an especially fun conference, with a lot of great people and some really interesting new material by my fellow speakers. The feedback has been excellent, really hammering home what’s been becoming more and more obvious – this conference format really works.

So, my thanks to those of you who made the conference such a success – the attendees!

After my presentation on Building UI Frameworks, I received a large amount

of interest in releasing one of my examples, the folder DSL, as a plugin. I’ll announce it here in a few days – after I have a chance to package it appropriately.

Ch-Ch-Ch-Chia!

2007-01-17T00:00:00-08:00

I’ve never had long hair. I grew up in a family where haircuts where performed on a nearly flawless bi-weekly schedule, and my service in the Air Force really put the nail in the coffin – even the thought of having hair over my ears and down my neck makes me a little crazy, not to mention a bit itchy.

Regardless, as of today I am resolved to grow my hair to a minimum length of at least 10 inches.

I’m not doing this because I’ve mastered electric guitar and am about to live out my dream of headlining an 80’s hair band, or because I’ve given up the trappings of animal enslavement, become a vegan, and plan to live out the rest of my life in a state of blissfully natural, unwashed hippiedom – in fact, I’ll continue to shower regularly and enjoy a good steak.

Rather, I’ve decided that I’m going to support a charity called Locks of Love. Locks of Love is a non-profit organization dedicated to providing financially disadvantaged children suffering from hair loss with hair prosthetics. Common causes of hair loss in children include chemotherapy (read: cancer) along with conditions like alopecia, an autoimmune disorder.

Over the last year I’ve been frequently impressed with the determination of Chad Fowler, a good friend of mine, to support Locks of Love. If you’ve had the opportunity to see Chad at conferences, talks, or training sessions recently, you’ll probably have noticed his hair has been steadily gaining length. He’s serious about doing this, and it’s been hard not to be inspired by that kind of selflessness.

I think this charity is something that’s really worthwhile to support–it’s an opportunity to make a difference in a way a simple financial donation can’t. I really encourage you to look at Locks of Love, and charities like it, and do what you can.

I’ll be making regular posts, probably monthly, on my progress. I’m really curious as to how it will turn out, from both a psychological and aesthetic standpoint. Will I lose my mind? Will my extremely thick, wavy hair doom me to some horrible caucasian afro? Stay tuned. Regular updates, including hair raising photos to come over the next several months.

KeywordSearch Released

2007-01-09T00:00:00-08:00

In the wild

Along with archival and a good UI, the thing that really strikes me about gmail–what makes it really useful–is the search feature. Obviously we expect good search capabilities in anything Google puts out, but the keyword-based searching is extra handy. I find myself doing things like this pretty often:

  presentation "rails edge" from:chad after:2006/08/16

This searches for emails in exactly as it reads; it will return emails from chad containing the words presentation and rails edge that were sent after the 16th of August, 2006. Nifty… and quick.

Google has developed a list of keywords, and in some cases, expected values for those keywords, that are translated into an advanced query. This is an interesting alternative to a large and unwieldy advanced search form.

Over the last couple of weeks I’ve become increasingly interested in adding a similar flexible, easy-to-extend search feature to a Rails application that I’m developing. I’ve wanted to play around with Dhaka since it came out, and this presented the perfect opportunity.

How it works

The library is generic–it’s not Rails-specific by any means– so you could use it for any Ruby project, but for the purposes of this example, let’s go ahead and put together a controller example.

As you might imagine, installation is as easy as:

sudo gem install keyword_search -y

Now let’s require it. In Rails, this means putting the following in your environment.rb:

require 'keyword_search'

For the example, let’s duplicate he concept of searching for messages, in messagescontroller.rb. Let’s work inside an index action (or search, if you prefer), starting out by defining a couple variables we’ll use to accumulate the conditions we’ll need to use in the call to Message.find. There’s better ways to do this (one of which is on my list to release), but for now lets just use a few arrays:

clauses = []
arguments = []
includes = []

The entry point for the library is KeywordSearch.search, which takes a string to parse and a block. Let’s go ahead and parse params:q, in Googlesque fashion:

KeywordSearch.search(params[:q]) do |with|

The method yields an new instance of KeywordSearch::Definition, which is just a handy container to define the keywords we want to allow. In our example, we’re calling the block variable it gets assigned to with… just because it will sound nice later.

First, we should handle the “keywordless” terms that are just floating around– these belong to the default keyword, which we can set with:

  with.default_keyword :text

Lets add a handler for the text keyword, too. In production, you’d probably want to use something like Ferret, or at least fulltext searches, but for this simple example let’s just use SQL like. Keyword handlers are always passed an array of values–keywords might want to allow more than one value, like the text keyword does:

  with.keyword :text do |values|
    # Check subject and body for each, allowing any match (OR)
    clauses << ["(subject like ? or body like ?)"] * values.size).join(' OR ')
    # Add 2 of each value to the arguments, fitted out with <tt>like</tt> globs
    arguments += values.map{|val| ["%#{val}%"] * 2 }.flatten
  end

Keyword handlers use the magic of closures) to give you the flexibility to do whatever you’d like with any variable in scope–in our case, we add a clause and two arguments for each value that’s encountered.

Now let’s deal with from, which is a bit tricker, from a query standpoint, requiring a join. We’ll allow multiple possible values here too:

with.keyword :from do |values|
  includes << :author unless includes.include?(:author) # just a good habit
  # Assuming the author is a User
  clauses << (['users.name like ?'] * values.size).join(' OR ')
  # Glob for <tt>like</tt> comparison
  arguments += values.map{|value| "%#value%" }
end

Let’s only support one since value, though:

with.keyword :since do |values|
  date = Date.parse(values.first) # Skipped exception handling
  clauses << 'created_on >= ?'
  arguments << date
end

Now that we’re done with keywords, let’s just close up the KeywordSearch.search block:

end

… and put everything together for the call to Message.find, building the conditions array as Rails expects:

conditions = [clauses.map{|c| "(#{c})"}.join(' AND '), *arguments]
@messages = Message.find(:all, :conditions=>conditions, :include=>includes)

Of course, you can always paginate the results–or do anything else you’d like with them.

A time and a place

It might be worth noting that Google, in the documentation for the GMail search feature, calls it “Advanced Search.” This feature truly is more advanced than an unwieldy, but in-your-face search form, requiring some effort and memorization from your users. For that reason, this approach might not be the best fit for many applications.

Although the keyword method does take an optional description argument, at the moment generating documentation for the supported keywords isn’t really built into the API, so use in in-house applications is a more likely scenario.

As to the stability and/or usefulness of the library for its intended purpose at the moment… it’s an initial release

From here

There are a number of things that still need to be worked on in the library.

* For the moment, the character set it allows in searches is extremely restricted (alphanumeric and a few extra characters)

* Better parser error handling/reporting is needed

* Dynamic documentation for keywords is desired

* Support for grouping and negation (v2.0)

You can read the API docs here

The Rails Edge Part Deux

2006-12-30T00:00:00-08:00

So, the second Rails Edge conference is quickly approaching; I’ll be flying to the East Coast here in a few weeks, where I’ll be lucky enough to speak alongside some really smart people (again) about something I find a lot of fun– Rails. I will, of course, be talking about Rails Views, and there’s a lot of other interesting things planned.

This one’s in Reston, VA, January 25-27. If you don’t know how The Rails Edge works, the most compelling fact to know about is its format. Casual. Collaborative. Fun. The last conference, here in Denver, was a blast, and the next one, we think, will be even better.

I’m looking forward to seeing you there!

Construction in Dubai

2006-12-30T00:00:00-08:00

This is a bit out of my normal topic area, but I really do love this article on the planned and ongoing construction in Dubai in the United Arab Emirates.

If you love seeing insane building projects, this is the article for you. I grew up in Las Vegas, so I’m used to constant construction and a tourism- focused economy, but this really takes the cake.

What sadly mars the city’s reputation through all this, however, is the treatment of low-wage workers from India, Pakistan, and other countries. Unfortunately the Gulf states in general have a bit of a bad reputation when it comes to poor, expatriate workers; in fact, when I was studying Arabic in school, I heard quite a bit from Egyptian friends about how the elite citizen minority in the Gulf treat migrant Egyptian workers.

What is it with money and bad behavior?

That nifty question mark

2006-12-16T00:00:00-08:00

Here’s a pattern you see a lot of in Ruby:

  foo.bar if foo.respond_to?(:bar)

I do this kind of thing frequently, as I’m a big fan of ducktyping over checking an object’s class explicitly. I’m not concerned with the class of an object as long as it does what I’m asking.

Io has a nice and simple way of doing this, built into the language:

  foo ?bar

If foo has slot bar (ie, in Rubyland it responds to bar), send the bar message to foo.

Simple trick: you can essentially bootstrap Ruby to do the same thing (note I use the word try in this example, which may have too much baggage for some of you):

class Object
  def try(meth, *args, &block)
    __send__(meth, *args, &block) if respond_to? meth
  end
end

Then you can do foo.try :bar

If the object doesn’t respond to the method, nil is returned, as in Io.

Migrate already!

2006-12-14T00:00:00-08:00

For some reason, people seem to have an issue with migrations … they get them confused with schemas. Allow me to explain.

A lot of people seem to sit on changes they want to make models, collecting changes for “one big migration.” As if it were of utmost important that the migration be complete.

Migrations are meant to encapsulate a single set of modifications to your database schema. If you discover suddenly that that your table doesn’t have columns x, y, and z, and you need them for a model, make a migration for it. Don’t hold out on the off chance that you’ll come up with more changes in 10 minutes. Taking care of business, and take care of it now.

Let me give you a few reasons why you shouldn’t be afraid of just migrating already:

Smaller migrations mean there’s less of a chance of making an error in the middle. Migrations that fail in the middle are a whole lot of fun to fix, right?
Smaller migrations make writing self.downs easier; less looking back and forth (if you’re not using a handy feature of your editor/IDE to write them for you)
Naming smaller migrations is easier– there’s less change in the migration you need to describe
More migration numbers mean you can roll back with finer granularity if you need to
Faster changes == Agility. If you don’t care about agility, you just might be using the wrong framework.
There’s no reason not to (unless you’re afraid of another file– eeek!)
“Speed” concerns are poppycock. At over 500 migrations on my mega app, running db:migrate chugs along handily.
A migration number is not sacrosanct. Ruby can count forwards and backwards faster than you can, and, surprisingly, absolutely no puppies or kittens die if you have more migrations.

And there you have it.

Introducing Badger

2006-12-08T00:00:00-08:00

Badges are an expected, even necessary hassle for conference organizers; they identify who’s allowed in the door, help people start conversations, and end up as souveniers once the conference is finished. The problem with badges, though, is that they can be a real pain to put together.

Design-wise, each badge at a conference is essentially the same– but the fact each badge has different information, getting them printed (and looking good afterwards) can be a challenge. Paying a print shop to fill-in the badges can be prohibitively expensive, if they offer the service at all (and having the badges printed is pricey enough). Trying to print over a blank sheet of badges with names, etc, is error prone and, in most cases, the badges come off obviously homemade. Using programs like Publisher isn’t hard to do, but feels heavy, ends up being less nimble if you need to make changes or fix mistakes, and, depending on your OS, may or may not be an option.

For RubyConf 2006, I wrote a small script called Badger which we used to generate the conference badges. It’s a lightweight solution that relies on the use of a PDF form template (which I have a pretty good amount of experience creating), a YAML data source (something any Rubyist can tackle), and an Open Source tool called PDF Toolkit to handle the form filling. It ended up being the right tool for the job; the results are professional, it’s agile (in terms of data changes), easy to automate, and lacking any stringent design limitations (big plus there).

I recently refactored the tool into a RubyGem, and I’m happy to announce its initial release. Check out the documentation, and see the sample project tarball.

You can install the gem, as you might expect, with:

$ sudo gem install badger

You’ll need to be able to create PDF forms (probably with the full version of Adobe Acrobat), and have PDF Toolkit installed.

Adding Date and Time Formats

2006-12-05T00:00:00-08:00

This is nothing new, but, having seen enough Rails developers using custom helpers to do the same thing, I thought it might warrant a quick tip.

If you’re entering dates/times in your fixtures, you’re probably familiar with this trick:

  ---
  item1:
    id: 1
    name: foo
    created_at: <%= 3.days.ago.to_s(:db) %>

Memoizing nil and false

2006-12-03T00:00:00-08:00

Here’s a common technique:

def foo
  @foo ||= compute_foo
end

For those that don’t know, this is an example of memoization; we only computefoo if @foo hasn’t been assigned a value.

Well, that’s not strictly true. Let’s say that compute_foo returns nil or false, completely acceptable values for @foo. Let’s also say that computefoo take 2.3 minutes, chugs 150MB of RAM while running, and hits the network like a room full of Rails programmers at a conference (just for kicks– I have no idea what compute_foo does, but it’s resource intensive, obviously).

Using this traditional memoization technique, if compute_foo returns nil, we’ll be calling compute_foo unnecessarily every successive time we call foo. Oops.

Ruby’s pretty dynamic, so let’s make use of it:

def foo
  @foo = `compute_foo` unless `instance_variables`.include?('@foo')
  @foo
end

Let’s add Rails-style “expirable” memoization, too:

def foo(force_reload=false)
  unless `force_reload` || !instance_variables.include?('@foo')
    @foo = compute_foo
  end
  @foo
end

And there you have it.

Keep in mind what I’m talking about is definitely an edge case; in most situations, compute_foo won’t return nil or false, so this won’t come up. Also, if you find expirable memoization to be tedious to do by hand (like any sane person does), take a look at Marcel’s memoize in aws/s3 for a nifty approach.

RubyGem-based Rails Plugins

2006-11-29T00:00:00-08:00

One thing about Rails that’s a bit annoying to those of us who have been using Ruby for a long time is the lack of support for RubyGem-based plugins.

You have to take into account the kind of torture conversations like this were, for years upon years, and the kind of psychological damage it did to all of us:

What’s Ruby’s CPAN?

Anything like CPAN for Ruby?

What’s the package/library manager for Ruby?

Ruby sucks! Where’s CPAN?

Every time someone new ran into Ruby (often from Perl, especially in the beginning), it would inevitably come up– and someone would respond (out of ignorance or some type of masochistic delight), and it would ping-pong back and forth for a few days. It was the Ruby mailing list equivalent of Groundhog Day … but less fun. It was painfully repetitive, annoyingly pertinent, and frankly, a bit embarassing (how long it went on, at least). Thankfully, a group of great developers put together RubyGems out of the blue, and it caught on (beating back a bully or two in the process). RubyGems is a complete success– that’s obvious from the tremendous download stats– and the fact we don’t have those annoying CPAN conversations anymore.

Don’t get me wrong.. script/plugin install is great; it’s been wonderful. It’s fast, it’s easy, and it’s a large part of why Rails development is so compelling– the community is involved … plus, it just works. But let’s keep in mind that the Rails community is growing out of control… plugins are becoming more widespread and advanced, and as such an important aspect of Rails, dependency resolution and versioning needs to become a serious concern if we want to keep plugins quick, fun, and easy to get working. The good news is we don’t need to reinvent the wheel, RubyGems is easily up to the task.

Truth be told, people have been talking about gem plugins from the beginning, and there have been certain in-roads (as with generators)– but it hasn’t been easily built into Rails itself.

Tonight I submitted a patch to do just that. It’s a bit naive, and likely broken in a few places… but hopefully it will spark some serious conversation, some good work, and someone smarter and more savvy than I will take up the torch and do something useful with it.

The idea is simple; install gems and use the existing plugin configuration to select what plugins you’d like to load (including version requirements) for each application. It’s backwards compatible; you can still use normal plugins if you’d like– but the gem plugins are structured the same way, have the same capabilities, and come with all the inherent benefits of RubyGems intact.

Rails Views,

2006-11-21T00:00:00-08:00

I’ve noticed recently, looking through my traffic, that a good number of people still come around looking for my dom_id articles.

I think it’s worth mentioning that you shouldn’t be using my dom_id code anymore- if you’re running a up-to-date version of Rails (maybe only edge?) you’ll want to use the simply_helpful plugin instead; I do.

It wraps the DOM ID related stuff with lots of RESTful goodness, so use it.

TFWY 1.0.0 Released

2006-11-21T00:00:00-08:00

I’m proud to announce (along with my co-author, Martin Owen) the v1.0.0 release of the Ruby bindings to the TheyWorkForYou API. TheyWorkForYou is a “non-partisan, volunteer-run website which aims to make it easy for people to keep tabs on their elected and unelected representatives in Parliament.”

The Ruby bindings currently support all of the services offered by v1.0.0 of the API, and makes accessing the data very, very easy to do.

Simple Examples

Get a client…

  require 'twfy'
  client = Twfy::Client.new

Then call services on it directly…

  puts client.constituency(:postcode=>'IP6 9PN').name
  # => Central Suffolk & North Ipswich
  mp = client.mp(:postcode=>'IP6 9PN')
  puts mp.full_name
  # => Michael Lord
  # Get a *lot* of info about this MP
  info = client.mp_info(:id=>mp.person_id)
  # Get a sorted list of all the parties in the House of Lords
  client.lords.map{|l| l.party}.uniq.sort
  # => ["Bishop", "Conservative", "Crossbench", "DUP", "Green", "Labour", "Liberal Democrat", "Other"]
  # Get number of debates in the House of Commons mentioning 'Iraq'
  number = client.debates(:type=>'commons',:search=>'Iraq').info['total_results']

Or, make use of the “daisy chaining” available for services– the correct arguments are passed around for you (plus you get the benefit of some in- memory caching).

  # Get the MP for the last constituency (if you sort them alphabetically)
  mp = client.constituencies.sort_by{|c| c.name }.last.mp
  
  # get the geometry information for that constituency (coming from the MP)
  geometry = mp.constituency.geometry
  
  # An overkill example showing caching (no services are called here, since
  # the results have already been cached from above)
  mp = mp.constituency.mp.constituency.geometry.constituency.mp
  
  # These return equivalent results (Note how much easier the first is)
  info1 = mp.info # this is cached for subsequent calls
  info2 = client.mp_info(:id=>mp.person_id)
  
  # Get pages of debates mentioning 'medicine'
  debates1 = mp.debates(:search=>'medicine')
  debates2 = mp.debates(:search=>'medicine', :page=>2)

See http://www.theyworkforyou.com/api/docs for the original TheyWorkForYou API documentation. The Ruby bindings has RDoc up at http://twfy.rubyforge.org. The project is still in its beginning stages, and feedback is and always will be welcome.

Get it

As with any gem…

$ sudo gem install twfy

Why I did this

It might be worth mentioning that I live in Colorado– a fair ways distant from London, or from anywhere else in the UK, for that matter. So why did I do this?

Sometimes I get bored, and that boredom eventually drives me to search for crazy, off the wall things to do. TheyWorkForYou is just one of the rare useful projects I’ve run across, and I couldn’t resist tossing some Ruby goodness at it.

My Rails Edge Wrap-up

2006-11-21T00:00:00-08:00

So, over the last few days I had the opportunity to be a speaker for The Rails Edge held in Denver, CO (incidently, just down the road a bit). The Rails Edge is a unique series of Rails-related conferences held by The Pragmatic Studio that will be held regionally across the US. What makes them unique is their format– open, friendly, and focused on up-to-date Rails information. The way I wish all conferences were.

I really enjoyed the conference, and definitely get the impression that the attendees did, too. This wasn’t a conference where the speakers only popped out to speak, keeping themselves isolated the rest of the time. If there’s anything the speakers have in common, it’s a very sincere love of Rails, teaching, and learning from each other (and the attendees)– and I think that was pretty obvious. In terms of atmosphere, it was definitely one of the best conferences I’ve been to (and in terms of material, I think it was pretty damn top-notch– but I’m a bit biased).

So, if you’re interested in Rails– what it can do and where it’s going– and have a passion for learning, I urge you to take a look at this conference series. The speakers have a lot to say, the format is built around collaboration and learning from each other, and we’re conveniently travelling the country to make it available to everyone.

The next one is in Reston, VA, in January… see you there?

The Rails Edge starting

2006-11-15T00:00:00-08:00

So, tomorrow The Rails Edge starts up.

As I get ready to hop into my car and drive the scant 30 minutes it will take to reach the venue (I’m lucky– this one is right in my neighborhood), I can’t help but be excited. I love conferences. They’re exhausting, but you can’t beat the experience of being at a location with so many people with the same passion for development.

RubyConf and RailsConf, this year always give me a huge boost of morale, seeing the new and interesting things that people have been working on. With the unique format of this conference (it feels more collaborative and “friendly” than most) I can’t wait to see the kind of discussion and ideas that will come out of it.

TextMate goes spooky

2006-10-31T00:00:00-08:00

Definitely the biggest surprise from today’s TextMate update was the new, spooky, and– I’m guessing–temporary– change of icons. I’ve gotten used to Google’s holiday theming, but this is probably the first time I’ve had a desktop app get festive on me.

Pretty neat, I think. I wonder what they have in store for Christmas.

Rtex moved to RubyForge

2006-10-29T00:00:00-07:00

The Rtex Plugin (LaTeX view engine for Rails) has moved to it’s own RubyForge project.

The subversion repository is now at svn://rubyforge.org/var/svn/rtex/trunk. I’m be making some non-backwards-compatible modifications to the way the plugin is configured during the next few days, but the current stable release will always be available at tt>svn://rubyforge.org/var/svn/rtex/tags/legacy.

Ruby Central Redesign

2006-10-25T00:00:00-07:00

Recently, I’ve been working with the directors at Ruby Central on a new design for their website, now running on top of Radiant.

At RubyConf, the new design was released. It’s a simple, clean design sporting their new logo (also by yours truly).

Onward Hoe!

2006-10-24T00:00:00-07:00

This is just a quick followup to latest release notice.

I used Hoe to release the paginator files… and I have to say that’s the easiest, least painful release I’ve ever done. As Ryan said at the conference, it makes it easy enough to release more often, and that is spectacular!

As a self-described Rake nerd, I find Hoe to be truly compelling from a technical standpoint– but its possible effect on the community is even more exciting. Quicker, smaller releases are better for everyone, and with the addition of sow to the library, getting up and running is easier than ever.

My thanks to Ryan Davis and Ara Howard (not to mention the bevy of other contributers) for making something like this available to the community.

Paginator Released

2006-10-24T00:00:00-07:00

Writing paginators sucks, and it’s something that we get stuck with doing from time to time. Deceptively simple, they can be pretty tedious to write– and they’re definitely not the type of code that makes you go, “Wow, that’s just cool!” I mean, comeon… this isn’t rocket science, it’s just boring.

The problem with most paginators (ie, the paginator in Rails) is that they’re tightly coupled with what they’re paginating– so it’s difficult to just rip them out and use the code elsewhere. On top of that, many times they’re too rigid (hard to change pages) or make it difficult to query for metadata (is this the last page?).

For a while now I’ve been using a “custom” paginator in my Rails projects; a small library I wrote so that I would have more control over changing pages and seeing metadata. From the beginning this paginator was written to be framework agnostic– something I can just rip out and use elsewhere (ie, a CLI, etc)– for one simple reason. I never want to have to write another paginator again.

Today I released the paginator 1.0.0, available as a gem. Here’s a quick example:

Rails

In your controller

  PER_PAGE = 20
  @pager = Paginator.new(Foo.count, PER_PAGE) do |offset, per_page|
    Foo.find(:all, :limit => per_page, :offset => offset)
  end
  @page = @pager.page(params[:page])

In your view

  <% @page.each do |foo| >
    <# Show something for each item >
  <% end %>
  <%= @page.number %>
  <%= link_to("Prev", foos_url(:page => @page.prev.number)) if @page.prev? %>
  <%= link_to("Next", foos_url(:page => @page.next.number)) if @page.next? %>

Elsewhere

bunch_o_data = (1..60).to_a
PER_PAGE = 10
pager = Paginator.new(bunch_o_data.size, PER_PAGE) do |offset, per_page|
  bunch_o_data[offset,per_page]
end
pager.each do |page|
  puts "Page ##{page.number}"
  page.each do |item|
    puts item
  end
end

It’s pretty simple stuff. You instantiate a Paginator object, telling it how many records there are and how many you’d like per page. You also pass a block that will be used to return the records for a page, given the record offset (and the number of records per page– which you just passed into the constructor– as a convenience).

To get it, it’s simple:

$ sudo gem install paginator

The full docs are here.

The theme goes official

2006-10-24T00:00:00-07:00

I’m happy to announce that my RubyForge theme, after flying under the radar for some time now, has been adopted as the official, default theme. Many thanks to RubyCentral and the RubyForge team for their support during the design.

If you run into any problems with the theme, please contact me so that I can address them.

Rake Shame

2006-10-23T00:00:00-07:00

If you’ve ever been working on a Rails application (or any application, for that matter) and found yourself stupidly slipping in your testing, I have just the tool for you.

Using rake and rubyosa, you can now automatically post your Code to Test Ratio as your iChat status message– meaning you can now use shame and self- humiliation to keep you motivated.

First, take a look at Mike Clark’s instructions for setting up rubyosa. After you’ve set up rubyosa, add shame.rake to your lib/tasks directory, which contains:

require 'rbosa'
require 'code_statistics'
task :shame do
  stats = CodeStatistics.new(*STATS_DIRECTORIES)
  code  = stats.send :calculate_code
  tests = stats.send :calculate_tests
  ichat = OSA.app('ichat')
  msg = "Code To Test Ratio: 1:#{sprintf("%.1f", tests.to_f/code)}"
  ichat.status_message = msg
  $stderr.puts %|iChat status set to: #{msg.inspect}|
end

Type rake shame and let the mocking (and motivation) begin!

Simple Complexity

2006-10-19T00:00:00-07:00

Rails is simple– or complex– depending on how you look at it. There’s a lot of complexity under the covers that makes creating applications simple. This simplicity can be a bit misleading; surely something everyone says is easy to use can’t solve complex problems or cater to rich domains, right?

While it’s true that Rails can’t simplify the problems and concerns that exist in a rich domain, it can make them easier to deal with. The fact you have a good, sturdy walking stick doesn’t make the mountain any shorter, it just makes it less exhausting.

Although you can still find plenty of naysayers out there complaining that Rails is unsuitable for the enterprise, and that anything based on a “scripting” language is just a hacked-together solution (thank you, very much), those of us who are writing huge web applications know better.

Take a look at the curious imaeg to the right… what is it? A drapery that I have, for some crazy reason, deemed interesting enough to dress up with a drop shadow and post?

No, it’s a very small detail of my application’s model diagram, showing models (ovals) and associations (lines). By “small” I mean– at most– 1/50th. Wer’re talking over 250 models with over 1,100 separate associations. And I just shiver at the thought of doing this in PHP, CF, JSP, or ASP (okay, vomit in the case of ASP).

IThis ain’t no /t(oa)d\1\slist/, folks.

Rails Views,

2006-10-19T00:00:00-07:00

I thought one or two of you might be in the market for a nice, full-time Rails job, and wouldn’t mind moving out to beautiful Broomfield, CO to do it. On the downside, you’d be working with me ;-)

Here’s the blurb:

Naviance is a small, well-established software company catering to the education domain. We�re currently seeking another full-time Rails developer to work at our Broomfield, CO office.

If you’re interested and would like more information, contact me.

RubyForge Theme

2006-10-06T00:00:00-07:00

Tom Copeland recently brought to light the existence of my RubyForge theme. It’s been around for awhile, but not something we really announced (just a mention on the credits page).

I was pleasantly surprised by the number of people who’ve elected to use the theme. If you’re in the market for a change of pace, please try out the theme. Your feedback (as always), is welcome.

The Problem with Solutions

2006-10-05T00:00:00-07:00

If there’s anything that there’s a lot of these days, it’s Javascript.

Seriously, take a look around. It’s everywhere. We’re not talking about the dumb marquee scripts and other “toys” that constituted the Dark Age of Javascript, either– it’s been the Rennaissance of Javascript for a while now– with Web 2.0, smart people are putting spectacular things together with Javascript every day.

“Web 2.0” has largely been about Javascript and our growing acceptance (and respect) for this much-maligned language, and as more people seriously started looking into the language, major libraries emerged to make life easier. Libraries like Prototype provide a layer of abstraction to protect us from browser irregularities, give us ways to handle data structures more naturally, and include “remote” request toolkits (ie, Ajax.Request and friends) that have quickly become the Web 2.0 standard.

This movement towards the use of foundational libraries has created its own niche market, the small compact scripts touting their lack of a requirement for these libraries, since they’re “too big.”

The problem with these little frugal scripts is that if you are using Prototype (or whatever library you prefer), the following things are probably true:

They’re longer than their Prototype-based equivalents would be– being less frugal in your case ($$ is obviously shorter than document.getElementById, and that’s just one function call, iterations are worse)
They’re more brittle, since they rely on different, sometimes spotty, ways of watching for browser irregularities (meaning more redundant code, too)
They provide wildly different APIs. Use of Prototype, etc, encourages the building of similar APIs (ie, MyLibrary.myFunction() vs someRandomFunction())
Their authors completely ignore the fact that caching exists and, in many cases, is good enough for most cases

I’m not saying that authors need to provide “Prototype” and “Lite” version of scripts they provide (this is free code, after all)– but if you’re using Prototype and you are looking at a non-Prototype-based script, you need to be aware of these issues. If you’re uncomfortable with the tradeoffs, have the chops, and the license permits, why not modify the script to sit on top of Prototype, rather than beside it?

Hopscotch

2006-10-03T00:00:00-07:00

Moved servers and changed stuff around a bit, so things might be hectic for a day or two. I’ll get the feeds working from the old URLs here shortly.

I’d put animated construction banners up just to be nostalgic, but I don’t feel that lame today.

Getting to know Io

2006-10-03T00:00:00-07:00

Those of you who know me well know that I’m a fan of languages. You could say this is one of my defining characteristics– right next to my addiction to caffeinated beverages

Provided a language meets a small set of criteria (cross platform, free) and has some unique characteristic(s) that catch my attention, I’ll give it a look. To do otherwise would just be narrow-minded (which is the same thing as being self-destructive, as a developer).

Io is just such a language. I’ve run into it a few times over the last few years, and as I’ve noticed an increase in interest in this fairly young language (especially by fellow Rubyists), I thought I’d show it some attention.

In this article I’m just going to discuss the very basic concepts of prototypes

Classless is Classy

Io can be a bit of a shock for those that haven’t played with other prototype languages like Self; we’re talking about a classless OO language here. Objects are just that– objects. The idea that there are special “blueprints” to an object simply doesn’t exist as a first-class concept.

Is this a class?

Car := Object clone

No, Car here is just an object, and so is Object. We can treat this incarnation as a class (cloning more objects from it), or we can just add data and logic to it for immediate use. For this example, let’s show how it can be used as a class, since we’ll want to have a whole autobahn of cars.

Slots are just that

, Objects have “slots,” which, essentially, are the list of messages that it responds to. “Car” in this example, is a slot in the Lobby object, the object our program is running inside. We could have written it Lobby Car := Object clone, instead.

Now let’s add a few slots to Car. These simple ones are somewhat analogous to attr_accessor:

Car newSlot("make")
Car newSlot("model")
Car newSlot("mpg")

Which just create blank slots for “make” and “model.” We can also assign slots directly. Let’s pretend all cars come with a full 16 gallon tank of gas, and there’s nothing on the odometer.

Car fuel := 16
Car milesDriven := 0

A slot is just a slot, and can also hold a method. Let’s make this baby roll. The syntax might seem odd at first, but you’ll pick it up.

Car drive := method(miles,
  fuelToUse := miles / mpg
  if(fuelToUse > fuel,
    "Fill 'er up first" println
    false
  ,
    milesDriven = milesDriven + miles
    fuel = fuel - fuelToUse
    "Miles Driven: #{milesDriven}, Fuel: #{fuel}" interpolate println
    true
  )
)

Something worth mentioning is the fact that the name Io, while short and sweet– and a name I particulary like– can make google searches for material pretty tricky. I recommend io language as a search term instead of the more false positive-prone io.

A Child is Born (again)

2006-09-13T00:00:00-07:00

My second child (and son), Jamis Peter Williams, was born at 8:46pm MST yesterday, the 11th of September.

We’re tired, and excited, and happy– and tired. I’ll get back to the grindstone soon, but I’m taking a short break for now.

Hotkey Plugin

2006-08-22T00:00:00-07:00

Recently I needed to add hotkeys to our application for quick navigation. The result of this work is the Hotkey plugin, which I’m releasing today.

The Hotkey plugin consists of a Javascript file and three helpers that use it. You can add a hotkey using Javascript directly using the Hotkey.add() function in your application.js, or you can use the helpers in your templates. Here’s a few examples of helper usage:

Calling an action remotely:

<%= hotkey_to_remote :d, :url => {:controller=>'some_controller'} %>

Changing browser location:

<%= hotkey_to :h, :controller => 'home' %>

Calling an arbitrary function:

<%= hotkey_to_function :p, "showPreferencesPanel();" %>

Here we’ve defined three hotkeys; d, h, and p. Pressing a modifier key (which modifier key depends on the browser/platform you’re using) and the letter activates the associated function.

The plugin is very easy to use, and suits our needs. Hopefully it will help out a few others.

Take a look at the README after installation for additional setup information.

Update 2008 I avoid “obtrusive” javascript whenever possible, so I don’t recommend this approach any longer.

Rails Views, Upgrade to 1.1.6!

2006-08-09T00:00:00-07:00

A quick aside, since it’s important:

In case you haven’t already heard the news, make sure you upgrade to 1.1.5 1.1.6 immediately due to a security issue in previous versions of Rails.

If you’re running Edge Rails, you’re okay.

patch-and-other-tidbits

Rails Views, Rails Edge

2006-08-08T00:00:00-07:00

Recently I accepted an invitation to be a speaker at The Rails Edge, a series of unique Rails-related conferences brought to you by the folks at The Pragmatic Studio. It’s an honor to be included alongside some of the smartest Rubyists/Railers out there.

My focus, as you might imagine, will be the development of Rails views– building small frameworks to minimize the chaos inherent in the view layer of any framework. I’ll go beyond the scope of the Rails Views series you’ve been reading here, delving into the implementation of the frameworks I’ve put together, and talking a bit more about my personal approach to developing views.

The first Rails Edge event is in Denver, November 14-16. I hope to see you there!

Buzzwords and Pitchforks

2006-07-17T00:00:00-07:00

A large portion of my life has been dedicated to the study of language. I studied and worked professionally with Arabic for a number of years, and have picked up little bits and pieces of various other languages as I’ve played around with them. I’m learning Hindi now, though more slowly than I’d like (anyone giving away free Hindi lessons near Boulder, CO?), and I’ll probably continue to tinker with languages until my dying day.

One of the funnier things about language is the way it changes over time– and in different circumstances. English is a good example of this; it’s changed so much in the past thousand or so years, and is such an amalgam of other languages, that it barely resembles the language it once was.

The changes can come pretty fast, too– especially in the IT industry. Our vocabulary is a constantly shifting landscape, brought on by various technologies coming to the forefront and slowly fading away– a landscape punctuated by buzzwords and the IT community’s reaction to them.

Buzzwords, we think, are like marketing slogans. Those of us that consider ourselves really hardcore developers think of them as some type of business scourge– the worst kind of proprietary technology marketing, little word- sized billboards advertising techniques and materials of no value whatsoever, attached to projects at a whim to garner attention.

Buzzwords are so hated, in fact, we have Anti-Buzzword Buzzwords. Mocking phrases like “Buzzword Compliant” to describe a group or project, a label of irrelevancy. We sneer, or pointedly ignore, anything tainted with buzzwords, considering them beneath our dignity.

The Rails community has been under attack since its inception for buzzword compliance, especially since Prototype (and RJS) cause the dreaded “AJAX” word to be uttered pretty regularly by what we’re now calling Railers.

Here’s the thing. I think sometimes a buzzword is just a common word for something– a word that everyone immediately understands when it is said. It’s counter-productive to describe something by anything other than the most common, understandable term– and for that reason I support using “AJAX,” to describe that particular set of technologies that XmlHTTPRequest is a part of.

But watch out next time you mention “AJAX” on the streets; there are literally droves of XmlHTTPRequest language purists out there with torches, pitchforks, and stacks of prosaic blog entries– they could very well drive you crazy with their incessant whining.

Rails Views, Preprocessing Parameters

2006-07-14T00:00:00-07:00

I’m a long-time lover of the simplicity of YAML, especially the underused domain type functionality. There’s just something about taking some chunk of text and saying “turn this into an X using the following process” and having it take care of things for me that’s just cool. Recently, I’ve put together something similar, but less structured, for params hashes, that I’m releasing as a plugin called param types.

Using param types is simple. First we define the different types we want to support, and how to convert values to them. Here’s an example for supporting multiple formats of incoming date parameters (I put this in environment.rb, but you can do it elsewhere):

  ActionController::Base.add_param_type 'date' do |value|
    case value
    when String
      Date.parse(value)
    when Hash
      Date.new(Integer(value['year']), Integer(value['month']), Integer(value['day']))
    end
  end

Here we’re registering a new param type ‘date’, and giving it a block to convert values. The block will be yielded the raw value of any incoming parameter matching the type you’ve defined, and the value returned by the block will be the new value of the parameter.

How do we say, on the view side, that a parameter (ie, form element) should be considered a particular type? A naming convention, of course.

Param types are defined by the use of parenthesis. For example:

  <%= text_field_tag 'birthday(date)' %>

This defines a parameter, ‘birthday’, with the param type ‘date’. Since we’ve defined a ‘date’ param type, we’ll end up with params[:birthday] (converted to a Date by our block) rather than a plain params["birthday(date)"] String.

It works with nesting, too.

  <%= text_field_tag 'student[birthday(date)]' %>

In this case, you’d end up with params:student, as you might expect.

The ‘date’ example above could also handle a Hash of date components, like:

  <%= text_field_tag 'birthday(date)[day]' %>
  <%= text_field_tag 'birthday(date)[month]' %>
  <%= text_field_tag 'birthday(date)[year]' %>

… or as selects, of course– and it will put the date together (as params:birthday) for you.

This is really just the tip of the iceberg– since params are converted depth- first, you can use the results of deeper conversions in shallower ones– making the building of really complex types possible.

If this sounds interesting, feel free to look at the README and install the plugin:

  ruby script/plugin source http://svn.codefluency.com/rails/plugins/
  ruby script/plugin install param_types

As you may know, I’m a big fan of form_for and FormBuilder. I’ll be going over how to integrate param_types with them soon, so stay tuned.

One of the trickiest things to deal with when developing complex interfaces in Rails is how to pass along objects as parameters.

This is easy when you’re dealing with simple bits of data– values in params are strings, and with some PHP-like magic with brackets, we get arrays and hashes of them. This is all part of built-in actionpack functionality. Integers (Fixnums) are easy, since parsing them on the action side is as simple as to_i (or, for the savvy, Integer())– and a lot of the time we’re using them in conjunction with ActiveRecord::Base#find anyway.

So how do we handle more complex cases? How do we pass along more complex objects?

Let’s start with dates. Sure, sure, Rails has date_select, select_date, etc, and they have their own bit of special-case magic that handles date conversions. But let’s be serious here– does anyone love the interface that these provide? Not that we should complain, mind you– they’re free and in a lot of cases they’re all we need… but for a consumer app, the sad fact is that a lot of us end up rolling our own date/time widgets (ie, with AJAX calendars). Then we go about manually parsing dates out of params using beforefilters or even calls to private methods directly from actions.

This manual parsing is no fun, folks– and it’s not limited to dates. There’s a lot of cases where data coming in from requests needs to be munged for one purpose or another, and having to keep track, on the action side, of what needs to be converted is tedious– and, in my opinion, somewhat inappropriate for the action side of the relationship. I want the actions to do stuff, not to be manually told to convert/parse the parameters that tell it what to do, then do stuff.

Can we make this more transparent?

Safari and the Stray Comma

2006-07-10T00:00:00-07:00

Here’s a little tidbit. Safari doesn’t like stray commas in Javascript (Firefox just ignores them, and IE is too busy choking on everything else to notice). Here’s an example of an offense:

new Effect.Highlight('foo', {duration:0.5,startcolor:'#ff99ff',});

See that extra trailing comma? Safari completely hates it. No neat highlight for you– sloppy coders are punished severely in Safari-land.

A few months back, I added a test to catch these. It goes something like this (it’s weak, I know, but it works):

  def test_no_stray_commas_for_safari
    Dir[File::join(RAILS_ROOT,'public/javascripts','*.js')].each do |filename|
      found = File::read(filename) =~ /([^\r\n]*),\s*[\]\})]/sm
      assert_nil (found, "Found possible stray comma in #{File::basename filename} at char index #{found} near:\n--START JAVASCRIPT--\n#{$1}\n--END JAVASCRIPT--" )
    end
  end

… and, what do you know, today it saves the day.

Rails Views, Getting In Context

2006-07-02T00:00:00-07:00

In the view, you need to set the context parameter. If you’re using link_to_remote, just set it manually. If you’re using a form, you can use the context_tag helper. Here’s examples of both in action:

  <%= link_to_remote "Complete", :url => {:controller => 'items', :action => 'update', :id => item, :params =>{:complete=>true,:_context => "Workflow One"}} %>

<% remote_form_for :item, item, :url => {:controller => 'items', :action => 'update', :id => item} do |f| %>
  <%= context_tag "Workflow Two" %>
  <%= check_box_tag :complete, true %>
  <!-- Other Stuff Here -->
<% end %>

Both of these hit one action, update. In it, we can use in_context to wrap our separate renders (mixing with respondto).

def update
  # Update stuff here
  respond_to do |format|
    format.html
    format.js do
      render :update do |page|
        # Stuff at this point happens regardless of context
        in_context do |context|
          context.nil? do
            # This happens if no context is passed
          end
          context.workflow_one do
            # For the link
          end
          context.workflow_two do
            # For the form
          end
        end
      end
    end
  end
end

If this looks like something that might help out, feel free to get it at http://svn.codefluency.com/rails/plugins/context. I’ll put it up on the Plugins page for installation via script/plugin install once the page editing is working again (it’s giving me a 500 error at the moment).

As usual, you can drop me a line if you have questions, suggestions, or comments.

So, here’s the problem. Let’s say that, in our application, we have different types of users that need to be able to do the same thing from different places. Their workflows are different– maybe one manages a list of items that need to be completed (they sit on that page, all day long, doing just that), and another visits each item’s page separately (in the process of managing more of the item’s information) and may complete items individually from that interface.

We need to support both ways of completing items– or maybe even more, and we want completion to occur via AJAX. Support for multiple workflows is a natural feature of complex products; the messy truth is that, sometimes, there’s no One Interface to Rule Them All. The land of picky users with long- established workflows, sadly, is not a minimalist Utopia.

Of course, if all our workflows are hitting the same controller action, the action needs to be aware of the context– different javascript may need to be returned for each workflow (we might reload a div in one case, and remove the item from a list in another, for example). We could just have a different action to support each interface– but that’s a bad kludge I won’t even address. I support the single-action, selective-render approach for the same reason I use respond_to instead of having separate actions for HTML and JS requests– sure, it might be verbose, but at least it’s DRY.

So, how do we let our action know the context from which it’s being called? There’s really not a clean option, since relying on referer is a bad idea (not to mention not enough information), but one approach– the one I use– is to pass along a parameter in requests, and have the action check for it, rendering the correct response. Since this can be a bit tedious (not to mention ugly) in practice, I’ve put together a little plugin called context to help out. Here’s how to use it.

Rails Views, Bulletproofing dom_id

2006-07-02T00:00:00-07:00

In my eternal quest to stave off DOM ID collision, I recently had to make a few small changes to the original domid]1 script from the indomitable Jamis Buck.

Recently, I needed two forms on the same page for two models from the same single-table inheritance table (though that’s not part of the issue), and I wanted to use the same prefix for both. Since the vanilla dom_id scheme removes the class name when a prefix is defined, collision would occur. My modifications ensure the class name is always included– after all, I don’t care how long the DOM ID is– part of the beauty is I don’t even have to know what’s being generated.
I removed the :bare prefix option, as I never use it (though some of you may).
I replaced dashes with underscores. I prefer dashes, myself (for CSS classes, too), but due to the reported issues with dasherized ids and scriptaculous drag-and-drop (a feature I use very, very rarely), I’m reluctantly letting them go.

Some examples:

>> person = Person.find(:first)
>> person.dom_id
=> "student_1" # Note: The first person is a Student
>> person.`dom_id` 'some_prefix'
=> "some_prefix_student_1"
>> Person.new.dom_id
=> "person_new"
>> Person.new.`dom_id` 'some_prefix'
=> "some_prefix_person_new"

Keep in mind that, since my original posting, a few people have released slightly-modified plugin versions of dom_id (most notably Geoffrey Grosenbach). They might already meet your needs.

RailsConf Facebook

2006-06-20T00:00:00-07:00

The facebook for RailsConf 2006 is up and running– if you’re going to the conference, don’t forget to post!

Many thanks to Rick Olson who created the facebook app; I just themed it for the conference.

Rails Views, Spring Cleaning

2006-06-19T00:00:00-07:00

The way I do this is with a Rake task. Rake and Rails go so well together, and we already have a boatload of custom Rake tasks in our app, so it was an easy decision.

Basically, what I wanted was a quick way to see what helpers and actions weren’t being used. Just a simple list that I could use to help me find things that we probably didn’t need anymore.

So here it is:

Keep in mind this is NIX only (since that’s all I care about, currently), and is in no way comprehensive. Someone could easily make this pure-Ruby, safer, or simply more intelligent.

namespace :stale do
  task :helpers do
    stale_for_glob 'app/helpers/*_helper.rb'
  end
  task :actions do
    stale_for_glob 'app/controllers/*_controller.rb'
  end

  def stale_for_glob(glob)
    Dir[glob].each do |filename|
      File.open(filename) do |file|
        file.each do |line|
         if line =~ /^\s*def\s+([[:alnum:]_]+)/
           meth = $1
           if `grep -R '#{meth}' app vendor/plugins | grep -v svn`.strip.split("\n").size <= 1
             $stderr.puts "#{filename} : #{meth}"
           end
         end
        end
      end
    end
  end
end

What does this do? Well, it looks though the helper (or controller) files, and tries to find helpers (or actions) that are only defined and not used. Granted, it’s not flawless. If you have helpers or actions that have the same name and are defined in different files (not an edge case), there’ll be false negatives. You’ll also need to run it several times as you remove items, since one helper may only be called from another that you’ve removed. Don’t just rip out all the helpers (or actions) that show up in the results, either. Maybe they’re just not being used yet (and maybe they’re the hard work of your fellow developers, too).

Don’t forget to remove the test cases for anything you remove, too.

The point here is to dredge up old helpers and actions that, when you see them, will cause a lightbulb to go off over you head. Maybe you’ll exclaim, “Ah, I remember that piece of crap– I thought I got rid of that a month ago!”

Now really get rid of it. Shorter code is happier code.

If you’re developing a large Rails application, chances are you’re going to end up creating a lot of extra helpers and actions that fall into disuse– helpers are generally tightly coupled with views and often exist due to design decisions that end up changing over time, and actions can just as easily become obsolete.

This is a natural side-effect of long-term development. But you need to get rid of all that clutter; it affects your test statistics, it means more code to shuffle through to find things you are using– and it’s just plain ugly to keep around.

Rails Views, Rails Recipes Selections

2006-06-16T00:00:00-07:00

These are in no particular order, and certainly aren’t the only recipes that I’d recommend– just the ones that immediately jump out at me as I flick through my copy.

Recipe 52: Making Your Own Rails Plugins

Plugins aren’t just for monkey patches and portable “drop in” functionality. You can toss views into plugins as well to make your app even more modular– or provide a common interface across different applications. This recipe gives you a kick start on putting together your first plugin. Plugins, people, are a mandatory skill.

Tip: I usually create a files/ subdirectory inside plugins, throw my views in there, and use my good friend, render :file with a relative path to take care of business.

Recipe 44: Write Tests for your Helpers

Now helpers can have all the stable goodness that TDD can help make possible; this recipe helps you set-up a test environment for testing these little beasties… something that, sadly, isn’t as cut-and-dry as we’d like.

Recipe 12: Creating a Custom Form Builder

This is really neat stuff. As I’ve mentioned before, form_for is the wave of the future, and FormBuilder is along for the ride. In this recipe Chad goes over how to build form builders, and highlights how useful they can be.

We use a little form builder, form_table, extensively in our application at work– both in and out of form_for. I can’t even guess at the amount of time it’s saved us– but it’s a lot!

Recipe 61: Adding Support for Localization

If you’re creating an interface that will have to support multiple languages, the Globalize Plugin just fits the bill. In this recipe, the extremely eloquent, good-looking author gives a brief overview of how to use this pivotal plugin.

Okay, I admit it– I wrote this one. It’s still really good, I promise.

Recipe 6: Update Multiple Requests with One Ajax Request

This recipe introduces you to the idea of using RJS is your responses; if you’re still using :update on your linktoremotes (or other such tomfoolery) you’ll want to give this a look.

Recipe 39: Write Code that Writes Code

In my opinion, this is one of the best recipes in the book, introducing important metaprogramming tools like define_method. Metaprogramming is the staple of the truly advanced Rails programmer– who is, framework knowledge aside, also an advanced Ruby programmer.

If you take the knowledge you pick up in this recipe, and apply it liberally across controllers, models, and helpers (in and out of plugins), can’t your application really become a language?

So..

If you know what’s good for you (and your skills), buy this book. If you’re a sucker for instant gratification, pick up a PDF copy, too (it’s great for searching).

Today my copy of Rails Recipes arrived, fresh from the press. Things have been pretty busy for Dave Thomas these last few days, getting the preorders out the door.

If you’re the type of developer that puts the ‘V’ in ‘MVC’ and are looking for a little direction, some examples of best practices, or just some really good ideas to help make you a better Rails developer, I’d recommend you add this book to your library.

There’s a few recipes from the book I especially think you should check out if you’re into views, and here they are…

Rails Views, Avoiding AJAX Faux Pas

2006-06-10T00:00:00-07:00

When developing applications that make use of AJAX, I try to remember one simple rule.

1. Don’t leave the user hanging

There’s nothing more annoying to a user than not knowing what’s going on. If you don’t keep the user informed, your application will seem less, rather than more, comfortable than a traditional web interface. After all, when a browser is changing locations it at least has the common decency to show that something is happening– and a new page is displayed when it’s done.

If your users are confused and have no idea what’s going on– if they’re not even sure your application is working– have you really taken a step forward by using AJAX… or are you just scratching a technical itch and doing your users a disservice in the process? This is about user happiness, not cool technologies.

Here’s some basic ground rules for interacting with users during remote actions.

You will always indicate when a remote action is occurring. Show a progress indicator; spinners are common these days, but use whatever makes sense. And don’t be fooled into thinking the action occurs so fast no indicator is needed– it may seem nearly instantaneous on your development server (with just you accessing it), but who knows what the future will hold?
You will always stop the progress indicator when the action is complete. An ever-spinning progress indicator is pretty, but probably pretty confusing, too.
If the action results in success, you will always show the result. Reload a div, insert an element, maybe do some fancy scriptaculous “Hey, look at me” effects. The point here is to do something. The user did something, and they want something in return.
If the action results in failure, you will always notify the user. The only thing more frustrating than not knowing that something is going on is not knowing it failed– or how to fix it.

So, those are the rules. How do we meet them without too much fuss?

First of all, let’s build a little helper method to help show and hide our progress indicators (setting the :loading and :complete options). A simple implementation might look something like:

def showing_progress(opts={})
  opts.merge :loading  => update_page{|p| p[:progress].show },
             :complete => update_page{|p| p[:progress].hide }
end

And, using it:

<%= link_to_remote "Do Something Remotely", showing_progress(:url=>some_url) %>

So, that leaves indicating success and failure– and here’s one approach. I’m not a big fan of using the :success and :failure callbacks on the link/form. I think it’s messier and less flexible to handle these events on the client-side than it is for the action, generating an appropriate RJS response for either outcome.

So, it all comes down to rendering the result of our remote action. If there’s been errors, we need to report them in a standard way– but if everything is okay, we need to have the flexibility to update the page in whatever manner makes sense for that action.

A good way to do this is to wrap render :update to handle both cases. Here’s an example with some pretty simplistic error reporting. This can be used from any controller action (put it in application.rb).

  def reporting_errors_on(*objs)
    valid = objs.all?{|o| o.valid?}
    render :update do |page|
      if valid
        yield page
      else
        flash[:error] = objs.map{|o| o.errors.full_messages}.flatten.join("\n")
        page.alert flash[:error]
      end
    end
  end

So, if any of the ActiveRecord objects passed into the method are invalid, the errors are reported. Otherwise, a javascript generator object is yielded to the block, and we can use it however we’d like. (Note: The errors are also stored in flash, though that’s primarily for functional testing purposes)

Here’s an example of how to use it:

def add_item
  item = Item.create(params[:item])
  reporting_errors_on item do |page|
    # Success; only happens if no errors are present
    page[:items].reload
    page[item.dom_id].visual_effect :highlight
  end
end

Obviously, these aren’t the only ways to handle indicating progress and notifying the user of errors. These are also fairly simplistic examples; you might want to show text with your progress indicator, for instance, or show which fields are invalid instead of just popping up an alert box.

The point here is to keep your users in the loop– at a minimum of pain and suffering to yourself. As in any relationship, communication is key… don’t make the mistake of neglecting your users.

References: (for the use of ActiveRecord::Base#dom_id)

The Radiant Conversion

2006-06-08T00:00:00-07:00

Fixing Issues

Hopefully this conversion will fix some of the problems that were cropping up before– especially the issue with invalid RSS feeds that news readers like NetNewsWire simply wouldn’t tolerate. I’ve done my best to preserve things like RSS URLs (and article URLs too, to some degree), but I recommend you update any feed subscriptions you have with the new locations– using autodiscovery or by looking in the sidebar.

In terms of running the site, I’m finding Mongrel with Apache forwarding to be a lot more reliable than fcgi, so performance should be a better– especially on heavy Rails Weblog and project.ioni.st traffic days.

If you do notice any problems, please drop me an email . I’ve copied over all of the old comments (as of yesterday), but commenting will be down for a few days.

Why Radiant?

I’ve known for a while that I needed to move to a full CMS; the plain blog structure is nice and simple– and don’t get me wrong, that’s a Good Thing– but I’ve been aching for a bit more control over the format of the site. After a bit of searching, I decided Radiant was the best choice; it’s written on top of Rails, has an interesting premise– and is proving to be exceedingly fun to play with.

John W. Long and the rest of the Radiant developers have really put together a compelling system that deserves some attention. Radiant hasn’t been technically released, so there’s still some things missing that you might be looking for; but if you’re an early adopter and like to look at cool new things, I sincerely recommend it.

If you’ve been here before, you may notice things have changed a bit.

Besides the obvious design changes, there’s a lot that’s different under the covers. I’ve switched from Typo on fcgi to Radiant CMS on Mongrel.

Rails Views, Using the :with option

2006-06-02T00:00:00-07:00

People forget this little gotcha all the time, even though it’s in the Rails API Documentation:

If you specify a string for the :with option without a ”=”, it’ll be extended to mean the form key that the value should be assigned to.

What this ends up meaning is that if you do something like :with => 'foo' Rails will automagically generate a query string that equates to something like: "'foo=' + value" (just passing along whatever’s in the value variable, something that makes sense in the context of observe_field, specifically). Neat, right?

Right … but if you try to use your own custom function to generate the whole query string, or make use of something like Form.serialize() without including a = inline in the option, Rails’ magic backfires and you end up with a fizzled remote action. This, for instance, is completely useless:

<%= link_to_remote "Foo", :url => some_url, :with => "Form.serialize('some-form')" %>

No =, so we end up with a mangled query string.

So, what’s the solution? Well … I’ll tell you what I do; just give it what it wants:

<%= link_to_remote "Foo", :url => some_url, :with => "Form.serialize('some-form')+'&='" %>

Pass along a bogus query string pair, just to eke out a =. Fight hackery with hackery.

One more gotcha, before you run off and inexplicably use that little bit of pedantic, arcane lore for some crazy reason:

Don’t put a semicolon at the end of the :with option value. Hold back … or you’ll just end up with a syntax error. (It’s inserted into a Javascript options object, essentially a Hash, and doesn’t stand alone as a separate statement like you might expect.)

This entry probably has a bit of a specialized audience, but I think it needed saying regardless.

One of the key “sneaky” aspects of developing AJAX applications in Rails is the use of the :with option, available in about all of the AJAX-related methods. This option is used to dynamically generate a query string (meaning params, once it hits the server) using Javascript. This allows you to roll your own parameters, freestyle, with DOM lookups.

It’s pretty neat stuff (especially when playing with observe_field and observeform), but it can be pretty tricky. Here’s a couple things to look out for.

Ruby for Rails Arrives

2006-05-31T00:00:00-07:00

So, today my fresh, dead-tree copy of Ruby for Rails arrived.

As the technical proofreader for this excellent book by David A. Black, I’ve obviously spent some time reading it in depth … but seeing the final result sitting on my table is still pretty impressive.

For those of you that don’t know, David has been a leading member of the Ruby community since long before Rails was a twinkle in DHH’s eye (who, by the way, wrote the foreword for the book). He’s one of the directors of Ruby Central, the parent organization for the official Ruby and Rails conferences, and knows Ruby.

In the book David did some great work explaining the language in depth and delving into Rails from a Ruby perspective; if you’re a Ruby programmer by way of being a Rails developer, this book is the one to pick up to help you understand the underlying language.

Rails Views, Block Helper Example

2006-05-31T00:00:00-07:00

A few articles back, I mentioned how useful helpers that take blocks can be within your views.

I thought I’d give a little example, giving a helper I find pretty useful in my own projects.

Here’s the code, which I’ll explain in a moment:

def link_to_section(name, html_opts={}, &block)
  section_id = name.underscore.gsub(/\s+/,'_')
  link_id = section_id + '_link'
  # Link
  concat(link_to_function(name,update_page{|page|
    page[section_id].show
    page[link_id].hide
  }, html_opts.update(:id=>link_id)), block.binding)
  # Hidden section
  concat(tag('div', {:id=>section_id, :style=>'display:none;'},true),block.binding)
  yield update_page{|page|
 page[section_id].hide
    page[link_id].show
  }
  concat('</div>', block.binding)
end

What this makes possible is stuff like:

<% link_to_section("View Details") do |closer| %>
  <h4>Details</h4>
  <p>Some detailed text detailing detailed details.</p>
  <%= link_to_function("Hide Details",closer) %>
<% end %>

What’s going on here is actually pretty simple. The helper generates a link (with the label you’ve given) to show a a hidden div and hide itself. The block given to the helper is what will end up inside that div, and it’s yielded the snippet of javascript necessary to switch back (so that you can use that snippet wherever you’d like).

Keep in mind assumes you’ll only have one link per page with the same label … if you think that won’t be the case, you’ll probably want ensure the ids generated inside the helper are unique; using object_id would be a simple way to do so.

Rails Views, ActiveRecord DOM IDs

2006-05-30T00:00:00-07:00

The solution– or at least a nice, cheap bandaid that can be applied easily, consists of adding a method to ActiveRecord::Base to help generate these ids without any brainpower involved.

Here’s a very simple implementation that I use in my projects, courtesy of Jamis Buck:

class ActiveRecord::Base
  def dom_id(prefix=nil)
    display_id = new_record? ? "new" : id
    prefix ||= self.class.name.underscore
    prefix != :bare ? "#{prefix.to_s.dasherize}-#{display_id}" : display_id
  end
end

So, you can do stuff like this in your views:

<ul>
  <% @entries.each do |entry| %>
    <li id='<%= entry.dom_id %>'>
      <%= entry.body %>
    </li>
  <% end %>
</ul>

And stuff like this in your controller:

def remove_entry
  entry = JournalEntry.find(params[:id])
  update_page do |page|
    page[entry.dom_id].remove
  end
end

Isn’t that nice, simple, and easier to remember than some half-baked scheme you thought up on your own? It is for me.

One of the things you do when dealing with views that will be modified via AJAX is set DOM IDs on elements you’ll want to modify or remove.

This is especially true if you’re creating elements for a set of ActiveRecord objects. Perhaps you have a JournalEntry model and give a series of list items ids like:

<% @entries.each do |entry| %>
  <li id='<%= entry.id %>'>
    <%= entry.body %>
  </li>
<% end %>

Isn’t this a tedious activity to do by hand? It’s not only frightfully dull to do in any volume, but it also increases the likelihood you’ll make a mistake, especially since you’ll need to remember what naming scheme you’re using in any RJS actions you develop to make use of the ids.

There’s a better way, and by “better” I mean lazier and generally more satisfying.

Rails Views, Internal Plugins

2006-05-29T00:00:00-07:00

Each of these consist of a mixin for controllers, a number view templates stored inside the plugin, and a helper for use by those views.

The module mixed into ActionController::Base provides a declarative way of defining all the actions involved at once, inside any controller we want. This might, for instance, look something like:

folder_for :student do
  tabs :general, :attendance, :surveys
  tab :report do
    # get report data
  end
end

This declarative method would handle defining each action, and determining what data needs to be prepared for each action, acting somewhat like a beforefilter, and then render the appropriate views stored inside the plugin (via render :file).

Sure, you could do all of this be defining the controller part in application.rb, manually attaching the helper, and having some type of cross- controller template directory to store its views … but this way certainly feels cleaner, and who knows if we might want to reuse the code (or even just the concept) in another application?

Putting stuff in plugins is worth it – if even just to make things easier to find in your own application.

One of the techniques we’ve been using at work to develop our Rails application is based on the Rails plugin system.

There are several UI components of our application that are a mix of Controller and View pieces. Rather than have each of these strung out across the Rails framework, we package them in plugins.

Even though we’re not distributing these, they’re large enough and used often enough in our application for the separate packaging to really pay off.

Rails Views, Helpers that take Blocks

2006-05-28T00:00:00-07:00

Helpers that take blocks are a core element of the new approach to developing views for Rails. What are they, and why should they be used? To put it plainly, block helpers are a bit of Ruby magic that will save you time and no little amount of sanity.

Let’s use a simple example. Imagine a situation where you are wrapping chunks of markups in a div with the same CSS class. This is happening in various templates.

The old approach would either be to just type in the wrapping div manually every time, or maybe have two partials; one rendered before, and the other after the chunk of markup.

This is the type of insert header here, and insert footer here PHP-like clunkiness I try to avoid.

Block helpers make this inelegant kludge unnecessary. They allow you insert “common” markup before and after the block, and also to yield whatever object you’d like to the block so it can be used – like form_for’s builders.

We’re going to make a quick little helper to generate little “tip” sidebar items with optional headers. Here’s the type of API we want:

<% tip "Block Helpers Help!" do %>
  <p>They really do!</p>
  <p>Use them, or deprecate yourself immediately.</p>
<% end %>

Notice the first line is in an ERB evaluation block, meaning we’re not trying to insert its result into the template– since we’re not even finished passing all the arguments to it, after all; the block.

And here’s how to make it all happen:

def tip(name=nil,&block)
  concat("<div class='tip'>", block.binding)
  concat(content_tag('h3',name), block.binding) if name
  yield  # now insert the markup in the block
  concat('</div>', block.binding)
end

So, what’s this block.binding tomfoolery?

To add anything to the page, we need to use concat, and ERB needs to know where add our text – the context. Handily, our block lives out in the template, and its binding is exactly what we need.

And that’s about it. It’s really not very complex, provided you have at least a little bit of Ruby experience, know what a block is, and can deal with ERB’s foibles.

So use block helpers!

Reference: form_helper.rb (in Rails) has some fairly decent examples. Rails Recipes, a great book by Chad Fowler also has a recipe on the subject. Buy it – you’re a smart Rails developer, right?

Update 2008 This article is pretty old (2 years is practically eons!). concat no longer needs block.binding, and other things have changed. Just consider this a historical document!

Rails Views, Use update_page in link_to_function

2006-05-27T00:00:00-07:00

Here’s a quick example, two ways. Let’s make all paragraphs on the page have green text using CSS class irish, just for the hell of it – just pretend it’s St. Patrick’s day for the moment. In fact, let’s quickly slide down a nice “Happy St. Paddy’s” banner, as well.

First, a traditional (if still prototype-enhanced) link_to_function.

link_to_function("Pinch Me!", "$$('p').each(
    function(tag) {tag.addClassName('irish');}
  );
  new Effect.SlideDown('banner',{duration:0.4});"
)

And, with updatepage:

link_to_function("Pinch Me!", update_page{|page|
  page.select('p').each{|p| p.addClassName('irish')}
  page[:banner].visual_effect :slide_down, :duration => 0.4
})

So, they’re about the same length .. so what’s the big deal?

Ruby is more powerful and easier read than Javascript. Keep in mind this is a very simplistic example.
Once you start dynamically interpolating different element ids, etc, into a string of javascript (using escape_javascript, of course), the non- updatepage version gets harder and harder to maintain (or even look at while holding down your lunch).
It’s easier to extend this technique using other helpers and frameworks (passing page to add common code, for instance) than passing around strings to be concatenated– and risking javascript syntax errors in the process (can anyone say “Missing semicolon?”).

Hopefully you’ll get some mileage out of this technique. It’s a small, very simple favorite of mine.

One of the least used techniques I’ve seen used in Rails applications– and one I think is not only very elegant, but also saves time – is the use of update_page directly in linktofunction.

Why aren’t more people using this? I just don’t get it. A lot of work went into RJS … so why not use it?

Introducing Rails Views

2006-05-27T00:00:00-07:00

I live in the land of Rails templates and helpers. To give you an idea of how seriously I’m talking here, let me just say the following. Our application currently has around 670 separate template files (around 8500 lines) and 75 helpers (around 2350 lines), and it’s still growing.

What does this mean– besides the fact TextMate’s ⌘-T is my best friend? It means that, if there’s anything I know about Rails, it’s how to manage a large volume of templates and view-related code, building frameworks to help DRY-up the chaos.

I’m going to try to help other Developer/Designers out there in the same boat as I am by posting a series of entries titled Rails Views. These posts will highlight techniques I use in my day-to-day work. Maybe you’ll find them useful; they’re certainly not the only way to do things, but they’re the way I do them.

Rails Views will assume you know Ruby fairly well; I won’t be focusing on explaining details I expect reasonably decent Ruby programmers to understand. I’ll also assume you’re using Edge Rails, since that’s what I work with every day.

I hope they’re useful!

Rails Views, render :update, not .rjs

2006-05-27T00:00:00-07:00

Ok, here’s the deal. I’m about to commit blasphemy. I’m going to recommend you put view-related code in the controller.

Wait a second. What about the whole MVC thing… never the twain shall meet, right? What kind of madness is this??!? (ducks lightning bolt)

Put down the pitchforks and torches, dammit, and listen.

Why, really, do we avoid putting view stuff in controllers? Why, that’s easy … because we’re talking visual elements here– things to lay out, things that aren’t necessarily a function of the application’s behavior or workflow, right? Things get muddled and then everything goes to hell, right?

Here’s the deal. I say replacing a portion of the page with another due to user interaction is behavioral. Granted, changing this or that element of the page can lead to some tight coupling, so it needs to be approached with caution … but there’s no glittering ivory tower here, folks.

A quick example, from a controller.

def add_item
  Item.create(params[:item])
  @items = Item.find(:all)
  render :update do |page|
    # Think "inline RJS"
    page[:item_list].reload
  end
end

Here, we have a listing of items; maybe they’re sorted alphabetically, so we want to go ahead and reload the whole listing (rather than just inserting the new item, which could also be done).

It’s pretty simple. If you know RJS and you look at this action, you know what’s going on– the whole process that occurs when the user submits the form. If the RJS is just an extension of the behavior that’s occurring in the controller, why put it in a separate file– why dig when you can just know?

Sometimes pure, rigid thoughts are just naive, dumb thoughts. Feel free to adhere to doctrine– but once it’s counter-productive, cut and run.

Rails Views, form_for

2006-05-27T00:00:00-07:00

The whole thing is pretty simple.

<% form_for :student, @student, :url => student_url(:action=>'update') do |f| %>
  <ul>
    <li>Name: <%= f.text_field(:name) %></li>
    <li>Age: <%= f.text_field(:age,:size=>2) %></li>
  </ul>
  <%= submit_tag "Save" %>
<% end %>

Some observations:

Anything in the block is contained in the resulting form tag (no chance you’ll forget it)
Unlike the plain text_field helper (and others) you’d have to pass in a symbol (and would expect a similarly named instance variable in scope), you can give the form_for any object you’d like, named anything you’d like, and any field method called on the form object will name the field correctly and use the existing attribute for its value.
You pass :url to remote_form_for as well, meaning there’s less chance you’ll forget what API to use for which method, and that’s good thing.

There’s a lot more to talk about here, including fields_for and form builders (which are worth a post all by themselves), but I think you get the point.

Reference: form_helper.rb in a fresh edge rails checkout.

In the beginning (or nearly so), we had form_tag and end_form_tag. Now, these were still better than typing form tags, and trying to throw in form attributes, but they really didn’t even begin to use the full power of what Ruby (and ERB) had to offer.

A while back, form_for (and it’s sexy friend remote_form_for) came on the scene, but a lot of people haven’t noticed. These are cleaner, more elegant, and more flexible ways of making both regular and remote forms, and you should be using them.

Closures; an Italian Sonnet

2006-05-18T00:00:00-07:00

I was recently challenged, in jest, to write a poem on closures. I was waxing poetic on the idea of closures as method “templates,” and Chad called me on it.

I could have answered Chad’s joke with a haiku, but who can truly contain their love for closures in only a few lines?

Instead, I figured an Italian Sonnet would be much more punishing for all involved, and somewhere where I could truly showcase my inherent nerdiness.

So, without any more ado…

A shame, it seems me, that closures still Are not lauded, not given their just due; Objects rock, but no paradigm’s so true, That should eschew the useful closure’s thrill. The outer scope, the fortress on a hill Is not opaque; the closure has a view Of variables assigned before– into The closure goes a binding’s heart and will. Closures seem like method templates; see Filled with variables that are in turn contained, This stencil used to fill a binding’s dreams, No banal limits, no local scope constrained. So pivotal, these functional gems agree With metaprogramming and other utopian schemes.

Getting a Handle on Rake

2006-05-02T00:00:00-07:00

If you’re a Rails developer, you use Rake. Sadly, many Rails developers don’t understand Rake well enough to fully grasp its potential.

At last month’s Boulder-Denver Ruby Group meeting, I spoke about Rake and how it can make a developer’s life easier. The presentation and example code is available here (Update These documents have been misplaced since this article was originally posted; sorry).

Hopefully, the presentation will serve as a good starting point for some out there who haven’t discovered how powerful and easy to learn Rake truly is.

Rails RTex Plugin, Generating PDFs

2006-03-17T00:00:00-08:00

One of the challenges that I’ve recently run into in the midst of Rails work has been PDF generation. For one project, it’s a mandatory requirement, and, unfortunately, PDF::Writer simply isn’t fast enough to handle the amount or complexity of the content.

I’ve liked LaTeX for several years; I’ve used it for resumes, business cards, and letterheads, and have always been impressed with its professional quality– especially when it comes to fonts. The speed isn’t bad, either.

Back in my PHP and Python days, I wrote a number of quick hacks to push generated .tex files through LaTeX, with pretty good results, so the last day or two I started thinking…

Why not offer a template format in Rails to generate LaTeX files for pdfLaTeX?

Yesterday morning, that’s exactly what I started putting together, and I’m happy to release the initial result of the work in a new Rails plugin, RTex.

If this sounds like something you’d be interested in, see the RTex Plugin page for more details.

Kites of Death!

2006-03-09T00:00:00-08:00

One of the more interesting, frightening stories I’ve run across recently is one concerning kites that can kill people in Pakistan.

This just goes to show you– some people can take the most inane concept and do something unexpected with it. In this case, by “unexpected” I mean “really, really, bad.”

If you’re drawing some kind of development/design/management parallel in your head right now, you think too hard.

Sometimes a Kite of Death is just a Kite of Death, sheesh.

1468494&src=rss/oddlyEnoughNews

Publishing; An Aside

2006-02-21T00:00:00-08:00

I’ve had the good furtune to be able to work as a Technical Editor/Proofreader for recently, and what an eye opener!

The publishing industry is definitely an interesting one, and from things I’ve read lately, one that’s changing due to some really cool ideas about what it means to publish really good books in new, exciting ways.

The Optional Partial

2006-02-09T00:00:00-08:00

A common Rails issue for me is when I have a section of my layout that may change per-controller; a sidebar, for instance, that looks one way in FoosController (foos/), completely different in BarsController (bars/), and doesn’t even show up in BazsContoller (bazs/).

There’s ways of doing this, of course. Here’s an evil one:

render(:partial => 'sidebar') rescue nil

The not-so-amazing Purple Rock

2006-02-06T00:00:00-08:00

This kind of critical, slightly cynical view is one that’s very easy to feel about software. After all, there’s a lot of crap out there. Bad or poorly trained developers, designers, and managers churning out loads of buzzword- friendly, “innovative,” truly crappy software. It’s stuff that may look neat, but turns out to be so derivative, unimaginative, and unusable that users eventually despise it. A lot of this is due to the rather drab view that software development is an engineering, rather than artistic, pursuit.

I love to find software, especially web-based software, that really breaks this mould. I’m especially lucky that I ran across 37signals back when I first started digging into Rails (right before RubyConf 2004). Here was a company that made good software, and knew clean design, to boot.

But nothing could have prepared me for Campfire. This, simply put, is one of the neatest, cleanest webapps I’ve ever run across. It’s easy to use, it’s useful, and using for more than a hour doesn’t make me want to kill myself.

37signals have really outdone themselves on this one. When it goes public, you owe it to yourself to try it.

(Special kudos go out to Sam Stephenson for what surely amounts to some serious javascript magic going on behind the scenes.)

As a young kid living growing up in Tucson, Arizona, I was a Webelo. For those of you that don’t know what a Webelo is, it’s a Boy Scout rank below, well.. Boy Scout (and even less cool). I liked it. There was always something new to learn, and, of course, we went camping.

I love camping.

At the end of one particular camping trip, I distinctly remember goofing around as everyone was packing things up. Walking by the extinguished campfire, I looked down and saw a neat purple rock. Being interested in Geology, I was intrigued. “A purple rock,” I thought. “What kind of rock is that?”

I found out, about two seconds later, when I grabbed it and discovered it was hot. How hot? However hot a rock has to be to be purple, cause excruciating pain, and force me to scream like a pre-pubescent girl. I had, apparently, forgotten that I was pulling the rock out of a newly extinguished campfire.

Luckily, besides feeling very stupid and having a mildly burned hand, no harm was done… and, of course, I’ve made even worse decisions since then.

But I did learn something.

Not all things that look neat are actually that exciting, or groundbreaking, or difficult to accomplish. Sometimes, events conspire to make something look neat, but in the end it just isn’t a good idea to play around with it.

The Next Great Book

2006-02-06T00:00:00-08:00

The Pragmatic Bookshelf has started selling Beta Book copies of Chad Fowler’s upcoming book, Rails Recipes.

As Chad points out, this book is the next step for those who’ve read the Pickaxe or Agile Web Development With Rails. I think it would also be a great resource for the beginning Rails programmer.

Chad’s been working incredibly hard to make this book an accessible, thorough reference for Rails developers who care enough about their craft to keep up on the latest patterns, and let me tell you, it’s already a useful resource.

Slam down your extra pennies here.

sInBeta.rdoc,v

Partially Painful

2006-02-03T00:00:00-08:00

I’ve been chatting recently with Chad about mixing code and content (ie, ERb) and how hard Rails partials can be to read. Both of us are language nuts, and I think this is something that’s very easy for us to get caught-up on.

As far as I can see, there’s a decision every Rails developer needs to make– with two choices that are largely mutually exclusive.

* More interleaving, meaning less partials and readability, but less files to dig through

* Less interleaving, meaning more partials and readability, but more files to dig through

I don’t think there’s any right choice for this type of decision. With the exception of partials for loop content and those necessary for AJAX updates, there’s not even any general consensus. It’s a matter of taste, and ultimately something that depends on what makes sense for you.

I tend to make lots of partials and rely on my memory, grep, and TextMate’s Command-T to help me find what I’m looking for. But it sure can get complex.

Tidbits

2006-01-28T00:00:00-08:00

If you haven’t checked out Moe Bot, you should. My personal favorite is Scarves Scarves Scarves (it actually frightens me quite a bit, but I get over it by laughing nervously).

And then there’s the Waterfall 2006 site. Links for this have been flying all over geekdom the last couple of days. Who knew we liked tongue-in-cheek humor?

My favorite tutorial so far has to be “User Interaction: It Was Hard to Build, It Should Be Hard to Use” by Jeff Patton.

Monkey Business

2006-01-27T00:00:00-08:00

I respectfully disagree with Python developer Ian Bicking’s most recent comment with regards to monkey patching.

If a guerilla/monkey patch is something that “that sneakily changes other code at runtime without any rules” (see definition), Rails’ extension of several base classes (such as Fixnum) certainly doesn’t qualify. It’s a well- documented aspect of Rails, and just simply makes sense.

Extending previously declared classes (reopening them) is a Ruby staple, and rightfully so. No “object of your own” is needed when the right object for the job already exists.. and, as long as you’re not submitting your patches to unsuspecting victims (ie, you make it obvious what’s going on), I think this approach makes sense– in the very least from an API design perspective.

fMonkeyPatching.rdoc,v

Replacing That Old Sofa

2006-01-26T00:00:00-08:00

People like tabs because they recognize them for exactly what they are: a holdover from the days of file folders. Is this bad? No. Is this right– in the sense that the web has progressed past the days of being merely a document repository to a platform for really neat applications? Maybe not. But… it’s just comfortable. Everyone’s seen a file folder. It’s a physical object they’ve touched, they’ve used, they recognize. It makes sense.

And there’s the pitfall. Comforting the user just isn’t that exciting, is it? Jarring, unique layouts and controls are fun, they feed our creative drive– and there’s nothing that makes us right-brainers more pumped than making something only we really understand (comeon, admit it).

Now, this doesn’t mean we should necessarily have to use old favorites like tabs. This just means we need to make really good choices about what makes sense and what doesn’t. No matter how cool the control you’ve designed looks, no matter how neat its behavior is, if the user has to figure out that it does the same thing those comfortable old tabs do, they’ll give just give up.

Deciding you’re going to educate the user through some new, ground-breaking interface is risky business. User interface isn’t about educating, it’s about mind-reading– the wise and gentle designer is the one that knows the goal is figuring out how to make really neat things comfortable.

If you can do that– if you can present your neat design in such a way that it intuitively makes sense, it works, and it’s understood.. who knows, you just might change the world.

I’ve been up to my neck in tabs lately. User interface tabs, that is. Eventually every complex application hits the point where all (or at least a large portion) of the page content needs to be sliced up into categories that make sense being visually exclusive.

This is where tabs come in. I mean, everyone is doing it, and it’s been happening for a long time.

I don’t like them. I’m not sure I ever have. But I also know they work, people like them, and I’m not the user, so I shouldn’t pretend to be.

Replacing something that’s so comfortable and easy to grasp (that we really don’t like) with some new, neat design (that’s actually more powerful) is a difficult challenge. Sometimes it makes sense, and sometimes it doesn’t.

Update 2006-04-03: See, I gave in. Tabs here too, these days.

Bruce Williams

Living without send(), or trying to

An evaluation

Method acting

Summary

A GitHubby config.gem hack

Updates

A sleep hack

More on super-and-extend

Multiple Wrappers

Wrapped Class Inheritance

The Vagaries of Overriding new

Wrapping a Method in Ruby

Technique #1: alias_method_chain

Technique #2: super and extend

Performance Note

Further Reading

Revisiting Python

Okay, looking back

Random feelings

Updates

Front Row to History

The Barack blog calleth

The narrowly avoided heart-attack

Off I go

Boston.rb Slides

Arrow Lambdas, a Ruby 1.9 Vignette

Calling them

With a block, no less

It can get really ugly

As hash values (in old-style hash literals)

Strung out or wrung out

Who are we? Who will we be?

ViewGem, a Little Script

Here’s a little script

Rails BootUp, Austin TX

Why we did it

It went pretty well

Salutations

RTeX 2.0 Released

RTeX on Lighthouse

RTex Webby Filter

Installing the Goods

Creating a Document

A Simple Filter

The Results

RTeX 2 Preview 1 Released

History

RTeX 2

RubyLearning Interview

Introduction to Ruby

Migrating to Ruby 1.9

Playing Catch-Up

Scotland on Rails, April 4th-5th

Advice for a Java Developer

The Statesman on Rails

Austin on Rails

Welcome Back, Codefluency

Taming Your Views

10 Minutes with Factor

Installing Factor

The GUI

Basic Concepts

Gem

Syntax Changes in 1.9

The Strategy Hash

The Filter List

It's time to play with 1.9

Ruby.framework

Drinks at RubyConf

Stackalicious

Some Leopard + Ruby Notes

Leopard, Off the Cuff

KeywordSearch 1.3.1

Changes in this release:

Rewrite Woes (Take Two)

Lone Star Ruby Conference Starting

Off Topic, FiveRuns is Hiring

Paginator 1.1.0

Forward and Delegate, A Simple Pattern

The Vagaries of Overriding `new`

Technique #1: `alias_method_chain`