dave wasmer

After watching Sean Cribb’s fascinating talk on the resources and WebMachine at RubyConf 2011, it got me thinking about the complexity of the state machine transitions involved in his diagram of an HTTP request. I decided to hack this together this morning just for fun. Disclaimer - I realize this isn’t the most effective way of doing, well, pretty much anything. Just a fun hack.

If2D (github) is a quick DSL for producing two dimensional if statements in an excessively readable format. You supply the columns, rows, and resulting values. Column and row headings are defined via lambda’s, which will be given the object to evaluate, and must return a truthy or falsy value.

Headers are evaluated left to right (for columns) and top to bottom (for rows). If multiple header lambdas return true, all the matching result values will be returned in an array.

A quick example of a weekend schedule with If2D:

schedule = If2D.new do
  col                      l{|d| d.friday?},  l{|d| d.saturday?},  l{|d| d.sunday?}
  row l{|d| d.morning?},   :snooze,           :sleep_late,         :church
  row l{|d| d.noon?},      :pizza,            :hot_dog,            :brunch
  row l{|d| d.night?},     :party,            :trivia,             :laundry
end

The l in front of those lambdas is just a proxy for the lambda keyword itself, for brevity’s sake.

Now, if we give schedule a Time object (monkey-patched to respond to the time of day checks), we get:

[1] pry(main)> t = Time.new  # 12:24pm Sunday
=> 2012-01-01 12:24:57 -0500
[2] pry(main)> schedule.evaluate(t)
=> :brunch

If you’ve got a lot of columns and don’t feel like breaking out that horizontal scrollbar in your code editor, just repeat the col and row calls again - If2D will simply append further calls on to the existing structure as if it was all on a single line:

schedule = If2D.new do

  col                      l{|d| d.monday?},   l{|d| d.tuesday?},   l{|d| d.wednesday?},  l{|d| d.thursday?}
  row l{|d| d.morning?},   :run,               :snooze,             :late,                :run_again
  row l{|d| d.noon?},      :subway,            :leftovers,          :chipotle,            :meeting
  row l{|d| d.night?},     :tv,                :volleyball,         :sailing,             :hacking


  col                      l{|d| d.friday?},  l{|d| d.saturday?},  l{|d| d.sunday?}
  row l{|d| d.morning?},   :late_again,       :sleep_late,         :church
  row l{|d| d.noon?},      :pizza,            :hot_dog,            :brunch
  row l{|d| d.night?},     :party,            :trivia,             :laundry

end
schedule.evaluate(Time.now) # midday Sunday
# => :brunch

If I’ve got more free time (ha), I may refactor to IfND: n-dimensional if statements!

Hey! If you like what you see, how about following me here or Twitter!

As the list of *-as-a-service’s continues to grow, I thought I’d throw one into the mix. What about the idea of a backend-as-a-service (BaaS)?

The recent surge of client side Javascript frameworks along with the attractiveness of simple RESTful APIs has created an environment where server-side interaction can be reduced to simply database interaction (including validation and some computation). But why stop there?

What if the server-side of the equation was simply a RESTful, schema-less API? It could utilize MongoDB or some other document-oriented storage to avoid a strict schema definition, and even infer data relationships from the inbound URLs.

For rapid prototyping, I think this would be amazing. Move your entire app development into the browser - just point Backbone.js or similar framework to the proper root URLs for their storage, and suddenly everything is down to client side HTML/CSS/JS.

Obviously, this won’t work for everything. High performance applications may need to tune their backend for speed. Security would be a major concern as well, but could be managed similarly to Amazon’s S3 permissions, combined with authentication tokens sent on each request.

The only other hiccup I see would session management. Traditionally, session management (and related issues like user authentication) are handled through the server side.

But ultimately, a cookie-based session is simply a way of tying a particular user to a particular storage record for session data. If that cookie were replaced with a Javascript token, not much would change on a conceptual level.

Ultimately, I think this would help developers produce faster while eliminating the need to hop back and forth across the increasingly obsolete divider between server and client side.

Edit:

I should mention - I realize Parse (and others) already have released a BaaS. But those focus largely on mobile deployments, and as far as I can tell, their primary value is in auto-generating model code and SDK’s to handle the REST calls. They don’t seem to offer anything for browser-based apps.