Eugene Shimalsky in his short piece "One Small iPad for Man, One Giant Leap for Apple" declares that the iPad is interesting primarily because it isn't a computer. As he puts it:

Yesterday, Apple got all of the geeks glued to their screens waiting for the "Jesus Tablet," iPad. An hour later, they were twittering that it did not come. Or maybe it just wasn't their Jesus?

It turns out it was his Mom's.

It's been a long time since most of us have used our computers to do anything approaching "computing," but the iPad explicitly leaves the baggage behind, leaps the conceptual gulf, and becomes something else entirely. Something consumery, media'ish, and not in the least bit intimidating.

The automobile went through a similar evolution. From eminently hackable to hood essentially sealed shut. When the automobile was new, you HAD to be a mechanic to own one. Later, being a mechanic gave you the option of tinkering and adapting it to your specific interests. In fact, that's how most people up until about 1985 learned to be mechanics. The big changes came with the catalytic converter and electronic ignition (and warranty language to match). Now the automobile has reached the point in its development where you don't even have to know whether it has a motor or an engine to use it, but to tinker at all requires highly specialized skills.

So, in some ways this evolution of the computer to the iPrius seems completely natural. I don't care all that much if the iPad is hermetically sealed, but I wonder uncomfortably if in a few years the MacBook and the PC will be too. Or, more likely, we'll just wake up one day to a world without MacBooks or PC's. As we continue our shift en mass to the mobile device ecosystem and the laptop as we know it goes the way of the desktop, banished to special purpose niches.

In mobile land, closed carrier heritage combined with Apple's product vectors may leave us with only closed options. A confluence of interests - commercial (get your pure non-pirated content only from me!), governmental (cyber defense!), and user (I want to be safe!) - will find that outcome attractive. Our generative and hacker-friendly world will be replaced by a sterile world of sealed aluminum.

No doubt the iPad will be hacked by someone to prove it is still possible. They'll run linux on it within a week of launch, but that's not where they will have learned those skills. They learned them on the highly generative PC they probably bought for something else. Slight differences in approachability and "ease of mastery" (as Zittrain puts it) make a big difference. The curves are steep. And tomorrow the people that buy iPad's descendants will be less likely to develop those skills. Who's going to buy a developer's license just to screw around?

For your phone Apple could make a strong argument that this kind of control was necessary. They needed to make sure it was a reliable first and foremost as a phone (rather than reliable as a snooping device or wouldn't just crash every time you really needed to make a call). The argument is being extended to the iPad more because of Apple's culture than real need, and if I was Steve Jobs looking at iTunes receipts I would do the same thing. But... directionally this is a vector toward compuserve, not away from it. The iPad is Steve's Minitel terminal.

Just for the heck of it, imagine for a minute that the MacBookPro was locked up like the iPad. The apps that run on the iPhone have been mostly trivial. One person for a few weeks is probably the average effort. Eugene Lin may be willing to build apps on spec and hope for the best after they are submitted, but will Adobe? Imagine when Adobe invests $X millions building Lightroom for a year only to have it rejected because Apple launches Aperture the same week.

This is one post/chapter in a serialized book called Startup 101. For the introduction and table of contents, please click here.

There comes a time for every venture when the owners have to decide whether hockey-stick-like growth is feasible or not. In your initial plan, you indicated a sudden surge in revenue at a certain point in time, i.e. where the hockey stick shows up. You have now reached that point. You may have a great business, but will it hit the big time?

Sponsor

You need to make an honest, clear-eyed assessment at this stage. You might spend money in the hope of achieving that growth and end up losing everything, which would be a big shame if your business was profitable and growing at normal rates (and therefore valuable). On the other hand, forgoing a chance at the big time just because you are too nervous would be equally unfortunate. How do you navigate this complex decision?

Understand Your Investor's Agenda

If you go for growth and miss your numbers and have to raise more money, your investor will get hurt a bit and you will get hurt a lot. The investor can put in more money, and they will do it on harsh terms if they have to because you have missed your numbers. You may end up with nothing at the end of the day while the investor will get their money back plus some.

If you don't know how that works, look up and understand Liquidation Preference. Your contract with the VC will have a Liquidation Preference clause. It is a perfectly reasonable term (although there are egregious variants), but it can really hurt you under certain circumstances. Basically, your view of risk and your VC's view of risk are different.

Let's look at a simple case. Let's say your VC invested $3 million for a 30% equity share and has a 5% Liquidation Preference (quite reasonable -- not one of those egregious variants) and that your business sells five years later for $3.8 million. What will you and your team get? Because you and your partners and team own 70% of the shares, you would get 70% of $3.8 million, right?

Wrong. You get zip. Nada. Nothing. Just do the compound interest calculation to see why. The fact that you own 70% of the common shares means nothing in this case. The VC gets their money back with interest, which is not a good result but not a disaster either.

If your venture does reasonably well and sells for $50 million, you and your VC will do just fine. The VC will get $3.8 million, and you will divide up $46.2 million (i.e. $50 - $3.8 million) according to the ratio of shares owned. (That works out to over $30 million for you and your 70%-owning team.)

If you hit the ball out of the park and sell for $500 million, the Liquidation Preference becomes essentially a rounding error of interest only to accountants. If your venture misses its numbers and sells for $3.8 million, you will get nothing, which is quite reasonable: the VC bought into a dream and a team, and if you do not deliver, you shouldn't get anything.

Even if the whole business goes kaput without any realizable value, your venture is still just one among many companies in the VC's portfolio. VCs don't like losing ventures, but as they say, "This will hurt you a lot more than it hurts me." This is akin to the chicken and pig contributing to the eggs-and-bacon breakfast: the chicken may be involved, but the pig is "committed."

Just understand that your interests may not be aligned and that your and their views of risk may be different.

Raise More and Go for It?

Let's say you raised $3 million, and you are now gaining traction and everyone is telling you to raise more and really go for it. The VCs are ready to write a big check. It's a no-brainer, right? Wrong. This is when you need to think hard.

Suppose you raise a second round. It's a nice big one for $10 million, and the headline valuation is triple that of your first round. You and your team are giving each other high fives. Perhaps you don't look too hard at the Liquidation Preference. This time, the terms may actually be egregious, but the thought of that $10 million and the headline valuation number cause you to overlook that.

For example, Mark Zuckerberg should be a billionaire because he owns a ton of founding stock in Facebook? Well, Facebook has raised $640 million and some of it a long time ago. There would almost certainly be Liquidation Preference. If Facebook sold for around $1 billion today, Mark Zuckerberg would probably walk away with nothing but a lot of experience and memories. But Facebook would never sell for as little as that, so not to worry, right?

Entrepreneurs are optimistic by nature. They have to be if they are going to get out of bed every morning and work against the odds as passionately as they do. VCs don't have to be optimistic: their downside is pretty well covered.

Run the numbers -- all of them, not just the rosy projections -- and see where you end up. Then make sure your interests and the VC's really are aligned.

And how do you align interests? Five ways.

1. Align Around Facts

Facts are hard to come by in a startup. There is a ton of unknowns. So separate fact from forecast: you can take facts to the bank, but you run sensitivity analysis on forecasts. If that sounds intangible, here is the simple version. Take your forecast and...

1. Double the cost,
2. Halve the revenue,
3. Double the time it takes to do everything in the forecast.

First, do you have enough capital for this scenario?

Secondly, look at what the business would be valued at in such a scenario... not what you hope it will be valued at, but rather what other companies in a similar position are being valued at.

2. Focus on Server Costs

In the Web 2.0 era, we achieved control over the costs that bedeviled the 1.0 era:

• R&D costs have shrunk through a mix of open source, new development tools and offshore resources.
• Marketing costs have shrunk, thanks social media and viral marketing.

Hearing the proud claim that "Our major costs are now only our servers" has become common. For some businesses, that is no longer a proud refrain but a business problem. If you hit that magic viral moment when user traffic takes off, you had better have some of these three things:

1. An incredibly low cost per user as a result of some really smart performance optimization,
2. A revenue model that kicks in right after traffic grows,
3. Enough capital to sustain you until #1 or 2 is figured out.

Ideally, you would have all bases covered, but two out of three is fine. Look at Google. It had #1 and 2. Twitter and Facebook have #3. I would prefer to own Google.

Even if revenue growth is lower than forecast, if the server costs are under control and user growth is booming, you will get more VC money on good terms.

So, don't skimp on that software performance design and coding early in the game. Leaving it as an afterthought was okay for a venture starting out in 2004, not for one starting out in 2009.

3. Control the Business Planning Process

This means you will need a process. If that goes against your grain (because, say, you are a creative type, a great hacker, or a sharp sales guy), then find someone on your team who can really run the numbers and unite everyone around a common planning process.

The type of process will depend on the type of business. At a high level, they all address these questions:

1. Where are we now?
2. Where do we want to get to?
3. How do we get there?

As the entrepreneur/CEO, though, you need to own this process and drive it. The worst thing you could do is let a junior member do this for you. They don't truly understand your business and certainly don't care about it as much as you do, and their interests won't be the same as yours.

The process must be dynamic and based on a financial model. This means you should be able to adjust each variable and re-plan efficiently as circumstances change. Your VC may use earlier plans to beat you up a bit, but those plans are irrelevant; all that matters is the current one (and your VC knows that).

4. Talk to Your Independent Adviser

This is when you will find it valuable to have an independent adviser on your board (see Building an Advisory Board). Being independent means that the adviser was not nominated by the VC. Having someone like that on the board (as opposed to their being merely a friendly mentor) is important because they will then know the numbers and character of the VC better. When you need critical advice in a hurry, it is vital that your adviser knows these things.

5. Do a Deal That Aligns Your Interests

This is possible. If you have a good VC, a good board, and some good advisers, having an honest dialogue to get everyone's interests aligned is quite easy. If you have a lousy VC and a toxic board, you will have a nasty fight on your hands. Don't shirk that fight.

The simplest way to align interests is for the VC to buy some stock from you and your founding team. But the right amount: not so much that they will be afraid (justifiably) that you will walk away to play golf or start another venture, but enough that your family feels secure and personal finances are not a worry. Too much stress is not productive. In other words, you and your VC should be in the same boat and view the world and your risk with the same perspective.

When your business finally gains traction and VCs want to invest more money because they see the big pot of gold at the end of the rainbow, your negotiating position will be strong. At this stage, they need you more than you need them. But don't abuse this position of strength: just use it to get what you and your team reasonably need, and then march on together to build the big dream.

Photo credit: jurvetson.

Hacker Croll, an eponymously named hacker, was able to get access to some very sensitive business documents from Twitter's Google Apps account this week. It was a very high profile hack, and quite embarrassing for Twitter. People familiar with the incident say that the hacker was able to easily figure out the security question to one employees account and, with that, access all of the documents stored in the company's storage cloud at Google. He put them in a zip file and emailed them to techcrunch.com. Ouch!

Note: Google Apps is a suite of free (and paid) business productivity tools that you can access from any web browser. You are probably familiar with most of the apps: Gmail, Google Talk (Google's version of IM), Google Calendar, Google Docs (word processing, spreadsheets and presentations) and Google Sites for websites and wikis. You don't download and install them, you use the tools when you're online. You also have the option to store your data in the cloud so that other team-members and colleagues can access them from remote locations.

This security breach has captured the imaginations of many cyber-pundits and self-styled security experts. It has also inspired some very lively conversations between proponents of cloud computing solutions and more traditional geeks. But there are two things to keep in mind.

1) Twitter is a very big, high-profile target that comes with associated bragging rights. In other words, Twitter is more likely to get on a hacker's radar than your company, and 2) The reason that this account was so easy to hack had very little to do with the fact that the Google Apps are a cloud computing solution. It could have been accomplished with any account that could be accessed from the web. This account was hacked because the user did not have a robust or strong password and security question.

With that in mind, I thought we might use Twitter's most unfortunate security breach as a teaching moment.

Passwords can only protect you if you use them correctly. Here are some guidelines.

Characters

Use letters (caps and lowercase), numbers and symbols. The more cryptic your password is, the better it will protect you.

Leet

Use computer geekspeak to make weak passwords stronger. Leet replaces English letters with numbers and symbols. For example: a=@, E=3, i=1, S=5, etc. Check out Wikipedia for a complete Leet table.

Leet can help you turn proper nouns, which are very, very easy for machines to crack, into stronger passwords. For example: macintoshczar becomes m@c1nto5hcz@r. You can still easily remember it, but it is much harder to crack.

Mnemonics

Make up a sentence and use the first letters of each word to create your password. For example: Mozart is one of my favorite cats in the car. would yield the password: Mioomfcitc. Then write it in Leet to make it even stronger, M100mfc1tc. The sentence is a mnemonic device that will help you remember your password, and Leet makes it much stronger.

Lastly, keep in mind that the longer a password is, the better it is. Change your passwords on a regular basis. No birthdays, names, proper nouns, ages or anything else that looks or sounds like English or says anything about you! And, don't reuse them.

As for security questions: never use your mother's maiden name, the last four digits of your social security number or anything else I can find out about you with Google or on your Facebook or LinkedIn profile. Don't even use your drag queen name (your first pet's name and your mother's maiden name, mine is Muffin Whitehead) it may be great fun at a party, but it is not secure!

If you keep these very simple principles in mind, you will be much more hacker proof than you are right now. Use your username and passwords on your personal computers all the time. Security begins right at your desk. And, don't write them down, of course!

Shelly Palmer is a consultant and the host of MediaBytes a daily show featuring news you can use about technology, media & entertainment. He is Managing Director of Advanced Media Ventures Group LLC and the author of Television Disrupted: The Transition from Network to Networked TV (2008, York House Press). Shelly is also President of the National Academy of Television Arts & Sciences, NY (the organization that bestows the coveted Emmy Awards). You can join the MediaBytes mailing list here. Shelly can be reached at shelly@palmer.netFor information visit
www.shellypalmer.com

Fever and the Future of Feed Readers

Time was, every self-respecting geek lived and died by his feed reader (or aggregator, if you prefer). Just several years ago, the number of subscriptions in your RSS-chomping tool of choice made for bragging rights. 200? Oh, I can get through 500 feeds a day. More subscriptions meant you were more in the know. Really good lists of subscriptions were traded amongst friends, but cautiously, just as one might hold back a recommendation to a superb but little-known restaurant.

At the time, the only real debate was around the best way to present all this information. Some preferred a river of news, others preferred their content categorized and neatly filed, like sections in a newspaper. But everyone was in agreement: having all this fresh content collected for you in one place was a boon. It was a change in mindset, and it seeded the demand for what is now being called the Real-Time Web. (Incidentally, the Real-Time Web is next year's Web 2.0. If you'd like to appear cool and aloof, start disdaining the expression now).

Today, at least in the web-tech echo chamber, feed reading is quickly falling out of fashion. Too many sites producing too many feeds of dubious quality means information overload, and a creeping sense of obligation to keep up with a torrent of questionably relevant content. Some have gone back to checking a handful of bookmarked sites, as we did in the early days of the web. Others rely on social aggregation sites like Reddit, Digg, and Hacker News to show them what's worth reading. Both strategies are highly manual and, to me, distressingly unoptimized.

Abdicating Aggregation

Another camp all but eschews the idea of trying to keep up with feeds. Chris Wanstrath, co-founder of the superb social coding site GitHub, is one of the more visible advocates of this approach, saying in a tech conference keynote last year:

Stop using Google Reader or NetNewsWire or whatever the kids are using these days. It's not worth your time. [L]et other people do the filtering for you. Use your time for other things.

This statement initially rings true. We're in the age of social networking, after all. I've told social sites about my friends, and my friends are always talking about things, so just show me what my friends are talking about and I'll always be in the loop, right? Then I can focus on my own interests and projects. Sounds great.

The problem with abdicating your content consumption to other people, though, is other people. Perhaps it's overestimating my ability to find interesting things to read, but I don't trust my friends and the Internet at large to educate and entertain me. In the venn diagram of my interests and my friends', there may be 80% overlap, but most of the content that I'm going to find deeply engaging is probably in the leftover 20% at the margins.

There's also a sort of collective danger to the strategy of exclusively consuming information through social osmosis: if everyone does it, who's going to find the interesting stuff? Who takes the reigns as the editors, the arbiters of taste? Going back to a post I wrote in 2003, who will be our cool shit aggregators?

If everyone took Wanstrath's advice, nobody would do any filtering and nobody would consume anything. Realistically, we're in no danger of that, but we're also not seeing a radical improvement in the way we consume information on the web. Surely someone's investigating another strategy?

Blending Subscriptions with Social Data

Google Reader is, as evidence of the slowly dying field of feed reading, pretty much the only regularly-updated, widely-used aggregator left on the web. Bloglines has been gasping for air for over a year, and NewsGator is positioning itself towards the enterprise, presumably trying to scrape some money out of the generally unprofitable business of aggregation.

Reader has been something of a playground for Google, and one of the products for which the behemoth has been most responsive to public feedback. When Reader launched, its interface was nigh-unusable. It was updated, improved, and gradually became the only feed reader worth using and not just on the web, something it pains me to say as the owner of licenses for multiple desktop aggregators that eventually had their price driven down to free, and have since seen little attention from their developers.

Today, Google seems hellbent on cramming its otherwise clean and speedy products with cumbersome, poorly conceived social features. Presumably they see social networks as a threat to their valuable side business of, uh, completely free products, and this is their ham-fisted response. In Reader's case, the user response has been one of confusion and derision.

Seeing content filtered through my social lens seems like the marriage of traditional feed reading to Wanstrath's more osmotic approach. Reader's implementation doesn't prove this to be a happy union. The tool is now cluttered with smilie faces indicating content that my friends liked, only Google has fairly incomplete view of who my friends are because they've yet to create a social experience that encourages me to share that information. Reader's myriad competing ways to share, vote on, annotate, and remember items further detract from its former appeal.

I've given up on Reader, but I'm not ready to give up on feed reading just yet. I wanted to try one more experiment.

Enter Fever

Fever is a feed reader designed and built by Shaun Inman, the developer behind the popular Mint web traffic analytics product. Like Mint, Fever is $30 (USD) and runs on your server a ballsy proposition in an age of free software running in the proverbial cloud. It is unapologetically for power users.

Fever's proposition is straightforward: supply it with the feeds you always want to read, and supplement those with feeds that you only want to read the juicy bits of. Fever will then show you a sort of personal Techmeme or Google News, pulling together stories that reference common URLs. Fever's precise formula for this isn't discussed on the product's relatively curt homepage. Take it or leave it.

I forked over my money, spun up a virtual server, and have been using Fever for several days now. Installation was as straightforward and slick as you could hope for given that Fever is a self-hosted web application. Special features aside, it handles the basics well imagine Google Reader before all the social bloat and with a far more attractive design. Fever's design is not perfect, but it's easy on the eyes and pleasant to use. Put another way, Fever doesn't make it harder to read feeds much as you always have.

The $30 question, though: does Fever really float the best, most relevant content to the top in a personalized way? Can it dig through all the noise on the web and show you what you need/want to know at a glance? The free answer: sort of.

For starters, it's easy to pollute your corpus of signal feeds, which Fever calls sparks. Fever needs sparks that contain a lot of links. If you put top feeds from Digg, Reddit, and the like into Fever, you'll basically just end up with your own dim, mostly irrelevant slice of the web. Fever really needs folks like Waxy, Laughing Squid, and Trivium to keep churning out link blogs full of references to good content. Without those sort of quality, URL-rich feeds, your Fever's view of what's hot is going to be lukewarm.

For this reason, Fever is just fine for floating good techie content to the top, but poor for most any other subject. I'd love it if Fever could find me good posts from the set of minimal techno or cocktail blogs I subscribe to, but link blogs and, indeed, linking outside one's own site just aren't as prevalent in those communities. Fever did similarly poorly given a number of sparks for top world news; a paucity of URLs means Fever can't replace Google News for figuring out what's on the front pages of the world's newspapers.

It's disappointing that I can't depend on Fever to be a one-stop shop for my daily information intake. With my current heavily-curated collection of subscriptions, I can rely on Fever to be a sort of no-bullshit Techmeme, but little more. For the topics of world news, music, art, culture, humor, food, and drink, I still need to read a number of feeds entry-by-entry.

Given Fever's initial cost, plus the ongoing cost of hosting a server on which to run it, I can't imagine that it's a tool that will last long in my tool belt. I already regret the time I spent setting it up and tuning my feeds, and I can't really justify keeping it around for the sole purpose of being a less-encumbered Google Reader.

The Future of Feed Readers

I'm not sure what the solution is here. Feed readers as we've known them are dying, but it's as yet unclear what will take their place. Filtering feeds for relevance algorithmically seems all but fruitless; filtering through the social graph is only a slight improvement, but misses the rare content that may only strike a chord with a small audience.

If there's one thing I'm convinced of at the end of this exploration, it's that there's more work to be done, and more businesses to emerge in this field. Social networks alone aren't focused enough tools to bubble up and share quality content. My hope is that a surplus open data of the sort we're trying hard to share at Twitter will help spawn a new generation of tools to manage the flood of content. I don't think it's a problem that Twitter, or any other pipeline for information, can solve on its own.

With all that said, perhaps the right approach really is to abdicate one's consumption of content to whatever you're passively exposed to, and to occupy your mind with other things. The act of creation is almost always self-affirming, and the act of consumption so rarely is.

Are you taking steps to protect your personal information online? 100% protection is, to be completely honest, impossible. However, there are steps you can take to shift the possibility of your personal information falling into the wrong hands from likely to very unlikely.

To put online security in simple terms: Let's suppose a burglar wanted to go through your house and take everything of value. We'll pretend you have a giant house with sturdy doors you keep locked at all times. Your possessions are still vulnerable to a thief who goes around breaking into houses with a crane and wrecking ball, but it's unlikely that you'll encounter such a thief. Your main concern is to keep your stuff safe from regular thieves just trying to make a quick score. In order to do that, you simply need to make it more difficult and time-consuming to break into your house than any comparable house in the neighborhood.

Here are a few tips to help you make life difficult for information thieves online:

1. Use a different password for each account

This one might seem like a no-brainer. Unfortunately, it's one of the most commonly overlooked ways of improving security online. It's easy to get caught up in the rush of new stuff and use the same password for multiple platforms. However, doing so is dangerous because attackers need only break into one of your accounts to access all of them.

2. Avoid passwords consisting of real words

Be creative and mix things up with passwords that include letters, numbers, symbols, and varied capitalization. Thieves aren't very good at guessing passwords that don't make sense. Use this to your advantage and avoid passwords that include words you'd find in a dictionary or combinations of your name and birth date or phone number.

3. Manage your passwords in an offline document

Think of this document as a secret box that contains a key to every room in your house. If you can protect the document with a password, all the better! Reduce the chances of your document being found by naming it something completely un-passwordish. Stopping by the woods on a snowy evening is a good name. (Hackers find Robert Frost quite boring.)

If you prefer an added level of security, write your passwords down on paper and keep them separate from your computer. One of my programmer friends keeps a list of all his passwords on a piece of paper in his desk. He's made daily password changes a part of his morning ritual by changing the password of each program as he signs in for the first time that day. Each new password is written on a piece of paper and locked in his desk at the end of the day. In order to directly access those passwords, a hacker would need to enter the office building where my friend works, break into his office, and pry open the desk drawer. Is his approach on the extreme side? Yes. But so is his need to keep important information secure.

4. Answer security questions with silly answers

Many platforms offer a secondary level of safety in the form of security questions. Most of them ask for your mother's maiden name, the name of a childhood pet, or the name of a favorite teacher. The real answers to those questions are often only a few guesses away. As such, the key to a security question's strength lies in your ability to choose what the platform will take as a correct answer. If you think a hacker would have trouble guessing that the correct answer to, What is the name of your favorite teacher? is OlarbearP37! you'd be right.

5. Keep important files on a detachable drive

The logic is simple: if it's not on a computer with web access, a hacker can't steal it. This method won't protect your data from absentminded behavior or physical theft though. Musician Imogen Heap recently ran into issues with her data protection plan when she lost a detachable hard drive containing many of the music files needed for her upcoming album. The hard drive turned up two weeks later when she went to wash a load of laundry and found the drive in the bottom of her laundry basket. =)

The Bonus Round:

• Make a habit of checking the URL before entering your password on a site. (Protect yourself from sites pretending to be a legitimate site just to get your information.)
• Lifestreaming is fun but there's no need to tell people when you're leaving your house for a few hours. (There's such a thing as too much transparency.)
• If you wouldn't do something in real life, don't do it online. (Advice about following your heart and throwing caution to the wind rarely serves one well online.)

Remember, if a password is easy for you to recall, it will be easy for a hacker to guess.

I know it might seem really boring and tedious to go about switching passwords and moving documents. But information theft is very real and the little bit of time and energy it takes to secure your data online is well worth your effort.

If you have any thoughts, tips to add, or would like to correct me on something, I'd appreciate your input. Thanks, and stay safe!

Click to share this post on Twitter

photo: mirkomakari

Related posts:

1. Do You Admit To Sadness Online?

Font faux pas happen all around us. Last night while you slept, someone wrote an entire sentence in Night Sky. While you ate breakfast, a notice about martial arts Shanghaied your inbox. And by the time you started work, thousands of grade school teachers typed their lesson plans in Comic Sans.

Sometimes poor typography is an honest mistake and sometimes it's bad judgement. In the same way that I love cringeworthy headline puns, you should be free to experiment as a web typographer. However, due to the limitation of web-safe fonts, the world might be missing out on your creativity.

Sponsor

The Microsoft and Apple camps simply can't agree on a catalogue of core fonts and Night Sky, Shanghai and Comic Sans do not render across all browsers without the help of a web-native font solution. For those who are unwilling to sacrifice looks for functionality, here's an explanation of 4 solutions to make your serif's sing.

1. sIFR (Scalable Inman Flash Replacement): sIFR is an open source typography solution that uses a combination of JavaScript, CSS and Flash to replace browser text with prettier web-native text. Essentially, you're playing a Flash layer on top of the original web text. SIFR co-creator Mike Davidson blogs about it as being "a method to insert rich typography into web pages without sacrificing accessibility, search engine friendliness, or markup semantics." Critics argue that the option is slow to render in certain browsers. Nevertheless, sIFR is an extremely popular solution amongst designers and the simplified embeddable sIFR-based Font Burner is quickly gaining users.

2. @font-face: @font-face is a CSS rule where web designers reference a hosted typeface. Dave Rosenberg wrote a great piece about Firefox 3.5's addition of the rule. Some designers prefer to use @font-face as it does not require viewers to have Flash installed; however, the solution is not available across older browsers. As well, Rosenberg notes that, "As with any linked asset, there is some level of security risk if a hacker gets their hands on the font file."

3. Cufn: Cufn aims to be a sIFR alternative. Essentially, the solution allows designers to upload fonts, convert them to a proprietary format and render them using JavaScript. This solution overcomes sIFR's speed issues as it is faster to render in Internet Explorer (since it uses VML) and it does not require the use of a plug-in. It also addresses @font-face's security issues because uploaders retain control of the font files.

4. TypeKit: Judging by the fact that Evan Williams, Caterina Fake and Matt Mullenweg just invested in Small Batch Inc's upcoming TypeKit, font designers might just get the recognition (and possibly pay) they deserve. While we're unsure how this project will take shape, thanks to a TypeKit blog post, we do know that Small Batch is "working with foundries to develop a consistent web-only font linking license." Naysayers already speculate that the solution will be slow and costly to website owners, but the legal implications of this tool may open up typeface options for designers.

Relational databases, such as MySQL, PostgreSQL and various commercial products, have served us well for many years. Lately, however, there has been a lot of discussion on whether the relational model is reaching the end of its life-span, and what may come after it.

Should you care? Which database technology should you be using?

Of course the answer is it depends, but that's not very helpful. Let me ask you a few questions to help you figure out which technology is appropriate to your particular application. Then I can give a few pointers so that you can find out more.

First of all, calm down. Chances are that your current database is perfectly fine for now. But you might want to keep an eye open in case you notice some symptoms which show that you are pushing the relational model to its limits. Some symptoms relate to the structure of your data:

• Do you have tables with lots of columns, only a few of which are actually used by any particular row?
• Do you have attribute tables where each row is a triple of (foreign key to row in another table, attribute name, attribute value) and you need ugly joins in your queries to deal with those tables?
• Have you given up on using columns for structured data, instead just serialising it (to JSON, YAML, XML or whatever) and dumping the string into your database?
• Does your schema have a large number of many-to-many join tables or tree-like structures (a foreign key that refers to a different row in the same table)?
• Do you find yourself frequently needing to make schema changes so that you can properly represent incoming data?

Other symptoms relate to the scalability of your system:

• Are you reaching the limit of the write capacity of a single database server? (If read capacity is your problem, you should set up master-slave replication. Also make sure that you have first given your database the fattest hardware you can afford, you have optimised your queries, and your schema cannot easily be split into shards.)
• Is your amount of data greater than a single server can sensibly hold?
• Are your page loads being slowed down unacceptably by background batch processes overwhelming the database?

In my opinion, too much emphasis is often placed on scalability, despite being a very remote problem on most projects. It's understandable large-scale computing systems are sexy, and everybody likes to think they are building a service which is going to be massively popular but more often than not, developers would be better off focussing on their customers' needs, and solving the scaling problem only if it actually arises.

That said, there is one more reason to consider non-relational databases: they are fashionable. It sounds like a silly idea to base a technical decision on fashion, but remember the human aspects of managing software projects. Great developers generally want to work with cool people in a cool environment using cool technology. That means if you want to hire great developers, providing all this coolness gives you a better chance of getting the best people to work with you. If you want to get on Hacker News, cool technology is also the way to go. Fashion shouldn't be your primary reason, but all else being equal, you can probably err on the side of coolness. Don't forget the cool people and the cool environment though. And now I'll stop saying cool it's not very cool.

Document databases and BigTable

The BigTable paper describes how Google developed their own massively scalable database for internal use, as basis for several of their services. The data model is quite different from relational databases: columns don't need to be pre-defined, and rows can be added with any set of columns. Empty columns are not stored at all.

BigTable inspired many developers to write their own implementations of this data model; amongst the most popular are HBase, Hypertable and Cassandra. The lack of a pre-defined schema can make these databases attractive in applications where the attributes of objects are not known in advance, or change frequently.

Document databases have a related data model (although the way they handle concurrency and distributed servers can be quite different): a BigTable row with its arbitrary number of columns/attributes corresponds to a document in a document database, which is typically a tree of objects containing attribute values and lists, often with a mapping to JSON or XML. Open source document databases include Project Voldemort, CouchDB, MongoDB, ThruDB and Jackrabbit.

How is this different from just dumping JSON strings into MySQL? Document databases can actually work with the structure of the documents, for example extracting, indexing, aggregating and filtering based on attribute values within the documents. Alternatively you could of course build the attribute indexing yourself, but I wouldn't recommend that unless it makes working with your legacy code easier.

The big limitation of BigTables and document databases is that most implementations cannot perform joins or transactions spanning several rows or documents. This restriction is deliberate, because it allows the database to do automatic partitioning, which can be important for scaling see the section on distributed key-value stores below. If the structure of your data is lots of independent documents, this is not a problem but if your data fits nicely into a relational model and you need joins, please don't try to force it into a document model.

Graph databases

Graph databases live at the opposite end of the spectrum. While document databases are good for storing data which is structured in the form of lots of independent documents, graph databases focus on the relationships between items a better fit for highly interconnected data models.

Standard SQL cannot query transitive relationships, i.e. variable-length chains of joins which continue until some condition is reached. Graph databases, on the other hand, are optimised precisely for this kind of data. Look out for these symptoms indicating that your data would better fit into a graph model:

• you find yourself writing long chains of joins (join table A to B, B to C, C to D) in your queries;
• you are writing loops of queries in your application in order to follow a chain of relationships (particularly when you don't know in advance how long that chain is going to be);
• you have lots of many-to-many joins or tree-like data structures;
• your data is already in a graph form (e.g. information about who is friends with whom in a social network).

There is less choice in graph databases than there is in document databases: Neo4j, AllegroGraph and Sesame (which typically uses MySQL or PostgreSQL as storage back-end) are ones to look at. FreeBase and DirectedEdge have developed graph databases for their internal use.

Graph databases are often associated with the semantic web and RDF datastores, which is one of the applications they are used for. I actually believe that many other applications' data would also be well represented in graphs. However, as before, don't try to force data into a graph if it fits better into tables or documents.

MapReduce

Going on a slight tangent: if background batch processing is your problem and you are not aware of the MapReduce model, you should be. Popularised by another Google paper, MapReduce is a way of writing batch processing jobs without having to worry about infrastructure. Different databases lend themselves more or less well to MapReduce something to keep in mind when choosing a database to fit your needs.

Hadoop is the big one amongst the open MapReduce implementations, and Skynet and Disco are also worth looking at. CouchDB also includes some MapReduce ideas on a smaller scale.

Distributed key-value stores

A key-value store is a very simple concept, much like a hash table: you can retrieve an item based on its key, you can insert a key/value pair, and you can delete a key/value pair. The value can just be an opaque list of bytes, or might be a structured document (most of the document databases and BigTable implementations above can also be considered to be key-value stores).

Document databases, graph databases and MapReduce introduce new data models and new ways of thinking which can be useful even in a small-scale application; you don't need to be Google or Facebook to benefit from them. Distributed key-value stores, on the other hand, are really just about scalability. They can scale to truly vast amounts of data much more than a single server could hold.

Distributed databases can transparently partition and replicate your data across many machines in a cluster. You don't need to figure out a sharding scheme to decide on which server you can find a particular piece of data; the database can locate it for you. If one server dies, no problem others can immediately take over. If you need more resources, just add servers to the cluster, and the database will automatically give them a share of the load and the data.

When choosing a key-value store you need to decide whether it should be opimised for low latency (for lightning-fast data access during your request-response cycle) or for high throughput (which is what you need for batch processing jobs).

Other than the BigTables and document databases above, Scalaris, Dynomite and Ringo provide certain data consistency guarantees while taking care of partitioning and distributing the dataset. MemcacheDB and Tokyo Cabinet (with Tokyo Tyrant for network service and LightCloud to make it distributed) focus on latency.

The caveat about limited transactions and joins applies even more strongly for distributed databases. Different implementations take different approaches, but in general, if you need to read several items, manipulate them in some way and then write them back, there is no guarantee that you will end up in a consistent state immediately (although many implementations try to become eventually consistent by resolving write conflicts or using distributed transaction protocols; see the algorithm of Amazon's Dynamo for an example). You should therefore only use these databases if your data items are independent, and if availability and performance are more important than ACID properties. For more information, read about Brewer's CAP Theorem, which states that amongst Consistency, Availability and Partition tolerance, you can only choose two, and no database will ever be able to get around that fact.

Richard Jones, co-founder of Last.fm, has written up an excellent overview of distributed key-value stores. Also Tony Bain gives an introduction to the conceptual differences between relational databases and key-value stores, and recently there was a NOSQL event in San Francisco at which a number of different non-relational databases were presented.

Distributed systems are hard really hard. I suggest that you use them only if you really need the scaling aspects they offer (or just for fun outside of a production environment).

Closing remarks

In this article I have concentrated on open source projects. If you are willing to bind yourself to a particular vendor/hosting provider, Google's Datastore, Amazon SimpleDB, Windows Azure Storage Services or Force.com might be worth considering. They are good technologies, but keep in mind the business risk of potential lock-in.

I can't make judgement about particular projects' suitability for particular purposes. There is some very clever software out there, but also some very new and unstable software. If you want to consider using them, you should do your own research:

• look around their websites for a list of sites using the database in production (and for which aspect of their service they use it);
• check if they have a lively open source community, in case the original developer loses interest and stops maintaining the software;
• try to find some benchmarks (though beware that many benchmarks published on the web are methodologically flawed and/or outdated, so if you are serious about it you should run your own tests, using data which matches your application's characteristics).

As with any fashionable topic, there are many people with strong opinions, both positive and negative; don't let yourself be put off by them. I hope I've given you an overview of the kind of things you can do with different types of databases so that you can choose the right one for your application.

Like this article?

If you enjoyed, this article, feel free to re-tweet it to let others know. Thanks, we appreciate it! :)

Photo Credit: flickr.com/photos/vermininc

No related posts.

Gary McKinnon, the British hacker who broke into an astonishing number of U.S. military systems via a 56k modem, lost his court bid to avoid being extradited to the United States. Here's what that means for him:

According to a fresh eWeek report:

By rejecting the appeal, the human rights court paved the way for McKinnon to come to the United States, where he faces up to 70 years if convicted. He is accused of hacking his way into computers at the Pentagon, NASA and the U.S. Army and Navy in 2001 and 2002, causing a reported $700,000 worth of damage.

Attorney Karen Todner, who is representing McKinnon, said her client would now appeal to Home Secretary Jacqui Smith to try to persuade her to reconsider an earlier decision and prosecute her client in the United Kingdom.

"Failing that he will be extradited...probably within the next three weeks," Todner added.

She said her client had recently been diagnosed with Asperger's Syndrome and hoped Smith would take this information into account. McKinnon told Reuters in 2006 he was just a computer nerd who wanted to find out whether aliens really existed and became obsessed with trawling large military networks for proof.

His lawyers have argued that sending him to the United States would breach his human rights because he could be prosecuted on account of his nationality or political opinions.

Not surprisingly, McKinnon has a lot of support among technical people:

Graham Cluley, senior technology consultant with Sophos, said a poll of IT professionals conducted in 2006 found that more than half were against extraditing him, mostly because they did not feel he had malicious intent.

There is a feeling in much of the IT community that McKinnon is being treated as a scapegoat by the U.S. authorities, that because he was arrested shortly after 9/11 that the U.S. agencies felt that they had to send out a strong message that hacking was not going to be tolerated."

(Photo by AP/Lefteris Pitarakis)

Posted by Ben Worthen

With apologies to Harvard graduates, who found out yesterday that a hacker stole their personal information from the school and eventually made it available over a popular file trading network, today's dose of security news (and a little fear mongering) is going to focus on China.

The Internet can be a scary place

Over the last several years, it's become increasingly clear that many cyber attacks particularly ones targeting the government originate in China. The extent to which the Chinese government is involved is a matter of debate. A few years ago, whenever we talked to people in the government about Chinese cyber espionage we were greeted with responses like: We can't say China was behind it because that would be an act of war, the idea being that no one was willing to go to war over something as trivial as computer hacking.

Now it seems the gloves are off or at least a lot looser. The U.S. commander in charge of cyberspace said this week that military networks are increasingly coming under attack from Chinese hackers, the Journal reports. Gen. Kevin Chilton wouldn't blame the Chinese government outright, relying instead on insinuation. You can kind of connect the dots, he said. Earlier this month, a Pentagon report said that the Chinese Army has units specifically focused on cyber warfare.

The Chinese government has disputed the report. But it might want to get its message straight with China's hackers. Some of these hackers boasted to CNN this week that they've broken into many top-secret computer networks, including the Pentagon's. They also said they've received secret payments from the Chinese government. No Web site is one hundred percent safe, one of the hackers warns the rest of the world. There are Web sites with high-level security, but there is always a weakness.

Incidentally, it's pretty clear that the threat hackers pose now has the U.S. government's attention. Federal agencies are quietly in the middle of a project to reduce the number of points where the government network intersects the public Internet from more than a thousand to about 50. The idea being that this would give security pros fewer points to watch for hackers.