Jabberwocky

Transparency

2011-09-17T00:00:00Z

2 weeks ago, we watched some of the Strata preview from the Office. Strata is a conference about bhe business of big data which takes place every year.

Michael Nelson's story: after Wikileaks broke some highly sensitive stories, not only governments but also organizations decided to clamp down on every possible leak and information source. Michael Nelson argued that this is a bad approach - a much better oneis to strive for maximum transparency. The brazilian company SEMCO, striving for total transparency, was one of his examples.

He posited that in most organizations there is a kind of Pareto principle of sensitivity of information: a large majority of data could be disclosed without any damage, only a few percentage are of strategic importance.

Even better, disclosing that non-sensitive information creates a sense of trust and familiarity in the customers. Being open is simply good PR.

I do agree with those points, especially the last one: as examples see the blog post by a Rand Fishkin, and the Peldi's blog. Both company founders talk about milestones, decisions, joys and disappointments in an earnest way. Their sharing creates a personal connection. The reader feels like cheering for their successes, and lamenting their losses, which does no end of good to their brand.

A more cynical part of me also senses that if you look transparent, people won't look that closely because they think they know all there is to know. Also, one could be drowning out relevant information in noise, as it were. Not to mention that any displayed infomation can be given the spin it requires.

On the other hand, I feel that a lot of organizations would still be reluctant to go that far: unfortunately, companies can be dysfunctional enough that they wouldn't like to wash their dirty laundry in public.

While in fact, transparency might be very beneficial for these organizations: public shaming is a strong motivator for change. Something they might want to come to terms with, because in the age of porous boundaries, disclosure might happen whether they want to or not.

Interlude

2011-08-23T00:00:00Z

I've been slack on the blogging front for several months now - been fairly busy:

moved to London
found a new job at Forward, also known from the concept of Programmer Anarchy
spoke at a motherload of conferences (euruko, rulu.eu, Nordic Ruby, Rubykaigi, SPA ) resulting in a lot of traveling.

I'm slowly regrouping and have a little bit more time to settle here in London. Time to start blogging again - plenty of material to do so.

Getting cosy with MRI Ruby

2011-04-28T00:00:00Z

Have you ever wondered what is going on in the entrails of MRI Ruby ? I certainly have. I started out studying engineering because I wanted to know how everything works. As it turned out, every fact just generated more questions, but that won't keep me from trying.

A little bit of poring through the source code (ruby 1.9.2) yielded some tools which can provide helpful insights for this research.

You're probably already aware that a Ruby program is executed like so:

parsing: the program is tokenized, lexed and interpreted into an Abstract Syntax Tree (AST). This AST is basically the source code reduced to a tree form, which looks vaguely lispy in construction.
compilation: this tree is compiled to a set of instructions for the Ruby virtual machine.
execution: the instructions are then executed by the ruby virtual machine.

Here are some tools, built-in in ruby, to see what happens to a bit of code.

Parsing

ruby --dump parsetree code.rb

say code.rb contains just one statement:

answer = 42

The corresponding AST yielded by this option:

# @ NODE_SCOPE (line: 1)
# +- nd_tbl: :answer
# +- nd_args:
# |   (null node)
# +- nd_body:
#     @ NODE_DASGN_CURR (line: 1)
#     +- nd_vid: :answer
#     +- nd_value:
#         @ NODE_LIT (line: 1)
#         +- nd_lit: 42

This gives us an insight in what constitutes an AST node for Ruby.

Compilation

2 ways to see the instructions produced by compilation.

The first one is a dump parameter like the one above:

ruby --dump insns code.rb

outputs:

== disasm: @test>====================
local table (size: 2, argc: 0 [opts: 0, rest: -1, post: 0, block: -1] s1)
[ 2] answer     
0000 trace            1                                               (   1)
0002 putobject        42
0004 dup              
0005 setdynamic       answer, 0
0008 leave

The second way to get information somewhat more tricky - in this case a C macro needs to be 'turned on' for it to work. A hint in the comments of compile.c:

 * debug level:
 *  0: no debug output
 *  1: show node type
 *  2: show node important parameters
 *  ...
 *  5: show other parameters
 * 10: show every AST array

There are two ways to set CPDEBUG: you can add a parameter to the compilation in the makefile -DCPDEBUG=5 Or you can change the default value directly in compile.c

#ifndef CPDEBUG
#define CPDEBUG 5
#endif

In both cases, recompilation is necessary, and will produce more output than usual. Running the same minimal program code.rb yields a whole lot of output about the generated instructions, maybe more than is useful, depending on how deep you want to go.

Execution in the VM

If you want to see output at the execution level: pointers, heaps, frame pointers, there's another debug constant you can activate. In vm.c, change the value of PROCDEBUG to a non-zero value:

#define PROCDEBUG 1

Apparently, this causes segmentation faults out of the box, but by commenting out some stuff I was able to get it compiled. This causes an output like so:

---
envptr: 0x100482f48
orphan: 0x100887358
inheap: 0x0
lfp:    0x100482f48
dfp:    0x100482f48
:1:in `require': cannot load such file -- rubygems.rb (LoadError)
  from :1:in `'

OK, not very enlightening still. Waiting for the ruby-core's feedback on that one.

By running these few commands on extremely simple programs, it seems to me that we can get a better insight into how it works.

Note: setting tabstop=8 (in vim, or tab = 8 spaces in other editors) gives you the proper incrementation for the Ruby source code. I had to find out.

The rise and fall of methodologies

2011-03-31T00:00:00Z

In my years as a software developer, I've seen several methodologies primed as the next big thing, the one way that would ensure a higher success rate of all software projects.

Let's see:

waterfall in large enterprise (ah, the scores of UML diagrams)
XP-scrum-agile
Kanban

There's an eternal hype curve, as with technology. Oh look, this will solve all our problems. Then some years laters, outcries because the results don't match the expectations.

Recently, there's been some backlash against dogmatic agile. Dan North's deliberate discovery is one, Fred George's Programming Anarchy (both good talks, both coincidentally ex-Thoughtworkers), or Zed Shaw's macho 'Programming, Motherfucker', a (hopefully) less serious one.

Here's the thing:

It's NEVER easy to drive a project.

Every project needs to be considered on its own, the task to accomplish, the shareholders, the team. Time needs to go into pondering how to handle each of these, how to navigate the ecosystem.

I know we, as developers, would like to be given the golden receipe. Laziness is our virtue, and we would like to have a clear algorithm so that we can just concentrate on the fun parts. And this makes us easy targets.

Gurus will not tell you about complexity.

I'm sure most gurus are genuinely convinced of what they're selling. They have worked in software, stumbled upon a good idea, and in their own context, applied it with the necessary creativity (hell, they were inventing), it works.

But they're also in the business of convincing (and maybe to sell books, courses, talks etc). That requires one-liners, clear and simple ideas. Theories that can be grasped immediately. They won't add multiple caveats to every simple statements, because that could be confusing and off-putting.

There are no easy receipes. Every practice needs to be assessed with a critical eye, and reassessed constantly. In some environments, with some people they'll work, and sometimes they won't, and then we need to think, ponder and improvise instead of sticking to the letter of any book.

Not saying that there is no value in existing methodologies. But the only methodology that works lives in the negative space between methodologies.
Read. Pick and mix. Use brains.

A bit like growing up - time to start relying on our own hearts and minds.

HTML5, pubsub and browser push

2011-02-02T00:00:00Z

I'm currently part of the team working on the prototype of an interesting web application. One of the features of this application is a constant message stream (think Twitter) pushed to the user.

The browser

In a first phase of the project we can count on a HTML5 enabled browser, so that allows us to use one of the options HTML5 offers for browser push, basically functionalities built in the browser which can be accessed with javascript. These are:

websockets: these sockets allow bidirectional communication

 var ws = new WebSocket("ws://websocket_host/websocket");

 ws.onmessage = function(evt) {
   doSomethingWithMessage(evt);
 }

 ws.onopen = function() {
   subscribe();
 }

 ws.onclose = function() {
   alert('whoops !  lost connection');
 }

obviously, the events callbacks should be modified to the desired action.

eventsource: one directional, push only

var source = new EventSource('/eventsource');

source.onmessage = function (event)
{
  doSomethingWithMessage(evt);
};

source.onerror = function (event)
{
  alert('whoops !  lost connection');
};

source.onopen = function (event)
{
  subscribe();
};

For older browsers (anything that is not Chrome, Firefox 4, Safari or Opera at the time of writing) the push mechanism needs to be replaced by long polling, i.e. a regular check for the resource.

The server

The interaction between browser and back-end is different from our usual client-server relationship. Essentially, the browser establishes a subscribe relationship to the server. Websockets create a bidirectional relationship, in that they both subscribe to something on server side but also publish back to the server (hence pubsub).

Your standard apache is not equipped for this, because it only handles classic request-response (as far as I can tell, I might be missing something). A server needs to be able to react to events: what is called an evented server. Added to that a publish-subscribe mechanism should be used, to dialogue with the browser.

I investigated two possible configurations, in Ruby: mongrel2 with ZeroMQ, and thin with cramp and redis. Node.js would certainly have been another option, but I stuck with Ruby since it might be easier for maintenance, for the time being at least (node might still be an alternative later).

Mongrel2 with 0MQ

I fell for 0MQ immediately, and will certainly be considering it for future projects, because it has a nice bare-bones feel to it. It aims to supercharge existing sockets and connections. It also has easy ruby bindings.

A 0MQ socket is what you get when you take a normal TCP socket, inject it with a mix of radioactive isotopes stolen from a secret Soviet atomic research project, bombard it with 1950-era cosmic rays, and put it into the hands of a drug-addled comic book author with a badly-disguised fetish for bulging muscles clad in spandex.

Mongrel2 is another story. While I like what it promises, the documentation is a bit sparse, and I had to dig through the internets to get my configuration right. Mongrel2 integrates with 0MQ. It offers handlers, which can be managed with Ruby. Mongrel2 is language agnostic, and stores its configuration in sqlite3. People who have looked at the code (I haven't yet) tell me it's clean and well-structured.

Mongrel2's basic config offers publish and subscribe handler, to have the bidirectional communication with the websocket. Good examples here.

So I got it running, but it took a certain amount of pain, especially in getting routing right.

But it works: mongrel2 creates 2 handlers (0mq queues with pubsub) to interact with the websocket. These 0mq sockets can be connected to from any other process, and that other process can publish any data it needs to push the browser, and handle any messages that come in. Excerpt of mongrel configuration:

root_dir = Dir(base='html/', index_file='index.html', default_ctype='text/plain')

esupdates = Handler(send_spec='tcp://127.0.0.1:9999', send_ident='54c6755b-9628-40a4-9a2d-cc82a816345e',
                    recv_spec='tcp://127.0.0.1:9998', recv_ident='')

routes = {
    '/websocket': esupdates,
    '/': root_dir
}
(...)

Since the code of the corresponding ruby handler is a bit long, I put a bare-bones commented handler in this gist.

Redis with Cramp and thin

In the meantime, I'd found another, pure ruby example in the Redis documentation.

Basically, cramp is a layer on top of sinatra which adds the functionality to talk with websockets. It makes writing a controller for the websocket blindingly simple, by adding a couple of handy callbacks. Sinatra (well, Rack) can then run on top of thin, which is an evented server. You need to use the edge version of cramp at the moment, because older versions have MySQL dependencies. The ORM has been removed in newer versions to just leave the controller DSL.

This choice ended up winning, because Redis is also used in another local project so the know-how is there. The fact that configuration and use were extremely simple and in ruby contributed to the choice. It also turned out that having named pubsub channels and the ability to subscribe based on a regular expression fitted well with our problem domain.

Redis has a lot of good functionality combined with a friendly programmer interface: we also use the sets, sorted sets and the key-value store. It's blazingly fast. Check out the interactive tutorial if you haven't played with it yet. The maintainer, Salvatore Sanflippo is a nice guy (being paid by VMWare to work on his stuff full time), which always helps.

The principle is basically the same as for the mongrel2 setup: starting a sinatra-cramp app on Thin with eventmachine, which will listen to the browser and publish to it. Cramp provides a number of callbacks to handle incoming messages.

require 'sinatra/base'
require 'cramp'
require 'yajl'
require 'daemons'

class ApplicationStreamController < Cramp::Websocket
  on_start :create_redis
  on_finish :destroy_redis
  on_data :received_data

  def create_redis
    @pub = EventedRedis.connect
    @sub = EventedRedis.connect
  end
  def destroy_redis
    @pub.close_connection_after_writing
    @sub.close_connection_after_writing
  end

  def received_data(data)
    msg = parse_json(data)

    # handle received data here
    case msg[:action]
    when 'join'
      handle_join(msg)
    end
  end

  # message channel is the redis channel which the socket subscribes to
  def handle_join
    @sub.subscribe(msg[:channel]) do |type, channel, message|
       render message
    end
  end

end

Redis is used in this example as the publish-subscribe pipe to make any other process send information to this process, which is then pushed to the browser. I'd like to add the functionality to talk with Eventsource to Cramp (instead of websockets), since we only push to the browser - I'll see if I find the time.

Update: people suggest using em-hiredis for non-blocking redis, and the slimmer em-websocket instead of going through the layers of cramp. Sounds interesting, and I'll definitely investigate. socket.io is rumored to provide graceful degradation from the html5 features.

Ingredients for browser push:

javascript websocket or eventsource in the browser
back-end evented server to interact/react to pubsub
back-end mechanism that speaks the right http to push messages to the browser

Two possible configurations were presented here, one with mongrel2 and zeromq, the other with sinatra/cramp on thin and redis.

Tail call optimization

2010-11-23T00:00:00Z

Tail call optimization: when in recursion, you can just reuse the stack of the recursive function you're calling again and again, instead of creating a new stack every time. This means saving memory and gaining speed, and that count for a lot when you're, say, calculating a large fibonacci number.

Now I'd been told time and again that Ruby doesn't do that out of the box, unlike languages like Lisp and Erlang.

Today, I saw this tweet by Jim Weirich, where he pointed to a blog post implementing tail call in Ruby. The code is very clever - it took me a good few minutes to parse it. Have a look for yourself, it's worth it !

Coincidentally (note: not so coincidentally after all, the person reporting the bug, Magnus Holm, is also the person having posted the blog), this very morning ruby-core closed an issue, showing a feature on ruby 1.9 I didn't even know existed: the possibility to tell the VM you want tail call !

To use the same example used in the beautiful ruby code I referred to

 RubyVM::InstructionSequence.compile_option = {
  :tailcall_optimization => true,
  :trace_instruction => false
}

RubyVM::InstructionSequence.new(<<-EOF).eval
class TCOTest
  # tail-recursive factorial
  def fact( n, acc = 1 )
    if n < 2 then acc else fact( n-1, n*acc ) end
  end

  # length of factorial
  def fact_size( n )
    fact( n ).size
  rescue
    $!
  end   
end
EOF

The performance of the vm-based tail call seems to be slightly better than the ruby one, as could be expected.

How does it work:
The main difference seems to be in compile.c, in the function responding to the friendly name of iseq_peephole_optimize.
As far as I understand, this function deals with a linked list of binary instructions (corresponding to the program), and tries to optimize its execution by introducing some shortcuts where appropriate.

The relevant code (iobj is the linked list of instructions):

if (do_tailcallopt && iobj->insn_id == BIN(leave)) {
  /*
   *  send ...
   *  leave
   * =>
   *  send ..., ... | VM_CALL_TAILCALL_BIT, ...
   *  leave # unreachable
   */
  INSN *piobj = (INSN *)get_prev_insn((INSN *)list);

  if (piobj->insn_id == BIN(send) &&
      piobj->operands[2] == 0 /* block */
      ) {
      piobj->operands[3] = FIXNUM_OR(piobj->operands[3], VM_CALL_TAILCALL_BIT);
  }
}

If we're in the right situation, the instruction gets a VM_CALL_TAILCALL_BIT. We find our friend the tailcall bit in vm_insnhelper.c in vm_setup_method

VALUE *sp, *rsp = cfp->sp - argc;
/* ... */
rb_iseq_t *iseq = me->def->body.iseq;
/* ... */
sp = rsp + iseq->arg_size;

if (LIKELY(!(flag & VM_CALL_TAILCALL_BIT))) {
  /* ... */
  /* clear local variables */
  for (i = 0; i < iseq->local_size - iseq->arg_size; i++) {
      *sp++ = Qnil;
  }
  vm_push_frame(th, iseq,
          VM_FRAME_MAGIC_METHOD, recv, (VALUE) blockptr,
          iseq->iseq_encoded + opt_pc, sp, 0, 0);
    }
  cfp->sp = rsp - 1 /* recv */;

} else {

  VALUE *p_rsp;
  th->cfp++; /* pop cf */
  p_rsp = th->cfp->sp;

  /* copy arguments */
  for (i=0; i < (sp - rsp); i++) {
      p_rsp[i] = rsp[i];
  }

  sp -= rsp - p_rsp;
  vm_push_frame(th, iseq,
          VM_FRAME_MAGIC_METHOD, recv, (VALUE) blockptr,
          iseq->iseq_encoded + opt_pc, sp, 0, 0);
    }
}

iseq contains the method instruction sequence. rsp contains the stack pointer of the control frame minus the size of the given arguments. sp contains the rsp augmented with the new methods' arguments size.
In the case of tailcall optimization (else) the next frame gets rewritten to the method instructions, else a frame gets pushed normally.
As far as I understand. I'm not blown away by the naming of the variables or the structure, though I can't claim I would have done an any better job since I'm not that familiar with the subject matter.

Since this tailcall optimization is an option and not a default, and since it's not one that is widely publicized (to my knowledge) (although I did find some threads when googling), I'm guessing that it's either experimental or that there are some downsides to it. Does someone know ?

Update: Magnus Holm (@judofyr) added notes in his blog post about this feature, and also benchmarking between about 5 ways to implement this ! nice.

Rubyconf 2010

2010-11-14T00:00:00Z

Last few days I attended (and spoke at) Rubyconf. It was the 10th edition, but the first time I did attend.

Excellent conference. A good level of presentations, a city that seems made for partying, warm and clear weather. Kudos to Chad Fowler, Kelly Jeane and crew for making it such a success. I met lots of people, and was glad to see others I'd met at Railsconf in june.

I was giving a talk about concurrency with Eleanor McHugh. It was a challenge in 2 ways:

first time I presented with Ellie, also the first time for me to present with anyone else at all.
it's such a vast subject there is too much to say for a 45 minutes session.

As we found out, Ellie and I have very different presentation styles. She told me that she prepares slides, but basically ignores them to launch into inspired improvisations. Being the hacker she is, this leaves most people in the dust but is extremely interesting to those who can keep up.

I, on the other hand, have to prepare. I like to rehearse the whole presentation at least 3 times, if possible in front of others. If I don't I have trouble finding my words, english not being my native language. I forget part of the things I wanted to say. I've found careful preparation allows me to give decent presentations.

The result of the combination was a bit unsatisfactory for both of us: she probably felt constrained by the prepared slides, and I felt woefully underprepared and more than a little bit nervous. You live and learn.

The subject, concurrency, is very interesting, fortunately. You can start from the hardware, dally at the VM, and go into language specifics. Playing around with different languages is great fun. Our slides are here. I'm pondering whether to open source all my experiments.

Where is the Global Interpreter Lock ?

2010-10-02T00:00:00Z

MRI Ruby and Rubinius are both blessed with what is called the Global Interpreter Lock. This means that only execute one thread can be executed at a time per VM instance (per CPU core). See also Ilya Grigorik's and Yehuda Katz's article on the subject.

This is not entirely a bad thing, since it means C extensions don't have to be thread-safe (thanks Benoit Daloze for the input). And as the wikipedia entry says, full concurrency can be achieved by spawning separate processes, which each have their own VM, and no shared state at all.

Rubinius is now getting rid of this lock in its Hydra branch. This is pretty cool, but it also means that all the C extensions you want to run concurrently will need to be thread-safe. Locks will have to happen at a more fine-grained level: if you need to modify a shared resource, it needs to be protected from indeterministic accesses by different threads.

But this aside, my aim in this post is to have a look at the MRI code, and see which bits of the code implement the lock. In ruby 1.9.2, MRI ruby uses native threads, POSIX threads for *nix (thread_pthread.c), and windows threads for win (thread_win32.c). The native interfaces are wrapped in thread.c.

Native threads have a mechanism to block access to a resource, which is called mutex (as in mutual exclusion).

So, which resource is protected in this case ? vm_core.h provides a hint in thread.c, you find the top comment:

model 2:
    A thread has mutex (GVL: Global VM Lock or Giant VM Lock) can run.
    When thread scheduling, running thread release GVL.  If running thread
    try blocking operation, this thread must release GVL and another
    thread can continue this flow.  After blocking operation, thread
    must check interrupt (RUBY_VM_CHECK_INTS).

vmcore.h:

#if RUBY_VM_THREAD_MODEL == 2

Ruby always has a 'current thread'.

RUBY_EXTERN rb_thread_t *ruby_current_thread;
extern rb_vm_t *ruby_current_vm;

The entry point of Ruby is, of course, main.c. main calls (amongst others) ruby_init (eval.c), which calls (amongst others) Init_BareVM. There we find rb_thread_set_current_raw(th), which is defined as

#define rb_thread_set_current_raw(th) (void)(ruby_current_thread = (th))

The actual thread creation happens in Init_native_thread, a bit lower in Init_BareVM. This is a call to the native library to create a thread.

Nearly every function in the VM (vm.c) starts by getting a thread GET_THREAD(), which gets the current thread to work with.

#define GET_THREAD() ruby_current_thread

There are a few mutexes in the Ruby source, but it's hard to miss the one used for the global interpreter (or VM) lock, thanks to the thread struct member being locked on: global_vm_lock.

At load time, the mutex in question is initialized (thread.c) in Init_Thread:

    /* init thread core */
    {
        /* main thread setting */
        {
            /* acquire global vm lock */
            rb_thread_lock_t *lp = &GET_THREAD()->vm->global_vm_lock;
            native_mutex_initialize(lp);
            native_mutex_lock(lp);
            native_mutex_initialize(&GET_THREAD()->interrupt_lock);
        }
    }

At thread scheduling (thread.c) in rb_thread_schedule_rec: grab current thread and unlock the lock, run the Thread block, and then relock the lock on current thread again.

    thread_debug("rb_thread_schedule\n");
    if (!rb_thread_alone()) {
        rb_thread_t *th = GET_THREAD();

        thread_debug("rb_thread_schedule/switch start\n");

        RB_GC_SAVE_MACHINE_CONTEXT(th);
        native_mutex_unlock(&th->vm->global_vm_lock);
        {
            native_thread_yield();
        }
        native_mutex_lock(&th->vm->global_vm_lock);

        rb_thread_set_current(th);
        thread_debug("rb_thread_schedule/switch done\n");

The function thread_start_func2 (in thread.c) is called at thread creation:

/* ... */
    native_mutex_lock(&th->vm->global_vm_lock);
    {
        thread_debug("thread start (get lock): %p\n", (void *)th);
        rb_thread_set_current(th);
/* ... */
/* and at the end : if the thread is not the 'main' thread, it releases the mutex */
    if (th->vm->main_thread == th) {
        ruby_cleanup(state);
    }
    else {
        thread_cleanup_func(th);
        native_mutex_unlock(&th->vm->global_vm_lock);
    }
/* ... */

Interesting factoid: it seems to be possible to run bits of code without GVL, in a 'blocking region'. I think this fact is not widely advertized because, as mentioned earlier, anything you want to run that way needs to be thread-safe.

/*
blocking region to release GVL
  rb_thread_blocking_region - permit concurrent/parallel execution.
 
  This function does:
    (1) release GVL.
        Other Ruby threads may run in parallel.
    (2) call func with data1.
    (3) acquire GVL.
        Other Ruby threads can not run in parallel any more.
*/

For my next blog post, I'll try to do a similar analysis for Rubinius, and how they managed to make a branch that is GVL-free. I needn't add that JRuby, since it benefits from the JVM threading, has never had a global interpreter lock at all.

Why I like giving talks

2010-09-27T00:00:00Z

I've had great news last week: the proposal Ellie McHugh and I made was accepted for Rubyconf ! This means I have 3 confirmed speaking engagements this fall, all around the same topic: concurrency. Once in Amsterdam at RubyAndRails, once in Ghent, at arrrrcamp, and then at Rubyconf.

Why speak at all ? It means tons of extra work, the preparation, the slides ... and there's no immediate return on investment - it actually costs you money, traveling doesn't come cheap. I'm also a fairly shy person, so there's some nerves involved. I'll tell you my reasons:

I usually pick a topic that interests me, and take it as an opportunity to dig into it until I know all I possibly ever wanted to know about it. Take concurrency: I'm reading about threads, CPUs, architectures, writing examples in different languages, academic papers, blog posts, mailing topics ... Nothing to sharpen the mind and create an incentive like the prospect of having to talk about it in front of a group of experts.
the talk grows organically, as does your knowledge of the subject, every time you give it. You get questions, feedback, new tracks to research.
you get to meet lots of people. The other speakers, who are often the programmers whose projects we use every day. But also other devs, who come up to you to discuss things after you talked.
well, I won't lie, you also get your name about, of course. As long as your talk is decent, that is.

Anyway, I'd really recommend it. If you have something to say, and you feel like those reasons would apply to you too, why not give it a try ?

The distributed Facebook killer

2010-09-17T00:00:00Z

Last spring, 4 students launched a new project called Diaspora. Their ambition was to create a distributed social network: everyone has their own node, and has total control over their data and how they decide to share them. They were asking for donations via the Kickstarter platform.

As it happened, they had the right idea at the right time, as Facebook had just changed their privacy policy in a murky, vaguely threatening way, which made many geeks very suspicious.
Plus, it sounded cool, right ? Never mind that this kind of projects had been floating around for quite a while.

So they hit the jackpot, and got more than 100,000 dollars to start working on their idea.

Fast-forward to this week. Their work, a Rails3 project, is open sourced on github. There's much loud disappointment in the developers' community, because there are almost no tests, the code's not that great, the license is wonky ... and generally, they were expecting something, I don't know ... more spectacular ?

Hello ? These are 4 inexperienced students. What are the odds that even one of them is a genius ? Will throwing money at them make it so ? They only had 4 or 5 months. The budget they got, while very decent seed money, is small change by Facebook development standard.

Let's not throw out the baby (distributed social networking) with the bath water just yet.

will someone just write a goddamned "social networking" protocol on top of XMPP already so people will shut up about diaspora. (aeden on twitter)

I'll go one further. The result should be deliverable as executables for (gasp) Windows and Mac, with large friendly letters and pretty, non-threatening icons. Because if you want your gran and the baker next door to replace Facebook with it, it'd better not be a bare Rails application.