Main themes
From the sessions I attended, some of the main recurring technical themes in this conference were:
- Consistency should be traded for Availability in typical distributed systems
- Eventual consistency over ACID
- Always expect network failures, i.e. systems must be able to tolerate partitioning
- NoSQL
Most informative talks
The Rich Get Richer: Rails 3 :- Obie Fernadez
Obie gave a enlightening summary of the events leading to and the people involved in the merging of the Merb and Rails codebases, resulting in the newly released Rails 3.0. The main drivers behind the new release were decoupling, modularity and prevention of code bloat. Many components of Rails 2 had been abstracted out and managed as third-party plug-in projects. He described Rack, Bundler, Arel and the upgrade process from Rails 2.x to 3.0. I look forward to the day when I get the chance to put all these into practice.
Integrated Tests Are A Scam :- J. B. Rainsberger
Having written myriads of tests over the years, it was easy to lose sight of the different roles of tests in different parts of the system. JB gave an excellent refresher on two fundamentals of unit tests : interaction testing and contract testing.
Interaction tests were the "normal" unit tests that I've been writing, where the external dependencies were replaced with stubs/mocks . In the example, he described interaction tests for a client assessing an external supplier. These tests were concerned with the pattern in which the system-under-test (SUT) called out to the external system (mocked out), and how the SUT responded to various return values from the external system (stubbed).
Contract tests referred to tests that verified that an external system satisfied a certain API and expected behaviour, i.e. the contract. In a strongly-typed language like Java, this contract could be abstracted out from the actual implementation of the external system into a public interface, that our code could depend on. In fact, our code would only depend on this public interface, with no knowledge of the implementation. In a strongly-typed language, any implementation of this interface would then satisfy the minimum requirements of the contract, therefore, the real implementation could be replaced with a stub. As long as the stub passed the contract tests, it would in theory make no difference to our code. Hence, we could then write integrated tests for our SUT that used the stub instead of the real implementation, which would make such tests extremely fast.
Personally, I was not too convinced that interaction and contract tests could fully replace the need for integrated tests against real external systems. There would always be unexpected surprises lurking in system configuration, and some behaviour could not be adequately captured by the abstracted interface. Furthermore, in dynamically typed languages, it would be much harder to enforce that the stub fully implemented the public interface.
Designing and Implementing RESTful Application Protocols :- Ian Robinson
Ian walked us through an example from his new book, REST in Practice, to illustrate the interactions of a client program ordering coffee beans from a coffee supplier via a RESTful interface.
The client first asked the server for a list of allowed operations. After that, it requested a quote of available product prices. It then placed an order by resubmitting all the pricing data it had previously received back to the server. In this way, the client could maintain conversation state over a stateless protocol. A checksum of the data was used to prevent price tampering by the client. Finally, the server immediately returned a HTTP 202 response, before kicking off the long-running order fulfillment process asynchronously.
Ian explained several basic concepts such as the use of media types, link relations and XForms in driving the process flow.
I found Ian's talk to be clear and concise, therefore I'm putting his book on my wish-list.
Most interesting talks
Exploring NoSQL :- Erik Meijer
This talk started a bit a slowly with an (mostly unecessary) explanation of how an object graph was represented in memory using pointers. This type of representation was embodied by noSQL, whereas SQL embodied a fully normalized relational view of data.
Things became interesting when Erik started describing Category Theory. Erik reasoned that because the direction of parent-child relationships was reversed between SQL and noSQL, they were duals of each other according to Category Theory. In other words, noSQL was actually "coSQL", i.e. for any statement that was true of SQL, the dual-statement (opposite meaning) would hold true for noSQL. Some examples of this duality were:
SQL | noSQL |
---|---|
The identity is embodied in the row, i.e. primary key (extensional) | Identity of an object depended on other objects in the environment (intensional) |
Closed-world view of data | Open-world view of data |
Synchronous operations | Asynchronous operations |
A very interesting concept indeed. Furthermore, this talk had the most obscure slide ever...
Computational Information Design :- Ben Fry
This talk was worth attending just for the visual candy itself. Ben talked about data visualization using his Processing programming language (IMO really a DSL over Java 2D/3D). Some of the examples shown were really amazing, such as:
- Mapping the program flow in old cartridge-based video games
- Tracking changes to six editions of Charles Darwin's work
- Comparing the human genome with other mammals
Ben then introduced Processing.js that allowed code written in Processing to be run on any HTML5 compatible browser. People could simply go to sketch.processing.org to write and run Processing code all within a Web browser. What was even more exciting was a port of the Processing runtime to Android, which meant I could run Processing programs on my smartphone. Super cool!
Workshop
For me, the best part of the conference was the iPhone workshop. Having done some Android development, I was eager to see how things worked on the iPhone side. In this half-day workshop, I learned some basic syntax of Objective-C, basic usage of xcode IDE, some iPhone frameworks, and finally put together a simple iPhone application. My verdict of Objective-C :- dynamic typing and late binding were nice, but the extremely verbose syntax really sucked. I guess I'll stick with Android for now.
Regarding your comment "Personally, I was not too convinced that interaction and contract tests could fully replace the need for integrated tests against real external systems": I agree. I neglected to mention a quite fundamental point in my talk: programmers should not need integrated tests to show the basic correctness of their system, meaning that, if we had infinite resources and patience, we'd compute the right answer. I use integrated tests for system testing issues, like the ones you mention here, but not to show that my code computes the right answer in a perfect world. I think programmers would benefit considerably by not doing that any more.
ReplyDelete