Cool, but why? Because if your business sells things on the web or otherwise makes you money as a result of people doing stuff on your website, you want to maximize the percentage of people doing stuff. That's where A/B testing comes in.

What is it?

Basically, if you test one version of your website against another version, you can measure which one better compels users to do something. So, for example, you might try testing your normal "Buy Now" button against a double-sized, bright red shiny button. You'd show one version to half your visitors, the other version to the other half. Pay attention to who saw which version, and whether they actually bought your thing.

After a week or so collecting data, you can see that, for example, 4.8% of visitors seeing your old button clicked it, whereas 6.6% of those who saw the big red one clicked it. That's valuable. As in, measurable in dollars valuable, so you need to be doing it.

How to do it

To do A/B testing right, you need to run it from the web server. There are tools out there that give you javascript code that Marketing will try to convince you to paste into your site, but don't do it. It would take an entire article just to explain all the ways that's a bad idea.

It's not too hard to code something up yourself, but there are some good libraries out there that you can simply drop in. I'm writing this post to tell you about the one I wrote for ASP.NET and ASP.NET MVC:

FairlyCertain - A/B Split Testing for ASP.NET

I've been using this for the past 6 months for S3stat and FairTutor, with some pretty impressive results. Now that it's good and stable, I finally motivated myself to package it up and release it as Open Source.

It's essentially a simplified version of Rails' A/Bingo, with one major departure in that participation data is stored in the users' browser rather than a local database. That helps it scale out better and means that you can pretty much just drop the code into your project and have it start working without having to configure anything.

Check it out and let me know if you find it useful.

FairTutor is our latest project here at Expat. It's a website that connects Spanish teachers in South America with students in the US and lets them hold live Spanish classes online.

We'll be starting Beta classes soon, so if you want to score some free Spanish lessons, you might want to go sign up for the waiting list!

Basically, we'll handle all the setup and configuration needed to get Logging enabled on your CloudFront distribution, and each night we'll download and process those logfiles, and deliver reports back to your S3 bucket.

Web Stats for Cloudfront & Amazon S3 This feature has been out of Beta for about a week, so go ahead and give it a try when you get a chance. I'd love to hear your feedback. ]]> Tue, 15 Jun 2010 06:49:21 GMT http://www.expatsoftware.com/Articles/2010/06/cloudfront-streaming-analytics-from-s3stat http://www.expatsoftware.com/Articles/2010/06/cloudfront-streaming-analytics-from-s3stat 0 .purple { font-weight:bold; color:#a200db; } .green,.filtered { font-weight:bold; color:#00e800; } .blue,.retro { font-weight:bold; color:#00a8ff; } .red,.known { font-weight:bold; color:#f5302f; } .gold,.notick { font-weight:bold; color:#f4b34b; } I remember the day I got my first Spam post at Blogabond, back in 2005. It was actually kind of flattering, since the site had only been live for a few months. I deleted it by hand and moved on.

Things have progressed substantially since then. Automated Spam Bots gave way to armies of cheap workers posting by hand, and now we've reached a point where roughly 90% of new blog entries on the site are attempted spam. The sheer volume of posts coming in is enough to sneak some of them past the Bayesian Filtering we have in place, so we're lucky to have some extra measures in place to make sure that the general public never sees any spam on Blogabond.

I've learned a lot about Blog Spam over the years, so I thought I'd share some advice for anybody building their own user-generated-content site. Presuming, of course, that you don't want to be overrun with spam.

Collect Everything

Never throw spam away. It's valuable. You need tons of spam to train your Bayesian filters, and you need to use real spam from your own site to get the filtering results you want. Our filters, for example, can differentiate between a post written by a backpacker traveling through Guatemala and a resort offering package vacations there.

Mark posts as spam and ensure that nobody can see them, but keep them around. They're handy!

Classify your Users

At Blogabond, we have the concept of a "Trusted User", whose posts we're comfortable showing on our front page, in RSS feeds, sitemaps, location searches, etc. The only way to become Trusted is to have a moderator flip you there by hand after reading enough of your posts. Everybody else is either a Known Spammer or simply Unknown.

These classifications are the main reason that the average person will never see any spam on Blogabond. All publicly browsable content is from Trusted Users, so the only way to see something from an Unknown user is to go to the URL directly. That means that you can start a new blog today and send out a link that people can use to see what you've written, but until you've convinced us you're trustworthy we're not going to let people off the street stumble across your stuff.

Never Give Feedback

The last thing you want to tell a Spammer is that his post was rejected as spam. Never tell him that his account has been disabled. Let him figure these things out on his own, hopefully after a lot of wasted time and effort.

Pages with spam content return a 404 (Not Found) to anybody accessing it from outside the author's IP block. That way, the author can (mistakenly) verify that it's live, while the rest of the world and Google never get to see it.

Never Show Untrusted Content to Google

The whole point of blog spam is SEO. Once Google gets ahold of a post, the game is over and the spammer has won. The worst thing you can do is blindly trust your spam filters to keep spam off your site and out of Google's index.

Assuming you're categorizing your users, this is simple. If it's from a Trusted User, it goes to places that Google can see it. If not, it doesn't. Sorted.

Maximize Collateral Damage

Stack the deck so that every action a Spammer takes increases the odds that he'll undo all his previous work.

When we flag something as spam, we also go back and flag everything in the past that came from that User and from his IP Address Block (as well as poisoning that IPBlock and User in the future). So while he may get lucky and sneak a post through the filter on his first try, chances he'll end up retroactively flagging that post as spam if he presses his luck.

We can actually watch as new messages drop onto the "Maybe Ham" pile, then mysteriously disappear a few minutes later. In essence, the spammer is cleaning up his own mess.

Automate Everything

You're going to get a lot of spam, so you need tools to make it really easy to moderate it if you want to stay happy. Our Spam Dashboard has a view showing snippets from every recent post that lets us flag an item with a single click (in a speedy, AJAX fashion). I'll spend maybe a minute a day running down that list turning Maybe's into Spam, and occasionally marking a new user as Trusted.

We also have a pretty view of everything that's been marked as spam recently, along with reasons why and daily stats to see how well we're doing:

That's a screenshot from our Spam Dashboard this morning. As you can see, we're doing pretty well.

GREEN items are ones recently caught by the filter, RED items are attempts by a Known Spammer to post something, and items that have been retroactively flagged (from the spammer pushing his luck too far) are shown in BLUE. PURPLE items (none shown) are ones that we had to flag by hand because they made it past the filter.

In this shot, you can see a busy spammer creating new accounts, posting enough blog entries to trip the filter and undo all his efforts, then creating a new account and trying again.

Filter Ruthlessly

There are two categories of people using your site: Real Users and Spammers. When you first start out, you tend to see it less as two distinct groups and more as a broad spectrum with some people falling in between. The longer you run a site, the more you come to realize that no, there are no Real Users with "good intentions" who are mistakenly posting commercial links on your site. Those people are spammers. So don't hesitate to flag anything that looks even a little bit fishy. Woman talking about her fabulous Caribbean Cruise out of the blue? Spam. Random person posting poetry in China? Spam. Guy from India who really wants to tell you about his hometown? Spam.

And how do you know you were right? Because you will never hear complaints from any of those people. We've labeled thousands and thousands of "bloggers" as Spammers over the years, and so far I've heard back from exactly one of them. Spammers know that what they're doing is Bad Behavior. When you shut down their account, they'll know why.

Make the Spammers feel successful

Spammers will put in a surprising amount of effort to get their posts past your spam filter. The harder you fight back, the harder they'll try. Once they've found something that works, however, they'll sit back and watch the posts flow. That's the place you want them, happily sending post after post into your Spam corpus and training your Bayesian filters.

A happy spammer is a spammer who's not going to spend any more time trying to work your system. A happy spammer is reporting success to his boss and costing the bad guys money. A happy spammer is constantly teaching your filter about new trends in the spam world so that it can do its job better.

You want to cultivate a community of happy spammers on your site.]]> Fri, 12 Mar 2010 14:56:00 GMT http://www.expatsoftware.com/Articles/2010/03/care-and-feeding-of-happy-spammer http://www.expatsoftware.com/Articles/2010/03/care-and-feeding-of-happy-spammer 0 article last week describing ASP.NET's Internationalization (i18n) scheme in less than favorable terms, and it occurs to me that I should probably offer up a proper justification if I'm going to start throwing terms like 'Hopelessly Broken' around.

As several members of the ASP.NET community so eloquently pointed out in response to that article, ASP.NET does in fact offer a way to translate web sites from one language to another, and it does indeed work perfectly fine, thank you very much. That fact, I omitted to mention last week, is not in dispute and I apologize for implying as much.

To clarify, I don't mean to say that ASP.NET i18n is Hopelessly Broken to the point where it's not possible to do it, but rather that ASP.NET handles i18n in a fashion that is demonstrably worse than the accepted industry standard way of doing things which, incidentally, pre-dates ASP.NET.

Here's why.

First, let me give a quick rundown on the industry standard way of localizing websites: gettext. It's a set of tools from the GNU folks that can be used to translate text in computer programs. The ever-humble GNU crowd have a lot of documentation you can read about these tools explaining why they're so well suited for i18n and how they're a milestone in the history of computer science and incidentally how much smarter the GNU folks are than, say, you. And why you should be using emacs.

But anyway, to demonstrate why the gettext way of doing things makes so much more sense than the Microsoft way, let me run down a short list of the things you need to do to translate a website. For each task, I'll give an indication of how ASP.NET would have you do it, along with how you'd do it using hacky fixes I've put in place for the FairlyLocal library I discussed at length last week. Also, if there's a difference, I'll talk briefly about how "Everybody Else" (meaning gettext, which is in fact used by Everybody Else in the world to localize text) does it.

Wrapping Up

So while it's certainly possible to localize a website the way that ASP.NET recommends, it is definitely a lot of work, and it tends to be quite confusing. Doing it in another technology, say Django for instance, just doesn't seem like that big a deal. That's the sort of experience that I'm trying to bring to ASP.NET with the FairlyLocal library, and I hope it's at least a good first step.

If you have any suggestions (or better still, code contributions) to make it better, I look forward to hearing from you. ]]> Wed, 10 Mar 2010 18:54:00 GMT http://www.expatsoftware.com/Articles/2010/03/why-internationalization-is-hopelessly http://www.expatsoftware.com/Articles/2010/03/why-internationalization-is-hopelessly 0 I've been building websites with ASP.NET for a little over 10 years now, and I have a dirty little secret to confess: I've never Internationalized a single one of them.

It's not from lack of trying, I can tell you. I've got a good dozen false starts under my belt, and plenty of hours spent studying the code from other people's sites that implement Internationalization (abbreviated as i18n for us lazy typists) the way that Microsoft wants you to do it. And my conclusion is that it's just plain not worth the effort.

I18n is hopelessly broken in ASP.NET. Let's look at this nice snippet of sample code to see why:

<!-- STEP ONE, in MyPage.aspx: Create Runat="Server" Literal Control: --> <asp:Literal ID="lblPages" runat="server" meta:resourcekey="lblPagesResource1" Text="Pages"/> <!-- STEP TWO, in MyPage.es-ES.resx: Create Message Key/Value: --> <data name="lblPagesResource1.Text" xml:space="preserve"> <value>Browse</value> </data> ...and that's for EVERY piece of text in your whole site!

Notice that you need to make every single piece of localized text into a runat="server" control. And that you then need to add this crazy long attribute (that Intellisense doesn't know about, so you have to type out in full) to each one of those controls so that ASP.NET can find them in one of the Resource files that you need to generate by hand for every text fragment in your entire website.

If it sounds like a ridiculous amount of work for your developers, you're probably being charitable. In practice, it's so much extra work that nobody actually does it. That, my friends, is the reason you hardly ever see any multi-language websites written with ASP.NET.

Recently, however, my hand was truly forced. We're getting pretty close to launching FairTutor to the public, and since it has target audiences in both the United States and Latin America it pretty much needs to work in Spanish as well as English. This is the part where I start wistfully looking back to a couple Django projects we did not too long ago, and the absolute breeze it was localizing those sites. If only the rest of Django wasn't so crap, we could just port this project across and… Hang on a sec. Port. Yeah, how about we simply port that amazing Django i18n stuff over to ASP.NET instead.

That was a week ago.

Today, I'm releasing some code that I hope will single-handedly fix i18n in ASP.NET. It's based on the way that everybody else does it. Let's pause a minute to let that sink in, since many of my fellow .NET devs might not have been aware of this fact: There's another way of doing i18n, and it's so simple and straightforward that every other web framework uses it in some form or another to do multi-language websites.

In Django, PHP, Java, Rails, and pretty much everything else out there, you simply call a function called gettext() to localize text. Usually, you alias that function to _(), so you're looking at like 5 keystrokes (including quotes) to mark a piece of text for internationalization. That's simple enough that even lazy developers like me can be convinced to do it.

Better still, frameworks that use this gettext() library (it's actually a chunk of open source code from the GNU folks), also tend to come with a program that will sift through your source and automagically generate translation files for you (in .PO format, which is basic enough to be edited in notepad by non-tech-savvy translators, but is popular enough that there are several existing editors built just for it), containing every text fragment that was marked for i18n.

The whole process is so simple and straightforward that you're left to wonder why Microsoft felt compelled to spend so much time and effort reinventing it all to be worse.

Introducing FairlyLocal

I really want ASP.NET to stop forcing people to monkey with XML files and jump through hoops just to show web pages in Spanish, so I'm going to package up all this code and release it as Open Source:

FairlyLocal - Gettext Internationalization for ASP.NET

At the moment, there's not a whole lot to it. It'll find where you're using the FairlyLocal.GetText() (or its _() alias) and generate .PO files for you. And it'll suck in various language versions of those files and translate text on your website. Not much there, eh? But then that's the whole point: i18n is supposed to be simple and straightforward. Hopefully, FairlyLocal will make that an actuality for the ASP.NET community.

I look forward to hearing your feedback.

FairTutor is our latest project here at Expat. It's a website that connects Spanish teachers in South America with students in the US and lets them hold live online Spanish lessons.

We'll be starting Beta classes soon, so if you want to score some free Spanish lessons, you might want to go sign up for the waiting list!

Ok, fine. Enough asking already! You can do that now.

A little background for those of you who couldn't parse a single word of that. S3stat is a service we built that provides Amazon S3 and Cloudfront Analytics. For five bucks a month, we'll set up logging on your cloud stuff, and every night we'll process those logs into nice shiny reports and graphs. It's pretty cool. You should go sign up for it!

But here's the deal. To do all that, we pretty much have to pretend we're you. We need you to trust us with your Amazon Web Services credentials so that we can make those changes and process those logs. Most people are fine with that (just like we're fine with handing out our credit card number to buy shoes online), but some organizations simply can't afford to take the risk, regardless of how trustworthy our company is or how nice a guy I seem.

That's fine. But it used to lose us a bit of business.

So now, we're proud to announce "S3stat Self Managed Mode", where you exchange an hour's worth of fiddling around with s3curl for the peace of mind that nobody will be using your bucket to store their vacation photos.

Try it out and let us know what you think!]]> Fri, 14 Aug 2009 16:55:00 GMT http://www.expatsoftware.com/Articles/2009/08/s3stat-announces-self-managed-mode http://www.expatsoftware.com/Articles/2009/08/s3stat-announces-self-managed-mode 0 Web Stats for Amazon Cloudfront.

It's actually pretty cool, if we do say so ourselves. When you sign up for the service, we'll set up your Cloudfront Distributions so that they generate the necessary logfiles. Each night, we'll download, translate and process those logs into useful reports. You'll get web stats for your Cloudfront usage without having to do any work. Sorted.

Web Stats for Cloudfront & Amazon S3 We also still do S3 Analytics, just like always. Check it out when you get a chance, and be sure to let us know what you think!]]> Sat, 13 Jun 2009 12:30:00 GMT http://www.expatsoftware.com/Articles/2009/06/cloudfront-analytics-from-s3stat http://www.expatsoftware.com/Articles/2009/06/cloudfront-analytics-from-s3stat 0 travel map template for Blogger, and mentioned it here. Much to my surprise, people started downloading and using it. Doing a quick search today, I see almost 500 sites running that theme now.

Cool!

So I figured I'd do the same for Wordpress users. Here is a screenshot of the Theme in action:

As you can see, it's a pretty clean look, with a Map up top that you can customize to show where you've been and where you're going. Try it out and let me know what you think!

Get a free Travel Map theme for Wordpress from Blogabond.com!]]> Fri, 30 Jan 2009 00:54:00 GMT http://www.expatsoftware.com/Articles/2009/01/travel-map-theme-for-wordpress http://www.expatsoftware.com/Articles/2009/01/travel-map-theme-for-wordpress 0 This morning, I opened the same site in Chrome, and was immediately greeted with this:

My first suspiction was that something else was running on that page and impersonating AdSense, but no. There's only one script include on that page, and it points to pagead2.googlesyndication.com. It seems that somebody has found a way to push out some arbitrary script through AdSense.

I did some digging around to see who else has been having this problem, and what Google was doing about it. Nothing, it seems. In fact, I only found one thread about it. But that one thread is filled with real people that are seeing the same thing.

I suspect this is an actual exploit.

EDIT: Here is another thread discussing the issue.]]> Wed, 21 Jan 2009 19:12:00 GMT http://www.expatsoftware.com/Articles/2009/01/google-adsense-serving-malware http://www.expatsoftware.com/Articles/2009/01/google-adsense-serving-malware 0 comparing Amazon's CloudFront CDN performance with that of Amazon S3 on its own. The results weren't all that surprising. CloudFront kicked the stuffing out of its older sibling in terms of latency. Just like it was designed to do.

That silly article kicked off quite a bit of discussion, most of which was speculation about how much more expensive CloudFront was when compared with S3 on its own, and how its costs stacked up to other Content Delivery Networks.

Well, keeping in the style of that last article, here is one statistically insignificant datapoint from which I'll draw a conclusion. Namely, my Amazon Web Services bill for two months. The following tables represent the costs of hosting imagery for Blogabond, a medium sized blog hosting platform that sees traffic of around 100,000 unique visitors per month and a little over a million pageviews:

October - Amazon S3 alone

$8.12 Total

December - Amazon S3 + CloudFront:


$6.09 + $6.28 = $12.37 Total

So there you have it: It's a little less than twice as expensive to host the same content on CloudFront as compared to S3 alone. And it's still dirt cheap at twice the price! I don't know about you, but I'm going to stick with it.

DISCLAIMER: This is not intended to be a thorough, or even fair, comparison of every available CDN on the planet. So if you happen to be a sales rep for, say, Akamai, and you've got your feelings all hurt because of this post, please remember that it was not directed at you. I'm sure your thing is really really great, but we're not talking about it here. ]]> Wed, 14 Jan 2009 21:30:00 GMT http://www.expatsoftware.com/Articles/2009/01/cloudfront-costs-compared-to-s3 http://www.expatsoftware.com/Articles/2009/01/cloudfront-costs-compared-to-s3 0 CloudFront, and so far it seems to be living up to expectations.

It's dead simple to set up if you're already using S3 to store your content. Both Bucket Explorer and S3fox have already integrated CloudFront support, so you don't even need to write any new code. Just configure a few settings, switch the CNAME records in your DNS, and suddenly your content is serving a lot faster.

How much faster? Lots. Here are my numbers for serving a one pixel .gif file to my development machine here in the North of England (I've given URLs that are guaranteed to point to the right places, even after my CNAME changes propagate):

Amazon S3:
http://img.twiddla.com.s3.amazonaws.com/images/pixel.gif
300ms - 800ms latency, ~0s download time

CloudFront:
http://d2livl246cusvi.cloudfront.net/images/pixel.gif
46ms latency, ~0s download time

S3 performance is all over the map. As expected. Amazon never intended S3 to be used as a direct web host, so it's no surprise that it performs like a big dumb file storage system.

CloudFront, however, is amazingly well tuned. That 46ms time remained constant within 2ms every single time I loaded that file. In other words, CloudFront is so much faster and more consistent that there is simply no reason not to use it for all your S3 content hosting starting today.]]> Wed, 19 Nov 2008 10:35:00 GMT http://www.expatsoftware.com/Articles/2008/11/cloudfront-performance-numbers http://www.expatsoftware.com/Articles/2008/11/cloudfront-performance-numbers 0 StackOverflow.com just launched this last week, and it looks pretty cool. It seems like it might be our best shot at getting back to the sort of useful discussion that we used to have on the Usenet back in the 90's. Lots of signal, hardly any noise, and even the occasional correct answer. Sign me up!

Uh... wait a sec... I can't sign up.

StackOverflow has made the inexplicable blunder of requiring its users to sign in via OpenID. That means you can't simply pick a username and password, but must instead go away and find yourself an OpenID provider, sign up for that, and bring it back to StackOverflow. It's like 14 steps, depending on which provider you choose. Observe:

• Click login
• Read a ton of instructions
• Locate and click the "get one" link
• Dismiss the javascript error popup from openid.net
• Read a bunch more instructions
• Find and click the "ClaimID" link (it's the first one on the list of providers)
• Click "Create a new account"
• Type in your information
• Open your email, find their email, click the link
• Go back to StackOverflow, click login again
• Paste in that giant URL that is now your OpenID
• Type in your Username & Password
• Type in a bunch of Personal Info
• ... and you're in! Easy as that!

Now, for sake of comparison, let's take a look at the steps required to start using Twiddla (the web meeting playground that we've been working on these last several months here at Expat):

• Click the "New Meeting" button

Can you spot the difference?

Look, it's not just me saying this. Talk to any Usability expert you like, and they'll tell you that every barrier that you put in front of your users will cause a certain percentage of them to leave and not come back. For most sites, even stopping to ask for a Username & Password is too intrusive. That's why we built Twiddla the way we did.

Our stated goal with Twiddla is to get the hell out of your way so that you can get some work done. We've taken that idea so far that most of our users will never see a login screen of any description. Some might not ever know they've used Twiddla at all, since we keep our Logo hidden away in the corner where it's not in your way.

Can we say the same about StackOverflow's new registration system? Unfortunately not. For me, it was 10 minutes of grumbling "StackOverflow", "F'ng StackOverflow" under my breath while stumbling through the painful OpenID signup process. Complete usability failure. I can only hope they'll come to their senses and put in a reasonable username/password login like everybody else.]]> Mon, 13 Oct 2008 14:19:00 GMT http://www.expatsoftware.com/Articles/2008/10/how-close-to-zero-friction-is-your http://www.expatsoftware.com/Articles/2008/10/how-close-to-zero-friction-is-your 0

That's what you'll see if you use Google Chrome to draw a rounded box in a Twiddla meeting today, and it highlights a minor cosmetic issue in Chrome's Canvas rendering engine. Oops.

If you think about how you would draw a rounded box on a canvas (straight line, curve, straight line, curve...), you can quickly see what's going on in that picture. We've told it to "turn right 90 degrees", and it though we meant "270 degrees". Or, in math terms, π/2 vs. -π/2, which is the same as 3π/2, since it ends you up in the same place.

Here is a Test Page that reproduces the Issue. Try it in a few browsers and see it for yourself.

The strange thing here is that Chrome is supposed to be using WebKit's Canvas engine. WebKit runs Safari, and Safari draws that box just fine. Funky.

As far as I'm concerned, Chrome is a great browser. With this one minor exception, it ran Twiddla perfectly right out of the box, which is certainly more than I can say for FireFox 3 (but that's another post...), and it's rendering engine is a bit faster than Safari (but not quite as fast as Internet Explorer. Go figure.)

Keep up the good work!

UPDATE: Google fixed this issue on December 11, 2008. Here'a a link to their bug report on the issue. ]]> Thu, 11 Sep 2008 11:33:00 GMT http://www.expatsoftware.com/Articles/2008/09/canvas-rendering-issue-in-google-chrome http://www.expatsoftware.com/Articles/2008/09/canvas-rendering-issue-in-google-chrome 0 I'm already wistful for the good old days, when hitting "Search" from windows explorer would pull up an annoying dialog asking a bunch of stupid questions about what you wanted to search for.

The one thing that old dialog had going for it, and I'm afraid that I never gave it its due credit, is that when you hit the Search button, it would actually, you know, search your hard drive for files.

Well, that's all gone with the new & improved Search dialog. Now, you get a bunch of even stupider questions to look at, but when you hit the Search button it immediately comes up with this:

Roughly translated: "I didn't find anything because I didn't actually look."

Now, being a reasonably computer-savvy guy, I figured it should be a simple matter of hitting the "Index this folder" button somewhere on that screen. Uhh... maybe it's in a dropdown someplace... in a menu maybe??? Nope. It's nowhere. To this day, I have no idea where to even look for the tool that might be responsible for indexing that folder. It just became impossible to search for files anywhere except for my C drive.

So here is my advice for anybody on the Microsoft Search team that might be reading this. In the case where your clever little index of "Things on this drive" doesn't know about the file I'm searching for, or maybe if your clever little index doesn't actually know anything about the hard drive in the first place, maybe you should fall back to, you know, searching the hard drive. It would make my life a little easier.

As it is, I'm back to DOS, pulling out commands I haven't used in 15 years. Thanks Microsoft!

At first, it might seem strange that a blogging site like Blogabond should offer tools to help people blogging elsewhere. After all, why not just force people to migrate their stuff over to Blogabond if they want to get a little map up on top of their blog?

But there's the rub. Forcing people to do things is BAD. People hate being told what to do. In this case, they've got a perfectly good blog going already, thank you very much, and all they want is a stinking map to put on it. Personally, I'll take a little goodwill over a new user any day, so it makes a lot of sense to just give these little freebies away.

In that spirit, you can now download an entire Blogger template that will give you the best of all possible worlds. Here's what it will look like if you install it on your blog:

So yeah, go nuts and try it out for yourself.

Get a free Travel Map template for Blogger from Blogabond.com!]]> Wed, 28 May 2008 12:02:00 GMT http://www.expatsoftware.com/Articles/2008/05/travel-map-template-for-blogger http://www.expatsoftware.com/Articles/2008/05/travel-map-template-for-blogger 0 How can so many smart people be so collectively bad at something as simple as Javascript on a web page?

It's just not that hard. And yet, not an hour goes by when I'm not stopped in my tracks by at least one javascript error. And it's especially sad because many of these errors are coming from well known sites, with huge development budgets and plenty of good talent that really should know better. Observe:

That was just a ten minute sample of browsing today.

The One Rule of DHTML Programming

Look, it's not that hard to do this stuff right. In fact, here is everything you'll ever need to know about Dynamic HTML Programming with Javascript:

That's it. Simple. Every little scrap of code you write needs to live inside its own little IF block that tests to make sure that the things it's expecting to interact with really exist. Here's how:

BAD: gbN2Loaded.style.display='none';	Good: if (window.gbN2Loaded) { gbN2Loaded.style.display='none'; }
BAD: document.getElementById('myDiv').innerHTML = 'stuff';	Good: if (document.getElementById('myDiv')) { document.getElementById('myDiv').innerHTML = 'stuff'; }

I don't care that Google's API Reference told you to put <body onunload='GUnload()'> into all your pages. That's just example code, and it's not intended to be used in the real world.

Real World Javascript will need to survive in dozens of strange browser environments that do things in strange unexpected ways, and as soon as you get it working right, Junior Dev Jimmy will accidently include it on every single page on your site and suddenly it won't be able to find the things it needs to live. When that happens, it needs to quietly stop trying to do stuff instead of throwing error messages all over the place.

What you need to do about it

Ok, cool, you've fixed everything, but you're not done yet. There's one more thing you need to do right this second. You need to turn on those annoying Script Error popups in both Internet Explorer and Firefox, and you need to keep them on from here on out. Don't just do it for your own machine, but for every computer owned by every employee of your company.

Yes, I know that you turned them off on purpose because they make the internet basically unsurfable, but most casual users of your site will have them on by default. That means that most casual users will see every single little script error that your site throws at them, and they won't like it. Those errors are pissing off real people right this minute, and you need to know about it. If you arrange it so that they start pissing off you and your co-workers too, you just might find the incentive to get rid of them once and for all.]]> Tue, 27 May 2008 17:54:00 GMT http://www.expatsoftware.com/Articles/2008/05/one-rule-of-dhtml-programming http://www.expatsoftware.com/Articles/2008/05/one-rule-of-dhtml-programming 0

Seriously. Do it now, before the initial shock wears off and that logical side of your brain starts coming up with lame excuses. You will never have a better chance to get out and see the world than right now. You have a pile of saving and a severance package. You've got 6 months to a year before your skills start getting rusty. There is absolutely no reason to start looking for work immediately, and every reason to take that round-the-world trip you've always dreamed about. Right. Now.

Trust me, your career will be just fine.

Where to go

Make your way to Khao San Road, find a room, grab a Beer Chang and talk to a few other travelers. Your trip will plan itself from there.

Where to go if it's May

How long to go for

In my experience (did I mention that I take about 9 months vacation a year and spend most of that traveling in the developing world?), I tend to start missing work after about 6 months away. By 9 months, I'm pretty much ready to commit to a real job in a real office just so that I can start using my brain again. Talking to other software guys on the road, it seems that this is pretty common. You're going to want to come back eventually, so be sure to keep a few good contacts back home.

Regardless of how long you plan to be gone, try to book your flight one-way. It will give you unlimited flexibility with your travel plans and let you pick your return date later when you know what you actually want to do. As a last resort, pick the return date furthest in the future, since it's a lot easier to move it forward than to push it back.

How much will it cost?

How do I get another job when I get back?

Three Lame Excuses and why they're not valid:

But I don't have any money saved...

But nobody will hire me after six months away...

Regardless of what you may have heard, skilled developers are very hard to find. If you fit that category, there's very little that you can do to poison your resume. Certainly, heading off on your once-in-a-lifetime trip won't leave you unemployable.

But I'm married with a family and a house...

Why you're not actually going to do it

That's cool. Travel is pretty scary when you look at it from the outside. But here's the thing. It stops being scary the moment your feet hit the pavement on Khao San Road in Bangkok. You're going to get blasted by 100 degree heat, power-wafted by smells of the most amazing street food one minute and an open sewer the next, assaulted with music from a thousand bars, and crammed into a tiny room overlooking it all with a fan that doesn't work. And you won't be able to wipe the silly grin off your face.

Book the flight today, because every day you delay it is one more day wasted on the couch, and one more day to come up with lame excuses for why you shouldn't go.

It is all good here. Get your ass on a plane.

]]> Thu, 08 May 2008 18:33:00 GMT http://www.expatsoftware.com/Articles/2008/05/laid-off-one-thing-you-absolutely-need http://www.expatsoftware.com/Articles/2008/05/laid-off-one-thing-you-absolutely-need 0 It was a disaster.

Countless developer hours were spent trying to chase down mysterious runtime errors where single quotes were either introduced, doubled up, or removed, causing disastrous crashes, data corruption and so much untold havoc that the feature was deprecated and eventually removed from PHP entirely.

You would think that people would have learned their lesson.

People are, by and large, dumb. We make the same dumb mistakes over and over again because we didn't bother to do any research or read about the last time that somebody tried whatever stupid idea we just re-invented. As a result, we have development frameworks and tools like Hibernate, ASP.NET's SmartNav, and Rails' ActiveRecord, all trying to magically solve problems that weren't very hard in the first place, and silently making a lot of people's lives a lot harder without them even realizing it.

The big problem with Magic tools is that they work fine the first time you try them. "Wow!", you say, " It posted the page back and scrolled my browser back down to the Submit button!" So you turn that feature on for all your pages and start to trust it. You get used to it. You take it for granted. You forget you're even using it. Then suddenly something weird starts happening with one of your pages and you can't figure out why.

Examples of this sort of side effect abound, but nobody yet has taken a stand and done something about it. How many developer hours have been lost trying to figure out what magical SQL statement was running behind the scenes and only “Hibernating” half of an object? How many CPU cycles have been squandered (and slanderous blog entries written) because some poor developer didn’t realize that ActiveRecord was hitting the database three times for every single row in that recordset? Are we really so scared of Outer Joins that we allow ourselves to be subject to this torment?

I’ll leave you with an axiom that I’ve been telling developers for years without much success. Call it Kester’s Caution:

For me though, it's been even better. We're finally getting enough traffic to start thinking about scaling issues. You might remember an article that I wrote a few months back, where I told people not to sweat Performance and Scaling issues too much, but rather to focus on Readability, Debugability, Maintainability, and Development Pace. The idea was that getting your product to market quickly and being able to move fast if necessary are more important than having the Perfect Dream System that takes forever to build. Of course, the implied point was that when and if that Big Day came, you'd be able to move fast enough to deal with Scalability and Performance concerns as they appeared.

On March 12th, 2008, I got to see first hand whether I was talking out my arse…

3/11/2008 7:00pm: 150 signups/hr, 50 hits/sec, 0-5% CPU

3/11/2008 11:00pm: 350 signups/hr, 120 hits/sec, 1-9% CPU

3/12/2008 9:00am: 300 signups/hr, 100 hits/sec, 1-6% CPU

3/12/2008 9:30am: 500 signups/hr, 300 hits/sec, 3-15% CPU

3/12/2008 9:41am

3/12/2008 10:00am: 700 signups/hr, 500 hits/sec, 5-20% CPU

3/12/2008 12:00pm: 600 signups/hr, 400 hits/sec, 5-17% CPU

3/13/2008 4000 signups/day, 100 hits/sec, 3-10% CPU

Twiddla Art

3/14/2008 3000 signups/day, 100 hits/sec, 2-5% CPU

One week later, ~1000 signups per day, 50 hits/sec, 0% CPU

Still, it's worth noting that everything in Twiddla was built using the simple, Readable, Debuggable backend that we've been using on our more pedestrian sites for years, and it held up just fine under traffic. When it turned out that parts of that backend needed refactoring to handle the kind of concurrency we saw last week, it was a simple 5 minute task to crack open the code, find what needed to change, and change it.

Readable, Debuggable, Maintainable. That's the plan. Thus far, that has enabled us to keep on top of any Performance and Scalability issues that have come along. With luck, things will continue to work that way!]]> Fri, 21 Mar 2008 20:34:00 GMT http://www.expatsoftware.com/Articles/2008/03/6-million-hits-day-time-to-think-scale http://www.expatsoftware.com/Articles/2008/03/6-million-hits-day-time-to-think-scale 0 Big Amazon Outage yesterday. It hit us pretty hard. A few of our sites were serving broken image links for several hours yesterday, and a service we run that relies on SQS was completely dead in the water.

You know what though? It's just not that big a deal. I think about how reliable my stuff was before I put it up on Amazon's machines, and really it wasn't any better. The only difference here is that I couldn't jump onto the server and do the hotfixing myself. I didn't get to spend all day writing a patch to some low-level shared thing that suddenly started misbehaving system wide.

Hey, wait a minute. Scratch that.

I didn't HAVE to do anything at all. It was somebody else getting that page at 3AM and scrambling to get my site back up. This is actually better from my perspective.

So yeah, my sites still see the rare hour-long down window. But now it's not my problem anymore.

Cool.]]> Sat, 16 Feb 2008 11:16:00 GMT http://www.expatsoftware.com/Articles/2008/02/amazon-goes-down-everybody-flips-out http://www.expatsoftware.com/Articles/2008/02/amazon-goes-down-everybody-flips-out 0