Shanti’s Dispatches

You’d give it two Subversion working copy directories, or two Subversion URLs in the same repository like:

http://yoursvn.com/svn/trunk

http://yoursvn.com/svn/branches/foo

The GUI would have two panes (left and right), one for each branch of code. The changes on each branch would be color-coded and easily previewable.

With a few clicks, you could tell it which changes you’d like to merge back and forth, depending on which branch they were made.

The changes would get rolled into one Changeset, which would get sent over the wire once you clicked Commit.

I’d pay $200+ per seat for something like this.

If you know of anything like this, please drop me a line. (Google yields little, I’ve tried Guiffy but it didn’t do quite what I was looking for as described above)

You know you’ve spent too much time in front of a web browser when you’re dreaming of Firefox.
I had a dream last night wherein someone showed me how to switch Firefox 2.0 close tab buttons back to Firefox 1.x style. If you’ve upgraded, you probably know what I’m talking about.

This post shows you how — if you’re like me, you’ll want the good ol’ 3 option set for Firefox 1.x close tab behavior.

When I click “OK” - it shuts down Outlook. When I restart Outlook, it shows the same error message, with the same result.

At least the coders at MS have finally perfected the fine art of recursion!

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?

I’ve been googling how to get IE6 and IE7 installed on the same box (without using a Virtual Machine). One post I read said that if you do that, the IE6 standalone version does not support cookies!

That may be fine for some apps, but not when you use cookies for sessions / user authentication! (like many Rails apps do)

If you know of a solution that can get both IE6 & IE7 working on the same computer (sans VM) with 99% of their functionality intact, drop me a line!

In the meantime I may checkout VMware.

I’ve heard of a few pretty major hosting companies that have data centers located in places like Tampa and Miami.

I always thought it was a bit crazy, especially with all the major activity that part of the country has seen these past few years.

This blogger has taken that idea to the next level and posted a weather map of the worst places to keep your servers, according to Mother Nature.

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

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

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…

I’m not plugged into the environmentalist scene too much. The brief exposure I have into that world mainly comes from my dad.

Oh and definitely check out An Inconvient Truth if you haven’t yet. I actually thought it would be a huge downer, full of lies, and boring as hell. It’s actually quiet eye-opening and presents what it has to say in a very straightforward & interesting manner. (I’m sure there are those that would disagree about its factual contents, but I haven’t googled it enough to know the difference yet)

I always used to always tell my Dad that capitalism, innovation & entrepreneurship will solve all the world’s problems. I still think that’s 90% true — but sometimes it might just need a little help along the way (tax grants, gov’t subsidies, etc) until the profit kicks in.

But anyway, that’s why I love seeing articles like this. My dad also loathes Wal-Mart and everything it stands for. Again, something we agree to disagree on.

But the irony would just be too much… if Wal-Mart really did pull something like this off and got these energy-saving lights in 100+ million homes.