Welcome to the first installment of the upcoming "Real Coding" series. Over the next two weeks, I'm going to develop a real, working application, working one Pomodoro per day and sharing the progress, reasoning, and lessons learned here on DZone.

Why Am I Doing This?

There are two categories of reasons on why I decided to start this little series: one purely selfish and one a bit less selfish.

The former category consists of me trying to fight off my recent writer's block, having little time for writing longer pieces, and missing the daily development of features at my day job.

The latter, less selfish category is mostly my hypothesis that people should learn more from real, working projects rather than from cheesy 5-line examples or, worse, a description of code without actual code.

Between the two categories lies the fact that the world lacks a good, "enterprise-ready" ranking application, which I need and I'm willing to open-source.

What Am I Going to Build?

Here started my first Pomodoro on the project. As much as I wanted to start coding from minute zero, I needed to answer the what question for myself, so that I actually know what I'm going to do and so I can share it with you here.

What the world and I are in need of is a ranking application for office games like table soccer, table tennis, board games, and the like. The term "enterprise-ready" I mentioned before implies a strong, non-negotiable requirement that the application should be able to integrate with the company's Single-Sign-On gateway or Active Directory so that people don't have to create accounts, manage passwords, etc.

A bit less strong, although still rather non-negotiable requirements are:

• A single instance of the application should support multiple rankings for multiple, different games.

• Both solo and team modes should be supported.

• The ELO system or something similar should be used.

• Both players/teams should accept a match/game result before any ranking adjustments are made.

Finally, there are two nice-to-have features that probably won't make it into the first version of the application, but we should keep them in the back of our minds:

• Tournament mode, which allows for organizing short-term groups and play-off tournaments.

• Automatic match-up — the application could automatically generate match-ups between players of similar skill, which would surely mean more cross-project and cross-department matches than normally.

Minimum Design

Having recalled and written down all of the above, there were about 18 minutes left on my Pomodoro. I decided that before I jump into the code and start bashing around, I should come up with some design starting point that would give hope for satisfying the requirements.

My first thought, which actually came before I started working on this, was that we can simply keep the rating along with the player. The player would update its own rating according to the match results being sent to it in the form of method calls.

Obviously, this idea falls short on the very first requirement, as there's no single rating for a given player. We could try to go a step further and say that the player keeps ratings in all of the rankings that he's a member of, but this would yield a pretty odd API and broad transaction boundaries, I imagine(d).

Taking two steps back, the idea came to my mind that it's actually the ranking that keeps track of the players' ratings. This way, I can create as many rankings as I want, and each of them can keep totally separate ratings. Sounds good. Seems like all other requirements could be satisfied as well with such design. There's a little red light in my head that a ranking object would be an uber-aggregate, which might slow down the application, but "5 minutes left" on my Pomodoro timer convinced me to let it go for now.

First Lines of Code

Yes, I really couldn't wait to start writing code that much. Unfortunately, 5 minutes was just enough to launch a new Maven project, configure Kotlin, and only begin fiddling with the classes:

package com.tidyjava.rankingapp

import java.util.*

class Ranking(val defaultRating: Rating,
              val ratings: MutableMap<PlayerID, Rating>,
              val matches: MutableList<Match>) {

    fun join(playerID: PlayerID) {
        ratings.put(playerID, defaultRating)
    }
}

class Match(val id: MatchID) {

}

data class MatchID(val value: UUID = UUID.randomUUID())

data class PlayerID(val value: String)

data class Rating(val value: Int)

As you can see, I just typed in some nouns that popped up during the analysis without a chance to do anything meaningful yet.

Final Thoughts

One thing that seemed obvious during the Pomodoro, and that I've just started questioning, is whether you actually join a ranking or maybe you start off as "unrated", which just implies a default value under the hood. Also, is ranking a really good name for the purpose? Or maybe I should name it league or ladder? Well, there's something to think about until tomorrow.