Archive for March, 2012


QCon Notes Part 2: The Future Application Platform

by Can Gencer

Unsurprisingly, there were several talks about the web and JavaScript at QCon. There is no doubt about the meteoric rise of JavaScript in the recent years, and it’s hard to imagine that this will not continue. Web browsers have been powered by JavaScript for years and more and more desktop applications are moving to the web. Node.js proved that JavaScript is as good as any other language for building a framework for web applications. Mobile web seems to be the next frontier and where progress seems to be among the fastest.

JavaScript Today and Tomorrow: Evolving the Ambient Language of the Ambient Computing Era

Allen Wirfs-Brock (Mozilla)

Download Slides

Allen is a Mozilla Research Fellow and was the project editor for the ECMAScript 5/5.1 standard.

Allen started off his talk by illustrating the two major eras in computing, the corporate computing era and the personal computing era. A major shift in computing happened in the late 70s and early 80s, where the shift to personal computers radically changed the nature of computing. Currently, we are undergoing another significant shift to what could be called the “ambient computing” era. Ambient computing has the characteristics of being device based rather than computers and being ubiquitous.

Every computing era had a dominant application platform. The dominant platform emerged as the winner through a combination of market demand, good enough technical foundation and superior business execution. The dominant platform for the corporate computing era was IBM mainframes. In the personal computing era, the dominant platform was the combination of Microsoft Windows and Intel PC (much lovingly called Wintel). In the emerging ambient computing era, it is becoming clear that the new application platform will be the web.

Each computing era also had a canonical programming language – COBOL/Fortran for mainframes and C/C++ for personal computing. The canonical language for the web and thus the ambient computing era appears to be JavaScript. Allen brought up the interesting question about what could replace JavaScript and how that could happen. JavaScript, even with it’s quirks is “good enough” and there doesn’t seem to be any apparent way that it would be replaced by anything else. As such, his claim that “JavaScript will be the next canonical language for the next 20 years” seems spot on.

After the ECMAScript 4 fiasco, TC-39, the committee responsible for deciding the future of JavaScript, is moving a lot faster and is more driven and organized to improve the language. There are a lot of improvements to the JavaScript language coming with ECMAScript Harmony, which represents ECMAScript post version 5. Some might be considered controversial, such as the inclusion of classes, and are ongoing current discussion. Considering the slow browser adoption rate, even ES5 is not yet mainstream and will not be for a couple of years more. This unfortunately seems to be one of the biggest bottlenecks in moving the new ambient computing platform forward.

The Future of the Mobile Web Platform

Tobie Langel (Facebook)

Tobie is currently the chair of the Core Mobile Web Platform Community Group which is dedicated to accelerating the adoption of the Mobile Web as a platform for developing mobile applications. Tobie and his team at Facebook put a lot of effort into analysing the most popular native applications and finding out what capabilities were missing in web applications to make them on par with native applications in terms of user experience.

Facebook recently launched ringmark, a test suite aimed to accelerate the adoption of HTML5 across mobile devices and provide a common bar for implementations of the mobile web standards. Ringmark provides a series of concentric rings, where each ring is a suite of tests for testing mobile web app capabilities. There are currently three rings, however the intention is to continue the project by adding more rings as the capabilities of mobile devices increase.

Ring 0 is designed as the intersection of the current state of iOS and Android and 30% of the top 100 native mobile applications can be implemented using ring 0 capabilities.

Ring 1 includes features such as image capture, indexDB and AppCache. Browsers implementing ring 1 should be able to cater to 90% of the most popular native applications, most of which actually don’t or need utilize advanced device capabilities such as 3D. Tobie highlighted that getting ubiquitous ring 1 support should be the short term goal for mobile browser vendors and developers to drive mobile web adoption.

Ring 2 will fill the gap with the final 10% of applications, with things like WebGL, Web Intents and permissions. Ring 2 is aimed to be a longer term goal.

Mobile Web should also be able to achieve beyond 100% of the native apps, with capabilities such as hyperlocal applications (e.g. an application tailored to a certain local event) and deep linking.

Lack of standards for mobile web applications when it comes discoverability or manifest files was also mentioned as one of the hurdles that mobile web needs to overcome. It will be exciting to see how fast we will be able to reach there.

The Future Is Integrated: A Coherent Vision For Web API Evolution

Alex Russell (Google)

Slides (Built with HTML5!)

Alex is a TC-39 representative for Google and is also a member of the Chrome team. One of Alex’s missions has been to drive the web platform forward. He is as frustrated as the rest of us developers with the current state of fragmented support and slow progress.

WebIDL and JavaScript have a cognitive dissonance problem. DOM was specified as an API for the browser programmers rather than the actual consumers of the API who are the JavaScript/web developers. It was also devised at a time where there were expectations that other languages than JavaScript would be consuming it, and artifacts of such an ideal still persist in the API. Moreover, DOM does not conform to normal JavaScript rules. The DOM types cannot be extended or constructured. It is not possible to do a new HTMLElement() whereas it would be very useful for many scenarios.

As web applications have increased in complexity, the disconnect between application data and the browser model has grown making web development painful. The developers have been trying to solve this using frameworks such as Backbone.js, however they are not perfect. Alex outlined two proposals to W3C that seek to make web development easier.

Shadow DOM is a way to create web components by a browser provided API. Modern browsers include native controls, such as the standard HTML form components. These built in controls are isolated from the rest of the page and are only accessible through whatever API they expose. There is currently no API to create third party components with the same strong encapsulation enjoyed by the native components.

The other proposal is Model-driven Views which reminded me a lot of how Knockout.js works. MDV provides a way to build data driven, dynamic web pages through data binding and templating via native browser support.


Also interesting, but didn’t get the chance to attend:

Mobile, HTML5 and the cross-platform promise

Maximiliano Firtman

Download Slides

Wrap Up

The various efforts around HTML 5, JavaScript and the mobile web all point to an improved developer experience. The question is how soon will this future will arrive? Combined with browser vendors pushing updates aggressively and consumers changing mobile phones every 1-2 years, it might not be as far as it seems. Listening to the talks also confirmed my opinion that native mobile apps are only a stopgap solution and the future lies in HTML 5+ and JavaScript as the platform that will power applications in the future.


QCon Notes Part 1: The Rise of Erlang

by Can Gencer

Last week most of my time was spent at QCon London. QCon is an annual international software development conference in London that covers a broad range of topics within the software development world. After looking through the schedule for this year, I ended up spending a good chunk of my Red Badger Training Budget on the conference, and it was totally worth it. The conference was 3 days with a massive amount of interesting content. I will try to do a series of blogs to cover the topics which I thought were highly interesting.

One of the most prominent programming languages at the conference was Erlang. As Damien Katz said in his talk, Erlang is a language from the future, built perfectly to scale reliably to multiple processors and cores at a time such needs did not exist. I attended several sessions relating to Erlang, driven by my curiosity for the language.

Building Highly Available Systems in Erlang

Joe Armstrong

Download Slides

Joe Armstrong is the creator of the Erlang language. He gave an excellent introduction to what highly available systems are, and how such a system can be built. Highly Available systems have six rules that they need to follow.These are:

  1. Isolation
  2. Concurrency
  3. Failure Detection
  4. Fault Identification
  5. Live Code Upgrade
  6. Stable Storage

Erlang is a programming language designed to satisfy all these six rules. It is not a coincidence that some of the world’s most reliable systems have been written in Erlang.

Erlang programs consist of many small processes, which correspond to something between an object and a thread in terms of size. An empty process is around 300 bytes, and the Erlang VM is capable of hosting millions of such processes. Each process is completely isolated and communicate with each other through only messages. A failing process does not effect the rest of the system, and can easily be restarted by a supervisor process. The lack of shared memory and mutable state ensures that it is easy to produce very reliable code.

One of the highlights of the talk was this quote from Alan Kay:

“Folks —
Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to
focus on the lesser idea.

The big idea is “messaging” — that is what the kernel of Smalltalk/ Squeak is all about (and it’s something that was never quite completed in our Xerox PARC phase)….”

The key idea in OOP has always been messaging and encapsulation rather than classes or methods, which, unfortunately has been how OOP is being taught generally.

An interesting footnote from the session was when asked about his opinion about Node.js, Joe mentioned that he is not really fond of event based programming and the style of such programming is difficult.

Games for the Masses – How DevOps affects architecture design

Jesper Richter-Reichhelm (Wooga)

Download Slides

Jesper works for Wooga, a German social gaming developer. While their cute Facebook games might not be terribly interesting for software developers, a backend for a single game deals with more than 20 million requests in a day and more than 100,000 DB ops in a second, which makes things a little more interesting.

Jesper outlined the journey Wooga took in terms of evolving architecture, where each new game gave them an opportunity to try something new and evolve their technology.

Starting with a traditional technology stack (MySQL/PHP/Ruby on Rails), the engineers at Wooga eliminated their database bottleneck first by using Redis and ultimately by switching from a stateless server to a stateful one.

To build a robust stateful server, they used Erlang, which brought in other problems such as code readability, testability and maintanability. Their ultimate solution to this was to use Erlang for the core parts of their backend and handoff data to small workers in Ruby using a message queue, which gave them the best of two worlds.

Jesper emphasized how the Wooga’s focus on small teams, collaboration, generalists, effort reduction and innovation paid off in spades in their journey to become the 2nd biggest social media games development company.

Building Distributed Systems with Riak Core

Steve Vinos (Basho)

Download Slides

Riak is a distributed database which is roughly based on Amazon’s Dynamo paper. It is similar to NoSQL databases such as Cassandra, CouchDB and Voldemort. Riak Core is a seperate component from Riak DB, and deals with the distributed systems aspect of Riak DB.

The session was a deep dive into how Riak Core implements availability, eventual consistency and partition tolerance, which are the three key aspects of any distributed system. Possibly one of the most technical sessions that I’ve attended at QCon, it was an inside look into how a distributed system works and how Riak Core solves many of the problems such systems encounter.

Not surprsingly, Riak Core is written in Erlang, which makes messaging across distributed system easy since Erlang processes communicate the same with each other the same regardless of if they are residing on the same machine or not.

Lot of the times we as software developers take for granted that the systems we use should just “work”. This abstracts the underlying complexity away from us and makes easier to think in our problem domain. However, having a little insight into how a complex distributed system works under the hood is always interesting and good to know.

Erlang in the real world: CouchDB

Damien Katz (Couchbase)

Download Slides

Damien is the original creator of CouchDB, a document oriented database written in Erlang. Having worked with Erlang for a real application, he shared several of his observations.

  • Erlang is simple: the core of the language is small; there are very few types, no classes and no object orientation.
  • Erlang is weird: It has a syntax influenced by Prolog, which nobody uses and is nothing like other programming languages.
  • Erlang is extremely productive: You can be very productive with it and produce small, reliable code once you come to grips with the syntax.
  • Erlang is built for the current reality: The Erlang model of isolated memory and processes is closer to the current reality than the shared memory space most programming languages use for the current multi core architectures.

However, it has a caveat: Erlang performance is slow. The Erlang VM, while beautiful in design is not as fast as other VMs like the JVM. Damien linked the reason for this all the way to the strange syntax Erlang has. A language needs mass adoption and investment to be fast, and for this to happen it needs to be familiar to programmers. Erlang’s unfamiliar and “weird” syntax is preventing it from getting mass adoption.

Erlang is not a perfect fit for every problem, string processing being an example — but it is perfect for distributed systems that need to be reliabile.

A lot of the benefits of Erlang can be achieved in C/C++ by following certain practices, however will take as much as 5-10 times the coding effort, but 5-10 times the performance as well.

Damien’s new venture, Couchbase, uses a hybrid of Erlang and C/C++ because they simply cannot compete on pure performance with Erlang. However, an interesting point he made was that if you are running your own application, it might be cheaper to solve performance bottlenecks by simply spending more money on CPUs rather than on engineering time.

Wrap Up

Erlang, even with its quirks seems to be growing and in Damien’s session somebody mentioned that there is a new $5 million investment into the language to improve performance. Patterns found in Erlang can certainly be applied to other languages and help a software engineer approach problems differently. The programming language itself will no doubt continue to grow and be a major player in the concurrent future.