Sylvain Zimmer

Today my new company Joshfire opened its main product in private beta. After a few months of internal use, we think it will do for apps what WordPress did for blogs. Apps for the Web, for TVs, obviously for mobile devices, but also for tomorrow’s connected things.

I will probably blog about the technical aspects of the Factory in the near future (regular readers may have already guessed that all the apps are HTML5-based), but in the meantime you can request an invite, email me if you think you should get one ASAP, or read our developer blog.

My previous post about the ongoing death of Flash got a lot of support but also a few sceptics, which were obviously expected.

The halt of mobile browser Flash development by Adobe today is another milestone that directly confirms my two main points:

1. The number of valid use cases for Flash is shrinking fast. There are still some ones that make sense, don’t get me wrong, but they’ll get more and more specific as time goes by.
2. Adobe continues to demonstrate major courage and open-mindedness. I’m betting they’ll have one of the best HTML5 creative tools in a few years.

Image by jonathan mak

The first day Flash died was January 27th, 2010, when Steve Jobs announced the iPad. A few months later, in his Thoughts on Flash letter, he confirmed and explained why he saw the future of the mobile web without Flash. He was hardly alone in thinking so, but it remained somewhat controversial at the time.

Since then, tens of millions of iPads have been shipped and no other tablet manufacturer or mobile manufacturer has been able to ship a device with a decent Flash implementation. However, beyond the “Steve was right” mantra and the obvious trend towards HTML5, the forthcoming death of Flash still wasn’t consensual.

Until today. Adobe just bought two hugely successful HTML5 tooling companies, TypeKit and Nitobi (makers of PhoneGap). It is hard to imagine a stronger endorsement for HTML5.

I think October 3rd, 2011 will be remembered as the second day Flash died, this time by the hands of its owner.

Of course Adobe will still spin Flash as a convenient solution for some use cases, which will remain true for the next few years, but they clearly announced where they want to go next, and boy, I couldn’t be happier that it’s towards the open web. For this, I think we can all give credit to Adobe. Few companies this size would even semi-publicly admit their technology is a dead-end and invest so heavily in a more open solution.

Big cheers to them for that.

Disclaimer: I co-founded Joshfire, a company also deeply invested in HTML5.

Update: We’ve won Node Knockout in the “Completeness” category ! Congrats to the team!

How we got there

Many people are familiar with the SETI@home project: a very large scale effort to search for patterns from alien civilizations in the ocean of data we receive from the sky, using the computing power of millions of computers around the globe (“the grid”).

SETI@home has been a success, obviously not in finding aliens, but in demonstrating the potential of large-scale distributed computing. Projects like BOINC have been expanding this effort to other fields like biology, medicine and physics.

Last weekend, a team at Joshfire (Thomas, Nathan, Mickael and myself) participated in a 48-hour coding contest called Node Knockout. Rules were simple: code the most amazing thing you can in the weekend, as long as it uses server-side JavaScript.

JavaScript is an old but exciting technology, currently undergoing a major revival through performance breakthroughs, server-side engines, and an array of new possibilities offered by HTML5. It is also the language that has the biggest scale. Any computer connected to the web can run your JavaScript code extremely easily, just by typing an URL in a browser or running a script in a command line.

We decided to exploit this scale, together with Node’s high I/O performance, to build a large-scale distributed computing project that people could join just by visiting a web page. Searching for aliens was quickly eliminated as we didn’t have our own antenna array available at the time. So we went with a somewhat easier problem: Chess.

None of us is a particularly skilled Chess player. But as we discovered that there was an entry in the Guinness World Records for largest networked Chess AI at 2070 nodes, we realized it was definitely something we could beat. The Chess@home project was born!

48 hours later, the prototype still had a few bugs but was in a very playable state and looked like this:

Challenges of a distributed Chess AI

As we started doing research, we identified several challenging areas:

Latency. We wanted to follow standard tournament rules (~90min games) which meant each move should be computed in about a minute on average. Moreover, players on the web would prefer even shorter response times so we had to aim as low as we could.

This short compute window wouldn’t play well with most existing distributed computing infrastructures which typically optimize for throughput. We had to come up with a new, almost real-time infrastructure. Websockets would definitely be a part of the solution.

Parallelism. Optimizing for latency means sending smaller amounts of computation to each worker. So we had to find a simple way to divide the computation for each move into thousand of smaller pieces.

Without going too deeply in the specifics, the minimax algorithm used in most Chess AI relies on a tree walk which is inherently sequential when you want to do alpha-beta pruning. We researched various algorithms that would be suited to parallelism keeping the following in mind:

• The workers shouldn’t rely too much on shared variables because websockets don’t work from client to client (going through a server wouldn’t scale).
• The work for each move should be divisible in thousands of smaller units.

We found two potential matches : APHID (simple, used in ChessBrain.net, current holder of the Guinness Record) and variants of YBWC (more complex but more efficient). Given the 48h coding limit, we chose to go with APHID for the time being.

JavaScript performance. State-of-the-art Chess AIs are able to scan more than 15 million nodes per second (NPS) on today’s high-end hardware. GarboChess, the open source JavaScript Chess AI we forked, had performances around 100k NPS under Chrome with a modern Macbook Pro. This 150x factor didn’t surprise us that much and in our 48 hours we decided not to invest time into profiling and optimizing this code which was already capable of beating us on only one machine anyway ;-)

For reference, it is said it took 200mm NPS for Deep Blue to beat Kasparov, which would be theoretically achieved in our 2070-node goal.

Fault tolerance / Security. Running JavaScript code on third-party clients means they can’t be trusted, both for availability (the users can leave the page at any time) and for reliability (malicious clients could send wrong scores and make the AI play dumb moves).

Reliability was ruled out-of-scope in the initial run but availability seemed important if we wanted the algorithm to finish on time without missing obvious paths in the decision tree. We settled on a FIFO queue for the work units stored in a MongoDB server. We set a timeout of 5 seconds on each work unit so that a second worker could grab the unit and recompute it if the first worker didn’t send anything back.

Our 48h prototype implementation

Here is an overview of the prototype design:

Let’s focus on some key components:

• dnode. A Node.js library for asynchronous bidirectional remote method invocation. It provides network socket and websocket-style transports (via socket.io) so that system processes can communicate with each other and with processes running in browsers using the same interface. We used it for nearly all network interactions.
• Web Workers. JavaScript is a single-threaded environment, meaning multiple scripts cannot run at the same time without risking a UI freeze. Web Workers allow us to fire up long-running scripts to handle computationally intensive tasks, but without blocking the UI or other scripts to handle user interactions. On the server-side we used node-webworker (a Web Workers implementation for Node) so that we had only one interface to talk with the AI.
• MongoDB. MongoHQ was a sponsor of Node Knockout and we decided to use their turn-key MongoDB instances for storing game states and the potentially huge position cache.
• Node. Central to the architecture, Node allows both fast development (sharing the same code on client and server) and high performance (its non-blocking I/O paradigm has been proved to provide excellent concurrency and throughput).
• Local AI on master. This will probably not scale but we still make a few calls to the AI on the server, mainly because APHID needs to generate a small tree first to divide the work between the clients. It may be removed in the future.

Future improvements will be made on this implementation, remember that it was all done in 48 hours. But launching the AI inside Web Workers, both in browsers and servers will remain the basic design idea.

What lies ahead

Widget ethics. Using third-party processing power has usually been opt-in: people needed to install SETI@home or the BOINC software to lend their CPUs. JavaScript allows us to use people’s CPUs without their explicit consent just when they visit a page with the widget, which makes this a grey area.

We decided to allow people to opt-out with a checkbox but widget adoption on third-party websites remains a major challenge towards the 2070-node goal and we will do our best to answer any complaints or objections people might have.

For instance, as we use “public” resources, we definitely want to keep the result as open as we can. The code will remain open source on GitHub (code release this week). We might also open an API to the Chess AI.

AI improvements. After smashing the few remaining UI bugs, we’ll continue optimizing the AI in several areas:

• Better parallelism: We plan to switch from APHID to YBWC to have a more elastic work split between workers. This is critical given the low performance of JavaScript: we must compensate it by very efficient scaling.
• Unit tests: We’ve already unit-tested a couple hundred positions but there are a lot more datasets available on the web that we should integrate like STS.
• Algorithmic improvements: GarboChess already implemented alpha/beta pruning, null-window searches, quiescence search, and a few other features but fine-tuning the evaluation function and adding more tweaks to the AI should make it play better in more situations.

Planning for D-Day. When the AI is strong enough, we’ll invite an actual french Chess Grand Master along with a Guinness official for the most epic Chess game, ever!

We need to coordinate for the maximum of people to join the compute grid at the same time. Installing the widget on a few high-traffic websites could do the trick. We also want people to be able to watch the game on the Chess@home page so that they also join the grid.

If you have other ideas on how to get the maximum number of people connected, please share them! We’re also looking for talented JavaScript developers to help in all the fields described above.

If you want to help you can also have a look at the current list of issues and try to find new ones on Chess@home. Good luck beating the Grid!

How crazy is this !! ;-)

By now if you’re as RSS-addicted as me you’ve probably seen the excellent “How to remain calm” Chrome OS video. Like the previous potato-powered Chrome ad, excellent job from the marketing guys at Google!

However this time with my fellow geeks at Jamendo we noticed an equation hidden at 2:23 in the video. We then proceeded to lose several hours of productivity running it through Wolfram Alpha…

All we got was X = 900.91/191605050401140404051920181525 ~= 4.7*10^-27 and we were not even sure of this one number because of barely readable numbers in the original video. At this point we were quite sure that there was something to find (and hopefully to win) but still had to find a way to give a meaning to this number.

The first path we explored was in Physics, 1.66*10^-27 being the atomic mass constant u. Having X=2.83u didn’t make much sense: too far from 2.0x or 3.0x where the closest elements I knew are. Then my friend Joachim Rambeau tipped me off with an idea on “Chrome UX” being the name of the team that released the video. There was an X in there! With the equation X=(U/Chrome), U being the mass of Uranium (~238u depending on isotopes) and “Chrome” the mass of Cr-48 or related isotopes, we found ourselves very close to the 4.7 ballpark. I posted this as a comment in the video, without much hope of it being the definite answer.

So we left this for a few hours and got back to work. Funny coincidence? The current work at Jamendo is actually building a Jamendo Pro player on cheap Android tablets ;-) So we didn’t quite leave the Google world…

Anyway, while having drinks at the office at the end of the day (Yes, Jamendo is almost as cool to work at as Google) , we realized “900.91″ did actually reference the goo.gl url shortener. The division obviously meant a slash in an URL, and then we had to make sense of the 191605050401140404051920181525 to find an URL. But the excitation was growing, we knew we were on the right path this time!

Unfortunately, at this point I had to leave and go catch a TGV back to Paris. I’m actually still on the TGV as I’m writing this, thanks to Android tethering ;-) Anyway, I tried to convert the 30 numbers into 4 characters, like all goo.gl URLs. Didn’t have much luck, I was trying to prepend “00″ at the beginning to have 32 characters, but couldn’t make sense of the resulting sequence “00191605 05040114 04040519 20181525″.

That was when I noticed there were far too many zeroes in that sequence, even without the ones I added… So I tried different splits, and ended up with “19 16 05 05 04 01 14 04 04 05 19 20 18 15 25″.

There, any geek would have known what to do! I translated it to letters and got “s p e e d a n d d e s t r o y”. Obviously, at this point my fingers were very shaky! But I managed to type goo.gl/speedanddestroy in my browser and got to a form telling me that I was the “first to figure out our MENSA-certified puzzle” and would receive a Cr-48. WIN ! ;-)

Here is a screenshot of that page:

I think I was indeed the first because now the goo.gl link just says “The form you are trying to access has either expired or reached its maximum registration limit.”. Well, that’s pretty cool if you ask me ;-) (Funny details, while submitting the form, I crossed the Luxembourg/France border, the tethering went off and I started sweating they were going to check the IP address but I was still able to submit the form from France)

Big credits must go to the to the tech team at Jamendo: our genius lead developer Vincent who showed us the video first, our incredible Android hacker Mauro who helped me a lot with the actual equation, my fellow Jamendo Co-Founder Laurent and my own personal Physics expert Joachim Rambeau.

Anyway, congrats to Google for being such nerds. The video itself is really funny, embedding an easter egg is even cooler, and, well, most people I know including myself couldn’t go back to anything else than Chromium/V8 anymore.

I’m obviously quite happy to have won the Cr-48 notebook, I also hope Google may start giving a little more attention to Jamendo! If you pardon the plug, we’re the biggest Creative Commons music repository, and we’ve never succeeded inking a deal with YouTube about these hundred of thousands of CC music tracks (be it AudioSwap integration, proper CC attribution, revenue sharing, …). Let’s hope that will happen in the future!

PS: Hey Google, could we also have one of the destroyed notebooks to include in our gallery ? ;-)

PS2: The form says that I should live in the U.S. to receive the notebook but sorry that’s not the case obviously! I left the address of a U.S. relative but I can’t imagine it being a real issue just for one laptop. I’ll keep everybody updated as I get contacted by Google.

It has been 10 days since we left Oxford, time for a definite wrap-up ;-)

My recaps and highlights for each session

• Day 1 TEDx Workshop, Welcome Party
• TED University Session 2 Lee Hotz on Antartica, Ron Dembo on risk-taking
• Sessions 1 & 2 cartoonist Patrick Chappatte, Matt Ridley on “When Ideas Have Sex”
• Session 3: Found In Translation Ethan Zuckerman from Global Voices
• Session 4: Irrational Choices Sheena Iyengar on choice, Laurie Santos on banker monkeys, Maz Jobrani stand-up
• Session 5: Healthier Together John Hardy on the Green School
• Session 6: Different By Design Miwa Matreyek’s performance, Eben Bayer on growing packagings, plus our acclaimed performance of “Sweet Hurdy Gurdy Dreams”
• Session 7: Creatures Great And Small Marcel Dicke on eating insects
• Session 8: Adventures In Fairness Jessica Jackley from Kiva, Auret Van Heerden and Peter Eigen
• Power outage: The ED Conference Maz Jobrani returns
• Session 9: The Unknown Brains Sebastian Seung “I am my connectome”
• Session 10: Who’s the Teacher? Sugata Mitra on unsupervised learning, Chris Anderson on crowd accelerated innovation
• Session 11: The Tiny Blue Dot Jason Clay from WWF, Ze Frank, Dimitar Sasselov on exoplanets
• Session 12: Waging Peace Surprise speaker Julian Assange from Wikileaks

Other resources

• TED Blog posts about TEDGlobal 2010
• Official photos from TED
• Flickr photos
• Videos of the talks as they come online (17 as of now)
• A few more quotes from the speakers

Final tho