Shanti’s Dispatches

See this post and this one (inc. comments) for some backstory.

Disclaimer: Vested Interests

I worked on SproutIt’s hosted Mailroom app since their early days.

I would say the target market between Mailroom and Litepost are fairly different.

Mailroom offers:

• a completely outsourced (hosted) solution
• spam protection right out of the box
• 24/7 monitoring for downtime/issues/etc
• great support (shoutout to Peter & the gang!)
• killer 100% AJAX UI (fine work of Charles Jolley)
• a team-based approach to handling large volumes of support@ and sales@ type of repetitive mails
• … lots of advanced features even GMail doesn’t have — i.e. autosaving & later autosuggestion of replies, etc

Litepost offers:

• ability to host the app yourself
• ability to modify the source code ass you see fit
• a typical “gmail for domains” type of approach to webmail where each user gets his/her own account (In Mailroom all mail is routed to a central account, with multiple users picking off their own messages to reply to)
• have 100% control of your mail data and how its stored/archived/etc
• an interesting take on email with the ability to rate conversations for later re-ordering

I’m sure Nathan has more but I’ll stop there. One thing I did notice is at this exact moment, Litepost does not seem to have a way to combat SPAM (unless it is first run through a filter). Please correct me if I’m wrong.

Of course I’m sure SPAM protection is on it’s way for Litepost. Heads up to Nate dog: combating SPAM (well) is a hugely annoying problem to solve and could easily be handled by a whole team of engineers working on it day & night, especially when when these spamf*ckers keep coming up with new & innovative attacks each week.

Nathan’s Reply

In the interest of fairness, here’s Nathan’s reply from Litepost:

Hey Shanti,

Thanks for buzzing me re this. Since the product isn’t remotely finished yet– we haven’t clarified the precise licensing provisions for the software.

Suffice to say, we want to abide by all relevant FOSS rhymes and riddles, and while there may be a tacit request to limit direct competition, I agree with you that this may certainly violate the spirit of open source:

So…I was actually planning on releasing the software under the NSL, Nate’s Software License, but I didn’t know if that would be too abominable or egotistical (to create yet another new license)…

This isn’t finished yet…it’s a work in progress so please tell me what you think of it (!).

NSL - Nate’s Software License v0.1 (aka GPLv4 LOL edition)

PREAMBLE

Software is too easy, free and fun to a) charge exorbitant sums for and b) require complex legal documentation (or indeed ideally documentation of any kind!!).

(Software is like sex and I don’t like getting my sex partners to sign contracts.)

So:

TERMS AND CONDITIONS

1. Litepost is totally free software. PLEASE FEEL FREE to do whatever the hell you want with it!
2. Always use condiments.

END OF TERMS AND CONDITIONS

3. Interpretation of Section 1:

*ie, as long as it’s legal, lawful, loving (abiding by all other relevant licenses) and in all other regards respectful and reasonable.

Ideally, you will improve the software and contribute to the community.

Naturally, there are no warranties for software released under the NSL. Please modify the NSL as you see fit and as it suits the situation. Please send any good ones you come up with to me at nathan@litepost.com.

Thanks again for requesting the clarification; I am most happy to give it!

Please let me know if you have any questions, comments, clarifications, advice.

Best
Nate

Good luck, Nate. Competition is always a good thing. If anything, you’re primarily competing against GMail and that is one crazy sonofabitch thing to do!

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!

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

Charles Jolley put together a video preview of the upcoming Mailroom 2 from Sprout:

Mailroom 2 Video Preview (direct link to YouTube video)

We’re really stoked about this upcoming release! We’ve also got another product in the works that we’ll be launching sometime within the next few months. (First, we’ve gotta get MR2.0 out the door!) Stay tuned…

Well, we finally completed the new Ferret Search Engine indexing system for Mailroom.

We’re now using Ferret to index anywhere between 150,000 and 200,000 Mailroom messages, growing by thousands more daily.

There were a few hiccups along the way. Very few, caused by Ferret itself. Some, by yours truly. Since I’ve only been coding in Ruby/Rails for a few months, luckily I still have that as an excuse. A few more months of doing this full-time and I’ll have nothing to fall back on when I get stuck on a silly problem!

Benefits of Pair/Team Programming

But more and more, I’m realizing how handy pair/team programming can be. Often-times, showstoppers tend to be solved by a simple solution — having another set of eyes looking at the problem.

I.e. the other day there was a majorly annoying JavaScript bug in some new (not deployed yet) Mailroom development code, which brought our new dev efforts to a halt briefly. (if it doesn’t work in IE6, you better bet we won’t be releasing it anytime soon!)

Charles & Co. use Safari as their default browser, which fortunately has an optional plugin called Safari Enhancer.

So while IE6 was reporting that the problem was simply a “undefined Ojbect” or something similarly useless, Safari Enhancer with its JavaScript console pointed me to the exact line of the problem.

Turns out, it was an extraneous comma in a function list, which Firefox was not complaining about, but ended up borking IE6 and Safari in nearly the same way.

If you’ve ever wondered whether the author of this blog is an Indian, black female, or well, what kind of name is Shanti anyway?!?!… well, it’s now revealed. (hopefully the picture of me and my girlfriend next to each post gives it away, but perhaps not)

You can read more at: sablog.com/about/

But seriously, the sidebar was getting pretty cluttered and had incorrectly proclaimed that I was still working at a company here in Phoenix for the past few months.

When in fact I’ve been telecommuting with the awesome crew at SproutIt.com, who’ve been in Prague (Czech Republic), but are moving back to California (The Schwarzenegger Republic) soon.

People also ask me from time to time about the status of other projects like Niner Niner, etc.

My secret: It’s still alive, just all highly automated and run by a kickass crew of writers!!! (it’s all automated except for when things break, like last week when our server crashed and it was down for 2 days. oops!)

I just rocked out some sweet ass JavaScript/Prototype/RJS code for Mailroom. I won’t spoil the surprise by announcing what it does, because we can probably make a nice todo out of it on the Big Act.

It took some time for me to make friends with JavaScript. It always seemed like a hackish, backwards kind of language.

But between Prototype, Rails’ RJS Templates and a little good-ol fashioned JavaScript, you can accomplish miracles. (But, I probably shouldn’t speak too soon… We need to put some polish on the hacks I just wrote.)

My buddy Gabriel links to JTF — JavaScript unit Testing Farm.

How does it work? From the site:

You write your javascript and insert some code to indicate a failure (or a pass) using the same functions as in JsUnit and other unit testing frameworks. Then, every time a visitor views your test case, it performs the unit test on their browser… providing information if the test fails.

Sounds like a novel idea.

Over at Sprout we now have a suite of Selenium JavaScript-based acceptance tests.

It was a little tricky, but our Selenium tests for Mailroom now pass in the following browsers:
- IE6 on XP
- Firefox on XP
- Firefox on OS X
- Safari on OS X

The first thing Charles asked me was… if we already have Unit & Functional tests already, why do we need Selenium ones too?

Granted, Selenium tests are not necessary for a small startup. But at previous employers, full-time Testers have been employed whose sole job was to:
- sit around for 4-5 days a week (waiting for a new release)
- if the developers happened to have a new release ready by Friday, the Testers would jump into action and earn their $37k a year in one afternoon per week.

Many lessons can be learned from this anecdote, but one is: hire someone who can automate away his or her own job in a few weeks and move onto things that cannot be automated.

Writing Selenium Tests in Rails

Often I feel the urge to simply create a new Selenium test for a new feature that we implement. There’s nothing like a full UI-based end-to-end test to see if something is functioning properly. (this could just be a psychological phenomena)

But, we also add Unit & Functional tests, and then sometimes maybe Selenium tests. That’s some pretty good code coverage.

Selenium on Rails Links

Selenium on Rails Plugin (Recommended)

Automate Acceptance Tests with Selenium

There is an alternative Selenium on Rails plugin floating around that comes up a lot higher in Google searches.

It’s sad because the devs on this other plugin did a tremendous job at marketing (and developing) their plugin, but I am not as impressed with it as the one mentioned above. Here’s a link, which includes a nice screencast:
Selenium on Rails Plugin

Screencasts are the *ultimate* linkbait! I needs to make me some of dem!

I guess this post was making the rounds this week while I was busy coding up a storm. Ironically, I was implementing a billing system so that we can charge cards at Sprout.

Hello. It’s never a good time to start a company without the intent of making money.

You don’t have to make a lot to begin with… Overture started by making pennies (literally) and went on to be acquired by Yahoo for $1.63 billion.

Evaluating Business Ideas

Whenever someone tells me about a new business idea, the first thing I ask about is the business model.

Here are some simple business models

- Buy widgets at $2, sell them for $4. (Wal-Mart)
- Offer a free, limited service to attract clients. Also offer a premium service and charge for it. (Sprout, 37 Signals)
- Blog about interesting things, sell advertising. (Weblogs Inc.)

It doesn’t take a rocket scientist to do some back of the envelope calculations to figure out how much dough you can potentially make with your business model.

If the model gets much more complicated than any of the above… I’m usually a little skeptical about its potential viability.

When to realize you’re in a Web 2.0 circle … you know what

99% of the population has never even heard of Web 2.0. Even in the tech industry in non SF Bay Area cities. (you’d be surprised)

These people:
- don’t have a gmail account, nor do they even know it exists (they are still using some crappy hotmail 2mb limit acct they opened 4 years ago)
- don’t read blogs
- especially don’t read TechCrunch (let alone know what it is)
- have never heard of Ruby on Rails
- Ajax? are you kidding? they think it’s a cleaning detergent

I’m not a part of the whole SF Bay Area thing (yet), but we do need to keep some perspective here… Pets.com isn’t going public again like it’s 1998. A few lucky (+ highly-skilled & passionate) guys in their garage got bought out for $15-30 mil. The rest of us have to actually bring in the Benjamins, with uhh, you know, paying customers n stuff.

Me-too companies… What’s the bfd?

Commenters on the Caterina post belittle all the ‘me-too’ companies coming out of the gates. I don’t really know what ‘me-too’ means exactly… Yes, there are some ‘me-too’ companies, but that’s really just a sign of competition and innovation.

The weaker ones will be weeded out, though, when hosting only costs $10 a month, what’s the bfd? Throw some AdSense on there and you’re all set.

Of course, if you’ve taken $5M in VC and your business model is “throw some AdSense on there,” well, you better have a lot of targetted content + traffic. They only make so many Yahoo/Google acquisition lottery tickets.

Eric Hodel dropped some more configuration goodies in this post about how their setup is configured to push out 2M + daily page views on 43 Things and their ever-growing network of sites.

CachedModel seems like it’ll make implementing MemCached dead-simple. Right now, though, our DB Usage in Mailroom* isn’t the bottleneck in app performance.

Armada looks interesting, too.

Andrew is doing an incredible job on tricking out our backend systems at Sprout. I’ve had to wear many hats at startups before, including system administartion ++, and, I’m very thankful we have Andrew on board here.

[1] Mailroom is SproutIt.com’s first in a suite of webapps for small businesses.