In 2013, Rafael Ördög put poker and code together, the result: Lean Poker, a competitive coding event that teaches continuous deployment and lean startup methodologies. Rafael is based in Budapest, Hungary.
What's Lean Poker?
Lean Poker is a coding workshop that is designed to teach people how to practice continuous deployment and lean startup methodologies. Companies can sponsor a free public event or hold an internal, team-building event for their own employees.
The basic starting code is really simple and teams can use the language of their choice. The challenge is not to understand an existing code base but to modify it—to build a new app. Teams must iterate their app quickly in order to compete against the others.
How do teams compete?
In a regular poker robot competition, you’d have a few hours or days to create your robot, and then they’re ready to start playing. With Lean Poker, it’s the other way around. The robots already exist and start playing against each other right away. The robots are not very intelligent and they just fold every time. It’s all about which team can deliver value faster than the others. This forces teams to deploy very differently in order to get ahead of the others as quickly as possible. It’s a lot harder to get ahead later in the game when the robots are smarter.
Does Lean Poker have an 'origin story'?
In 2010 I went to my first code retreat. I really enjoyed the day-long practice. At the same time I started playing poker with my friends. A couple of years later my company Emarsys started doing continuous deployment. As I saw my colleagues struggling, the idea just clicked. Combining poker competitions with coding was a perfect opportunity to learn continuous deployment. I spent four months building Lean Poker before the first event in January 2014 and I’ve been iterating on it ever since.
Let’s talk about how you developed the Lean Poker app
At work, I was asked to be a team lead for a new Ruby team and had to learn Ruby in two weeks. The best way to learn a new language is to build something in it, so I decided to use Ruby for Lean Poker.
The back-end is built in Ruby using the Sinatra framework, and the front-end administration panel is two thousand lines of JavaScript mess! Basically I’d already had the back-end running and had only two nights to build the front-end before my first event, so I had to hack together something otherwise we wouldn’t have had a UI. Maybe some day I’ll clean it up, but for now two thousand lines of legacy is still perfectly maintainable for me, so it wouldn’t pay off yet to spend time on that. Especially because I only make minor changes to the UI.
I’m the kind of developer who doesn’t like it when a framework eats up my application. My main objection against Rails is that it makes you inherit from classes that you don’t want to inherit from. So I try to use plain old objects as much as possible, and the framework is just useful for wiring it up with the web server. That is why I chose Sinatra. It works better for me. If I were to start the app now, I would probably use Grape, which is even better for building single page apps with a pure API back-end.
Tell us about your architecture
The entire system is designed using a microservices architecture. Lean Poker itself is composed of five microservices, each of them running on Heroku. Each team represents an additional microservice. So for example, if an event has five teams, then I’d run ten Heroku apps in parallel.
The microservices communicate via a very simple HTTP interface, using a REST API (although it’s not perfectly REST. I’ve never seen an API that is entirely RESTful, but it’s as close as it can be to a REST API.) Everything is running with HTTP but I do use Sidekiq for message queuing because the Lean Poker system is built in Ruby. I also use Mongo for my database, Heroku Add-ons Zerigo DNS for domain management, Logentries for log management, and Redis Cloud to run Sidekiq.
What do the core microservices do?
I have one microservice (called “Manfred” after a character in the movie Croupier), which is a very simple service with a single API endpoint. I use it to post a JSON structure that specifies the teams and their addresses on Heroku, and it initiates a “sit-and-go” tournament. Then it sends back the actual game log so you can step through the game and see every move. It basically organizes players and the game, like a croupier.
Another microservice (called “Hermes” after the Greek God of transitions) is basically a Heroku deployment application. Whenever it’s informed by GitHub that there’s a push, it just takes the tarball and uses the platform API to deploy the application.
“Lumber” is a logger microservice that subscribes to the Heroku log drain, loads up the logs, and stores them in memory. Although I can use Logentries to monitor the main app, for the players I needed more flexibility than Logentries and Papertrail could provide. Each player needed an individual account, so we wrote a basic logger, which displays log lines in HTML and stores them in memory for a few minutes. Lean Poker gives players a number of controls including the ability to add a custom log drain using the Heroku platform API.
Then there’s a ranking microservice (called “Rainman” after the movie with the same title). I extracted a separate service from Manfred, which the players can call. If a player sends it their cards, the service will tell them what kind of hand it is and rate how good it is.
Finally, there’s the live app itself that wires together the other microservices—basically the front-end stuff that communicates with the database and users. It’s the hub of the entire system.
And then of course, there’s the Lean Poker marketing website, which isn’t really an app but more like a static website.
Do you authenticate requests between services?
There is some authentication for the riskier requests. The system sends out tokens and only accepts responses with those tokens, using a shared secret and decrypting the token locally on each microservice. I do have plans to migrate to the Escher Auth library. It’s a much more secure solution, and it was designed for communication between Heroku microservices specifically.
What is your deployment workflow?
When a team pushes code to GitHub, Lean Poker automatically deploys to Heroku using the platform API. When I built the app, Heroku’s GitHub integration wasn’t available yet. I use the URL to the tarball on GitHub, take it from the GitHub API and push it to the Heroku platform API.
When someone registers a team, the system automatically creates their own repository in GitHub. It pushes the scaffolding to their GitHub repo and from there they can immediately deploy a first version of the application.
How did you end up on Heroku?
First I tried running Lean Poker on Rackspace, using Docker to contain the players. But I always had this fear that someone would hack the system and hijack the underlying server for bitcoin mining or misuse it in some other way. I’m a developer, not a sysadmin, and I didn’t want to care about that stuff.
At my company, we started to use Heroku, and I thought, “That’s amazing!” I decided to give Heroku a shot. At first, I kept the Lean Poker app on Rackspace and only moved the players to Heroku, but I eventually moved the entire system to Heroku. I had to change a few things, primarily using MongoFS to move files to Mongo, but the migration only took me a few days.
How many events have you run so far?
So far there have been 21 Lean Poker events across Europe and I’m looking to expand to the U.S. I lead most of the events myself but I also train other coaches to run their own events.
If you're interested in attending (or running) a Lean Poker event, visit: Lean Poker.