Shanti’s Dispatches

Practical Javascript, DOM Scripting, and Ajax Projects picks up where Beginning JavaScript with DOM Scripting and Ajax left off.

Frank Zammetti’s practical guide to real-world JavaScript and Ajax will have you developing actual client-side apps in no time. As more of a hacker than a theoretician, this kind of guide appeals to me. Usually when I start developing my own apps, some of the code used previously (in building sample apps) will be adapted and tweaked for my own purposes.

Some of the projects you’ll learn how to build in Practical Javascript:
* JSDigester - a library that simplifies (takes away the pain) of parsing XML on the client side
* Mashing up a list of hotels + a Yahoo Map for a user-entered zipcode
* Client-side persistence techniques
* A JavaScript validation framework
* Building widgets and working with UI widget frameworks
* Building a JavaScript mini-game (cool!)
* An Ajax-based client-server chat pplication

You can pick up a copy of Practical Javascript, DOM Scripting, and Ajax Projects at Amazon.com (avg. review score is 4.5 stars).

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!

Note: this was written a while back but was sitting in my drafts section. Worth a read if you are coming from a Microsoft background at all.

About two years ago, I implemented a billing system in ASP and SQL Server. It took about a month and a half to get fully flushed out.

Even so, we still experienced intermittent problems with it that drove our salespeople batty. (we could never replicate the problem in-house, since we didn’t have a test lab)

The requirements were, however, different, since we needed to charge cards in real-time in the ASP scenario.

With Sprout, though we might at some point need to do that for certain things (i.e. re-enabling locked, past-due accounts), we generally have the luxury of billing people as needed. (on the backend, at a time of our choosing)

Billing Systems on Rails

The system we just knocked out at Sprout took only about a week. Though, Charles had been working on the requirements for quite some time.

Requirements really do help us programmers. That way I don’t have to idle on IM, asking my manager every 5 minutes about some minutiae of how the system should be implemented.

Yeah - you can always plow ahead and just do things your way… but once you’ve been burned too many times from just doing that, you tend to seek out a little more guidance in the future.

Our system at SproutIt is also a lot more robust than my previous ASP endeavor. Our Sprout system includes a really robust notification system that includes:

- three days worth of charge failed notices
- three days worth of no card present notices
- Activation reminders (signed up for a paid plan, but haven’t entered a card yet, etc)

Hopefully we won’t have to send too many of these various types of notices… but it helps to be prepared.

Rails Productivity Numbers Legit?

Much has been bantied about re: productivity and rails (10x productivity boost, oh my!). Let me just say that I think a 10x number is pure hogwash.

However, even if it were only a 50% increase … that would be incredible. Can you imagine going to a decent manager and explaining that you can get 50% more done if you just use X technology? They would be crazy to ignore that possibility.

In all reality though, I think the number hovers somewhere between 1.5 and 3. That is, you can sometimes get things done in Rails that it would take you three weeks in PHP, or ASP.Net, for example.

Now, Rails productivity vs. Java/J2EE? You’re probably 4-6X as productive in Rails compared to such a bloated monstrosity as J2EE.

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.

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!

Rails 1.1 has arrived!

RJS is a templating language that allows you to write JavaScript in a native Ruby style.

Some Good RJS Links

Cody Fauser's Intro to Rails' RJS
More on RJS and some of its advanced features
Rails JavaScript Generator Methods

Now, here's an absolute Must-Have RJS Debugging Snippet to drop into your rhtml page when you're playing around with this stuff:

(via techno-weenie)

Chris Bauman of SproutIt.com is liveblogging SXSW 2006 over on The Big Act (our weblog).

I don't really know what SXSW is all about. Bands ... geeks ... music ... food ... austin ... and this year ... ajax !

The panel at SXSW includes the coiner of the term 'Ajax' (thank god we don't have to keep saying XmlHttpRequest ad infinitum) ... none other than Jesse James Garrett of Adaptive Path.

Here's a peak at the liveblogging of SXSW so far: ajax: what you need to know, ajax, cont'd and ajax, pt. 3

Charles Jolley has a great post over on The Big Act (SproutIt.com's weblog).

He talks about the shrink-wrap software development lifecycle. It's not uncommon, as he describes, to only release a new update every quarter.

Can you imagine ... a bug in GMail or some really popular web app ... and Waiting. Three. Months.

Now, Charles on web apps, such as Mailroom:

The other night I happened to be working when someone reported a bug they found Mailroom. I immediately knew how to solve the issue, so I fixed the problem and emailed the person back within maybe 10 minutes of their report.

Three months to deliver a fix down to 10 minutes. That’s service! Think about that the next time you find some nasty bug in the software you use for your business and you have to wait for the next release to have it fixed.

This is one of the things Joel is really going to have to grok soon, if not already, following the release of Fog Creek Copilot.

Of course, Paul Graham understood this way back in the day, when he created one of the world's first web apps. (the first, he claims. :))

What is a *REAL* Programming Language?

I got into a bit of a pissing match back at my old company, because one of my fellow developers decided that scripting languages (you know, powering many if not most of the new innovative web apps coming out these days), are not real programming languages.

Only compiled languages like C++, Java, and ... wait for it .... C# are real programming languages.

Do we all remember COBOL? Mainframes?

What do we think hardcore, diehard C++ programmers will be like in 8-10 years? Hmmmm....