Email/IM bad for communication?

I keep reading news articles about the inferior nature of email, instant messaging, web forums, and other forms of non-verbal communications. I have finally found the source of one of these articles and have found some very interesting details out.

The news article I’m referencing is “Your Emails Aren’t As Funny As You Think”:, which is based on the research in “Egocentrism over E-Mail”: The research study is mentioned in various places throughout the internet, but I need to stay focused if I want to tear both the research and the article apart.

The general belief I’ve gotten from the research is that when you’re communicating verbally, you can read body language and hear tone and voice inflection to get a better idea of the true meaning of the message – sarcasm, annoyance, flirtiness, humor, etc. In email, for instance, there is no body language and no tone to be read.

h2. The flaws in the research study

I have found that the study has made some decent points, but seems to very specifically avoid certain aspects of email communication that would likely have helped show email in a better light.

First off, I’m not talking about study 5 here. This is a study where they took preselected Jack Handey quotes from Saturday Night Live to see how often people’s humor meshed with somebody else’s, when the message was shown in video vs. email. I’m just not sure the point of the study when the humor is not from the actual person. I don’t think anybody will question that humor is better spoken by a practiced comedian than sent in email by an anonymous stranger, so if that’s all they meant to prove, I think they wasted their time.

h3. Most of the studies relied on pre-written text

Studies 1, 2, and 4 had people deliver a certain sentence word for word. These were to be delivered in a certain tone: sarcastic, serious, angry joking, maybe a couple others. These sentences were not divulged (I think that without these sentences, it’s very difficult to determine the validity of the tests), so I can’t comment on how useful they may have been… but think about this: if the sentence is “Your mother is such a bitch for making you pay for your own car”, it’s totally ambiguous whether the speaker/emailer is being sarcastic if all you do is read the text. If I were trying to say that sarcastically, I would probably start off with “Oh yeah, your mother is just such a bitch…” and end with “God forbid….”. Maybe even laugh.

With vocal inflections, I can certainly make my meaning clearer no matter the full text I read. But in email, we rely on things like context to make a message’s intent more clear. Even in normal vocal conversation, we change our message to indicate a different tone, though it’s not nearly as necessary.

The problem I have with these three studies is that the email group of the studies wasn’t allowed to modify the message in any way. No bolding, italicizing, capitalization, smilies, or laughter (LOL, ROFL, hehe, etc) could be added. This, in my opinion, makes for very fallible results. Look at the next section for more details….

h3. Email and IM communications most certainly can have a tone.

As I just said: there are things like bolding text, italicising text, CAPITALIZING text, and using smilies (:D, :), =), ;), :-P, etc.) to get the point across about your intent. Read the following two sentences:

I think the direction our company is headed is absolutely correct, and I’m glad to be a part of it. I won’t be looking for a new job anytime soon.

I think the direction our company is headed is absolutely correct, and I’m GLAD to be a part of it. I won’t be looking for a new job anytime soon ;).

It’s not crystal clear, but the second sentence has a different tone than the first, and will give people a better chance of “getting” the real message (“I hate the direction we’re going, and I’ve already posted my resume to”).

Now consider that some email programs (and most forums and IM clients) even have graphic smilies for showing even more specific emotions. Add an eye-rolling smilie () to that prior message, and I doubt many people will mistake the tone.

The interesting thing to note here is that the study admits that smilies (referred to as “emoticons”) might help send the right tone, but they claim that won’t make much difference.

The way they “prove” this conclusion: * Some smilies are ambiguous, such as “;-)”. Is that a happy response? Flirty? A “just kidding” response? ** This is true, but the same is true of real life! If somebody says “I like that shirt” and winks, I won’t know if they’re being friendly-but-wierd, flirty, or just kidding. * A “follow-up” study was done that allowed emoticons, and found that overconfidence wasn’t affected between the emoticon-users and non-emoticon-users. ** Um… what emoticons were used? What tones were available? What size was the group? In other words, without showing specifics about that follow-up study, how can you use it to dispute emoticons? ** Along the same lines, what was found in that study? Overconfidence may not have changed between the groups, but did accuracy change? If accuracy went up, the level of overconfidence may well not have changed, but that would very nicely prove my point about email tone!

h3. Emailing strangers will lead to more misinterpreted messages than emailing friends or even coworkers.

Study 3 “proves” my above statement incorrect. But you see, here’s where I get into context again. Familiarity is all fine and dandy, but if users can’t bold, italicize, use smilies, or otherwise convey context, then you’re not testing their ability to communicate!

In email, if I’m sarcastic, I’ll add a smilie or “p’shaw, whatev” or something. In fact, to different people my sarcasm will be different. To a good friend, I can say “Oh dude that is totally so like awesome man! I’m so stoked about it, sign me up, brotha!” My friend will know I’m being sarcastic because I don’t normally IM/Email like that. My father, on the other hand, whom I speak to more formally, won’t know how to interpret that message.

Surrounding context is even more important in my opinion. Read on…

h3. The overall conversation’s context isn’t even evaluated!

Context is incredibly important. If I’m asked to convey anger in a single sentence, I don’t know how I’d do it in a reliable way, other than “I’m really angry” (and note that this too can be interpreted many ways depending on context). Measuring the results of effective communication based on a single sentence is simply measuring the wrong thing. They’re seeing how well people can convey an emotion in a single, context-free instance. They then use those results to claim that email is inferior to verbal communication, even though in normal communication, a huge amount of interpretation is based on the context of the conversation.

If my wife and I have been joking around and she suddenly says, “You’re such a jerk!” I’ll know she’s joking, even if her tone would suggest otherwise. The same sentence, spoken similarly, could mean anger, hurt, frustration, or nothing at all. All depending on the surrounding conversation.

h3. The study is flawed by the nature that the participants knew what was being studied!

This may be a controversial statement, but I believe it’s true. Let me explain. If I yell out “You ASSHOLE! I’ll kill you!” in the meanest voice I can muster, and your options for my tone are: angry, sad, sarcastic, or joking, you’ll probably pick angry. If you know me well enough, though, you’ll know that in real conversation, if I yell that out, I’m joking. So if you and I know we’re being tested for tone, I’ll speak the way I expect the average person will understand me, and not the way I would speak in a normal conversation. In fact, I’ll likely exaggerate my speech (sarcasm: “OOOOHHHHH I’M SOOOOOOOOOOOO EXCITED”) to “get the test right”.

In a normal conversation, my angry tone is barely different than my serious tone. I don’t yell; I rarely even swear (out of anger, at least). If you had to interpret a real tone from a real conversation, you would not have nearly as easy a time, and friends and family would have a huge advantage over strangers.

My point is that the experiment should have measured tone in a different way. The speakers/emailers could have been told to create a message as if it were to various family members or friends, for a specific scenario. After typing it up and speaking/emailing, they would have been asked to rate each the overall tone of the message. It could have been presented as some study in effective communication. The recipient of the message would be asked various questions, some related to the study, most not. How well did they get their point across? Was it too wordy? Too brief? Etcetera.

h3. The Implications section of the study is flawed

So we’ve got, in my opinion, some flawed results. The idea that we communicate in a way that is egocentric makes plenty of sense, but most of the other conclusions I’ve seen are, at the very least, misguided. But the final section blows me away.

The claim is that other forms of nonverbal communication are going to be as bad as, or worse than, email. They explicitly include instant messaging.

I’m convinced this study was done by people who view email as a necessary evil, and not by people who “get” it. Their conclusions would suggest this much, but this section really convinces me. Instant message programs like AIM, Yahoo, and MSN all have some very animated smilies for conveying tone. As shown above, the eyerolling animated icon can do wonders for a message. Now imagine dozens of these, all available in one or two clicks. For those of us who like to type, these animated emoticons are even easier to put in a message.

Look at the variety of emoticons in most IM programs and tell me you can’t effectively convey sad vs. angry vs. sarcastic vs. serious. Hell, I could run a study using Yahoo Messenger where people only get to use one icon to convey those four emotions, and guarantee better results than this study….

h2. Gripes about the news

The news article that references the study is flawed as well. The one I’ve referenced above draws conclusions that aren’t in the study – they go from the SNL Jack Handey jokes losing funniness in email to the conclusion that emails you don’t find funny are inherently flawed.

This sentence is just the beginning: “According to a recent study by a trio of business scholars, people think their emails are twice as funny as they really are.” The study is talking about going from a comedian reading of a very specific joke to a FLAT EMAIL. Jokes forwarded around the internet may not be funny to a lot of people, but they tend to circulate well because they’re the kind of humor that doesn’t need to be heard! Jack Handey quotes most definitely gain a lot from their reader.

What’s more, people rated a flat reading of certain jokes at a higher level than the recipients (for instance, I rate a certain quote at 7, but the person I send it to rates that one lower because they like a different one better), showing us that flat reading -> flat reading loses something! Study 5 (the one about humor and Jack Handey) taught us that people have vastly different tastes in humor. Any given person choosing the 5 funniest Jack Handey quotes, even in text-only form, will find that, on average, other people don’t find those 5 to be the funniest! WTF does that have to do with this news article’s conclusion?

Then this article specifically mentions “Photoshopped celeb pics” and “a hilarious clip of a napping cat” as problematic emails addressed by this study. But pictures don’t fall into the boundary of email communication problems! Again, WTF?!? When (and why) did the author think to jump from email communication problems to pictures that he doesn’t find funny? How the hell do those even relate?

Then he goes as far as to say the study is “a much-needed slap in the face to the forward-frenzied emailers out there”. Whereas the study drew a lot of incorrect conclusions, and tested the wrong data, it was at least paying attention to something, and did have a lot of research behind it. The author of this article, David Silverberg, apparently didn’t even READ the damn study! He probably heard about it, wanted to make himself look clever, and chose to revel in his complete ignorance rather than actually research the facts.

As much as I disliked the lack of proper scientific method in the study, this article (and others like it) makes me sick! How can we trust any journalists anymore, when so many of them just recycle other people’s data? And fuck if they can’t even do that right!

h2. Conclusions

Email is almost certainly inferior to verbal communication. But c’mon people, let’s measure the right data next time! And Mr. Silverberg, please try doing the tiniest iota of research before you write again. Might save you from coming across as an ignorant, lazy twit. Oh wait, too late for that….

Friday the 13th: the series!

Do you remember watching Friday the 13th on TV as a kid? Not the movies, the “TV show!”: Of course not, nobody does! But all the same, I’ve just re-remembered it and thought I’d share with all my loyal readers! So mom & dad, here you go:

It was totally rad! Which is to say, it was a moderately interesting idea turned lame due to bad writing and acting. But all the same, I did like a lot of episodes. Then again, I was like 12 when it was on the air, so that doesn’t necessarily mean much. And if you think I’m a geek today, man, you should have seen me back then…

So here’s the basic idea – These three people have discovered that an evil family member (uncle to the two cousins, Ryan and Micki, and I’m not sure who he was to the old dude, Jack Marshak) has been selling cursed antiques. Generally speaking, any given item will give the user some kind of crazy special power for the price of killing somebody. There were lots of variations, but I remember most episodes being that way.

Part what made this show truly special was the absurdities of some of the plots: * Wheelchair episode ** Girl gets harassed by a bunch of guys, and apparently near-raped. ** She runs away and is hit by a car, paralyzed. ** She gets this magic wheelchair (s/magic/cursed), and is able to leave her body to get revenge on her aggressors. ** As she kills each person involved, she gains more mobility. Screw “The Scooter Store”:! ** I think the moral of the story was that murder is bad, even if it happens to bad people. Or something. * Snow globe episode ** Satan captures our three heroes inside… a… snowglobe. WTF? ** He uses damned souls of their friends to lure them in, though I can’t recall exactly how that happens. ** One of the damned friends decides she can’t go through with the betrayal. So she somehow manages to help the trio get a car. ** They drive the car through the edge of the snowglobe, crashing out back to the real world again… ** Satan put them into a breakable container, and left a car there that was in running condition. I think this episode really showcased how stupid Satan really is. * Leather Jacket of Invisibility ** This one’s crazy-awesome – a cursed jacket turns the wearer invisible when they kill people and wipe the blood on the jacket! ** The main plot escapes me at the moment, but I remember they stopped the killer by faking a murder. That is, they let the killer stab one of the main characters, but the dude was wearing a fake pack of blood on his chest that stopped the knife while making him appear dead. This ploy somehow caught the killer offguard even though he was still holding the knife he used to kill people, and let the heroes stop him.

The other really great thing about the show was the intro. First, we get to hear what I recall as cool, creepy music. In all honesty, I was pretty geeky so the intro probably sucked… but we got to see a cymbal-playing monkey!

Then there was the cast. Three names (the three main characters of course), two of which I don’t remember (Ryan and Jack’s characters). Micki, I remember – she was billed simply as “Robey”. I always found that funny, and more so today, because she’s some nobody who really never made it big. Trying to make herself into one of those stars with just one name…. It’s just so pathetic and yet so funny.

Perl vs. Ruby

Just a quick random thought about getting rid of whitespace from a string.

In perl, you trim.

In ruby, you strip.

Now which language is really sexier? You be the judge.

Chips with a KICK

I’ve tasted pain before, but never quite like this.

I rinse with Listerine. Most notably, the “Yellow Death” flavor (I think some people refer to it as “Original”). To me, that’s always seemed pretty hot. Leave it in your mouth longer than the recommended 30-60 seconds, and you’re liable to start crying like a schoolgirl. For real fun, go for 2 minutes, then rinse your mouth with hot water. Now that is painful.

Back to the story – Blair’s Death Rain Habanero chips make Listerine feel like a cool breeze on a hot summer day.

A friend from work brought these babies in and was offering them around. I tried one and found it a bit spicy, but no big deal. So I grabbed a couple more pretty quick. Funny twist… it seems that habaneros are the kind of spicy that takes about a minute to really hit. I guess God thought they’d be funnier that way or something.

Being a “man”, I felt it was my obligation not to show my pain, and eat some more when they were offered. By the end of my 10-chip run, I’d drank around a liter of water and couldn’t quite speak normally. When it was suggested I eat the crumbs at the bottom, my mind screamed at me to “duck and cover” (the neurons weren’t firing quite right, so they must’ve just latched onto whatever warning message they could find). Naturally, I instead casually acquiesced. I’m such a man.

So I ate what could only be described as a concentrated version of agony. I didn’t even flinch. Not once. Of course, once I left for the privacy of the bathroom I wept uncontrollably. Oh well.

This article might help explain how dangerous the chips really are.

Rants about Ruby on Rails

h2. Disclaimers

  1. Ruby on Rails is as good as the hype, it really is. Building a maintainable web application just doesn’t get much better (yet). These are just some caveats I’ve found while using ROR(Ruby on Rails), and some will probably make me sound a lot more pissy than I intend, so keep in mind I would still rather use ROR(Ruby on Rails) than PHP, Perl, java, C, C#, etc. And also keep in mind that some of the problems I’m mentioning here are going to be found in other frameworks. ORM systems try to keep us from having to write SQL, and that is guaranteed to have some issues when performance is our #1 concern.

  2. I’m also the kind of person who seems to get pissed off about almost anything. And the thing is, I’m not actually pissed off – I’m annoyed. I just happen to be vocal about my annoyances…

  3. One final note… I’m not claiming to be a Rails expert! These issues are ones that I find problematic because of people like me who learn as we go. A true Rails guru probably will have better solutions to a lot of these issues. But I’m trying to help the Rails people who haven’t had the time to learn every little nuance in Rails, because I think there are a lot more of those than there are gurus…

h2. Background

Here’s the deal – at my job, I was assigned to a big project (monstrously big when you consider I was the only developer for 90% of the project), and I chose to use ROR(Ruby on Rails) for it. I don’t know if I’m at liberty to discuss the exact details, so let’s just say I’m working on a community-oriented site, revamping their product reviews. Currently, the site has information about something like 70,000 products, and each product has anywhere from 1 to 1000 user-submitted reviews. My revamp is a temporary fix until we get a java portlet solution working (That one was definitely not my decision).

h2. Minor annoyances

My main gripes relate to performance, so I’ll cover them in detail below. First, a list of my minor gripes… keep in mind, it’s often the “little” things that add up.

  1. Rails doesn’t currently support portlets in any way (I can’t find anything about ’em on google, at least). If it did, maybe we could convince the genius management types that Rails is a suitable solution. Hell, I don’t even think portlets are half as interesting to site visitors as they are to site builders. But since they’re a requirement in the long term, they’re what we’ve got.

  2. Rails documentation is pretty sparse for some of the internals. Look at the api site ( and try to find information about RJS or specific information about using routing / named routes. It may be there, but I sure can’t find it! And much of the documentation simply doesn’t go deep enough. Look at ActiveRecord::Migration and ActiveRecord::Schema – they tend to give the simplest cases and still have undocumented functions that you have to look into the source to figure out… no big surprise, Rails is still new, but still an annoyance.

  3. The testing is weird. I haven’t tried integration testing yet, and I think it might fix some of my issues with testing, but unit tests and functional tests are a bit odd at times. I have one test that passes when run by itself, 100 out of 100 times. But it fails when run with rake. I still haven’t figured that out… and functional tests… ugh. First off, the name seems to be wrong. They’re just more view/content-oriented unit tests. Second, they act strangely if you call multiple actions in one test. Even with the recent inclusion of integration testing, it’s just more convenient to write a “quick” functional test that hits the same action in various ways. But if you do that, there are cases where the test won’t work. I’ve had to split up some tests in order to get them to work in a situation where, for some reason, the testing framework is breaking them. Like the data refuses to change after calling one action… and this only happens sometimes, not always. And with such crappy documentation about how testing works (most docs for testing are third-party docs, and generally very shallow), it’s a pain in the ass!

  4. Some things are just documented incorrectly, and seem to be done on purpose for “simplicity”. Associations, for instance. If I ask for, the docs say I get an array back. Well, technically it is an Array. But it’s been mucked with (the specific instance itself, not the Array class) in order to allow for the association’s special functions. Let’s say I want placeholders – for products with less than 10 reviews, I want the array padded to 10 items, where nil items tell my view to show the text, “Your review could be here!” (Stupid example, yes. There are other ways to do this, etc, etc. But the point isn’t this specific example so shut up.) The moment I call @reviews.push(nil) on that “Array” I got back, I’ll hit an error that nil isn’t a review, so I can’t add it to my array. The Array object that’s sent back is modified to allow the cool association features, but this is not clearly documented! The solution? @reviews = (complexassociationlogic).dup. By adding dup, you get a new Array that hasn’t been mucked with. Horrible for performance on large Arrays, I’d bet, but if you know the Array is going to be small, you can deal with it and get a true Array back.

  5. Inconsistent API gets really old. Parameters are a great example. When parsing parameters, hashes exist for parameters that are sent in a certain way (‘object[attribute]’ as an input field’s name is the most common reason to see this). And in the testing framework, you can send parameters to an action as hash elements, such as:

    get :action, :param1 => {:nested1 => 1, :nested2 => 2}
    You cannot do this with url_for style parameters! It will not internally convert from a hash to the expected “url-friendly” values. I don’t see the usefulness in allowing the hashed params in two places, and then having them break in another! I’m hoping it’s just an oversight, but all the same, it’s difficult.

h2. Major annoyances

Quick sidenote about how badly this site was written: when a user submits a review for a product, the review is stored as a flat text file instead of in the database. When the admin looks at reviews for approval (or rejection), he’s looking at the first line on the flat text file. When he clicks “Next”, the ENTIRE FILE is rewritten to move the next line to the top of the file. And this is one of the more logical operations on the site. Other examples include the fact that there’s currently a page that shows all reviews for a given category, and the biggest category, housing over 15,000 products, ends up with a 2.3Mb page that’s got so much stuff on it, it’s totally worthless to anybody. Don’t forget the minor detail that all pages are static html, generated every night by a review generation script that takes up to two hours to run on some extrememly fast systems (yes, there really is a lot of data). Dynamic content is so much sweeter after seeing a system like this.

Moving right along… so I’ve got this crappy legacy system to work with. I’m only trying to make the system a little easier to use, and more maintainable in the short term. This means I’m not getting any content folks to rewrite pages, I’m not totally redoing layout, etc. It’s all going to look very similar to the end user, but behave much differently on the back end. The current system is all perl scripts, and is easily the worst code I’ve ever seen. And given that I’ve seen my own code from years ago, that’s saying quite a lot.

So while I’m rewriting a lot of the backend here, I have to try my hardest to keep the look and feel moderately similar to what’s there right now. Tricky, tricky. And when moving from gobs of static files to dynamically-generated output, things get really painful….

Now to unveil my #1 gripe: Rails is very stupid when it builds SQL. Watch the dev log fly by when you do things that are oh-so-simple in code. (Lame gripe? Sure… this is actually a gripe that would exist in most ORM frameworks, even. But with this project it caused me some major headaches, so instead of having a more legitimate major gripe, I have this one. Deal with it.)

First example is a Rails newbie (me around the beginning of 2006). I have a list of manufacturers, and want to show each one, its products, and the product reviews. Simple:

  <% @manufacturers.each do |mfg| %>

<%= %> <% mfg.products.each do |prod| %>
  • <%= %> <% do |review| %>
      <% review.ratings.each do |rating| %>
    • <%= %>: <%= rating.text %>
    • <% end %>
    <% end %>
  • <% end %> <% end %>

    When there are 1000 manufacturers for a given category, each with an average of 15 products, each with an average of 10 reviews, each with ~5 rating items, you can see very quickly that the number of hits to the database is insane. And this is a relatively simple example of what I’ve had to do.

    I learned quickly about eager loading. When I load my manufactureres, I pull in all products at the same time. This means a longer hit to the DB, but a lot less time parsing. But this still means a lot of hits for reviews and ratings! What do we do?

    Well, some of the smarter folks out there might suggest using a :through association to eagerly load the reviews. Then we’re only grabing each review’s ratings. Great idea, right? Surprisingly, no. While it may be a better situation than the prior one, it’s still far too slow for a page hit. The SQL for eagerly loading products will run on our dev machines in about 1/10th of a second. Throw in reviews and it’s up to TWELVE SECONDS! (Yes, I’ve already checked indexes, thanks for the tip, smartass). What’s more, the query gives me over 200,000 rows, while the manufacturer + product query only gives me about 30,000. That’s a whole lot more data to deal with. In fact, it’s exactly the number of rows that are in the review table to begin with. (This is obvious to somebody familiar with SQL….) Either way, the page load just for that data being processed (read from database and then turned into ActiveRecord objects) can end up being in excess of a minute.

    Now the naysayers will pipe up with “use caching!”

    So on to my next major gripe: caching is not very useful for a site with huge amounts of data to present. Oh sure, only one person has to be hit with that huge penalty, then everybody else is good. No big deal. Except when you need your data refreshed every hour, and 10 places on the site are dangerously slow (I consider >30 seconds to be in this realm). All of a sudden you have 10 pissed off customers an hour, 240 a day, and eventually everybody knows something’s not right.

    Background caching is something I would love to see! I wish I were a better programmer, I’d submit a patch… but boy, wouldn’t it be great to be able to say, “start rebuilding this cache, but until it’s done, show the old cached page”? Then nobody is ever hit with that initial page load! That would make insanely large sites able to present a perfect interface to the user, while keeping the data up to date as often as needed!

    Okay, back to my situation. Not only do I need to display all the data previously mentioned, but I also need to present some advertising-related data. Each product can have many advertiser_links. Each of those links points to an advertiser. To get at that data, I’ve just added two new joins. Pulling all the data at once is simply not doable. Just adding the ratings to the above query (remember we were just doing manufacturer, product, and review) makes it too slow (47 seconds!! over 1,370,000 rows!! YAY!) for me to ever consider for a real website. Adding the advertising information isn’t even worth timing. I tried, just for kicks, and couldn’t sit around long enough to see how long it took.

    So how do I get past this? Why, I turn to my friend the paginator! That’ll fix all my woes! Right?

    Once again… no. It’ll help, but certainly isn’t the final solution. The problem is that this site just has too much data. I paginate the hell out of it, and still most pages take too long to wait for loading. Especially since I can’t eagerly load as much as I need to in order to stop hitting the DB 10-50 times per product. Pagination is part of the answer, but by itself it isn’t bringing page load down low enough to matter. Early tests revealed 5-15 seconds per page because even though I’m pulling less data, I’m still hitting the DB so many times. And when I do lots of eager loading, the DB spends so much time that I don’t gain much on getting a small result set.

    SO HOW THE HELL DO I GET PAST THIS? At this point I had hit a wall; I just didn’t know what else to do.

    NOTE: there may be more options available that I don’t know. I know enough about Rails to know that there’s still a lot more that I have to learn.

    I ended up doing what I should have done long ago: building custom SQL. Okay, I actually didn’t build SQL outside of the Rails system except once, where I needed hundreds of thousands of rows of data without the overhead of building an object for each one. But I did have to make heavy use of the find method’s :joins and :select options (once you hit those two with a :conditions option, you’re writing about 70% of the sql for the query, minus the weird table/row aliasing rails does), and I did a lot of preloading data. For instance, I’d have my list of manufacturers (with products eagerly loaded) and the load all advertiser information, stored in a hash by product id. This allowed me to hit the database only a few times, and with relatively quick transactions.

    Another little cheat was to do a lot of @product.mfgid = xxx@ or @if (product.mfgid == xxx)@, instead of @product.manufacturer = xxx@ and @if (product.manufacturer == xxx)@. I may know an id for something, but not have it loaded on that specific product instance. Punching in the extra few characters (and therefore not loading more data) can yield tremendous performance bonuses.

    Another nice solution I came up with is one I will put up as a plugin at some point – cachedfind. If findevery (all finds eventually hit this one) is called with the same parameters twice, within a given amount of time, the plugin will not hit the database again. This saved me a ton of DB hits on tables that have a lot of data that never changes. Some will say, “A good DB server will cache that for you!”, and they are right. But that still requires a hit to the DB server (rarely on the same server your code is running, at least in a large app), and Rails has to parse that data. Returning pre-parsed data that was previously being loaded 50+ times per page makes a big difference. This can end up involving a ton of data being stored in memory, so this trick is really only good for small sets of data that are rarely changed, and loaded in a lot of different places for different reasons. In my case, things like product categories (loaded for products, manufacturerers, and reviews) and advertiser info (only a dozen or so advertisers exist in the data, but the extra join on two or three queries was still painful).

    The moral of the story is simple. Rails is proven for small sites, and even medium-to-large sites written with Rails from the beginning. Redoing a huge site to work in Rails requires a lot more than what the tutorials will ever tell you. It requires a lot of banging your head into walls, trying to rattle out one more life-saving plan. It requires a tenacity that not a lot of developers will have, especially those buying into the “Rails projects go 10 times faster!” hype. It requires a lot of digging into the internals of Rails. It requires at least a small amount of brain damage.

    Is it worth it to do this when I could be working on the Java solution? I certainly think so. I find that Java is painful enough to use (compared to Ruby) that it is still easier to play with new technology that may have little quirks than to deal with “reliable” and “proven” frameworks based in Java.

    Cold Mint Listerine

    Funny story. You’ll all laugh.

    Today I brought a bottle of Cool Mint Listerine to work. One of those travel-sized bottles. You know, for when I eat at work and my breath is bad and I can’t score with all my hottie coworkers.

    Well, I put the bottle in my lunch box so I wouldn’t forget to bring it to work. Then I put my lunch box in the fridge, having forgotten to take the bottle out once I arrived. Then I opened my lunch box just now, and found that I had a bottle of cool Cool Mint Listerine.

    So I have this bottle of cool Cool Mint Listerine. Hilarious!! Haha! Right?

    JESUS NO. It pisses me off, even. It’s so stupid, I end up feeling like I’m in an episode of “Friends”. Uh oh! Chandler put his god damn Cool Mint Listerine in the fridge! And that fucking laugh track grating on my nerves, firing off every few seconds to make sure we know how much fun we ought to be having. And then Joey pipes up with “Hey, so is it like… Cold Mint Listerine now?” Laugh Track. Stupid expression from Chandler. Laugh track. “Okay, then.” Laugh track. Jennifer Anniston wishing she could act. Laugh Track.

    The worst part is, it would be funnier than the typical episode.

    I can’t decide if I’d rather forget that “Friends” ever existed, or just kill the producers.

    Quick update…

    Now that I have a blog and am striving toward better information delivery, I figured maybe I should post an update on Bloodsport Coliseum.

    It’s actually coming along nicely, but will be a while longer. I’m estimated around 100 hours left until a release candidate, with an average of 6 hours a week going into it, so in theory just about 4 more months. I must stress the “in theory” bit, because let’s face it, my estimates are rarely on target. I promised an open beta at the end of last year and still don’t have one, so… take this announcement with a grain of salt.

    Why did I do it? WHY???

    Blogs are for idiots! Everybody knows that! I certainly am well aware of how stupid they are… so why am I, a well-educated college dropout, choosing to host and even make a half-assed effort to maintain a blog?

    Simple. I need filler. My site has a few games and two real articles. Games take a long time to build, and the articles just feel a bit out of place. They have no organization, so adding more to the list would be a pain. And I’m just not sure the direction they need to take. So They’ll probably eventually be moved into the blog and dropped from the main site. Or maybe not. I’m pretty lazy.

    So that’s it in a nutshell. I hope you all enjoy my ramblings, because I sure as shit wouldn’t.