Perspectives: Writings from The Killswitch Collective

Understanding Your Communication Style

Wed, 16 Jul 2008 14:15:55 -0700

Developers don't argue. If disagreements do occasionally occur, the topic is usually settled or dropped in favor of something more productive. And designers? These girls have so much work they don't even have the chance to realize that the workplace is a social setting.

However, this firm is constantly expanding, and even a few tiffs may eventually snowball into arguments of unnecessarily enormous proportions. With this said, Ben had the excellent foresight to offer me a chance at educating myself on diffusing difficult situations in the workplace. I found the seminar (Dealing with Difficult People, sponsored by CareerTrack) so enlightening, I'd like to share with everyone some tidbits I have learned.

Approximately 75% of long term job success stems directly from people skills; only 25% derives from technical knowledge. This is huge! So what can you do to ensure successful people skills?

Listen

This is an incredibly simple act, and yet few people take the time to actually stop what they are doing, direct all their attention onto others, and really listen. In order to do this, you need 3 things: the capacity to listen (focus), the desire (or willingness) to listen, and the ability to evaluate what you hear. In other words, you need to WANT to grasp what it is others are saying to you, and go out of your way to do so. People really only want 2 things out of their transactions with others, and that is to be valued and understood. You can show both of these by hearing them out to completion, and then going over what you heard in your own words. A good example of a listener at KSC, and I think the devs will back me up on this one, is Neal; when someone has a question, no matter how minute, he will take out both headphones, turn his chair towards you and give you ALL of his attention. This indirectly lets people know that they matter and creates feelings of appreciation and respect among employees.

Body Language

Interestingly, body language (55% of communication) and tone of voice (38% of communication) affect how people react to you much more than what you actually say (only 7% of communication). The best way to communicate, is to follow the anagram SOFTEN:

Smile
Open Stance
Forward lean
Territory
Eye contact
Nod head

The quickest way to anger someone is to fold your arms, look past him, and lean back in your chair as soon as he walks into your office. The best way to diffuse anger is by modeling behavior you would like others to exhibit. Nothing crossed implies honesty and openness, leaning forward demonstrates interest, and maintaining eye contact builds trust. Speaking softly and slowly, and avoiding personal space and pointing are also good ways to communicate effectively. To learn more, you can visit www.changingminds.org/techniques/body/bodylanguage.htm.

Don't Be Scared!

The best way to handle interactions with people is to do so assertively. If you aren't sure what being assertive entails, keep in mind this basic message: "This is what I think. This is what I feel. This is how I see the situation." It respectfully brings the issue out on the table to be dealt with quickly and with everyone's side of the situation in mind. You can't possibly solve a problem if you aren't even sure what it is! And don't back down! The more you stick to your guns, the more respect you'll get, I promise. If you want a situation to change, you really have to confront it immediately and persistently (as scary as that sounds). A good way to assert yourself with others is by following this sentence pattern:

"For the sake of (name the relationship), when you (name the problem) and this happens (what happens when the problem occurs), I feel (name honest feelings). What I want is (name what you would rather happen). Can we agree?"

What you are looking to do is change the behavior, not the person. It will never help to attack the person who is causing problems, but behaviors can be modified easily. It is also important to add "Can we agree?" at the end of the sentence; you are then in oral contract with the person, and can bring this up if he engages in problematic behavior again. Here's a more detailed example:

"For the sake of our friendship as neighbors, when you let your dog poop all over my yard and then I accidentally roll in it when I play with my kids, I get extremely irritated. What I want is for you to pick up the poop immediately after you let the dog out. Can we agree?"

Remember, it takes at least 6 tries and 21 days to form a new habit, so be patient with those "lazy neighbors."

The most interesting part of the seminar was hearing about CareerTrack's version of the 4 different personality types: thinkers, relaters, directors and socializers. For reference, these would be found in the Myers-Briggs personality test as Introvert Thinker, Introvert Feeler, Extrovert Thinker and Extrovert Feeler, respectively.

Curious as to where you fit in?? Here's a little test you can take to get an idea:

Thinkers

These guys are the meticulous task-oriented individuals of the world. Organized, focused and on-point, thinkers need things to be correct more than anything. In fact, their main goal in the workplace is ACCURACY. Because they can be perfectionists, thinkers are not very good at receiving constructive criticism, and may complain if they have a problem they can't seem to fix. The best way to work with them is to provide them with as much information as you can, the "who, what, where, why, and how" of the situation, so that they can see and understand your process. Also, help them move into "problem-solving mode" by directing their concerns toward working on a solution. Negativity may rear its ugly head when things go wrong, and the best way to counteract it is to bring the thinker back to the task at hand: instead of what CAN'T be done, focus on what CAN.

Relaters

Can't we all just get along?? This is the relaters' motto; their goal is STABILITY and harmony within their relationships. Sensitivity and a need to be liked drives their actions, and they tend to shut down, submit, and exhibit passive aggressive behavior when pressured. When speaking with relaters, be casual and sincere, slow down and listen to how they feel about the issue, make honesty safe by being open and patient to what they have to say, and reinforce to them the fact that you want to get along with them, and that the relationship is important to you. All of these things will help create a safe haven for confidence and honest transactions, and will prevent the break-downs in communication which lead to arguments.

Directors

Also known as people who "get it done," directors seek to be in CONTROL, and always know what they want and how to get it. Life is a giant comprehensive checklist, and great pains are taken to remain focused, direct and blunt on each task and with each individual they come into contact. Trust and respect are very important, and at times, if you don't gain either, you may become invisible. They tend to react aggressively to pressure: they may raise their voices, bully others and become irritable and impatient. When working with them, try to be proactive, task-oriented, and direct in your speech. Also, don't be afraid to stand your ground! They respect those who command it. Show them that you understand and support their goals, and they will become more flexible with your ideas.

Socializers

This one is my favorite. Socializers are direct, charismatic, energetic, creative, people-oriented and adore RECOGNITION. On the flip-side, they are disorganized, sensitive, dramatic, horrible procrastinators and cannot function without recognition. When asking them to do something, focus more on the results rather than the process; they enjoy creative freedom when working on projects. Show flexibility and positive affirmation when talking to them, and don't forget to let them talk as well; this will help them feel valued, allowing them to open up to criticism and suggestions and utilize their enthusiasm and optimism to the max.

Of course, not everyone will fit neatly into one specific category, but you can definitely use these descriptions to better understand yourself and how to communicate with fellow coworkers effectively.

Exercises in Pruning Code, Episode Two

Wed, 09 Jul 2008 07:00:37 -0700

A story about building an application

I was recently working on a Ruby on Rails application that had a section for sending messages. This sounds pretty easy, right? I started with a User model and a Message model and some basic associations:

 class User < ActiveRecord::Base
    has_many :messages
 end

 class Message < ActiveRecord::Base
    belongs_to :user
 end

Fig.1 - initial User and Message models

But when it came time to actually start building the application, I found this simple model code was not enough. The devil is in the details, as they say. There was a lot of functionality I needed to add beyond just a list of messages connected to a User.

1) Filtered views

I needed different views of the messages such as sent messages, drafts, and deleted messages.

How do I determine 'draft' status? Well one way is to fill in a delivered_at date whenever a message is sent. Then a draft is just a Message with no delivered_at date.

So after adding that field (and a sender_id and receiver_id) to the database I went to my messages_controller.rb file and added a few methods that looked sort of like this:

 def index
   @messages = user.messages.find(:all, 
     :conditions => ['delivered_at is not NULL and recipient_id = ?', 
       user.id])
 end
 
 def sent_mail
   @messages = user.messages.find(:all, 
     :conditions => ['delivered_at is not NULL and sender_id = ?', 
       user.id])
 end
 
 def drafts 
   @messages = user.messages.find(:all, 
     :conditions => ['delivered_at is NULL and sender_id = ?', 
       user.id])
 end

Fig.2 - initial fragment from messages_controller.rb

2) Pagination

Nobody wants to load a page of 1000 messages at a time, so I needed to be able to break up that list into limited sized chunks. I used the excellent plugin will_paginate for that purpose. Then my controllers methods got a little more verbose:

 
 def index
   @messages = user.messages.find(:all, 
     :conditions => ['delivered_at is not NULL and recipient_id = ?', 
       user.id]
    ).paginate(:page => (params[:page] == "" ? 1 : params[:page]))
 end

 def sent_mail
   @messages = user.messages.find(:all, 
     :conditions => ['delivered_at is not NULL and sender_id = ?',
       user.id]
    ).paginate(:page => (params[:page] == "" ? 1 : params[:page]))
 end
 
 def drafts 
   @messages = user.messages.find(:all, 
     :conditions => ['delivered_at is NULL and sender_id = ?', 
       user.id]
    ).paginate(:page => (params[:page] == "" ? 1 : params[:page]))
 end

Fig.3 - fragment from messages_controller.rb with pagination

3) The ability to flag content (i.e. spam, objectionable content etc...)

What if someone gets spam in the message system - or something objectionable in some other way. Well I need to filter that stuff out. I added a Flag model and connected that to messages like so:

  class Message < ActiveRecord::Base
    has_many :flags
    belongs_to :user
  end

Fig.4 - Message model with flags added

However, at this point my controller methods are starting to look like this:

 def sent_mail
   @messages = user.messages.find(:all, 
     :conditions => ['delivered_at is not NULL and 
         flags.flagged_item_id is NULL and 
         recipient_id = ?', user.id], 
       :include => :flags
    ).paginate(:page => (params[:page] == "" ? 1 : params[:page]))
 end

 def sent_mail
   @messages = user.messages.find(:all, 
     :conditions => ['delivered_at is not NULL and 
         flags.flagged_item_id is NULL and 
         sender_id = ?', user.id], 
       :include => :flags
    ).paginate(:page => (params[:page] == "" ? 1 : params[:page]))
 end
 
 def drafts 
   @messages = user.messages.find(:all, 
     :conditions => ['delivered_at is NULL and
         flags.flagged_item_id is NULL and 
         sender_id = ?', user.id], 
       :include => :flags
    ).paginate(:page => (params[:page] == "" ? 1 : params[:page]))
 end

Fig.5 - fragment from messages_controller.rb with flags

I'm looking at some ugly code - with a lot of repetition. How do I pare this down?

Begin Pruning

My first thought is that if anything in my application can be flagged, I should be able to do a little meta-programming to create a find method that will give me only un-flagged items. Ideally I could even send in all the rest of the find arguments exactly the same.

There is the named_scope addition to Rails 2.x that does just that - but I also want something I can add to any class as a Mixin. That way I can write code like this:

  Message.unflagged_items.find(:all, 
    :conditions => ['delivered_at is not NULL'])
  SomeOtherThing.unflagged_items.find(:all, :conditions => ...)

Fig.6 - call to imagined method unflagged_items

The method with_scope is a good candidate for sending in some pre-determined find conditions - but leaving it open to add more later. I'm wanting to add the following method to all my classes that need to be flagged:

  def unflagged_items(*args)  
    self.with_scope(:find => {
        :conditions => 'flags.flagged_item_id is NULL', 
        :include => :flags}) do  
      self.find(*args)
    end  
  end

Fig.7 - code for imaginary unflagged_items method

How do I do that? Well, I can turn that code into a Module and add it to any class automatically using a little metaprogramming:

  module Flaggable

    def self.included(base)
      base.class_eval do
        has_many :flags, :as => :flagged_item, :dependent => :destroy
      end
      base.extend(ClassMethods)
    end

    module ClassMethods

      def unflagged_items(*args)  
        self.with_scope(:find => {
            :conditions => 'flags.flagged_item_id is NULL', 
            :include => :flags}) do  
          self.find(*args)
        end  
      end  
    end

  end

Fig.8 - Flaggable module

Any model I put the line include Flaggable in will have that method available. So if I include it in the User class I've added a method user.messages.unflagged_items which returns a sort of incomplete version of the find function - with all the necessary logic to limit the list to unflagged items already filled in. I still have to fill in the :all or :first or any other :conditions I want. But the function is sort of half-called. This is a useful thing - getting half-called functions. In functional programming it's called currying. I'll come back to that in a moment.

Anyway, So now my controller methods now look like this:

 def index
    @messages = user.messages.unflagged_items(:all,
      :conditions => ['delivered_at is not NULL and recipient_id = ?', 
        user.id]
    ).paginate(:page => (params[:page] == "" ? 1 : params[:page]))
 end

 def sent_mail
    @messages = user.messages.unflagged_items(:all, 
      :conditions => ['delivered_at is not NULL and sender_id = ?', 
        user.id]
    ).paginate(:page => (params[:page] == "" ? 1 : params[:page]))
 end
 
 def drafts 
   @messages = user.messages.unflagged_items(:all, 
     :conditions => ['delivered_at is NULL and sender_id = ?', 
       user.id]
    ).paginate(:page => (params[:page] == "" ? 1 : params[:page]))
 end

Fig.9 - fragment from new messages_controller.rb

Continue Pruning

It's getting better, but isn't there some way I can pare it down even more? Now I'll go to the User model. Instead of simply using has_many :messages - since has_many supports blocks - I can add some more convenience methods to the User class:

  class User < ActiveRecord::Base

    has_many :received_messages, :foreign_key => 'recipient_id', 
          :class_name => 'Message' do
      def delivered_and_unflagged(page=1)
          unflagged_items(:all, :conditions => 'delivered_at IS NOT NULL'
        ).paginate(:page => page, :per_page => @messages_per_page)
      end
    end

    has_many :sent_messages, :foreign_key => 'sender_id', 
          :class_name => 'Message' do
      def delivered_and_unflagged(page=1)
          unflagged_items(:all, :conditions => 'delivered_at IS NOT NULL'
        ).paginate(:page => page, :per_page => @messages_per_page) 
      end
    end

    has_many :draft_messages, :foreign_key => 'sender_id', 
          :class_name => 'Message', 
          :conditions => 'delivered_at IS NULL' do
      def paginated(page=1)
        paginate(:page => page, :per_page => @messages_per_page)
      end
    end

    def inbox(page=1)
      self.received_messages.delivered_and_unflagged(page)
    end

    def sent_mail(page=1)
      self.sent_messages.delivered_and_unflagged(page)
    end

    def drafts(page=1)
      self.draft_messages.paginated(page)
    end
  end

Fig.10 - more developed User model

I'm doing pretty well with reduction of code in my controller now. The only ugly bit of code leftover is the params[:page]... bit - but I can make that slightly better too by factoring it out. I would like to use params[:page] || 1 but params[:page] returns an empty string if there is no matching parameter and will_paginate interprets an empty string as a request for page 0 and returns an error. So I have to use the longer statement with the ternary operator. Now my controller code looks like this:

 def index
   @messages = user.inbox(figure_page)
 end
 
 def sent_mail
   @messages = user.sent_messages(figure_page)
 end
 
 def drafts 
   @messages = user.drafts(figure_page)
 end

 def figure_page
   params[:page] == "" ? 1 : params[:page]
 end

Fig.11 - pruned fragment from messages_controller.rb

I'm happy enough with that. I've made different lists of messages for the currently logged on User that automatically paginate and filter out flagged items with just one line of code per method.

3) Next and Previous Message

I'm not done yet though - because the view page of a message needs a next and previous link. So if the user is looking at a draft - next should be the next draft - not the next sent message - and previous should be the previous draft - not the previous sent message. Make sense?

One way I could do this is to have a show_draft method, a show_sent_item method etc... and just call the correct link from the correct listing page (i.e. the list of all drafts page has links to show_draft, the sent items page has links to show_sent_item etc...).

There are 2 problems with this though. 1) That is creating several methods for basically one 'show' action. So they will all be virtually the same code over and over again. 2) I'm using a partial to render the list of messages - so I'd have to send in some way to create a different link based on the type of filter ('drafts', 'sent mail' etc...) but I'd rather just call render :partial => "message", :collection => @messages. I don't want the partial to have to worry about what particular filtered list of messages it happens to be rendering.

I'm sure there are a lot of ways to solve this. What I came up with was to add a 'from' value as a parameter for each link_to :action => 'show' in the partial. That way I could just append params[:action] to every url and by the time the controller gets the request, it knows where the request is coming from. This gives me the information I need to respond differently to the show action depending on that parameter. And leaves that logic out of the view.

In order to get the next and previous messages though, I needed to be able to identify and generate a list of messages based on the value of a string (i.e. value of params[:from]).

The code I wrote at first looked something like this and was in the controller:

  def show
    @message = Message.find(params[:id])
    # need @messages for previous, next
    case params[:from]
    when 'sent_mail'
      @messages = user.sent_messages(figure_page)
    when 'drafts'
      @messages = user.drafts(figure_page)
    #...
  end

  def bulk_action
    # ... do bulk action

    # need @messages for previous, next
    case params[:from]
    when 'sent_mail'
      @messages = user.sent_messages(figure_page)
    when 'drafts'
      @messages = user.drafts(figure_page)
    #...
  end

Fig.12 - fragment of messages_controller.rb with new code

So I've lost some of my simplicity, I'm repeating myself again and my code is in need of pruning.

What I need is a function that returns a function waiting to receive arguments. This is similar to the with_scope method I mentioned earlier, and the idea of function currying. I need a function that's partially filled out - but not called yet - waiting for some parameters. This is a good place to use the the fact that a Method is just another object in Ruby - and create a method to return whichever User method I want.

A method that returns a method

  def get_messages_function(param)
    # special case of 'index' action
    if param == 'index'
       self.method('inbox')
    else
       self.method(param)
    end
  end

Fig.13 - fragment from User model

returns a method as an object waiting for arguments. So I can put that code in my User class and I can call it like this in my controller:

 def index
  @messages = user.get_messages_function(params[:action]).call(figure_page)
 end

 def sent_mail
  @messages = user.get_messages_function(params[:action]).call(figure_page)
 end
 
 def drafts 
  @messages = user.get_messages_function(params[:action]).call(figure_page)
 end

 def show
  @message = Message.find(params[:id])
  @messages = user.get_messages_function(params[:from]).call(figure_page)
  # ...
 end

Fig.14 - fragment from new messages_controller.rb

One last trick

I'm almost done. But I can go one step further in minimization of code. Taking advantages of the fact that a method can be converted to a block by putting an & in front of it. In the controller, since all the returned methods are taking that same figure_page parameter - I can factor that out as a method accepting a block and do something like this:

  def index
    @messages = find_messages(&user.get_messages_function(:inbox))
  end

  def sent_mail
    @messages = find_messages(&user.get_messages_function(:sent_mail))
  end

  def show
    @message = Message.find(params[:id])
    @messages = find_messages(&user.get_messages_function(params[:from])) 
    # ...
  end

  def figure_page
    params[:page] == "" ? 1 : params[:page]
  end

  private
  def find_messages(&func)
    yield(figure_page)
  end

Fig.15 - fragment from another revision to messages_controller.rb

It's odd looking, I admit. I've lost a little readability for the sake of density. But I've left myself very little code in the controller and nothing specific about controllers in the model. That much I like.

Conclusion

So if you ever writing a Ruby on Rails application that has messages that need to be filtered, paginated and include a detail view with a previous, next link - you might be able to glean some code from the article to help get started. Also, today's lesson is that it's sometimes handy to pass around functions as objects.

NOTE: I've included a zip file of various items related to this article. It includes some Ruby code as a demonstration which requires a sqlite3 installation. Also, I used Python to generate this document with all the color-coded sections. I've included that in case it is of interest to anyone. It requires the Mako and Pygments packages.

A Fresh Look at Virtualization

Mon, 30 Jun 2008 12:20:41 -0700

For a few years I have been experimenting with virtualization software and technology. Virtualization is not new, and chances are that some of the programs you use on a daily basis using simulation. Manufacturers want to pack as many features as possible into their products and virtualization allows them to create more attractive offerings to purchasers.

It has been only recently, however, that virtualization has caught the public eye as software has evolved to the level where entire operating systems can now be virtualized. Thanks to virtualization Macs can now run Windows, PC's can run Linux and a single computer can run several systems simultaneously. For Killswitch, virtualization means the ability to assess our development solutions in different computing environments without incurring the overhead of purchasing new machines.

Pros and Cons of Virtualization

Here are some possible benefits of integrating virtualization into your workflow:

It allows businesses and power users to test and assess solutions in different environments and configurations on a single machine.
It gives businesses the ability to test out a new system without having to purchase dedicated hardware for it.
It gives power users and businesses the flexibility to switch between different operational environments (for example, between desktop work and local server environments).
It saves money because a system can run on pre-existing hardware.

There can, however, be certain drawbacks:

Older hardware may not have the processing power to successfully run the native system, virtualization and the guest system.
Some functions and features may not work correctly if there are system incompatibilities with the hardware.
Memory limitations may prohibit the environment you are trying to test from properly installing.

Overcoming Obstacles

In my opinion, the biggest obstacles to widespread virtualization are memory limitations and company end user policies. We are barely breaking out of the 4 GB memory limitation that has plagued the computing world for the past several years. Finally there are motherboards that allow users to upgrade from the 4 gigabyte limit to 8 or 16 GB, provided you use the right processor and operating system. The more memory available on a system, the better a computer running virtual systems can handle errors and bottlenecks.

The other problem, which is progressively getting more annoying, is a company's EULA. I understand a company's need to protect its profit margin, but that should not come at the cost of consumer satisfaction. Allowing virtualization of a product does not take away from it; in fact, if the product in question is stable and user friendly, that product will fly off the shelves!

Let's say that your computer is running Ubuntu, but a piece of software you need is available for Windows only, there simply is no equivalent for the Ubuntu platform. What's a user to do? Obviously, you could go out, spend a lot of money and buy a new Windows machine to that one program. Thanks to virtualization, however, you can now load a copy of Parallels Linux on your machine and install Windows XP or Vista. Note: Virtualizing Vista Business and Ultimate violates the software's EULA. If anything goes wrong, you are on your own.

Here at Killswitch we primarily use Macintosh computers, so virtualizing Windows XP has come in handy. At one point we had a client who misplaced some Flash source files that were used to create a .swf file on their site. Wanting to change the content in this .swf file, we needed a SWF decompiler (and we needed it fast). Though we were concerned when we found out the program we needed was Windows only, we were quickly relieved as it ran perfectly on our Macs using Parallels.

Based on my personal experience, here are some software virtualization solutions that I would recommend:

Mac Software

Parallels: This is one of the premiere software packages that you can use to emulate another computing environment. The interface is clear and everything is well explained. I use this both in the office and personally at home.

VMware: I have used VMware and it is right up there with Parallels. Some of the more advanced functions are a little complicated, but there are several tutorials online that can help clear up confusion.

Windows Software

Virtual PC: This software is a veteran commercial product and is a leading virtualization program for PCs with a robust feature set.

Virtual Box: This program is free and very straight forward. You can load Windows, Linux and other operating systems, as well as server environments.

Looking Back at RailsConf 2008

Fri, 20 Jun 2008 08:00:16 -0700

Let's face it, everything seems to move at a breakneck pace in our industry. It seems like every other day there is a new start-up with some amazing product that's supposed to change the way all of us work. At least once a week I get software update notifications for some application or another. It is our job (and usually our passion) as developers to keep up with the tools that we use, and constantly be evaluating these upgrades, new features or sometimes even the alternatives. As a Ruby on Rails shop, there is nowhere better to check the pulse of the Rails community than RailsConf 2008.

RailsConf 2008 was held in Portland, Oregon again this year and Chris and myself had the chance to experience it first hand. It was the first RailsConf for both of us so our expectations were high, and for the most part we weren't disappointed. We met some really cool people from all over the world (including the cool guys from Blue Box Group), picked up a ton of information on where things with the Rails community are headed, and Chris even held a Birds of a Feather (BOF) discussion about his GiftWrap plugin.

There's simply too much to cover in a single blog post for those who couldn't make it, so please excuse my brevity. You can check out O'Reilly's website to read all about the events and schedules, and you can even grab most of the presentation materials there too.

Maybe my surprise was simply because this was my first RailsConf, but some of the best stuff for me wasn't specifically related to Rails! I went to a cool BOF on Rails alternatives, an interesting discussion about frameworks like Merb, Rack, and Mack, and we even got into the DataMapper ORM and replacing Subversion with Git. I also saw some great presentations on meta-programming, the internal workings of Git, and perhaps the topic I was most curious about – Phusion Passenger. I also enjoyed the well-delivered keynotes from Joel Spolsky and DHH. All these things gave me a taste for what else is out there, and how people are using not only Rails but other tools as well in our industry. The BOF sessions were great as well, bringing small groups of really bright people together to just chat about different topics. Oh, and the food rocked – plus all the Starbucks coffee you can handle, sweet.

That said, there were a few things that weren't so great that I thought I should share as well. The topic of scalability has been a hot one since way back when. Maybe it's just because we've built several high-traffic applications, but the scalability issue has been beaten to death in my opinion, and was beaten quite a bit more this year with about 5 talks covering scalability. Also, the tutorials weren't really worth the extra fees in my opinion – don't get me wrong, they were useful and interesting, but several of the topics ended up being covered in other sessions that were part of the conference, some of them were even the exact same presentation! Finally, while it was great to get a feel for a lot of the other tools out there being used, I must admit I was hoping for a bit more Rails-specific content. It was great to see the keynote by Jeremy Kemper announcing Rails 2.1 (some great stuff in there), but I still don't have a feel for the roadmap of development for Rails and where things are going next.

Overall RailsConf was great, and Portland was a great location for it (despite the 4+ hour flight from Chicago). Would I recommend it? Absolutely. You won't find a collection of brighter developers out there than the ones in the Rails community. Everyone seems to 'get it' and they're all interested in advancing the framework and expanding Rails into the main stream. So thanks to everyone who presented, it was quite an experience – see you next year!

Letting Google Globalize Your Rails App

Fri, 13 Jun 2008 14:50:13 -0700

Just give me the globalize_with_google plugin now!

Anybody who's looked into localizing or internationalizing a Rails app has probably come across the "Globalize" plugin. It's a bit of an 800 lb. gorilla in the sense that it supports potentially hundreds of languages, automatic generation of validation messages, and even multiple pluralization cases based on the exact number of objects being counted. (There's a story about a people whose language only had three numbers- 1, 2, and 'many'. Globalize can handle that!) But as long as installation is as easy as "script/plugin install ...", who cares how much the gorilla weighs?

On a related note, Google recently released a series of AJAX APIs that are dead-simple to plug in to any web app, including one that does automatic translation. Can you guess where I'm going with this?

As soon as I saw Google's announcement that they were offering a free translation API, I started thinking about how to write a plugin that used it to initialize a Globalize database.

My solution, as sketched on the back of a napkin, had two pieces: The first would override Globalize's "String.translate" method. The other one would cache the translations so we still had a checklist of phrases for professional translators to go over, if necessary, and so we weren't dependent on the uptime of Google's servers for the functionality of our application. (Not that Google has lousy uptime; but if by chance they ever take down the service or start charging for translations, we can't have our translations just turn off).

The Actual Translation

This part was the easiest. We just modify Globalize's ".t" method to use Google's translation service:

module String
  def self.included(base)
    base.send :alias_method_chain, :translate, :google
    base.send :alias_method, :t, :translate
  end
  def translate_with_google(default = nil, arg = nil)
    local_base_language = defined?(BASE_LANGUAGE) ? BASE_LANGUAGE : 'en'

    #don't translate this if it's already written in the target language
    return self if Locale.language.iso_639_1 == local_base_language

    result = Locale.translate(self, '__translate__', arg)
    return result unless result ==  '__translate__' 

    return %Q{<span id="translation_#{self.object_id}">#{self}</span>
                <script type="text/javascript"> 
                ......}
    end
  end

The only flaw is that you can't use this on the labels of buttons or in javascript alert()s. Instead of showing a translated string, it would display a huge mess of javascript. I don't think there's a simple workaround for this, though, since the ".t" method can't know what context it is being called in. So in your views, make sure all of your translated buttons use something like

<input type="submit" value="<%= "Submit".translate_without_google %>" />

The Caching

This part nearly killed me. How do you cache the result of a google translation? It never goes through our server! The solution was a little convoluted, but very educational to a guy who had never written a plugin before.

First, we need to make the Javascript report the result of each translation back to our server. Fortunately, Google's "translate" function offers a callback once the translation is complete. So I just told it to execute the following:

new Ajax.Request('/cache_google_translation',{method: 'post', parameters: "phrase=#{self}&translation="+result.translation});

Next, we need a way for our Rails app to recognize the request for caching. But how can a plugin respond to a request like a controller does? It takes two steps. First you need to make a pseudo-controller that will do the caching:

class TricksController < ActionController::Base
  def cache_google_translation
    bound_vars = [params[:translation], params[:phrase]]
    ActiveRecord::Base.connection.execute("UPDATE globalize_translations SET built_in = 2, text = ? WHERE tr_key = ? AND language_id = #{Locale.language.id}".gsub('?'){ActiveRecord::Base.connection.quote(bound_vars.shift)})
    Locale.translator.put_in_cache(params[:phrase],Locale.language.iso_639_1,params[:translation])
    render :text => ''
  end
end

And then you need to extend Rails' route parser to attach a URL to your controller. (alias_method_chain to the rescue!)

module MapperExtensions
  def self.included(base)
    base.send :alias_method_chain, :initialize, :google_caching
  end
  def initialize_with_google_caching(set)
    #we have to add ours FIRST, otherwise the final line of the regular routes.rb is usually a catchall that would intercept OUR route
    set.add_route('/cache_google_translation',{:controller => 'google/tricks', :action => 'cache_google_translation'})
    initialize_without_google_caching(set)
  end
end

Finally, in your plugin's init file you just attach these classes into Rails:

ActionController::Routing::RouteSet::Mapper.send :include, Google::MapperExtensions
ActionView::Helpers::AssetTagHelper.send :include, Google::Javascript

And that's it! Well, not quite. Did you notice the reference to Locale.translator.put_in_cache? If you want to make sure that the auto-translations in your database are easily distinguishable so that you can have them manually translated later (machine translation isn't quite there yet!) then you have to add an extra step. It was easy enough to use a manual update statement instead of Locale.set_translation, which allowed me to set "built_in = 2" (that's how you recognize the auto-translations). But then the 800 lb. gorilla gets in the way. Globalize maintains a separate cache of translations in memory to avoid wear and tear on the database, but if you don't update the copy in memory as well, Globalize will never actually USE your cached version! It's a protected variable, so one more module extension:

module LocalizeCacheAccess
  def put_in_cache(key,language,translation)
    @cache["#{key}:#{language}:1"] = translation
  end
end

and then include it in your app with

Globalize::DbViewTranslator.send :include, Google::LocalizeCacheAccess

And that's it! Now you're REALLY done! To get all of this code in a simple Rails plugin, download globalize_with_google.zip and unpack it in #{RAILS_ROOT}/vendor/plugins/.

Wrapping Up View Repetition with GiftWrap

Tue, 03 Jun 2008 13:33:38 -0700

NOTE: My thanks go out to the guys at RailsConf who attended my "Birds of a Feather" talk about DRYing up views using wrapper helper classes. They gave me the idea to abstract my ideas one level further into its own class and now we have GiftWrap -- I hope you guys can make good use of it!

Just get GiftWrap now!

UPDATED: GiftWrap has been now been updated to allow for using wrapper partials with the use_partial method rather than the before_yield and after_yield methods. Read the README file to see examples of how to use this new functionality.

Blocks and Procs

I have always been very impressed by the way the Rails form_for helper method works. I loved that you never had to remember the </form> closing tag or use the silly (and very deprecated) end_form_tag helper method. Perhaps what I was most drawn to about the method was how the block acted as a "closure" -- not just in the programming sense, but also in a semantic sense. It struck me as very beautiful that this method could create a mini-environment of rules and abilities, allow anything to happen within this environment and then close that context until the next time.

And that, of course, is the beauty of using blocks and procs in Ruby.

So why do these blocks in the view stand out to me when their counterparts in models and controllers simply aren't that big of a deal? I think part of the reason is that you don't see blocks in the view very often. The content_tag helper takes a block, but the method itself isn't really that helpful. Looping methods like each take a block, of course, but again that's nothing to blog about. Form_for seems to be a fairly unique method within the Rails framework.

I have found, however, that using blocks within the view to wrap and contextualize markup can be extremely helpful in DRYing up views and making markup more modular.

Nice and Easy Blocks with GiftWrap

Creating a method that works like form_for is a little tricky. First you have to create a helper class with a series of methods for generating the wrapper markup and anything else you need. Then you need to create the helper method itself, which initializes your class, uses the confusing concat method to write your wrapper markup to the ERB buffer, and then yields the class instance to your block.

Thankfully, I was able to abstract all the common elements into the GiftWrap class. By subclassing GiftWrap and following a couple simple conventions, you will easily be able to create wrapper classes that can bring clarity and DRYness to your views.

Example: The Help Popup

The site that I am currently building requires a large number of "question mark" buttons -- if the user is unsure of what a certain section of the site does, a quick press of help button gives them a simple popup box with an explanation. The markup for these buttons/popups looked like this:

<p class="help_popup_link" id="feature_help_popup_link">
  <a href="#" onclick="$(this).up('.help_popup_link').next().toggle(); return false;">Help</a>
</p>
<div class="help_popup" id="feature_help_popup" style="display: none;">
  <p class="close_button">
    <a href="#" onclick="$(this).up('.help_popup').hide(); return false;">Close</a>
 </p>
 <!-- any amount of markup should be insertable here -->
</div>

These popups will all share similar markup, but their content can vary wildly. I quickly ruled out using partials to DRY my view -- I need too much flexibility in what goes inside this wrapper markup.

I chose instead to use a wrapper class that inherits from GiftWrap.

class HelpPopup < GiftWrap

  before_yield :help_button, :open_block, :close_button
  after_yield :close_block

  def initialize(id)
    @id = id
  end

  private

  def help_button
    %Q{
      <p class="help_popup_link" id="#{@id}_help_popup_link">
        #{link_to_function 'Help', "$(this).up('.help_popup_link').next().toggle()"}
      </p>
    }
  end

  def close_button
    %Q{
      <p class="close_button">
        #{link_to_function 'Close', "$(this).up('.help_popup').hide()"}
      </p>
    }
  end

  # Called before yielding a block to this instance
  def open_block
    %Q{<div class="help_popup" id="#{@id}_help_popup" style="display: none;">}
  end

  # Called after yielding a block to this instance
  def close_block
    "</div>"
  end

end

As you probably have guessed, the methods passed into the before_yield method will be called in order before the block is run and the returned values will be added to the markup. The after_yield method acts the same.

When GiftWrap is subclassed, a helper method is dynamically generated as the underscored name of the new class. In this example the helper method will be named help_popup because the class is named HelpPopup.

The implementation now looks like this in the view...

<% help_popup :feature do %>
  <p>This is explanation text within the popup box.</p>
  <p>More text here.</p>
<% end %>

This generates this markup...

<p class="help_popup_link" id="feature_help_popup_link">
  <a href="#" onclick="$(this).up('.help_popup_link').next().toggle(); return false;">Help</a>
</p>
<div class="help_popup" id="feature_help_popup" style="display: none;">
  <p class="close_button">
    <a href="#" onclick="$(this).up('.help_popup').hide(); return false;">Close</a>
 </p>
 <p>This is explanation text within the popup box.</p>
 <p>More text here.</p>
</div>

Example: Boxes with Rounded Corners

Another quality of this site is that it uses boxes with rounded corners extensively. Using a GiftWrap subclass I can remove all the repetitive wrapper markup needed for a 'sliding doors' approach, but that's not all! I also want to use a standard set of markup and CSS classes for my subheaders and "more" links, so it would be great to encapsulate that within this block as well. Here's how we can do it...

class RoundCornerBox < GiftWrap
  before_yield :header, :open_divs
  after_yield :close_divs

  # A new instance of RoundCornerBox will be instantiated each time the
  # dynamic round_corner_box is called in the view. The arguments passed into
  # the helper method are passed on directly to the initialize method.
  def initialize(name, options={})
    @name = name
    @header = options[:header]
  end

  # # # These methods can be used within your wrapper block. # # #

  def subheader(text)
    "<h4 class='subheader'>#{text}</h4>"
  end

  def more_button(text, url)
    "<p class='more_button'>#{link_to text, url}</p>"
  end

  private

  # # # These methods will only be used internally for creating the wrapper markup. # # #

  def header
    @header ? "<h3 class='round_corner_box_header'>#{@header}</h3>" : ''
  end

  def open_divs
    %Q{
      <div class="round_corner_box_top">
        <div class="round_corner_box_bottom" id="#{@name}_round_corner_box">
    }
  end

  def close_divs
    "</div>\n</div>"
  end
end

Now here's how we can implement those public methods...


<% round_corner_box :news, :header => "Today's News" do |b| %>
  <%= b.subheader "Top Story" %>
  <p>Today was a very exciting day in the news...</p>
  <%= b.more_button "Full Story", top_story_path %>

  <%= b.subheader "Lesser Story" %>
  <p>This story is definitely less important than the top story...</p>
  <%= b.more_button "Full Story", bottom_story_path %>
<% end %>

With the GiftWrap class, you now can easily harness the power and flexibility of using wrapper classes in your view to DRY up your code. So go ahead, get GiftWrap now!

If you have ideas for how to improve or extend GiftWrap, please feel free to fork the Git repository or leave comments.