a timocracy of one

An eye-opener about your own biases

Mon, 10 Oct 2011 09:27:00 -0700

Even though I have been preaching about this stuff, and admitting I have non-conscious biases, it still caught me off guard to see it in myself: a web demo of Harvard's studies on our implicit, unconscious biases that you can take yourself in 5-10 minutes (per test).

Permalink | Leave a comment »

My response to the pushback on my diversity talks

Sun, 09 Oct 2011 10:29:00 -0700

After I gave a couple inflammatory talks on diversity and discrimination in the ruby community I got some feedback and pushback.

Here is my response:

To use your example, plenty of hockey players are probably racist, actually, even if they don't realize it. Not to pick on them, but part of my talk was about how pretty much everyone is, they just don't consciously acknowledge it. I'm not talking about overt racism, just the basic assumptions of the privileged that come out in everything because they don't realize the are privileged and how underexposed to other cultures, races, ways of life, etc, they may be.

Athletes in all nearly white fields certainly aren't immune to bigotry. Having grown up a competitive bump skier I can attest to that. Like most winter sports it's a very white field. Often bigotry is strongly linked with lack of exposure and diversity. Due to the very fact of not having more minority and female colleagues we start subconsciously building assumptions.

In SF, the majority of downtown business people's exposure to black people is the homeless. I'd put a fiver on that negatively affectively their biases. There are studies that watching the Summer Olympics, which has a lot black role models performing well, temporarily counters some of the subconscious racist bias in test subjects. And I think everyone has anecdotal experience with racists justifications they've overheard that negative experiences can create biases.

A large part of what sparked my initial talk, was a) @bryanl giving a talk where he had a line about it being about time we (the white audience) were the uncomfortable ones in the room and b) @gigglegirl4e gaving a talk titled "Whose wife are you?" because that is something she hears, especially at conferences. As long as she is hearing that...

You really should read up some on feminist theory and privilege. I really, really don't care if a bunch of straight white males get a little offended that they don't realize how good they have it and how exclusionary they are. I am queer, and yes the field is to blame. Not entirely, no. And maybe in part it's better than other fields, but it's far worse than many. We are an awesome, low bullshit community, based around a very easy language to learn. We should be the best community there is on this topic. It's not that I don't love us, it's that I do enough to have set a higher bar for my expectations. As @dnscollective said in his far gentler, more inclusive lightning talk, let's be the industry and community we want to work in.

If you think being offended at having people say the field is discriminatory and that you have biases is rough, then you should sit down longer and listen, not talk to, but listen to some of the black guys or women in the field, on the topic. Not all of them may have had a rough time, but most will be able to talk your ear off.

As for the other example, I think comparing the cultural stereotype of interior designers all being gay, to the straight, white, male predominance in ours is actually offensive. For one, it's based on a huge assumption without any apparent research backing it. It comes off as a defensive knee-jerk rather than having to admit that being a white male in a field making giant amounts of money, while the rest of the country swirls down the drain, might be a pretty cush situation, that being excluded from is actually a form of class warfare. Do you think Interior Design and Ruby Programmer are equivalently powerful positions in our current economy? Also, there are some long standing reasons for straight men not being as prevalent in Interior Design (which has actually shifted farther in the last 5 years than our field, so hah, its a straw man AND moot!) and they have mostly to do with sexism and discrimination.

Interior Design has been the domain of housewives and openly gay men, because the "real men" were busy dominating the "real jobs." Do you think Jewish people were discriminating against the goyim by keeping them out of the money-changing field, during a couple hundred (or thousand?) years of European history? By my admittedly limited reading (not being a history major), largely not, it was actually discrimination the other way that drove Jewish people into that field as one of the few jobs they were allowed.

Also, I don't get what our whole field's anti-intellectual and academic obsession is. We seem fine saying "Well I haven't read the Gang of Four, but it's not much use anyways" or "Well I haven't really studied this field, but I have lots of opinions based on my own personal experience which is obviously applicable to the position of the historically discriminated-against and oppressed." This stretches out to me, too - I am a college drop-out. So I do understand the bias against overly academic CS, but unfortunately, we've let it bleed over so far into anti-academia that we sounds like George W. Bush supporters ranting against those damn liberal (feminist) snobs, sometimes.

Usually, I just write negative responses off as the classic example of what happens when you speak to power and privilege: offense, defensiveness, and pooh poohing. "There isn't any problem with black people having to use separate water fountains; they get the same water." Almost universally, IME, when you explain the huge difference between discrimination by the majority, by the patriarchy, by those who have always had it easier, without even realizing how much so, versus discrimination up the ladder by the oppressed, you get anger, justification, and dodging of responsibility.

In fact DHH, is one of the few counter-examples I can think of - after the first Gogaruco, when these concepts were explained to him he said roughly "Hmm, that makes sense, if you are already the minority in the room, and here for professional development or work, that wouldn't be very fair, to be forcefully exposed to something that highlights just how in the minority you are." When he did that I gained even more respect for him than when I got in a technical debate with him and only realized how right he was 3 months later, when I learned more.

End of my response

I never sent it, because the guy in question wrote the nuancing reply that I mention in my previous post and gave me the go ahead to use his anonymous words for a discussion point. And now I add him to the small pool of guys who, even when pushed hard by my intentionally inflammatory, discussion-starting claims, actually listen, process, and admit that maybe those crazy feminists aren't totally making this all up. ;)

UPDATE

Thanks for the edits @alexch

Permalink | Leave a comment »

Pushback from my diversity talks

Sun, 09 Oct 2011 10:18:00 -0700

This is part of the exchange that occurred in response to my talk on diversity at gogaruco, where I pointed out the the entire audience, and myself, are a bunch of sexist, racists, homophobic bigots, and the slightly more nuanced followup at rubyconf.

I'm anonymizing this to avoid causing a flame war for the quite reasonable guy who posted it, and because he followed up with this:

Well, I'm glad we had our conversation last week. I feel less strongly about the issue now than I did before that conversation. I think I was mostly reacting to the inflammatory nature of your talk (ie. opening with calling the audience racists, bigots, and misogynists). I've gone back and watched your talk on confreaks, and it doesn't seem as inflammatory as it did that night (chalk that up to either having more perspective after our conversation, or being over the shock value of those statements).

...

So I feel I've gotten my thoughts out of my system, and don't feel strongly enough to post them publicly.

His original thoughts are below:

I care about equality and despise discrimination, and yet I am concerned and offended by a growing trend to accuse the technology sector, and the software industry specifically, of being bigots, racists, and misogynists. Think about this question: Are the interior decorating power elite keeping straight men out of their industry? I don't know the answer to that question, but I doubt that they are. Some may suggest that the analogy isn't a good one, because straight men aren't typically systematically oppressed. I'm not sure I agree with that either. I'll return to this analogy.

I've not studied discrimination, oppression, women's issues, etc. beyond that which is taught in a typical American college education and that which is generally reported in major news media. But I do have eyes, ears, an open mind, and I generally don't see evidence of discrimination in the software development industry.

I do see that the industry is dominated by white males. There is no question of that. Furthermore, I personally would greatly welcome more diversity. But are the demographics of the software development industry an indication of systematic oppression/discrimination? Is the white male dominance a malignancy?

Surely there is discrimination. I would be foolish to suggest that it doesn't happen. It is a sad fact that discrimination persists everywhere. So when blaming a lack of diversity of a group on discrimination, then surely the accusation is that the group discriminates more than the population on whole.

[need to flush out more of my thoughts prior to wrapping up]

Returning to the analogy of the interior decorating industry, I would argue that fewer straight men are interested in interior decorating. I would also argue that there is nothing wrong with that. To argue otherwise would to suggest that there should be a uniform distribution of interests and competencies across all genders, races, and sexual orientations. I don't believe that belief in human equality in general means a belief in uniform distribution of interests and competencies.

[Other analogies include: Are ice hockey players racist since most ice hockey professionals are white males? I'd argue that socio-economics play a bigger role in determining someone's likelihood of becoming a professional hockey player.]

Permalink | Leave a comment »

Video of the 'Scaling your Rubyists' the panel I organized on hiring rubyists

Sun, 09 Oct 2011 07:58:00 -0700

Permalink | Leave a comment »

My 2nd diversity lightning talk - rubyconf

Thu, 06 Oct 2011 07:00:00 -0700

A less rapid and angry diversity lightning talk for rubyconf 2011. I think I might mix it up and continue to give some variation of this at each conference I attend.

Permalink | Leave a comment »

My diversity lightening talk at gogaruco

Sun, 18 Sep 2011 10:12:00 -0700

www.justin.tv/timocratic/b/295399005

Permalink | Leave a comment »

My upcoming speaking events

Thu, 18 Aug 2011 01:25:33 -0700

I had a blast speaking at the Database meet-up that Wellness FX put on last month where I talked about managing migrations in Mongo. I'm pumped to follow that up with speaking at Madison Ruby this coming week-end where I will be expanding the material from that initial 20 minute talk to the fuller 30 minutes allotted at Madison. I'll definitely be fleshing out some of the positives of working with MongoMapper that I glossed over in the initial talk - namely the incredibly fun power of the DataMapper pattern combined with a schemaless datastore. Hopefully this helps alleviate some of the anti-Mongo vibe my first talk seemed to give off; MongoHQ are speaking at Madison as well and we wouldn't want that to lead to a pub brawl during the post conference drinking (we're rubyists, the drinking is a given). Don't worry though, I won't let that entirely keep me from speaking my mind. ;)

Next I'm organizing a panel on hiring rubyists, coming up in Sept, with some very well known names in the local ruby community. I'm honored that they all seemed to jump at the chance to do this panel with me. As a consultant, how to deal with hiring rubyists is a question that comes up constantly and it will be great to get these 4 views on the topic posted up on the web so I can point to it and say "that's how." I definitely have to say thank you to Engine Yard for graciously offering to host the event.

And to cap off my continuously expanding talk on Mongo and how to deal with your lack of schema, data validity, migrations, etc, I will literally be closing down the conference at RubyConf. I'm hoping that even though I am speaking dead last, my immediately following Tom Preston-Werner will help motivate attendees to stay to the bitter end for my talk. I will have already added some code examples to my nearly Bauhausian minimilist slides from the Wellness event for Madison, but talks are 45 minutes at RubyConf, so there will certainly be even more of the nitty gritty and code examples that people have been asking for.

Permalink | Leave a comment »

The unbearable flexibility of schemalesness

Sun, 20 Mar 2011 13:45:00 -0700

Everybod hates Single Table Inheritance, right? MongoMapper has a similar concept, Single Collection Inheritance, but also a better alternative. MM provides, and in fact is mostly built with, a simple plugin system that is a thin wrapper around ruby's include. It includes the InstanceMethods, extends the ClassMethods, and provides a callback for configuring the model.

This better use of the ruby approach to grouping methods into modules becomes truly powerful when combined with the DataMapper pattern (which MongoMapper essentially implements) and a schemaless datastore like Mongo.

In the gist below I demonstrate using MongoMapper's plugin system to build aggregate models, in place of a pure single inheritance hierarchy with which it is fully compatible. You can couple this with composition by using your plug-in to add associations and associated proxy methods for them.

I think this flexibility is the real power of NoSQL: not "web-scale", which people have been doing with SQL for years, but defining your data type once, in your model, with the full dynamism of ruby. I was skeptical about key-value stores as a default storage engine for web apps, until very recently, and still think MySQL is the right answer for many people and projects. But my most recent client project uses MongoMapper, and as we started to refactor and DRY up the models, I finally saw how truly useful not being bound to a datastore's schema is.

Migrations? Yes, you don't get AR migrations. The 'proper' migrations, which only affect schema, are unneeded anyways, in a DataMapper. And data migrations are done wrong 99% of the time anyways, imo; pretending they are instantaneous is a mistake. In either AR or MM you should handle you data migrations more robustly, via code switches and async tasks to transform the data. If I get a chance to make this a talk, I may explore that more fully.

#rvm use 1.9.2
#brew install mongo
#gem install mongo_mapper
#gem install bson_ext

require 'rubygems'
require 'mongo_mapper'

MongoMapper.database = 'mm_demo'

module MMDemo
  module HasDoorsAndWindows
    def self.configure(model)
      model.key :doors, Integer, :default => 0
      model.key :windows, Integer, :default => 0
      model.key :sun_roof, Boolean, :default => false
    end
    
    module InstanceMethods
      def enterable?
        doors > 0
      end
      
      def well_lit?
        windows >= (doors * 5)
      end
    end
  end
end


class House
  include MongoMapper::Document
  
  plugin MMDemo::HasDoorsAndWindows
end

class Vehicle
  include MongoMapper::Document
  
  key :wheels, Integer
end

class Motorcyle < Vehicle
end

class Car < Vehicle
  plugin MMDemo::HasDoorsAndWindows
  def well_lit?
    sunroof?
  end
end

require 'minitest/autorun'

describe "a House" do
  it "has doors" do
    House.new(:doors => 2).doors.must_equal 2
  end
  
  it "has windows" do
    House.new(:doors => 7).doors.must_equal 7
  end
  
  it "is enterable if there are any doors" do
    House.new(:doors => 0).enterable?.must_equal false
    House.new(:doors => 4).enterable?.must_equal true
  end
  
  it "is enterable if there are any doors" do
    House.new(:doors => 0).enterable?.must_equal false
    House.new(:doors => 4).enterable?.must_equal true
  end
  
  it "is well lit if there are 5x as many windows as doors" do
    House.new(:doors => 1, :windows => 5).well_lit?.must_equal true
    House.new(:doors => 1, :windows => 4).well_lit?.must_equal false
  end
end

describe "a Car" do
  it "is well lit if it has a sunroof" do
    Car.new(:sunroof => true).well_lit?.must_equal true
    Car.new(:sunroof => false).well_lit?.must_equal false
  end
end

Permalink | Leave a comment »

A pattern for testing class methods in ruby with rspec explicit subjects

Mon, 07 Feb 2011 21:57:00 -0800

RSpec's subject method, both implicitly and explicitly set, is useful for declaratively setting up the context of the object under test. If you provide a class for your describe block, subject will implicitly be set to a new instance of this class (with no arguments passed to the constructor). If you want something more complex done, such as setting arguments, you can use the explicit subject setter, which takes a block.

describe Person do
  context "born 19 years ago" do
    subject { Person.new(:birthdate => 19.years.ago }
    it { should be_eligible_to_vote }
    its(:age) { should == 19 }
    it "should be younger than a 20 year old" do
      twenty_year_old = Person.new(:birthday => 20.years.ago)
      subject.should be_younger_than(twenty_year_old)
    end
  end
end

The subject block is called after any befores. In fact, it is not called until it is referenced in the spec - the compact syntaxes of 'it { should }' and 'its(:property)' implicitly call subject as needed*. This means any method calls in the subject block reference the state of the system (like your db), at the time subject is called.

describe "the oldest person" do
  subject { Person.new(:birthdate => Person.oldest_person.birthdate - 1) }
  it "should be older than the next oldest person" do
    original_oldest_person = Person.new(:birthdate => 100.years.ago)
    subject.should be_older_than(original_oldest_person)
  end
end

subject thus provides a decent syntax for testing method calls directly. Sometimes, though, you have methods you want to test almost purely based on what is passed into them, with few other concerns of state, for instance, when testing class methods. These specs may have a little shared set-up needed, but really the true object under test is the method call itself. In these cases it makes sense to set that as the subject, and this leads to an effective and succinct, if slightly distasteful, pattern for setting the method arguments via standard rspec ivar trickery.

describe ".first" do
  before { Person.create_10_people }
  subject { Person.first(@number_of_people) }
  it "should return the specified number of people" do
    @number_of_people = 5
    subject.size.should == 5
  end
  
  it "should return a single person when so specified" do
    @number_of_people = 1
    subject.should be_a(Person)
  end

  it "should default to returning a single person" do
    subject.should be_a(Person)
  end
end

I was bemoaning the difference between ruby and more functional languages like JavaScript, where you do have ways of easily differentiating between a method reference and call (parentheses), and how that would make a pattern like this easier by letting you set the method as the subject and then call it in the spec. Then I realized, of course ruby has a way for creating a callable reference like this: a lambda.

describe ".first" do    
  subject { lambda { |number_of_people| Person.first(number_of_people  ) } }
  it { subject.call(5).size.should == 5 }
  it { subject.call(1).should be_a(Person) }
  it { subject.call.should be_a(Person)
end

If I continue to like this pattern enough after more usage, I'll probably see if I can get them to accept a patch to allow passing of arguments directly into subject itself. That could possibly get a little messy in the code for subject itself, but behind the scenes gymnastics to get a nice testing syntax is what rspec is all about, after all.

*The latter syntax actual resets subject, the getter, to be the result of the property access, allowing for the intriguing abuse of syntax: 'its(:property) { subject.should....'

Permalink | Leave a comment »

Simplest static site on Heroku (plain Rack)?

Sun, 05 Dec 2010 21:47:00 -0800


  gem 'rack-rewrite', '~> 1.0.0'
require 'rack/rewrite'

use Rack::Rewrite do
  rewrite '/favicon.ico', '/images/favicon.ico'
  rewrite '/', '/index.html'
end
run Rack::File.new('public')

Permalink | Leave a comment »

Help me pick the new logo for my company

Tue, 09 Nov 2010 08:07:04 -0800

So, as part of transitioning back to full-time contracting I am rebranding my company. Help me pick the final logo design: http://99designs.com/logo-design/vote-mwq9kd

Permalink | Leave a comment »

The new css 100% width and height with header and sidebar

Sun, 10 Oct 2010 15:08:00 -0700

It's been a while since I've had to deal with making a cross-browser 100% height layout - long enough that a couple version of IE have come out since. CSS support in IE has come a long way, so I thought I'd start fresh and try a purely standards based approach for the latest IE and standards based browsers, using the 'display: table-*' styles, and just do a fallback for older versions of IE (a 100% height modified Holy Grail layout that relies on the IE quirks box-model).

Unfortunately, while IE8 does support the table display styles, IE7 doesn't, and there doesn't seem to be any way to put IE7 in quirks mode, while keeping IE8 and every other browser in standards mode. So I just settled on the old-fashioned approach of having one layout for all other browsers and keeping the IEs clumped together in quirks mode.

See the full gallery on Posterous

<!-- keep IE in quirks mode -->
<!DOCTYPE html>
<html>
  <head>
<!-- This following meta tag does no good since there is no way to trigger quirks
mode only in IE7.  The problems with an xml prolog that triggered quirks mode were
fixed in IE7, but this meta tag was not yet introduced, so the only thing you can do
is trigger IE-wide quirks via the comment before the DOCTYPE //-->
    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />
    <style type="text/css">
/*You still need an unbroken chain of 100% from the viewport down to the 'table' 
container*/
      html, body, #wrapper { margin: 0px; padding: 0px; height:100%; }

/* This is the heart of the new layout.  You don't even need to worry about 
min-height vs. height issues, because table handle those fine without weird issues
when the browser window becomes smaller than the content.*/
      #wrapper            { display: table;      width: 100%;  }
      #header             { display: table-row;  height: 99px; }
      #logo               { display: table-cell;               }
      #header_contents    { display: table-cell;               }
      #container          { display: table-row;                }
/* This is the one min-X needed, it prevents the sidebar from collapsing down to
it's contents width when the containing div tries to shrink due to the window being
shrunk down*/
      #sidebar            { display: table-cell; width: 200px; 
                            min-width: 200px; vertical-align: top;}
      #content            { display: table-cell;               }
      
/* Fluff, purely for illustration of the containers */
      .box { width: 100px; height: 100px; background: grey; }
      #content .box { width: 300px; }
      #header_contents { border: 2px solid green; background-color: #cfc; }
      #sidebar { border: 1px solid blue; background-color: #ccf; }
      #content { border: 2px solid red; background-color: #fcc; }
    </style>
<!-- The quirks mode based IE approach below.  Since in that box model paddings and
margins are not additive with the contents width/height, you can just add some
paddings to the parent. For an explanation of the sidebar negative margin tricks,
google 'holy grail css.' And the header is just absolutely positioned over the space
created by the padding trick on the container //-->
<!--[if IE]>
    <style type="text/css">
      #wrapper, #logo, #header, #container, #sidebar, #content { display: block }
      #header { position: absolute; padding-left: 200px; }
      #logo { float:left; height:100%; width:200px; margin-left: -200px; }
      #header_contents { height: 100%; width:100%; float:left;}
      #sidebar { float: left; height: 100%; margin-left: -200px; }
      #container { height: 100%; padding-top: 99px; padding-left: 200px; }
      #content { height: 100%; width: 100%; float: left; }
    </style>
<![endif]-->
  </head>
  <body>
    <div id="wrapper">
      <div id="header">
        <div id="logo">Logo</div><div id="header_contents">Header</div>
      </div>
      <div id="container">
        <div id="sidebar"><div class="box">Sidebar</div></div>
        <div id="content">
          <div class="box"></div>
        </div>
      </div>
    </div>
  </body>
</html>

Permalink | Leave a comment »

Getting back on the horse that threw me

Sat, 09 Oct 2010 16:31:17 -0700

So after about 3 years of happily working at YieldBuild, I decided it was time to try something new (or retry something old). I'd still definitely recommend them as an employer, so let me know if you want to your resume passed along.

I'm in the process of rebooting my web contracting firm (I'll post when I have the new rebranded web-site up) and am currently doing a gig at the the incredible Pivotal Labs; learning more about their approach to the agile way.

I am planning on focusing on doing quick prototypes for start-ups/founders that will help them flesh out their ideas and perhaps secure funding for a next stage. Projects initially too small for a firm like Pivotal could grow to a size they would be interested in after I help them out.

That means I'm definitely in the market for contract work again. I'm busy 9-6 PST for a while, since Pivotal does full-time pairing and you can't cut out easily for other stuff, but I have a some bandwidth for side-projects in the evenings and on the week-ends.

And after that gig wraps up I'll be looking for more larger projects - if I can get enough consistent work I may be rehiring some of my old employees.

Drop me a line if you need some ruby, javascript, html/css, etc done.

Permalink | Leave a comment »

A list of some sites I follow to keep up in my field (ruby and web development)

Sat, 04 Sep 2010 14:33:21 -0700

http://www.google.com/reader/bundle/user%2F12740622692005399469%2Fbundle%2FRuby%20JS%20and%20other%20dev

Permalink | Leave a comment »

Git sub-tree merging back to the subtree for pushing to an upstream

Mon, 21 Jun 2010 17:35:00 -0700

While git sub-tree merge strategy works great for merging a library into vendor (when you want to pull HEAD on that library instead of waiting for releases), I had trouble finding documentation on pushing back to upstream. This is annoying because one of the most obvious times you may want to use subtree is when you manage the library yourself, so can just pull straight from the repo, and want to push your maintenance changes back.

Surprisingly, and not what I have come to expect from git, it just works. From the example in the docs I linked, when you are checked out on master

git merge --squash -s subtree --no-commit rack_branch

will merge the rack_branch into where you have specified. But it just works the other way to. If checked out on rack_branch

git merge --squash -s subtree --no-commit master

will do what you expect, so you can now just push your library branch back to it's upstream.

Awesome!

Permalink | Leave a comment »

Our vows and pre-vow speeches

Wed, 19 May 2010 23:32:00 -0700

Roula

I am honored that you have chosen me to be your wife. You: the best person I know, my dearest friend, the highlight of my day.

I may have doubts and questions about life, but of you and this marriage I have none - it is the most fulfilling work of my life.

The sounds of your voice and the touch of your hand assures me that I am, at last, home, and I cannot wait to spend the rest of my life with you.

I love you now and always.

Tim

Some of you know that we aren't very traditional and aren't sold on the cultural expectations of marriage. We decided we'd try and have a kid before we decided to get married and we live as if we are married: we live together, share our expenses, daily life, hopes, dreams, and plans. Yet, I very much wanted to have a wedding and get married.

I want to commit so absolutely that Roula can feel it incarnated on her finger. I want her to have a constant reminder that I am here for her, at all times, and I want the same for me. I want to gather our loved ones and have them share a moment where we formalize our commitment. I want to crystalize and distill this moment down for all eternity, for us to share and remember when we are 102 and and hobbling down to the park for a Sunday picnic. I want to make the implicit, explicit, and for us to say out loud, in front of witnesses, the things we already both know and feel.

Vows

I promise to love and treasure you always, in sickness and in health, in poverty and in wealth;
to be considerate of your feelings, kind in all things, and ask forgiveness when I fail at that;
to talk through the tough times and always remember to the good ones;
to hold you above all others in my heart.

This I vow: to commit to this marriage with all my being and no reservations.

Permalink | Leave a comment »

The Tea Party is Racist

Tue, 27 Apr 2010 18:09:45 -0700

http://politicalirony.com/2010/04/27/the-tea-party-is-racist/

Permalink | Leave a comment »

Unobtrusive JavaScript vs. Kool-Aid

Tue, 27 Apr 2010 18:06:44 -0700

Great response to @jamis' UJS == Kool-aid posts. Welcome to the post-2005 era of web dev. ;)

Unobtrusive JavaScript vs. Kool-Aid

via DailyJS on 4/26/10

This article is a guide to writing unobtrusive JavaScript. It’s not always easy for people to transition to writing JavaScript this way, so I’ve tried to address common concerns.

The techniques presented here should enable you to think differently about client-side code and work more productively.

Background

It’s important to realise that unobtrusive JavaScript is an evolving concept, perhaps even a movement. The broad goal is to separate JavaScript into a behaviour layer, but related goals include: enhancing browser behaviour, capability detection, and transparently supporting modern platforms like touchscreen phones.

This article was inspired by my surprise at the following tweets:

almost two months later, I’m still have trouble swallowing the UJS kool-aid. @jamis

Funny how the JS people get all shocked and dismayed when jamis complains about UJS. Evidence of kool-aid. @rjs

Unobtrusive JavaScript isn’t a fad, it’s how you should write JavaScript. If you read this blog, you’re probably doing it already. If you have server-side developer friends who don’t write much client-side code, please send them this article!

I don’t advocate blindly applying the techniques championed by the proponents of unobtrusive JavaScript. However, I have learned lessons from several hard-won battles which have enabled me to write JavaScript more productively — my own practices have evolved towards unobtrusive JavaScript over the last 4-5 years.

Inline JavaScript

Where does inline JavaScript come from? One common place is server-side frameworks. It’s easier for frameworks to inject JavaScript through helpers — popular frameworks like Rails do this. This is because the HTML and JavaScript these frameworks generate is naturally tightly coupled. It’s also because the framework builders often try to appeal to the host language rather than seasoned JavaScript developers.

Inline JavaScript crops up in several places:

Events like onclick are added to page elements through attributes
Inline script tags
Conditionally generated combinations of the above
Custom solutions like Rails’ RJS templates (often used to communicate between the server and client)

These techniques work well for frameworks and make life easy for the host language developer. In fact, Rails is one of the projects that helped JavaScript frameworks bring Ajax to the world, and also the now ubiquitous use of visual effects through projects like Scriptaculous.

The Alternative

The alternative isn’t just about moving your JavaScript into its own files. It’s to change the way you think about JavaScript, the DOM, and HTML templates.

If you’ve worked with CSS, you’ll be familiar with the separation of style from structure through the use of stylesheets. The popular argument for writing unobtrusive JavaScript is that scripts define a behaviour layer, and therefore should be separated, just like stylesheets.

This is true up to a point, but it takes a leap of faith to get there. The key is to stop thinking about templates like static blocks of HTML, and see documents for what they are: living, breathing tree structures of DOM objects, events, and styles.

Concerns

The main concern of those who are uncomfortable with writing unobtrusive JavaScript is maintainability. This is deeper than just finding code, or the link between a template and a script — it also affects project management.

When planning new features, it can be difficult to determine what page elements will be affected by a change if all of the JavaScript is outside the templates.

Or is it?

Mental Models

People resist writing JavaScript this way is because their mental model of a HTML document is based on HTML templates. A more useful mental model is one which encapsulates the true nature of the DOM — a document is a collection of interrelated objects, affected by scripts, stylesheets and their very structure.

When I start work on a new project or feature, I think in terms of these objects and how they’re related. I try to group like items and behaviours — just as styles can be efficiently shared, events can also.

Strategies and Patterns

DOM Ready

This is what makes healthy client-side code possible. DOM ready lets you run a function when the document is in a usable state. This allows you to safely bind event handlers. In jQuery it looks like this:

$(document).ready(function() { // Your code here });

Prototype:

document.observe("dom:loaded", function() { // Your code here });

This isn’t actually an easy thing to write from scratch — let the framework do the work. I’ve written my own DOM ready handler before and it wasn’t much fun (mainly due to IE).

Event Delegation: DRY

If you’ve come to JavaScript through jQuery, you might be wondering what I’ve been talking about. People raised on jQuery think in terms of event delegation, and this is one of the key strategies to writing unobtrusive JavaScript.

Event delegation is where an event is bound to a containing element, then conditionally executed based on the event’s element.

Imagine if you wanted to open popup windows when the user clicks a link. You could attach an onclick attribute and set up a window. Every link would then have to repeat this code.

An alternative approach is to use event delegation to bind an event to a high level element, the use a class to trigger a special popup event handler:

$(document).click(function(event) { if ($(event.target).is('.popup') { // Open a new window with specified parameters } event.preventDefault(); });

The benefit is similar to the benefits brought in by stylesheets — you can now change the behaviour of all popup windows across your entire project. You could even have multiple class names for different window properties — sizes, toolbar hiding, whatever! It also makes the page size smaller, all for the price of one event handler with an if statement.

Internal Relationships

On larger projects I use a technique that maps controllers to JavaScript objects. I do this by using body ID tags and classes. A function runs when the DOM is ready and calls the appropriate object.

For example, let’s say you’re making a blog application in Rails (or similar) and you have an ArticlesController. I’d use a helper in my Rails layout to create an appropriate body tag:

<%= body :id => controller.name %>

Which is defined like this:

def body(options = {}) tag 'body', options, true end

Then my JavaScript delegation function would look at the body tag and call a method on an associated object:

ArticlesController = { run: function() { // Do stuff that the articles templates need } }; $(document).ready(function() { var controllerName = ''; if ($('body').id) { controllerName = $('body').id + 'Controller'; if (typeof controllerName !== 'undefined') { controllerName['run'](); } } });

This body ID delegation pattern has allowed me to build very large Rails projects without feeling lost when moving between JavaScript and Rails templates. I also use body class names for shared functionality. The JavaScript “controllers” are generally stubs that invoke other objects.

Any framework could use this technique — it’s really just an agreement between your server-side code and JavaScript.

Test First

When I start writing JavaScript for a project, I try to think in terms of the core functionality, independent of the browser. I’ll write console-based code and run unit tests in the console. Once I’m happy with my “models” I’ll start to hook up event handlers.

Get used to thinking about events through CSS classes — try to group like events and rely on high-level delegated event handlers. Not only does this result in fast UI code, it also makes testing easier.

Light Event Handlers

Good code us usually easy to test. I’ve found that writing light event handlers then calling higher-level objects helps keep testing simple and increases reusability.

Basics

It’s useful to be fully-versed in JavaScript’s object model and prototypal inheritance. Even though you can use certain libraries to ape classical OO, good code comes from a deep understanding of the tools at hand.

Maintainable and clear code comes from knowing when to exploit JavaScript’s flexible object system, rather than trying to write in a style that doesn’t suit it.

Byte-sized Takeaway

Keeping JavaScript out of templates can help:

Reduce page size
Improve performance
Allow broad brush-stroke changes across a site

To ensure projects are maintainable:

Create a clear link between templates and the location of associated scripts
Use the body ID/class technique
Think in terms of DOM objects — the DOM is a living, breathing system, not just a static page
Exploit JavaScript’s inherent advantages rather than trying to force it to be something it isn’t

Permalink | Leave a comment »

Following up on how to test a config.ru, an actual patch

Thu, 22 Apr 2010 00:37:19 -0700

http://github.com/timocratic/rack-test/commit/dd5324627890b4632c07deed1fc2528...

Permalink | Leave a comment »

Testing a rackup (config.ru) file with Rack::Test

Wed, 21 Apr 2010 10:20:00 -0700

The ever useful rack-test gem let's you easily integration test any rack project. All you have to do is include the Rack::Test::Methods and define an app method that returns your rack app. So people usually have a config.ru that just references their my_application.rb that they reference in their config.ru and then in their test file they can also reference that app and return it. Something to to this effect:

class MySweetRackApp
  def initialize
    Proc.new { |env| [200, {'Content-Type' => 'text/html'}, ['success']] }
  end
end

I had a project where I was actually trying to better breakdown a more complex app, and I wanted to just be able to use Rack's built-in map method at the top level of my config.ru to route to different apps. And in at least some of the cases I wanted to be able to test the whole thing. Also, I figured sometimes it's useful to actually be able to test your rackup file itself, all routing/mapping included. So I dug around in the rack code and found how the rackup command handles the .ru file, and came up with this:

use Rack::Bug
map '/my_sweet_rack_app'
  run MySweetRackApp.new
end
map '/'
  DenyAccessAndRecordRetinaApp.new
end

Update

If you are running off of a new enough version of rack, you could also just use Rack::Builder.parse_file

Permalink | Leave a comment »