/dev/winter


Below are my notes on /dev/winter 2015, a free, one-day event for software developers in Cambridge area.

Overall

The conference is well organized, right mix of people, good venue and food. The balance feels right, the programme has a range of talks from machine learning to software design while maintaining practicability.

First session: Modeling complex game economy with Neo4j

The first talk, given by Yan Cui from Gamesys, was both clear and informative. Yan showed us how you could use Neo4j, a NOSQL database for graph data, to help on modeling and balancing the economy of a large scale on-line game.

The key takeaway messages are:

  1. Use Neo4j to model the play content as a interconnected network. Each play item will be represented as a node, whereas the edge between the nodes describes the relationship between the items. For example, to make a bread you need some flour, both bread and flour will be a separate node in the play content network. Therefore, if you change the price of the flour, the price of the bread will also be affected. This effect can be investigated using simple Neo4j queries.

  2. Neo4j can only be run on one machine, and cannot be partitioned into different machines.

  3. GameSys is using genetic algorithmm written in F# to model and propose solutions for balancing the game playability.

  4. GameSys’s entire system is based on Amazon EC2. They are using technologies such as: Amazon DynamoDB, MemCached, CouchDB.

Second session: Git for teams of one or more

I picked this practical session since our team is making the transition from SVN to Git. Emma Jane, the workshop organizer, has been doing training on source control system for many years. You can find her slides here, and she is also writing a book, called Git for Teams.

The key takeaway messages are:

  1. Documentation on agreed git workflow is necessary for the team. This document should outline how the team members interact with the code. It should also provide a governance strategy and branching strategy for the project.
  2. Different branching strategies for different use cases. If you are doing scheduled release, you can use either Gitflow or Simplified Gitflow. If you are doing constant integration, you can choose either Branch Per Feature or GitHub Flow.
  3. To view the commit history and the relations between different commits, there are several tools you can use: log, gitk, blame and bisect.
  4. Emma highlighted the differences between merging and rebasing. She recommended against using rebasing if it does not provide additional benefits for the team.

Third session: Java is dead, long live Scala, Kotlin, Ceylon, etc

Russel Winder showed the differences between several JVM based languages, namely Java, Scala, Kotlin, Ceylon, Groovy, Fantom and Goush. The demo was based on approximating pi using quadrature. The main idea is to investigate scaling to see how different languages solve this parallel problem. You can find all his code examples from here.

The key messages are:

  1. Scala has its own implementation of data structures, whereas Kotlin is using Java’s native data structures.
  2. Groovy can now be run on Android, all its nice functional programming features are already available and can be used on Android devices directly.
  3. Groovy is not as slow as before, it offers comparable performance to Java.
  4. Scala, Kotlin, Groovy are all offering functional-style parallelization. This lead however has been cut short since the introduction of Java 8.
  5. Upgrade to Java 8 to take advantage of G1 garbage collector, Nashorn, Lambda features.

Fourth session: How to ditch the debugger and use logging instead

The main motivation behind this tutorial is to address the problem that one cannot attach the debugger to the application in Production, and debugging in a distributed environment is even more challenging. Logging can be used in a way which means you can diagnose problems very easily in both development and production.

The key messages are:

  1. Event tracing, which is a specialized use of logging to record information about a system’s execution. This tracing can be used to log different execution steps as well as record their performances.

  2. For any system, there are different types of events, these can be categorized as technical level events, e.g. database connection, out-of-memory, or domain level events, e.g. bank transaction, user login. Also, depending on the nature of the events, one can categorize them into unknown events or defined events.

  3. It is important to assign event type id for each event, as this will help to group and interpret the logs. In Java, a typical way of defining these event type IDs is to use enum. When used in a distributed system, these event type IDs can be passed between different services, this will enable the developers to trace the events occurred on different systems.

  4. It can be difficult to choose a severity level (such as ERROR, WARNING, etc) for logging which will be appropriate for production, as the severity of an event type may need to be changed after the application has been deployed based on experience of running the application. Different environment (Dev, Test, Production) may also require different severity levels. Therefore, it is better to have the severity level of all events configurable. There is a nice blog post about how to archive this in the production system.

  5. Event-tracing based logging using the Elasticsearch ELK Stack, which includes Elasticsearch, Logstash and Kibana. Logstash takes logs and other event data from the systems and store them in a central place. Elasticsearch is then used for indexing the logs for searching and access. Kibana works with Elasticsearch to visualize logs and time-stamped data.

  6. Use a virtual machine manager called Vagrant, which allows the user to script virtual machine configuration as well as the provisioning, to setup the Elasticsearch ELK Stack. The demo can be found here.

Remarks

All in all, a very good one-day conference. Look forward to /dev/summer 2015.