Part 1 of the series is here.
Sessions (Contd.)
Building Real-Time Web Applications with Lift
David Pollak, founder of Lift (an open source) Scala-based web framework, did a live demo building a chat application. I haven’t seen many sessions (that I attended) in the conference where the presenters did code demos. David pulled it off without major glitches. He developed a comet-based chat application along the way touching the concepts of Lift’s templates, snippets and Ajax support.
After the demo he went over some of the features of Scala and Lift. Lift applications are secure by default, and he mentioned that penetration testers are having tough time finding security vulnerabilities in the application. Some of the factors that makes this secure: Lift’s forms mechanism associates randomly generated GUIDs with form elements and functions. Risk of replay attacks is relatively low with Lift applications. Lift builds all web pages as well formed XHTML rather than a String or a stream of characters or bytes. Lift’s SiteMap provides unified menu generation and access control. All these and more actually makes the developers life lot easy by having them concentrate on the business logic of the domain and not on the underlying plumbing work.
Performance concerns with one of the applications built on Rails caused Pollak to think about a Scala-based web application utilizing the power of the JVM (which eventually improved the performance). Lift borrows a lot of good ideas from Rails and other frameworks into Lift.
Foursquare and Novell Pulse are mentioned as publicly available apps that are built using Lift. There are many more startups and enterprise applications building interactive applications using the framework.
Mint.com’s Technology Behind the Scenes: Practical Lessons for Scalable Web Apps
David Michaels and Daryl Puryear presented what turned out be one of my favorite sessions of the conference. Mint.com is world’s largest free personal financial application with four million users covering 40K zip codes and all 50 states of the USA. Currently hosts 20 millions financial accounts with over 15K financial institutions.
The speakers went over step-by-step how they built the foundation of quality and security, and went over each of the other aspects of the pyramid: performance, scalability, manageability and maintainability. They traveled back in the time and shared the excitement and environment at the launch time some time in 2006/7 time frame. During that time they have a well-defined feature set but with unknown traffic. They wisely invested in production performance monitoring. Doing this enabled Mint to be proactive and enable fast triage of the issues. Monitored only the expensive operations to keep the overhead low. They decided to build a monitoring application (rather than buying) as they have some in-house expertise. Used Spring’s auto-proxy feature. Aggregated results in memory and persist periodically. Simple interface was built on top to analyze the data.
Mint performed some performance tests and found that their database is the bottleneck (sounds familiar?). So they tuned the application code to reduce database usage. That brought only marginal improvement, and they hired services of an outside DB conultant who helped optimized the MySQL configuration, which ultimately removed the bottleneck. Lesson: small team can’t have all expertise, hire consultants occasionally.
Traffic continued to grow, there were major spikes after press coverage. Once again database scaling was the need of the hour. They did horizontal scaling with multiple smaller databases. Shards are based on user and they made every user independent with no refs between the users. Non-user data is separated into logical databases (user lookup, shared data, monitoring data, user data).
Mint made continuous investments into beefing up security. Standard items were covered like data encryption, penetration testing, automated security scans, multiple DMZs and secure datacenter. Mint also took care of their application architecture so that a developer mistake will not result in a security hole.
Apart from that they have demoed an application they built for triaging errors in application logs, which was interesting. Mint is using XMLC as part of their frontend! Overall this is a very informative session not just from the technology standpoint but also to hear a startup’s success story.
Ninety-Seven Things Every Programmer Should Know
Kevlin Henney and Kirk Pepperdine presented one of the entertaining sessions that I attended. Kevlin Henney in particular is an excellent speaker who knows how to present the message in an entertaining way.
If you haven’t read this book yet, here are those 97 things appeared in the book. Speakers chose sixteen out of the list for the talk:
Ubuntu coding for your friends – Aslam Khan; Do lots of deliberate practice – Jon Jagger; Know your IDE – Heinz Kabutz; Put the mouse down and step away from the keyboard – Burk Hufnagel; Code reviews – Mattias Karlsson; Read code – Karianne Berg; Comment only what the code cannot say – Kevlin Henney; Code in the language of the domain – Dan North; Prefer domain-specific types to primitive types – Einar Landre; The road to performance is littered with dirty code bombs – Kirk Pepperdine; Interprocess communication affects application response time – Randy Stafford; The longevity of interim solutions – Klaus Marquardt; Two wrongs can make a right (and are difficult to fix) – Allan Kelly; Testing is the engineering rigor of software development – Neal Ford; Write tests for people – Gerard Meszaros; The boy scout rule – Uncle Bob
One of my favorites is the boy scout rule interpretation for the code:
Always check a module in cleaner than when you checked it out.
This is one of those sessions that is difficult to summarize in a post like this. Checkout a video from the speaker on the same topic but at a different venue.
Simpler Scalability, Fault Tolerance, and Concurrency Through Actors and STM
Akka is a tool that you should seriously cosider if you are writing applications with high concurrency needs. Jonas Bonér, the founder of Akka, presented the concepts pertaining to its software transactional model (STM), actors and persistence mechanism. I have recently started evaluating various concurrency models, and this presentation is exactly what I needed for some concrete guidance!
Actor model was popularized by Erlang which emerged in mid-80s. Actor model is a higher level abstraction, for the developers working on concurrent applications, dealing with the traditional locking and thread management. Actors do not share state with the other actors. Each actor has a mailbox and they can only interact with other actors by sending messages. All processing is done asynchronously, actors do not block so they are excellent candidates for event-based applications. Akka actors are extremely lightweight, you can create millions of them on a single workstation. Jonas Bonér discussed the Java API, Akka has also got a Scala API.
Akka’s supervision model is inspired from Erlang. It goes by the “let it crash” approach implemented by linking actors. Akka’s approach is that failures do happen, don’t try to prevent them as they are inevitable. Your goal should be to make them fail soon and let a supervisor (who has a bigger picture) deal with it. A supervisor is an actor responsible for start, stop and monitoring child actors. Bonér discussed All-for-one (restart all the components that a supervisor is managing) and One-for-one (restart only the crashed actor) strategies.
STM model sees the memory as the transactional dataset. It can provide atomicty, consistency and isolation attributes to a transaction. Transactions are retried automatically after the collision. Akka STM is based on the ideas of Clojure STM, a compelling idea for providing transactional shared state. Akka also has pluggable storage backend currently supports Cassandra, MongoDB and Redis.
It is one of those sessions that I felt organizers saved the best for the last (day)!
