Humm… I should be doing a trackback on this, but I’m not really sure this blog is ready for prime time.

The smoothspan blog is one of favourite reads in that it provides some very deep insights into “what’s up”.  Today’s copy-paste focus on ways to succeed on this technological jungle.

Summary of Guerrilla Platform Tactics

1. Launch a Great Application that has a thinly concealed platform attached.  Defer announcement of the platform until the Great Application is well established.
2. Give away a distributed open protocol that’s suitable to create a platform around.
3. Be the middleman that matches disparate protocols between services to create a Bridge Architecture.
4. Talk down your platform.  Focus on solving a few key problems and helping others out.  Give away those first couple of keys to prime the pump.
5. Minimize the friction to enter and maximize lock-in to create a Slippery Slope.
6. Offer Quid pro quo.  Give away something to platform participants that enrolls them as unwitting platform supporters.
7. Use Widgets or other bread crumbs to pull people off another platform and onto your own.

From the top of my head here are some companies/apps that lead the way in each of these tactics:

1. Facebook
3. Meebo
4. 37signals
5. jottit (in the entry friction at least :))

I never really thought about the remaining points but I think they should be considered while creating the basis for any wannabe 2.0 app.

Today I spent some time getting started slowly with Erlang and I must say I didn’t expect to finish the tutorial with a distributed message server (with built in error recovery). Nice!

Focus, Davide! Focus!

So… I was reading a great text on Function Languages by Slava Akhmechet when I came across a description of Pattern Matching which seemed to provide what was my first step in understanding Erlang.

The following is the normal way we’re used to look at the Fibonacci function:

int fib(int n) {
    if(n == 0) return 1;
    if(n == 1) return 1;

    return fib(n - 2) + fib(n - 1);
}

And here we have it in a pattern matching functional way:

int fib(0) {
    return 1;
}
int fib(1) {
    return 1;
}
int fib(int n) {
    return fib(n - 2) + fib(n - 1);
}

The underlying (made up) language tries to match the calling arguments with the various function definitions (somewhat like overloading does) but choosing the more specific version.

Erlang makes extensive use of mattern matching and understanding the first Erlang programs you come across is mainly an exercise of pattern matching. After that the learning curve goes down as apparently complex functions are partioned into the various function definitions. A simple way to look at it might be thinking of mathematical branch functions.

More on the language if I end up using it.

This wasn’t a very good day production wise, but on the learning aspect I couldn’t be happier.

I found this article explaining the MapReduce algorithm used by google in the massive computations they have to do every day to give us all that google goodiness.

Not many firefox tabs latter I found Hadoop, an open source implementation of the same algorithm, and another tab later here’s Johnny!: a tutorial on setting up Hadoop on EC2.

To harness this kind of large scale computing power the algorithms must fall within the MapReduce constraints. Argh… f*ck. Can’t spell out the idea that’s brewing in my head. Bah… no biggie. More ideas will come.

Update: Me again! In yet another tab I found Starfish! A ruby MapReduce implementation that can work with the Rails Active Record ORM or plain files. Sweeet!