Participants guide

This documentation provides useful information for participants during an event.

Event structure

Lean Poker has a very similar structure to coderetreats. Events take about 8 hours and usually start in the morning at around 9am. After the introduction and forming the teams there are 5 or 6 coding sessions each followed by a retrospective and a break. The day ends with a closing circle before announcing the winner.

During retrospectives and breaks the robots are not playing and participants are not allowed to code. The only exception to this rule is the last retrospective and the closing circle during which the robots keep playing. The primary purpose here is to make sure that changes pushed in the last few minutes still have some effect on the final results.

Introduction

The day starts with a short introduction that explains why Lean Poker was created and what to expect during the day.

Forming the teams

The facilitator gathers participants into a large standing circle. Supported languages are called out one by one and people who would like to work with that particular language put their hands up and look around for possible teammates. Finally participants are asked to self-organize into teams and get comfortable around a table as a team.

Coding sessions

During these hour-long sessions the robots play rounds (sit'n'gos) of Texas hold'em every few seconds, and the team with the robot who won will receive 5 points. The second comer collects 3 points. The team can make changes to the git repository provided by the platform. When new code is pushed into this repository it will be automatically deployed into production.

Retrospectives

After each coding session the facilitator gathers the participants into a large standing circle and the previous round is discussed. What was interesting, surprising? What kind of problems were the teams facing, and how did they handle the situation? This is also a great opportunity for the facilitator to point out some Agile or Lean principles that might apply or could have helped the team in solving their problem. Each retrospective is followed by a short break.

Closing circle

At the end of the day, after the last retrospective it's important to step back and reflect on the entire day. The purpose of the closing circle is to make people think about what is it that they are taking away. During the closing circle each participant is asked to answer the following three questions: What if anything surprised you today? What if anything did you learn today? What if anything are you going to do differently in the future?

Rules

There are not many rules, but please keep them in mind. All rules of no limit Texas hold'em apply.

Lean poker - although it has a competitive feel to it - is not a competition. The emphasis should be on practice. Because of that any prize more valuable than a few dollars should not be promised to the winner.

Fair play is also important: no one should try to exploit weaknesses of the framework or deliberately inject backdoors into its source code. Also - with some notable exceptions listed below - no team should use any pre-written code.

We would like to avoid a situation where one team has a huge advantage over the others due to a library that solves some part of the problem. For that reason the rule of thumb is that only the language's standard library, and open source libraries are allowed. Similarly only open source data files can be used. Proprietary libraries and files are banned under all conditions.

Also note that repositories are public, but we count on participants not to look at each others code during the event. Please do not try to make your repository private in an effort to hide your code from others, since that will break the deployment pipeline.

Getting started

Registering a team

Each team has to be registered by one member, the team lead. Choose a name for your team, select a language and the preferred git provider GitHub or GitLab. Note that GitLab also provides a CI system, something that GitHub lacks. Once the team is registered, the Lean Poker application will create a repository, a production environment on Heroku, it will set up a deployment pipeline and push a simple folding player into the repository.

Adding team members

Further team members can ask to join the team and the team lead needs to approve them. Once a team member is approved they will be able to push new code into the repository without creating a pull request.

Cloning the repository and deploying

Once a user becomes a team leader or team member the clone URL will appear on the event dashboard. Just clone the repository, make changes to it, commit, and once you are ready to deploy push the commits. Lean Poker Live will automatically deploy your new code into production.

Changing the default player

Each team is provided with a default folding player implemented in the language of their choice. In each ported version there should be a file called player.*. The team should start working with the bet_request function in this file. For a documentation of how this should be used please be referred to the Player API documentation.

Frequently asked questions

What does the chart on the event dashboard show?

The main chart on the dashboard is a relative performance chart. The X axis represents the games in order of end time. The Y axis is the number of points the team had after the nth game, minus the average number of points all teams together had at that point. This normalization is necessary to make it easy to see the difference between the performance of each team. Essentially when the curve for a team is trending down, the team performs worse than average, if it is trending up, the team does better than average.

There are also black dots on each line. These dots represent the approximate time when a new version was deployed for that particular team.

It is also possible to click on a line on the chart to open a particular game.

How often and how long do sit'n'gos run?

Both the frequency and length of sit'n'gos vary.

The length of a sit'n'go can be anything from a few seconds to up to 3 minutes. If a game takes too long, but a number of hands were already played, a decision is made based on stack sizes.

The frequency of the games start at one game every 40 seconds for the first hour. After that every hour the frequency is reduced by 5 seconds, i.e. during the second hour there is a game every 35 seconds, during the third hour every 30 seconds, etc. Once the frequency reaches every 5 seconds, it remains that. Note however that at most 8 games can run in parallel. If there are already 8 sit'n'gos running when a new one should be triggered, it will be skipped.

Is there a time limit on responding to bet requests?

Yes, there is! Each player has a total of 25 seconds for responding to all bet_requests during a sit'n'go. If a player exceeds the allowed time, then its remaining stack is taken away and it gets banned from the current sit'n'go.

How can I look at the sit'n'gos played by the bots?

Either click a data point on the relative performance chart to get to that particular game's viewer, or open the game from the event wall. Once on the game viewer page you can step through by using the arrow buttons on your keyboard.

Suddenly the player lost all its money without even betting, why?

This happens when the croupier bans a player from the game. While stepping through the game you should find an error message that describes the reason for the ban. Possible options are that the player ran out of the allowed execution time, did not respond with HTTP 200 status code, or the response body did not contain a valid non-negative integer.

Two players had the same hand, but one of them won the money, why?

Both of them won, but the croupier awards the money to each team one-by-one. If you keep stepping through the sit'n'go you should see multiple "player won" messages.

Is it possible to access game logs via an API?

Yes! On the dashboard you can find a url in the Event menu under Games JSON that points to a JSON data structure that lists all sit'n'gos. You can extract the game ids and the tournament ids from that. After that you can use the url bellow to download the JSON data structure representing each game.

Game log url:

https://live.leanpoker.org/api/tournament/<tournament_id>/game/<game_id>/log

How do I know if my deployment was successful?

The deployment menu on the event dashboard will show the result of the last 5 deployments. Each deployment is indicated with a color depending on success - blue is in progress, green is successful, red is a failed deployment. Each deployment is identified by the commit hash of the last commit in the version deployed. To look at the deployment log, just click on the commit hash in the deployment menu.

Is there a way to log in production and look at the results?

Whatever your application writes to stderr will show up in the application logs. You can access the last few minutes worth of application logs from your teams menu on the event dashboard.

Can I use a proper log indexing service?

You may find the default log viewer pretty uncomfortable, or you may want to keep logs around for a bit longer. There are some very good free services for that like Papertrail.

To set up Papertrail, go to papertrailapp.com and sign up for a free account. First you will need to add a new system. Once you have done that you will find a syslog url on the top of the Setup systems page that opens. Copy that url.

Next head to the Lean Poker event dashboard and find Custom logdrains in the team menu. You will have to type syslog+tls://<syslog url provided by papertrail> into the input field and click add logdrain.

When you head back to Papertrail you should see logs showing up for your player.

If you still have questions, head over to the frequently asked questions section.