Architects

posted by hampton on December 11th, 2007

I read this in an article in Toronto Life magazine about two architects who run a small architecture shop. As soon as I read it, I knew that it applied nearly perfectly to Unspace.

I didn’t think anyone in business refrained from courting continual growth and ever increasing profits, either, but Shim and Sutcliffe don’t want a big firm. They turn down clients; I asked Sutcliffe, half-jokingly, whether they’d accept a commission from Conrad Black. The answer was very abruptly negative. They told me of an overture from a local plutocrat, described meeting in his imposingly fake Victorian-style boardroom in some downtown skyscraper and how, well, it just wouldn’t work. “Different cultures,” was Sutcliffe’s tactful summary. They say they want clients who are not just consumers buying something from them, but who are as engaged in ideas as they are, who will be part of the thinking process. One of the first things he and Brigitte do when they’re approached, says Howard, is “discuss whether they’re decent clients or not… I mean, what we do is complicated and takes a lot of time, and if we’re going to spend two or three years we might as well like them. And then we see if the project is one we can do something interesting with.” The process after that is slow and organic, involving much discussion.

-“The Big House” by Gerald Hannon - p78, Toronto Life, Jan 2008

That’s very similar to our philosophy at Unspace. We really put our hearts in projects and finding the clients who will respect and work with us on our shared vision is key. Growth is our last goal. Our primary goal is to make amazing software and work with great people. We aren’t right for a lot of potential clients… and conversely they are just as wrong for us. When you get that chemistry though, there is no stopping the amazing business/software you can create together.

3 comments

Nathan joins Unspace

posted by hampton on December 6th, 2007

You heard it here first: Nathan Weizenbaum has officially joined the Unspace team. After a year of working with Nathan on Haml, I can easily say that he is the best programmer I’ve ever met. We got to hang out with him for the first time at RailsConf, and started immediately plotting how he could work with us.

For now, Nathan will continue to spend much of his time keeping up his schoolwork at the University of Washington, but will be doing a lot more work for Unspace as well. Previously, Nathan has consulted with Microsoft. By the way, Google refused to hire him; he’s 17. Luckily, we have no such moral qualms. Tiny fingers!

Nathan is known in the Ruby community as the primary maintainer of both Haml and make_resourceful. He is also the creator of the amazingly fun Scribble! for HackityHack. You can often find Nathan talking shop in the #ruby, #haml and #merb channels on IRC.

This has been a long time coming, and we’re really glad to finally have him on board.

5 comments

Merb-tastic

posted by hampton on December 3rd, 2007

Here at the Unspace offices we've been nerding around with Merb a lot recently. If you don't know what Merb is, its a super-light framework written by Ezra Zygmuntowicz from Engine Yard. If you want to be more specific, its really a re-write of Rails' ActionPack that integrates directly into Mongrel with small bits of glue around to make it a framework (folders, folders everywhere!).

Merb is highly influenced by Rails. That might be an understatement. Anyone who knows Rails will quickly find Merb to be very familiar, but with a few key differences. Mostly, Merb is built around the philosophy of keeping it as light as possible. Don't come looking for AJAX helpers, ORMs built-in, large core extensions, or lots of the other cushy niceties that Rails provides by default. Most of these things can be installed into Merb quickly using gems, but they aren't in the basic Merb install.

This makes for a different feeling experience. Merb requires a little more legwork from you as the developer, but it also steps out of your way more often than Rails does. Merb is like Rails for those who want to hack around with more freedom.

I probably wouldn't recommend someone new to Ruby to start with Merb. Start with Rails for many, many reasons. Most of all, Rails skills are far more bankable than claiming Merb skills (for the time being at least). Most people don't know what Merb is. Also, Rails teaches you lots of good things. Its when you start to feel the edges of Rails that you want to push out of them and customize your framework more that Merb starts to become a good option.

Also, Merb is fantastically fast. The original idea behind Merb was to do Mongrel and ERB (M+Erb) together and make them work as quickly as possible. The inspiration was Rails for the way the original version was built. However, as time has gone on, the code has expanded into being a real development powerhouse for experienced Ruby developers. Did I mention that its fast as shit...? I don't find Rails prohibitively slow, but when you start to see how quickly Merb uses Ruby to produce HTTP requests my nipples start to get hard. I've seen 500 requests a second for a basic request on my commodity box. Checkout the benchmarks against Rails.

ORMs

Merb is ORM-agnostic which means that you can choose whatever ORM you want. Its easy to write ActiveRecord models just as easily as Rails, or you can experiment with some of the up-and-coming Ruby ORMs like DataMapper and Sequel.

DataMapper

DataMapper is the closest to ActiveRecord, but it has a lot more magic when it comes to handling attributes associated with your models. Imagine if you didn't have to write migrations for your models because they were smart enough to know how to express themselves in the database.


Let's look at this example.

class Zoo < DataMapper::Base
  property :name, :string, :default => 'Unknown'
  property :notes, :text
  property :updated_at, :datetime

  has_many :exhibits

  validates_presence_of :name
end

In this example, DataMapper sees that you want a property called :name when it is loaded and so it checks to make sure that the column is there. If it isn't it builds it for you. Did I mention that DataMapper is thread-safe? That means that Merb can run in all of its multi-threaded glory. I'll be honest that I haven't gotten to use this one much, but I know the developers are working hard to expand its feature base and have it in extremely active development. Read more about it here.

Sequel

Sequel is a type of ORM that I've never really come across before. It is focused much more on building queries than DM or AR are. You basically construct these objects using Ruby syntax that represent an un-executed query object. Let's build one here that will get us all of the users who are admins and in the order that they were created.

DB = Sequel.open 'mysql://root:1234@localhost/test_database'
admin_list = DB[:users].filter(:is_admin => true).order(:last_name)

Now, this is just a symbolic object at this point. Nothing has been executed. We can execute the command using Enumerable-style interfacing

admin_list.collect do |user|
  "#{user[:last_name]}, #{user[:first_name]}"
end
#=> ["Bergin, Candace", "Ferrier, Emerson"]

Every time we execute collect on that object, we get a fresh new query with new data. So, Sequel isn't a replacement for DM or AR, but it does give us a really awesome and speedy way to interact with our database. I am looking to use this in some places where I need some super-fast and simple queries to be run in a lightweight section of one of my applications.

Views

Well, I would be remiss not to mention that Merb is one of the new crop of frameworks that supports Haml out-of-the-box. Not only that, but it defaults to Erubis and has built-in support for Markaby. If you have the gem installed for any of these, Merb magically begins to work with them. My only note about integrating Haml with it is that right now you have to add a line to your config/dependencies.rb file to get Sass stylesheets to render properly in your Merb application.

dependency 'haml'

That should do it. You now have the full Haml/Sass suite running in your Merb application. Easy as your momma.


Et Cetera

Some of the other differences between Rails that I really like are....

Installation

Its as simple as....

$ sudo gem install merb -y

but of course you'll also want to...

$ sudo gem install merb_datamapper datamapper haml erubis -y

Yup, that's it. Now generate a project this way

$ merb -g project_name

Are you sure you're getting this? I know its complicated. If you're scared just go back to PHP and hug your doll. Now, go dive into that and see what you can figure out with your Rails-fu. You'll be surprised at how familiar it feels.

Final Thoughts

Merb isn't some perfect "Rails killer". However, its a really interesting framework that will hopefully make Rails answer to some of its long-standing claims (performance isn't that important) and keep the Rails core team on their toes. Flat out, competition is good. Extra frameworks in Ruby doesn't mean that we dilute some special chemical in the community, but it means that we can start to focus on solving the problems for our applications and not making our applications fit our solution.

This is especially true if you are starting an application that you know needs to be high-performance. Merb is the place to go for that then. That's the case at Unspace right now. We are working on a project that requires unbelievably high uptime and request performance in order to be tenable. Rails just simply isn't the solution for that. Its why 37s wrote a C library to build Campfire with... because Rails is just not built for that kind of thing. Does that make Rails bad? No way! Rails is fantastic and will continue to be fantastic into the future. However, now there is a new kid on the block that is worth consideration for new projects where Rails isn't a perfect-fit.

Stay tuned for more from Unspace with Merb though. We've even already started patching Merb and we'll soon be announcing our new internal project that uses Merb to handle possibly millions of requests quickly. First we have to get the patent filed.

9 comments