Posterous theme by Cory Watilo

Operating Node.js in Production, with Bryan Cantrill

"Bryan talks about the challenges of operating Node.js in real
production environments and the experiences he had working with it at
Joyent. He also talks about DTrace, SmartOS, V8 and compares with
other platforms..."
Bryan Cantrill is VP of Engineering at Joyent, where he has led
development of Joyent's SmartOS and SmartDataCenter products.
Previously a Distinguished Engineer at Sun Microsystems, Bryan has
spent over fifteen years working on system software, from the guts of
the kernel to client-code on the browser and much in between.
http://www.infoq.com/interviews/operating-nodejs-production-bryan-cantrill

Games for the Masses

Games for the Masses (QCon London 2012)
View more presentations from wooga

"Building a backend for a successful social game is always challenging: It needs to service over 1 million users per day that generate 10.000 http requests per second or more whereas the vast majority of those requests are changing persistent state. Using a conventional technology stack that leads to over 50,000 database writes per second. Throughout the last two years half a dozen teams at Wooga have set out to build a backends for social games, each trying to improve on previous solutions. Each team was able to leverage experiences made by other teams but was free to choose their own technology stack and hosting environment. They also operated the game themselves in a DevOps way. This talk will trace back that evolution of backends: Starting out with a simple LAMP stack, first replacing PHP by Ruby, then replacing relational by NoSQL databases and ending up in maintaining stateful application servers utilizing Erlang OTP - and more. We will discuss limitations and problems we faced in live operation and show how later teams improved on the overall design..."

24/192 Music Downloads ...and why they make no sense...

"Articles last month revealed that musician Neil Young and Apple's
Steve Jobs discussed offering digital music downloads of
'uncompromised studio quality'. Much of the press and user commentary
was particularly enthusiastic about the prospect of uncompressed 24
bit 192kHz downloads. 24/192 featured prominently in my own
conversations with Mr. Young's group several months ago.

Unfortunately, there is no point to distributing music in
24-bit/192kHz format. Its playback fidelity is slightly inferior to
16/44.1 or 16/48, and it takes up 6 times the space.

There are a few real problems with the audio quality and 'experience'
of digitally distributed music today. 24/192 solves none of them.
While everyone fixates on 24/192 as a magic bullet, we're not going to
see any actual improvement..."
http://people.xiph.org/~xiphmont/demo/neil-young.html

lthread is a multicore enabled coroutine library written in C

"lthread is a multicore/multithread coroutine library written in C. It
uses Sam Rushing's _swap function to swap lthreads. What's special
about lthread is that it allows you to make blocking calls and
expensive computations inside a coroutine, providing you with the
advantages of coroutines and pthreads. See the http server example
below.

lthreads are created in userspace and don't require kernel
intervention, they are light weight and ideal for socket programming.
lthread scheduler uses a shared stack for all running coroutines to
save space, allowing you to create thousands(tested with a million
lthreads) of coroutines and maintain a low memory footprint. The
scheduler is hidden from the user and is created automagically in each
pthread, allowing the user to take advantage of cpu cores and
distribute the load by creating several pthreads, each running it's
own lthread scheduler and handling its own share of coroutines. Locks
are necessary when accessing global variables from lthreads running in
different pthreads, and lthreads must not block on pthread condition
variables as this will block the whole lthread scheduler in the
pthread..."
https://github.com/halayli/lthread

Bayes' Theorem Illustrated (My Way)

"(This post is elementary: it introduces a simple method of
visualizing Bayesian calculations. In my defense, we've had other
elementary posts before, and they've been found useful; plus, I'd
really like this to be online somewhere, and it might as well be
here.)

I'll admit, those Monty-Hall-type problems invariably trip me up. Or
at least, they do if I'm not thinking very carefully -- doing quite a
bit more work than other people seem to have to do.

What's more, people's explanations of how to get the right answer have
almost never been satisfactory to me. If I concentrate hard enough, I
can usually follow the reasoning, sort of; but I never quite "see it",
and nor do I feel equipped to solve similar problems in the future:
it's as if the solutions seem to work only in retrospect.

Minds work differently, illusion of transparency, and all that..."
http://lesswrong.com/lw/2b0/bayes_theorem_illustrated_my_way/