Web-based WYSIWYG for Developing Webapps?
Wednesday, February 21st, 2007New article up over at On Web Apps.
New article up over at On Web Apps.
The elephant in the corner in the Ruby community has long been the speed of the Ruby VM.
People have finally started talking about this issue. Ruby, in its present state, is “fast enough.” It will get the job done, you might need a few extra dispatch.fcgi’s or mongrel instances in your mongrel cluster, but you will have a scalable N-tier system.
This excellent Ruby VM shoot-out does a great job comparing the current state of various Ruby VMs.
YARV is rumored to be the next Ruby VM, taking over for the previous VM in Ruby 2.0.
From the shoot-out, it’s clear why. YARV performs 3.47 faster (on average) than the current Ruby VM.
Implications of a 3x Faster Ruby VM
Deployment issues aside, it does take some planning on how/when you’ll deploy RoR applications. I’ve got a PHP box that serves up 30+ PHP apps (low traffic). You can do this without much thought.
While I imagine guys at Engine Yard and specialized RoR deployment shops have figured out some clever ways to deploy tons of Rails apps on a single server, for the average developer, you’re not putting more than 1-3 Rails apps on a box.
If the Ruby VM required 3x less fastcgi’s / mongrels, it would make deploying Rails apps a no-brainer. You wouldn’t have to worry that 3 mongrels are using 100MB+ of RAM (when RAM always seems to be the most scarce resource), chewing up CPU, etc.
This Rolling Stone piece talks about how medical marijuana legalization (at the state level only) in California could reap some big rewards for companies that get into the game early.

This is the only hope (greed, or capitalism, at the corporate level, that is) for eliminating the Prohibition of the 21st century. God knows marijuana users themselves will never actually show up at the polls to vote for any amendments.
Decriminalizing marijuana would have the following benefits:
I used to work with someone from the Netherlands who grew up in Amsterdam. He said he never once smoked pot or took other illegal drugs which were readily available. Meanwhile, over here in the states, for many kids, marijuana is more accessible than alcohol and quite socially acceptable to smoke with one’s peers.
It was also sad in college to see rich white kids get away with tons of illicit activity in the comfort of college campuses and posh apartment buildings.
If the cops busted up a party of young black males in a not-so-affluent neighborhoods, there’s no way they’d get off the hook without incident like the people at school would.
Sadly, this was a joke heard often while driving around near our school.
When a car with a bad paint job, full of several black males, was seen pulled over by police by the side of the road, someone would say:

Oh, busted. DWB.
Someone who didn’t know the joke:
What’s DWB?
The teller:
You didn’t know? Driving While Black. It’s an offense strictly enforced here in Clayton.

This is something I wish more people understood, at least when you’re talking to them about your startup or startup idea. “Dunkin’ Donuts’ CEO Jon Luther says his company is helped by its rivalry with Starbucks: “[It’s] created an awareness for the category, and we’re benefiting.”
The chain’s success illustrates a little-advertised truth of business. Too often the financial pages read like the sports section, filled with winners and losers. Reality is more complex. In many markets, business is not a zero-sum game, and competitors create opportunities.
Full Article. Via: 37 Signals
Too often you tell someone what you’re doing, and even if they don’t say it out load (sometimes they do), they’re thinking it. “Oh, you’ll get crushed by X.”
There are way too many examples to list here of underdogs or new spins on ideas that took off and crushed (or simply carved out a niche) formerly owned by a dominant 400lb Gorilla in a space.
Reading Founders at Work only reinforces that point.
Just a few examples (though the landscape has changed since then) from the book:
Early spreadsheet market: First pioneered by VisiCalc, which got crushed by Lotus 1-2-3, which eventually got crushed by Excel.
Early OS/PC market: IBM’s game to lose, of course. They got owned by Apple, who eventually got owned by Microsoft.
Just goes back to my mantra on small business and startups:
Back when a new Rails update would drop, pulling down the latest version from Rails from its svn repo would take just a few clicks.

I’ve been sitting on an svn update of the latest stable Rails release for a good 10+ minutes now.
I know some fine tech folks are on top of this so it couldn’t just be poor server management. Rails has gotten popular, and popular fast!
Sadly, I fear the competitive advantage for startups using RoR is dwindling… now that it’s becoming more mainstream and popular to develop greenfield apps in RoR.
When I talk to random non-techies, more and more they know about Rails and want to do something with it, or at least get my take on whether or not “it can scale.” (Heh. Everyone thinks they are going to build the next Facebook.)

One of the killer features of Ruby on Rails is its caching abilities, specifically fragment caching.
Rails fragment caching allows you to cache any piece of html or RoR-generated JavaScript.
Things like generating Tag Clouds are ideal for fragment caching — they generate a lot of SQL queries and you don’t need them to change that often.
RoR also offers page and action caching, but I haven’t found these to be as useful.
If you’re working with RoR on apps where you need to display different page elements depending on whether or not a user is logged in, then page/action caching does not help you so much. (though there some plugins to help you get around this problem)
At Sprout, we just deployed Mailroom 2.0. We’ve made a ton of improvements, but as part of that each Show Conversation request (made via Ajax, and cached on the client-side) was producing a ton of queries on the backend.
We’re doing a lot of stuff in that action — collecting messages and notes for the Conversation, checking hotlists, etc.
And it’s also the most-used system call in the application. The whole point of Mailroom is that you want to spend less time as a team managing your email, while still keeping that small company, good support vibe with your customers and clients.
That means the Show Conversation method needs to be fast. Blazing fast, hopefully. (which, under some scenarios, especially for power users, it hasn’t been 100% of the time — not that it can ever be 100%, but 95%+ would be nice =)
Fragment Cache Results
By implementing rails’ fragment caching for that action, I’ve got that action down to 3 SQL queries (and change):
Org Load
Member Load
Conversation Load
(there will be a few more under certain circumstances, i.e. of there is a note applied to the conversation)
When watching the rails log, this is then what I see next:
Fragment read: .00078
YEAH buddy!
.00078 seconds = 1,282 requests per second without breaking a sweat!
Of course, the real bottleneck, once this is implemented, gets moved up the chain, to the Org/Member/Conv loads. The only way to reduce those is to use something like memcached or to tweak Postgresql.
If you’re a Mailroom user, stay tuned in the next few days as hopefully some of these performance improvements will hit the streets!
My mac mini has really been faltering lately… It used to take just 7-10 seconds to load a Ruby console.
Now it’s taking 15-20! That’s a lot of spare developer cycles. I *really* wish macs were as cheap as PCs.
Dear Steve Jobs - I know you’re reading this so please just license OS X so we can run your stuff on inexpensive hardware!!
You are currently browsing the Shanti’s Dispatches weblog archives for February, 2007.
Shanti A. Braford blogs here.
If you really want to know, just read this.



