Shanti’s Dispatches

Programmers seem to be obsessed with programming language speed.

I’ve ranted before abaout Joel and his Wasabi project, for bashing Ruby.

Last night / this morning we were pushing out a major release of Mailroom.

Some of the maintenance scripts we had to run to catch up the database are/were taking an incredibly long time.

We were pushing two boxes to loads of 4.0 - 6.0. When we started MR’s receiver, we were seeing loads of 8-10. For the non-techies, that means that something like “800%” of the CPU was being used, or something like that. Basically, you don’t ever really want it that high.

But anyway.. the point is that a majority of the processing juice seemed to be going to the DB. I would guesstimate 80-90% of the cpu juice on that server was being used for the DB, not Ruby. That was really the limiting factor, it seemed, not Ruby code.

So why do coders get their panties all in a bunch about programming language speed, but not so much when it comes to database speed?

I guess because we really only have a few options in the Database game, so the DB wars are restricted to “MySQL vs PostgreSQL” or maybe throw Oracle in their if you can afford the $30k licenses.

Whereas programming language wars let you explain why you think VBScript, Wasabi, Lisp, Java, Smalltalk, Ruby, Python, Perl, PHP, etc. is better than X language.

That’s everyone’s favorite Slashdot (now Digg) thread right there.

Now, I know this totally depends on the application… but it’s true for ours. And I’ve seen it be true for many that I’ve worked on in the past:

If 90% of your application’s process is spent in the DB, how much does a 50% increase in speed in your programming language (or VM) get you, in terms of overall application performance? …

… 5%! Nothing to get too excited about, eh?

Update: The release is delayed a bit. Hopefully it’ll launch in the next few days or so, but we’ve got some cross-browser compatibility issues to work on. Heck, even GMail launched without Safari support. We’re aiming for Firefox 1.5 & 2.0, IE6, and Safari compatibility, as much as humanly possible, at least.

I’ve already blogged a bit about Mailroom 2.0.

Looks like it’s finally happening… This Sundayy (say it in your loudest Monster Truck Commercial announcer Guy Voice), the latest release of Mailroom will be dropping (99% sure, we do have some last minute stuff to knock out).

We’ve aptly code-named it Growing Pains. It has, after all, been a long time coming. But I hope the wait has been worth it to our now thousands of Mailroom users.

The biggest changes are in the UI (that’s all Charles — newly minted JavaScript Blackbelt Samurai & probably the smartest coder I have ever worked with, among other things (he’s CEO). Truth. But a lot of work has also gone into the backend to support those changes & fix a few bugs (that was my role).

Already got a lot of great feedback on the YouTube video we put up previewing Mailroom 2.0. If you haven’t seen it yet, you can check it out here.

Lessons Learned: It Takes Both

Ninjas: You Probably
Need 2 of ‘em.

In this case, the lesson I learned from the experiences of this release is that it takes both a UI Wizard and a Backend Pro to deliver a solid product.

At least, when we’re talking about this level of complexity. One way I like to measure the complexity of RoR apps is by looking at how many migrations they have gone through. (for the non-geeks reading this, that is how many changes have been made to the underlying data model, i.e. adding a Person object’s “first_name” and “last_name” fields would be 2 data model changes) Sometimes you throw several changes into one migration but usually each migration encapsulates some unit of change.

No. of migrations now in the Sproutit Suite application: 127 !!!

And of course… this says absolutely nothing about the level of complexity on the client side!

Lesson Learned:

CRM: It’s a Jungle Out There

The reason this release took so long was because during this time we were also working on a new CRMish (Customer Relationship Management) app that will be an adjunct to Mailroom. So far the plans are to make this puppy free (for the average user).

It’s good enough though (imho) that we could easily sell this app to the average small business and make a pretty penny. We’d rather use it as friendly intro to our other services, which it will help provide the glue for, and perhaps sell bigger packages to those companies who need thousands and tens/hundreds of thousands of contacts in their database.

Stay tuned in the next few months for more on a tool (we still don’t have a name for it yet) to help your small biz keep that friendly small-company vibe with your clients & customers, while scaling to thouands and tens of thousands of clients and customers.

That should be the real goal with CRM, after all, we believe. To keep your clients close, not turn them into another statistic for your bottom line.

Cross-blogged at my new weblog On Web Apps:Lessons Learned from the Development of a Web 2.0 Application, Version 2

Found this via del.icio.us/popular:

Not to take it too seriously, but my personal take on being a Ruby programmer, well, more of a Ruby + Rails programmer, is not so much about it being a superior language or considering myself superior to developers of any other languages, but rather that I’ve just found a “secret” (not so much lately) way of getting things done faster.

If suddenly a new framework for Erlang, VBScript, or heck, Blub, appeared that would make development incredibly efficient on that platform, many Rubyists would definitely take a look (that’s how 99% of us came to Ruby in the first place).

Mythical (but possible) blog post:

Hey — have you checked out the new VBScript on Rollerblades framework? I know it’s hard to believe, but I get about 10x as much done!

When All Else is Commoditized, Optimize for Time

I remember when a professor back in school first introduced the appeal of commoditization of complimentary services to your own. IBM and Linux is the quintessential example. Why would IBM want to commoditize the OS market (by investing heavily in Linux), when they already make a few of their own?

Now it seems normal, with Sun GPLing Java, but a few years ago many analysts were scratching their heads as to why IBM would want to invest $1 billion in Linux and open source.

Because now IBM can sell consulting services @ $250 per hour, while the cost of their OS and server software (used to deploy production systems), remains virtually nil. A $1 bln investment is pretty cheap for a rock-solid OS, especially when you’ve got $20 billion a quarter in revenues.

If you have any doubts about this, talk to a small business owner who’s buying SQL Server and Windows 2003 Server licenses because they decided to build out their platform on MS. (I had the pleasure of doing this recently - business owners are not happy about paying more for a licensing fee than the actual hardware!)

With servers and bandwidth being incredibly inexpensive these days, while OSes, database software and web framworks remain free (that is, if you use the right one *wink*), the only thing left to optimize for is developer time.*

* I do have a vested interest here. But I challenge you to try out an inexpensive Indian outsourcing firm (commoditized developer time) and report back your results. I haven’t heard too many success stories yet.

Amazon is now using RoR in production code (for an admittedly non-core area of their business):

UnSpun - Community Opionions … Ranked!

Still, I wonder what kind of traffic a link on the Amazon.com homepage drives! (I’m guessing quite a bit)

Via: Signal vs. Noise

Sidenote

Amazon seems like they are really cool with their developers when it comes to letting them choose their technologies. Very Starfishy (just picked this up the other day).

From some of Stevey’s stories, it sounds like they even have some LISP code powering some backend processes there!

Let’s say you have a method that looks like this:

 def foo
   if !params[:id] || params[:id].blank?
     render(:text => ‘400 An ID is required for this method. ‘, :status => 400) and return
   end
   … # real action goes here
 end

But you start seeing that same pattern in many different actions, for the same parameters. (:id, usually)

You can instead add this to the top of your controller:

class FooController < ApplicationController
  verify :params => ‘id’, : only => [ :foo, :bar  ],
         :render => {:text => ‘400 An ID is required.’, :status => 400}

  def foo
    … # just do the action, secure in the fact that a
        # params[:id] will be there if it gets to this point.
  end

  def bar
    … # ditto
  end
end

Note: i had to change it to “: only” otherwise a would appear there. =) The method also takes :except and a whole host of other options.

The verify method is also used (much more commonly) to require POST, etc. For example:

  verify :method => :post, : only => [ :foo, :bar ],
         :render => {:text => ‘405 HTTP POST required.’, :status => 405, :add_headers => {’Allow’ => ‘POST’}}

Hope that saves you a few extra lines of crufty ‘once-of-prevention’ code =)

Update: Yes! These instructions did the trick.

Gruff is some hot stuff. If you’re working on a Rails app and want to pimp out your backend, or have data that would be much more useful if visually illustrated, it’s the goto tool in the RoR world.

Example Gruff graph

The only problem I’ve had is getting the whole stack of dependencies installed & working on my PPC mac on OS X 10.4.8.

It seems like plenty of people have been able to get it working, so I’m not sure exactly what’s up.

I spent a few hours one night compiling/recompiling the stack to no avail. (Though, Rubyforge being down that evening didn’t help, either. :))

Just tried this option which says to install RMagick via Darwin ports:

sudo port install rb-rmagick

That didn’t work.

Now trying these instructions… (which, incidentally, weren’t available that night b/c of Rubyforge being down. Maybe it’s the golden ticket!

For future Googlers… this was the error I was receiving when trying to build a Gruff graph. I must just not have Postscript/ghostcript or Freetype installed from the looks of it…

sh: line 1: gs: command not found
sh: line 1: gs: command not found
RMagick: no decode delegate for this image format `/var/tmp/magick-HGhhQTrg’.
RMagick: Postscript delegate failed `/var/tmp/magick-HGhhQTrg’.
RuntimeError: Can’t measure text. Are the fonts installed? Is the FreeType library installed?
from /usr/local/lib/ruby/gems/1.8/gems/gruff-0.2.3/lib/gruff/base.rb:875:in `get_type_metrics’
from /usr/local/lib/ruby/gems/1.8/gems/gruff-0.2.3/lib/gruff/base.rb:875:in `calculate_caps_height’
from /usr/local/lib/ruby/gems/1.8/gems/gruff-0.2.3/lib/gruff/base.rb:434:in `setup_graph_measurements’
from /usr/local/lib/ruby/gems/1.8/gems/gruff-0.2.3/lib/gruff/base.rb:397:in `setup_drawing’
from /usr/local/lib/ruby/gems/1.8/gems/gruff-0.2.3/lib/gruff/base.rb:376:in `draw’
from /usr/local/lib/ruby/gems/1.8/gems/gruff-0.2.3/lib/gruff/bar.rb:8:in `draw’
from /usr/local/lib/ruby/gems/1.8/gems/gruff-0.2.3/lib/gruff/base.rb:357:in `write’

If you have models in subdirectories in your Rails app (i.e. app/models/billing/, app/models/observers/, etc), you need to add this line to your environment.rb if you upgrade to Edge Rails:

  config.autoload_paths += Dir[RAILS_ROOT + '/app/models/*/']

Via: I.NFECTIO.US

Carlos Gabaldon has a slick way of handling plan/feature matrices in this article on Plans, Features and Ruby DSL.

The approach is to encapsulate various features like “can have 15 open projects”, etc. into a ‘features’ table which can house the feature name, etc.

This allows you to do things like:

if some_model.has_feature?(:can_send_foo)
  # send the foo
end

Nice!

Yes, Ruby does have poor UTF-8 support out of the box.

You might even call Internationalization implementations in Ruby / RoR “hacks”, though they do seem to work quite well by the time the bits get down to the end-user.

I don’t have firsthand experience in doing an RoR internationalization, but it appears that many of the underlying implementation details can be hidden off out of view in your vendor/plugins directory by using the Globalize plugin for Rails.

Ahhh, the beauty of Ruby! It’s shortcomings in one area are made up for by its elegance in other areas.

Shopify Goes International

RoR-powered Shopify now has checkout in multiple languages, even Scottish!

Robby Russell of Planet Argon responds in the comments as well:

i18n in Ruby on Rails isn’t really that difficult to do. At PLANET ARGON, we have done a few projects that supported multiple languages. The last one that we did supported the following languages:

ENGLISH, ČESKY, DEUTCH, ESPAÑOL (ESPAÑA), ESPAÑOL LATINO, FRANÇAIS, ITALIANO, MAGYAR, POLSKI, PORTUGUÊS (BRASIL), PORTUGUÊS (PORTUGAL), � УССКИЙ, TÜRKÇE, � าษาไทย, 简体中文
, 繁體中文, 日本語, and 한국어.

We used the Globalize plugin for this.

There you have it.

Via: Riding Rails

Well, much has already been said about the recent Rails vulnerability and security patches.

My $.02 — it’s not about making mistakes — because who doesn’t? It’s about how you respond once you’ve realized a mistake has been made.

I don’t know enough of the full story to comment on the early “security by obscurity” policy as some are calling it.

As far as I understand how these things work, there’s usually a certain assessment period where people are encouraged to upgrade to a later version before the beans are spilled wide and far about what the security problem is exactly. That seems like what happened here, for the most part.

Microsoft vs. Rails - A Bad Comparison by Any Metric

If you want to see how long it takes a big corporation like Microsoft to respond to critical security bugs in their software, there’s a nice chart at this website and a pretty graph here.

Microsoft Patch Summary

In 2005, for example, there were 37 critical patches.

Avg. days from report to patch: 134
Avg. days from disclosure to patch: 46

134 days! Now, they are better with the more serious security vulnerabilities discovered. Those, it usually only takes them a few weeks. Again, apples and oranges (desktop software vs. web frameworks), but it gives you a sense of how open source communities deal with these things compared to Big Cos.