Ping Conference, Play Edition, Day 1
The program was organized in a single track, with each talk at around 50 minutes plus 10 minutes of questions. Every two talks there was plenty of time to get coffee and talk to speakers and attendees.
The ticket included high quality food (breakfast + lunch), drinks, and an after-party. What I really liked was the organizers’ attention to detail, for example the badge consisted of two cards, where the second one would contain the schedule.
Around 150 people from mostly Europe, but also the US and Australia, came to watch and listen to talks dedicated to our favorite framework. The attendees’ backgrounds were pretty diverse, long-time Play hackers vs. people who were only interested in it, developers vs. project managers, Java vs Scala, and so on3.
I think it’s rare to go to a technical conference and meet so many nice people. It was also interesting to put faces to the names of the guys who are active on Twitter, blogs, and the mailing list.
All in all, it was exciting to talk to people who share the same passion about this little web framework4.
Talks and Speakers
This conference didn’t have a single boring talk, each one offered many take-aways and bits and pieces. They also dealt with many different topics and originated from various backgrounds (as you’ll see later on). They included high-level Scala abstractions as well as practical challenges like how do you migrate PHP developers to Scala.
Another big plus was the fact that the guys behind Play were (nearly) all there. Everytime a question about Play internals or design decisions came up, the experts themselves would answer. I also made quite extensive use of this opportunity ans asked them many questions directly. Thankfully, I got detailed answers and gained a lot of new insights, some of whom I’ll try to share in this and the next blog post.
All of the talks can be watched online. In the following, I’ll give a short summary and also add some of the stuff I asked the speakers in person.
Keynote – Stream
Sadek Drobi (@Sadache), co-creator of the Play framework 2.0, talked about how Play came to be, and how functional programming influenced its very core abstractions. He started at explaining that the most powerful feature functions have to offer is composability, and you can see mapping an HTTP request to a response as a function call5, and how to maintain functional properties in various different contexts.
Talk 1 – Expanding Play to a Multiple JVM Architecture – Stream
Note: This was a replacement talk for Scott Clasen from Heroku.
Matt Hamer (@mthology) shared Gawker’s approach to scaling Play apps by running multiple JVMs (instead of just servers). Each JVM runs one part (i.e. module) of their Play application. This way you can load-balance easier by firing up more JVMs if one part of your app is receiving more load than others. It also allows you to isolate components and deploy them individually (so a bugfix only make one service go down for a short while instead of the entire system).
He then went on to explain their service architecture which is currently REST+JSON, but they are experimenting with Akka for messaging between services. For this they are unifying data using Protocol Buffers and a custom serializer (e.g. for data compression).
So far there is no clear winner between the two approaches. In terms of performance, Akka + ProtoBuffs should be faster. It however means that every app needs to consume services via Akka.
The first one is sbt-web, which offers the basic infrastructure, i.e. sbt settings and directory layout for web projects (independent of Play).
Christopher demoed the sbt-jshint-plugin which uses both sbt-web and js-engine to run JSHint from within Play (or sbt), and fully integrates with Play’s error reporting. The interesting thing about js-engine is that it can run both JVM-based engines (the default is Trireme) as well as natively running Node and thus achieve speed-parity for development (in his demo JSHint ran equally fast in Play and Grunt).
He rounded this off with a short intro to writing sbt plugins7.
Yann Simon (@simon_yann), a French guy living in Berlin, showed us how to refactor a "typical" Play app to a more modular architecture and this way introduced us to the Cake pattern. This was a multistep task, and concluded by actually merging traits to reduce some of the complexity and compilation speed issues. All this was presented using funny monster videos and a French-German accent.
Julien Tournay (@skaalf) and Pascal Voitot (@mandubian), both employees of Zengularity and active Play contributors, put on quite a show introducing us (again, French accents) to the ideas of entropy8 versus complexity. One take-away was that while entropy ("disorder", or "randomness") keeps increasing, complexity only initially increases and then decreases. This laid the foundation for what they called Entropic Design of web services, which should be polgylot, multichannel, and multiformat, providing a thin adaptive layer that protects the client from malformed data sources.
To achieve this, we must validate the incoming data, and transform it to the format our service is offering. Luckily, Captain FP will help us with this daunting task.
Back to Play, where the JSON and the form API currently solve a similiar problem, but in distinctive ways (complexity). These two APIs will be united in 2.3 to form a new API (more entropy, less complexity) that also allows to add new formats (via the new Rule typeclass). The API is slightly different from the JSON API, and very different from the forms API. You can check out this pull request for more info.
Afterwards there was quite a discussion about some of these concepts. Again, thanks to the authors being there, questions could be answered on a very high technical level.
Talk 5 – Writing a reactive web app with Scala.js and ReactJS – Stream
Matthias Nelsen (@matthiasnehlsen), well known for his blog posts about BirdWatch, showed us his latest findings in rewriting his chat app (to add some juice to the chat demo, he had some actors quote Romeo and Juliet) and BirdWatch using Scala.js and Facebook’s ReactJS.
$digest-cycle compares if an object has changed (via a
$$hash key) to update the UI. As we all know, when you ‘modify’ a Scala collection, you receive an entirely new collection and Angular tries to update everything, ultimately blowing up its internal stack (the dreaded
10 $digest() iterations reached. aborting exception). ReactJS on the other hand builds on the (functional) concept of immutable streams (Reactive programming principles anyonone?) and only expects a
key property to identify objects. This makes it the ideal framework to work with Scala.js. It also offers significantly better performance than Angular, thus being well suited for mobile development.
Talk 6 – Play2 and Redis: when simplicity meets productivity – Stream
Nicolas Martignole (@nmartignole) talked about his startup ZapTravel, built on top of Play, Scala, and Redis. He argued how Redis was offering better tools (in his specific context) to query for travel results depending on the user’s search parameters (for example, you can union different result sets together in the database).
He also talked about how it can be quite a challenge to find Scala developers, so they switched their hiring strategy to find good developers (with any language background) and train them on Scala.
The evening before the actual conference, the organizers hosted a Scala user group meetup to introduce people (both attendees and non-attendees) to Play.
The goal was to create an app that fetched tweets from Twitter, put them in Redis and stream them to a websocket. The individual tasks were split across several teams9. The app didn’t get finished, but it was nice to already meet some of the other attendees.
Well, that covers the first 1.5 days of this awesome conference. Day two coming soon!
Disclaimer: I don’t go to a lot of conferences, around two per year.↩
However not many women attended, I think I’ve seen like three.↩
Of course this is not a perfect analogy because HTTP requests are not necessarily idempotent.↩
They are also considering integrating Grunt with Play directly.↩
So far it looks rather complicated. I hope to blog about it in the future.↩