A metaphor in poor taste to kick off this lengthy article.

The major problem with this form of advertising is that it takes a person with tact, diplomacy, and self control to do it right. If Twitter supports the '$1 / $$ message' universally it will attract many advertisers lacking any if all of those characteristics. That could result in a diluted user experience and eventual spamization of the system.

Still, in its purest form (and micro doses), this is a great way to perform grassroots marketing.

That said, the patent system is so far gone when it comes to software that you can patent anything. Everyone has. If you write "Hello World", you are infringing. A web form with a button? infringing. The power switch on the computer... ok, you get the idea.

Just do your thing. In software there's no such thing as infringing because the answer to "can I make a computer do X?" is always yes if you work hard enough at it. All of the paths to X will be different.

If you are successful enough for someone to actually sue you for infringement, take this as a compliment. You will also likely have the resources to mount a defense as well.

Worrying about all of that now is just premature optimization. If you succeed, you will be sued. That's just the business climate of today's market. Cross that bridge when you come to it.

Provides a complete IVR written in Ruby, with helpers for menus, multiple dialing, etc. Provides a complete user interface written using Ruby on Rails, for an easy to use configuration tool for both users and administrators. Supports PSTN numbers as extensions, providing a completely virtual PBX. Supports automatic creation of workgroups, including insertion into the dial plan, right from the Ruby GUI. Supports workgroup scheduling from the user interface, so you extension only rings when you tell it to. Supports dialing multiple phones and employees to answer an inbound call. Forwards voice mails to everyone in the workgroup Supports click to dial, call history, etc. from the GUI

The cool part is we're going to open source this thing in the next few weeks. It's probably the biggest adhearsion app out there yet and will serve as a great example for folks looking to do cool stuff with adhearsion.

Take Amazon (established 1994). It was a great success as a startup in 2-4 years (IPO in 97'). It got big fast. It made waves. It challenged the way the industry needed to work & it presented a net gain for the economy as a whole. It became profitable in 2001/2 (7-8 years). A reasonable definition of a successful business . By 2004 - 2008 (10 - 14 yrs) it's a stable business it is clearly here to stay. The elements of its strategy that made it successful in the second half of its life (the profitable one) are the slow & steady ones. Reliability, customer service, trustworthiness, customer goodwill, a long lived affiliate program...

But I agree, some of the examples he gave were probably not the best.

I've setup a hadoop cluster for a start-up I am working in. Initial reason? The amount of incoming log data was getting too slow to process on a single machine and having had a single graduate course in distributed systems I knew a) what is required to go from a single script to a system distributed across nodes b) that I am not in the capacity (alone) to create this system in a time window that will meet business needs.

As a result, I saw hadoop as offering a solution to: implement a distribute process where by records are processes in parallel by multiple machines without having to worry about implementing locking and message passing; distribute disk seek times across a cluster of nodes, pool together disk space with ability to add disk space by simply adding new commodity machines to a cluster.

If you have these specific needs: a) need to rapidly and robustly process more data than a single machine can handle (think of it this way -- if you do data processing with a Perl script on a single machine, will the data be simply too old by the time the Perl script is done?) b) ability to add storage for new data without powering machines down c) the data is non-relational (i.e. you aren't exporting data from MySQL and then re-importing it again - if your data can be stored effectively inside a MySQL cluster and queried in a relational manner, you don't need to use hadoop).

Now, if you still think you need hadoop (in most of the cases, answer is "you don't"):

To get hadoop going minimally to be useful right away is actually almost trivial.

However, as your dataset grows, the amount of jobs and the size of the cluster grow as well as the expectation of hadoop to also be a reliable data store grow, you will run into plateaus that you'll need to overcome.

To answer your questions directly: - Getting it going is easy, trivial. Do it first on your desktop (if you run Linux directly, if not under VMWare). Process is straight forward. - Peeking into the source is not required to get it going - Pitfalls: * Use enough memory, JVM is a memory hog. Always make sure you have sufficient swap (4x your memory) * Find the optimal size of input data for your task (if you are using compressed files for input).

(Yes, I will write these learnings up eventually).

Read the original here: http://classics.mit.edu/Aristotle/rhetoric.html

Wow, biased much?

08/11/08

NEVER FORGET.

(Anyone wanna make shirts?)