How S3 Versioning Works
Versioning is a critical feature many developers had requested as data stored on S3, while maintained in triplicate across the S3 file-system automatically, is still vulnerable to sweeping delete operations by developers, errant scripts, or other causes. Moreover, developers had to manually version changing files if they wanted to preserve the ability to roll-back to an earlier revision or undo a “delete”. In any event, a lot of custom code had to be created to replicate these behaviors, and most solutions weren’t particularly graceful.

Versioning is easy to enable and brilliant for Amazon: make a simple API call to enable versioning for an entire bucket and all changes to the files within that bucket will preserve versions. Moreover, deletions of files through the typical DELETE API call will simply create a delete marker, making the file unavailable for all intents and purposes, but preserving its presence and all of its versions in the S3 filesystem, until its permanent deletion is called for. It’s brilliant for Amazon because you pay the additional storage fees for each version and for each “deleted” file that hasn’t been permanently destroyed.

This means that versioning can be easily enabled on any existing S3 implementation with out breaking compatibility with existing code. Naturally, developers will need to rewrite their delete calls to make use of the version delete options, but for an application with little-to-no deletions, this is a feature implemented with a single API call.

Amazon also introduced Multi-Factor Authentication. MFA works with security code-generating key fobs that act as a physical token one must have in order to perform an action. In this case, if you enable MFA, you need the token to log in and manage your AWS account, and you can also optionally require the token to commit a permanent deletion of a file version. For the uninitiated, it’s considered multi-factor as you need two types of authentication to login or make deletes on your account. (Your AWS username and password for account management and your AWS public/private key for API calls each make up the other half of the multi-factor equation with the MFA code.)

The S3 Trash Bin
Using MFA, it becomes possible to create a highly robust and secure safety net that prevents the wholesale deletion of an S3 account’s contents without first enforcing an additional review step. After enabling versioning and MFA-Delete mode for a bucket, a developer’s application will continue to function to the end-user as expected. This means very little rewriting of code needs to be performed to get these features up and running. A simple trash bin script could then be created which would identify all files whose current version is a delete marker, and present them to an admin. Since permanent deletions require the MFA code to be appended to the API call, only the individual with physical access to the code (which recycles every 30 seconds) would be able to commit the delete operations necessary. After reviewing the files queued for permanent deletion, they’d enter the code and the script would be sent off to the races.

Naturally, this still leaves some room for error: the script that commits the permanent deletes would need to be scrutinized to ensure that it itself is bulletproof, but beyond that, this should protect against nearly all accidental deletions, and establish a command and control hierarchy for an organization. It’s important to reduce the sheer number of individuals who have complete deletion privileges for myriad reasons, and this helps accomplish that. The MFA key fob is available for all of $13 and you’re off to the races. You simply input your serial number on the AWS site, and Amazon’s servers knows what the code it’s generated should be based on the time and a seed that’s private to them.

More on Amazon AWS Multi-Factor Authentication
S3 Versioning | Amazon Developer’s Guide

While managing your social networking presence on Twitter and Facebook, it can be difficult to quantify the impact of each medium. While I’m a huge fan of Twitter, traffic results from earlier today on one of my sites confirmed for me what may sound like common sense: Facebook fans drive far more traffic per-user than Twitter followers for a given promotional message.

I’m currently running a contest in association with T-shirt company Threadless. (It’s called Threadknits, and it’s based on knitting and crocheting their t-shirt designs into crafts.) Today, Threadless posted a message on their Facebook page and  Twitter, both with essentially the same content: an invitation to check out Threadknits. They were both posted at nearly the same time.

The numbers are what might surprise you. Threadless has almost 1,500,000 followers on Twitter, and “only” 102,000 fans on Facebook. With the posts made within an hour of each other, my traffic on the site shot up, with a couple thousand visitors hitting by day’s end. Here’s the breakdown of traffic driven from each:

 
The difference is absolutely staggering. Whereas Facebook generated an approximate 1.08% clickthrough rate, Twitter’s was closer to, well, 0%. 232 visitors came from Twitter or related sites directly and 450 additional clicks landed on the home page without a referrer, which I’m chalking up to clicks from Twitter clients. (Though, to be fair, this could easily overstate Twitter’s influence.)

On a previous contest, Threadless would tweet and I’d see between 1,000-2,000 clicks on their roughly 1.4 million followers, so while it may be a bit low today, I think the point stands: Even at its best, Twitter for large audiences generates clickthrough rates dramatically lower than Facebook. For 2,000 clicks, the rate at 1.4M followers stood at 0.14%. A quick look at the bit.ly stats on a few links from Ashton Kutcher (the #1 Twitter personality by followers) shows they typically net about 20,000-30,000 clickthroughs, on 4.3M followers, gaining a decent amount on the Threadless best-case scenario all the way up to 0.48% ~ 0.60%. (This accounts somewhat for the viral nature of Twitter as bit.ly clicks are counted for retweets as well.) Naturally, clickthrough rates will vary dramatically even amongst popular Twitter personalities for a variety of reasons. I’d like to focus more on the significant difference between the Facebook and Twitter rates I witnessed today.

There are likely several possible reasons for this:

• The audience may be slightly different—people willing to consider themselves “fans” on Facebook may be more picky with their allegiance than those willing to follow an account on Twitter.
• The phrasing and formatting of the message were slightly different—not exactly apples-to-apples as Facebook includes the logo and a text clip from the website, but I imagine this had a negligible effect.
• My mileage may vary—this is an admittedly small sample size, but I think the evidence and logic around these results indicate they’re not anomalous.
• Most importantly, Facebook lingers while Twitter sails by. Users are probably more likely to follow links during their Facebook time than from a passing Twitter notification unless it’s of particular interest to them.

That last point is particularly important. Facebook, having reconfigured their News Feed yet again, no longer sorts things there chronologically. They’ve merged the Highlights functionality back into the News Feed which they now use to keep certain posts “stickier” than others based on what they believe you might be interested in. (It manages to do a strikingly horrible job at this compared to how it used to perform, but that’s a conversation for a different post.)

With Twitter, the very nature of real-time can be summed up: blink and you miss it. While you can use a Twitter client to review tweets over the past day or two, it’s still less likely your tweet was as visible over Twitter as a post would be on Facebook’s News Feed. I’d like to see some more statistics on total audience reach. The clickthrough rate surely only tells part of the story—I’d be far more interested to learn what percentage of each audience even saw the post, and determine true clickthrough rates from that.

In the end, it’s important to consider the overall spirit of the findings here. Twitter is great for growing virally and interacting with customers, but your message on Facebook may have a far more lasting impression and generate greater returns, even if fans are more of a fight to procure. Engage on both, but recognize the differences between them and leverage each of their strengths. I’ll likely post about the best way to do that for each site in the near future.

(The above graphic represents the total clickthrough breakdown by medium assuming a linear progression of Threadless’ Facebook audience to match their Twitter audience, maintaining the same clickthrough rates from today’s traffic. It’s likely the Facebook clickthrough rate could in fact fall some as their audience grew, but it’s my belief that it would still beat Twitter, user for user.)

You can preview the book beforehand and regenerate the notebook as many times as you’d like, though for now, you can’t hand-pick tweets for the notebook. The notebook also appears to only have non-ruled pages much to my chagrin, but it sounds like TweetNotebook is planning on beefing up their offering in the near future if this takes off. For now, they have three different covers available, onto which your current avatar and cover tweet appears. Here’s mine:

Suffice to say, I’ve already bought mine. I think it’s a fun conversation piece, and I think that it’s a fun look into what was relevant to you a few days, weeks, or for some of us, even a year or two ago, in a blurb. It’s almost like thumbing through a diary in a sense, a simple snapshot at the bottom of each page that makes you pause and try to remember what context surrounded that tweet.

We’ve seen Threadless make T-shirts out of great tweets, and I think it’s no stretch to imagine other potential products that can be built out of a users’ Twitter feed. Consider a timeline, complete with tag cloud, friend diagrams, statistics, and more. Twitter lends itself to these sort of changes in medium because of their brevity and relevance—no one’s wearing a shirt with excerpts from their blog on it, but a poster that shows off my activity on Twitter is fun enough even if you’re not a raging narcissist.

For now, there’s also nothing to stop you from using someone else’s tweets, like a celebrity. (Or a friend, for a gift.) That situation may change if copyright issues arise. All told, my order was just $14.50, including shipping to Tempe, Arizona. Here’s hoping they’ll offer different sizes, bindings, and rulings in the future.

TweetNotebook | via TechCrunch

What makes Speed Tracer different?

Developers have long used Firebug to identify what AJAX requests were causing bottlenecks and to analyze responses to those requests. Firebug is an extremely powerful tool and does a serviceable job with this approach, but Speed Tracer takes things one step further, analyzing the “sluggishness” of your application by examining how busy or blocked the UI is in your browser. This can help developers analyze why their application feels slow, instead of simply focusing on network-based bottlenecks.

Speed Tracer makes use of specific, unique APIs built into Webkit for this very purpose, which gives it a unique advantage compared to other profiling tools. Instead of simply guessing and checking, developers will now have full visibility into what’s causing their applications to appear slow:

Using Speed Tracer you are able to get a better picture of where time is being spent in your application. This includes problems caused by JavaScript parsing and execution, layout, CSS style recalculation and selector matching, DOM event handling, network resource loading, timer fires, XMLHttpRequest callbacks, painting, and more.

Very cool stuff. What’s more, it’s free, open source, and available for users of Google Chrome right now. Check out their tutorial below:

Google Speed Tracer

In spite of the fact that parts of the interview sound like it was recorded at a high school basketball game, Eric provides some great insight, even suggesting at one point to “launch” an idea with just marketing materials and an ad campaign, and no backing product. Based on the clickthrough/conversion rate when customers move to subscribe or purchase your product or service, you can reasonably gauge how the idea might do.

There may be an argument to be made about potentially losing those individuals as sales, but you can ask their email, make up an excuse, or explain that things aren’t ready yet and thus limit your costs to just a simple ad campaign and marketing/informational site. If you’re presenting the idea as you will once it’s built, and no one is clicking through, it’s a good indication that you’re going to want to tweak the idea or that you’re headed down the wrong path.

The interview is split into two parts, and I’ve embedded the first part below.

What is the minimum viable product? (Part 1) | Venture Hacks
Opening Board Meetings (Part 2)

Developing a “web 2.0″ application brings with it a host of new challenges previously unfelt or easily ignored with older, single-page-load-per-action apps. The browser has evolved from a simple page renderer to an application platform that busily executes JavaScript and receives, parses, and displays loads of new data without ever leaving the page. Developers are now struck with the challenge of ensuring their applications manage memory properly and efficiently—your JavaScript can leak memory, killing the user experience on your site, but also impacting the user’s complete experience with their system across the board.

To date, it’s been a bit of a struggle to manage memory, since developers are essentially forced to rely on their operating system’s memory managers to even monitor the memory usage of their browser. Even then, testing can be frustrating, as Firefox, for instance, stores all tabs in the same process. Google Chrome is multi-threaded; each tab is its own process. Chrome also features its own built in task manager, so you can identify which page is using exactly how much memory, CPU, and bandwidth. Even at its most detailed, the stats available only show aggregate memory and virtual memory usage—these abstract figures make troubleshooting individual pieces of your code difficult to say the least.

The folks over at Mozilla’s Developer Tools Lab are looking to change that by building a memory analysis tool that helps devs understand exactly how their application is using memory, and the behavior of the cycle (garbage) collector:

We plan on the initial implementation of this tool to be simple. For memory usage, we want to introduce the ability to visualize the current set of non-collectible JavaScript objects at any point in time (i.e., the heap) and give you the ability to understand why those objects aren’t collectible (i.e., trace any object to a GC root). For the cycle collector, we want to give you a way to understand when a collection starts and when it finishes and thus understand how long it took.

Ben Galbraith and the team are soliciting help and feedback, so if this is an issue you’ve had to deal with in the past, make sure you comment.

A New Memory Tool for the Web | Ben Galbraith’s Blog via Ajaxian

Design firm Squidspot has published a very cool and useful Periodic Table of Typefaces. They’re grouped roughly by “family” and “class” groupings, and ranked roughly based on their popularity from several different font ranks, though they’re loosely grouped in order to enforce the aesthetics of the table.

This will be very useful for anyone trying to play the mind-numbingly difficult Deep Font Challenge game. My personal favorite is Frutiger, followed very closely by Myriad. (Naturally, I also love and respect Helvetica and all its gifts to the world—I mean, it’s the only typeface to have a documentary produced about it, and is listed, quite fittingly, as the Hydrogen of the table.)

Periodic Table of Typefaces | Behance
Deep Font Challenge | via iLT

EDIT, 12/28/09: It appears that Qwitter is no longer functioning, but the site makes no mention of this. Your mileage may vary.

If you’ve ever spotted a dip in your Twitter followers count and wondered which of your faithful disciples haven’t been quite so faithful, sign up for Qwitter. It’s mind-numbingly simple: enter your Twitter account name and your email address and you’re off to the races. Qwitter doesn’t need your Twitter password since the follower information is already available, so they just basically run a diff and see who you’ve managed to bore away, sending you an email with their name and the (potentially) offending last Tweet that convinced your follower to bail.

Qwitter

I agree with almost all of them, like Clicking on the logo should take you to the home page—this has become a convention most people expect on a given site, along with highlighting your current location in the navigation bar. There are a few, however, that I might nitpick, such as always underline links, except some navigational cases (unless he means either on hover or the regular state; I note quietly that the links on his blog are text-decoration:none and only underline on hover).

Either way, it’s a great, quick read with some things to always keep in mind when building a website, so take a look and subscribe.

50 Tips to A User-Friendly Website | Designing Interactive

Related articles by Zemanta

• 50 Beautiful And User-Friendly Navigation Menus (web2list.com)
• FeedbackArmy.com – Test The Usability Of Your Site (killerstartups.com)

The problem with following these people is that, while they keep things interesting, they sometimes drone out the people I care most about.

Enter Filttr. Filttr is a clever tool that grabs your twitter timeline (as your home page is called) and applies some algorithmic magic (the best sort of magic, we always say) to show you tweets it thinks you’ll be more interested in.

Filttr offers you the ability to add whitelist and blacklist keywords, which I don’t find particularly useful, since “blacklisting” any particular word or phrase is a bit strange to me (since, without context, how do you know if you’re really not interested, unless you just want to “mute” a particular topic for a bit) but it also offers the ability to rank individuals. So I’ve gone ahead and put a few of my friends on “less” and a couple others on “more” and Filtrr’s timeline is showing me a compressed version of the regular timeline, without all the crap. You can still view hidden tweets, but they’re compressed and cleaned up.

I’ve already suggested that they do a better job aggregating filtered tweets, since they still take up one “row” worth of space, but they’re on the right track here. Further, Filttr threads replies when a friend is replying to someone who had tweeted at them. This is a REALLY nice feature because it gives you context right there. I don’t particularly mind following through an interesting looking reply to see the other side of a conversation, but this is just a nice feature.

You can also establish groups of friends, much like you can do on Facebook, to only see a timeline of a certain subset of the users you follow. This is another useful feature that I’m glad someone else has bolted on to Twitter.

Filttr also offers a free Adobe AIR application to show the feed on your desktop. The app is new and a bit buggy: Scrolling is slow and can spike CPU usage, the app can’t be properly minimized to the system tray, and there are absolutely no options which they say was related to their effort to keep things as lightweight as possible. The app is lightweight, but I’d like to be able to configure a few things, and the lack of even a minimize button is a little strange to me.

When someone builds what is, to me, such an obvious feature for Twitter, it always piques my interest. There’s essentially nothing stopping Twitter from offering the exact same featureset. In fact, I’d expect them to add at least a few of these features. This brings about the argument of the platform versus the provider—many people wondered what would happen with Facebook’s third-party developers, since Facebook’s applications sometimes had direct competition in third-party apps. Thus far, they’ve been able to co-exist, but a third-party app will always be at a disadvantage if the platform decides to start delivering the same applications that the provider is offering. I’ll save the rest of my arguments on that for another post.

For now, try Filttr. It requires you to change the way you do things a bit, but there are some compelling reasons to give it a shot. What do you think?

Filttr (Blog Post) via Techcrunch