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!

New article up over at On Web Apps.

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!

This article talks about what makes software projects so hard.

There are a number of reasons.

But the people / books / etc. that all claim to have a monopoly on knowing why software is late, or why their consulting practice / paradigm will solve the problem, are often-times selling a pipe dream.

Next time you hear a horror story about how late a software project is — all you have to know is this:

That’s the “Big Secret” about software dev. Not too complicated.

If Thomas Edison was a software developer, working on his “filament project” for someone:

Dear Edison,

We’re sorry - but your filament project is 200% over budget.

We’re cancelling your project — and truth be told — I never saw the need for any technology more sufficiently advanced than that great classic invention — The Candle, anyway.

Sincerely,
Your PM

Excerpted from “Great Software Failures of the 1800s” by Simon & Schuster

This is destined to be a classic.

My favorites:

C++
You accidentally create a dozen clones of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can’t tell which are bitwise copies and which are just pointing at others and saying, “That’s me, over there.”

JAVA
After importing java.awt.right.foot.* and java.awt.gun.right.hand.*, and writing the classes and methods of those classes needed, you’ve forgotten what the hell you’re doing.

Ruby
Your foot is ready to be shot in roughly five minutes, but you just can’t find anywhere to shoot it.

PHP
You shoot yourself in the foot with a gun made with pieces from 300 other guns.

ASP.NET
Find a gun, it falls apart. Put it back together, it falls apart again. You try using the .GUN Framework, it falls apart. You stab yourself in the foot instead.

SQL
SELECT @ammo:=bullet FROM gun WHERE trigger = ‘PULLED’;
INSERT INTO leg (foot) VALUES (@ammo);

Perl
You shoot yourself in the foot, but nobody can understand how you did it. Six months later, neither can you. (via Andy)

CSS
You shoot your right foot with one hand, then switch hands to shoot your left foot but you realize that the gun has turned into a banana.

Change the savepath to your desired temporary save location.

Click the 'Plain Text' link below to view the raw code w/o the formatting.

Via comments on this post.

Take a look at these two, very similar queries for two alternative open source products:

postgresql backups

The top results for this query all seem to be forum posts. Wouldn't a tutorial or link to the Postgres manual be nicer?

Now take a look at the mysql results:

mysql backups

There we go. That's better - some tutorials and howtos from big name websites.

I love Postgres. It took a little while for me to be a believer, but it's growing on me. This post on FeedLounge about them switching to Posty from MySQL pretty much sealed the deal.

Hopefully Postgres' Google results pages will improve over time & be more welcoming to newbies. (like we all were *once*!)

Finally had a chance to sit down and play with SVK over the weekend.

It helps you manage multiple Subversion repositories -- i.e. keeping one in sync.

Let's say you've modified Typo, but your changes won't be making it into the core distribution.

But you also want to keep up to date on the latest trunk and changes made by the core Typo dev team.

Enter SVK.

I was a little paranoid about SVK killing my Subversion 1.2.1 with its 1.3.0 bundled version, but everything has worked like a charm. (latest OS X Tiger)

SVK Links

• SVK Tutorial
• Free online SVK Book (not quit eas good as Subversion's yet)
• Distributed Development with SVK
• SVK - Distributed Version Control - Part I
• Explaining the SVK Workflow

Six servers to scale to that kind of traffic. Not too shabby for the framework / language (Ruby) that isn't supposed to be able to scale.

Site traffic is currently spread across all four web boxes as each box runs all of our sites by a hardware load balancer of unknown manufacture. Eventually we’ll switch to running 43 Things on a pair of machines and all other sites on the remaining machines.

More here.

MogileFS also looks really interesting.

After writing some extraction scripts to extract out the exact body of emails generated via Ruby on Rails' ActionMailer, I came across a more elegant and maintainable method for testing RoR mailers.

Johan describes this method here.