Keynote: Objects on Trial
Michael Feathers – Object Mentor
Brian Foote – Laputan
Richard P. Gabriel – IBM Research
Joshua Kerievsky – Industrial Logic
Eliot Miranda – Cog VM
Dave Ungar – IBM Research
The opening keynote to QCon SF 2011 was a silly mock trial in which the original claims and alleged benefits of Object Oriented Programming were re-evaluated. A panel of experts, many of whom were involved in the early days of OO, were called on as witnesses to support or refute the charges laid against Objects. These charges include:
- Objects have not fulfilled their promises of promoting reuse
- Objects have not proven to make code more readable
- Static typing systems introduced with OO have negatively affected general performance and alienated dynamic language programmers, all for the sake of linguistic simplicity
- By encapsulating behavior and mutable state, Objects have not paid enough attention to concurrency and left the industry vulnerable to an ill-conceived ‘Neo-Functional Renaissance’
- The innumerable tools, products, and patterns that OO practitioners must master to be effective has raised the bar of skill and education required to a point that it is prohibitivly expensive to create state-of-the-art programs
The majority of the following discussion focused on the failures of object reuse and the misapplication of patterns.
The space shuttle was used as a metaphor for object reuse. The shuttle is a large, incredibly expensive piece of equipment. Now, the shuttle is reusable, but the cost of creating and maintaining the reusable spacecraft could easily exceed that of simply creating, launching, and discarding several disposable craft (ie. Saturn 5 rocket). The same goes for programming.
The cost of creating a reusable framework that is sufficiently generic for your predicted needs, configuring and using the framework in the instances when it is needed, and maintaining it’s backwards compatibility, could easily exceed the cost of simply rebuilding the specific piece of functionality required in each case (with a healthy dose of copy and paste). Instead of reusing code, the thing that gets reused much more often is patterns. Patterns have become the atomic unit of code reuse.
While on the topic of patterns, one of the contributing factors affecting the simplicity and cost of OO code is the overuse of patterns. By implementing general, extendable, patterns in every part of the target system, we have lost sight of simplicity. When programming, always be aware of the ROI of that particular piece of code. If it is an important, critical part of the system, spend the time and engineer it fully. If it is not often used or of low importance, don’t spend the time – the the most return for your programming dollar.
One () to Rule Them All – Clojure Script
Aaron Bedra – Think Relevance
Clojure Script is a web scripting language based on the Clojure programming language. Its fast compiler produces both server-side application executables and client-side scripts, using the Google Advanced Compiler, to compile from Clojure Script to minimal, fast Java Script.
Some current features of the Clojure Script language:
- html templating
- supports json and xml wire protocols for ajax
- browser connected REPL
Clojure Script is under active development, and not yet production ready.
See: Hiroku – an Amazon EC2 wrapper. Hiroku manages EC2 machine setup and configuration, so all you have to do is deploy your .war, instead of setting up a tomcat, apache, hadoop, etc.
Have your Cake and Eat it Too: Meta-Programming Techniques for Java
Howard Lewis Ship – Apache Tapestry
This seminar discussed the features of Tapestry Plastic – a new meta-programming framework by the folks who brought you Apache Tapestry. This framework functions like many other AOP tools, allowing you to add aspects and pointcuts to your code which are weaved into the bytecode after the compilation step.
Scaling Social Computing – Lessons Learned at Facebook
Robert Johnson – Facebook
During this seminar, Rob discussed several of the performance challenges faced by Facebook during their growth. Also, Facebook’s unique development culture contributes to a slightly different set of problems and solutions than in traditional dev shops.
Minimize the Cost of Failure
One of Facebook’s key principles is fast movement. They continually experiment, try out new features on the live site, and adapt their business and product to keep up with their competitors. This means they take more risk – usually in the form of frequent, small changes to the live site. Inevitably, one frequent small changes to the live site will have a bug. This is an accepted fact, in fact, no extraordinary effort is spent to ensure bugs never make it to the public site (long QA or UAT cycles do not exist at Facebook), as this would slow down development. Instead, extra effort is spent to minimize the cost of these mistakes. One mechanism used to achieve this is the Dark Launch.
A Dark Launch is a deployment process in which an app that has changed is brought up in a new cluster, parallel to the cluster supporting the current live version. The two parallel clusters sit behind an elastic load balancer. Once running, load is slowly slid over onto the new cluster.
If the new cluster performs as expected, it becomes the new live cluster. If problems occur, the load balancer simply shifts traffic back to the old version until the problem is solved. Having two (or more) versions of the code running in production at once apparently supports scalability and availability – Facebook considers software to be a Single Point of Failure. You can have as much parallel hardware as you like, but if everything is running the same software with the same bug, the entire system is a SPoF.
The essence of Facebook’s performance model is an enormous amount of random reads. Each Facebook page contains hundreds of pieces of data which must be read from various places in the Facebook data layer. To achieve this, they use clusters of memcached machines (with Flash Cache fast access modules) pulling data out of their databases (MySQL for non-transactional stuff and Cassandra for NoSQL needs). The data is modeled as a large graph of nodes. This graph is spread out over the vast storage network. As such, it is a challenge to partition.
One rule of thumb that Rob lives by while maintaining Facebook is “If something keeps you up at night, break it”. That is, if you feel a part of the system is fragile, break or overload it in a controlled way to determine both a) what the problem is and b) how to fix it. This removes any areas of uncertainty in the system, and contributes to confidence in operational processes.
A short video about Facebook’s release engineering process: https://www.facebook.com/video/video.php?v=778890205865&oid=9445547199&comments
StubHub – Scaling and Innovation at the World’s Largest Ticket Marketplace
Charlie Fineman – StubHub
Charlie runs the architecture group at SubHub.com, which is an extremely large online eCommerce site. This site, like others discussed at QCon, uses a horizontally scalable cluster of machines serving apps to customers, supported by a memcached data layer.
StubHub makes use of Solr as a searchable document store. It was chosen for it’s speed, expressive query language, and full text search ability, as well as having out-of-the-box geospatial searching and pluggable search facets. However, Solr does not perform as well as they’d like for things like frequent writes and replication. The flat document structure has also made storing graphs more difficult than desired. Also, searching based on computed ‘scoring’ mechanisms is difficult.
Debugging with a Request Dye
One debugging mechanism used by StubHub.com is to inject a unique ‘dye’ into every incoming request to the site. This dye is passed with the request through its entire trip through the system, and appended to the beginning of every log statement this request generates. Then, using Splunk, one can easily see everything that has happened due to a single request.
Rick Simmons – Rally Software
In this session, Rick gave an overview of how he and his associates at Rally ramp teams up on using Kanban in 48 hours. Basically, the process is tuned specifically for each organization in which it is to be deployed. The most important step is to understand how the team works before Kanban is introduced, then set up a system which fits well within that environment.