DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Real Coding: An ''Enterprise'' Ranking Application

Enough cheesy code examples and talking about code without code. In the ''Real Coding'' series, we're going to develop a real, working ranking application in two weeks.

Grzegorz Ziemoński user avatar by
Grzegorz Ziemoński
·
Oct. 10, 17 · Tutorial
Like (16)
Save
Tweet
Share
10.50K Views

Join the DZone community and get the full member experience.

Join For Free

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.

application Coding (social sciences)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • AWS Cloud Migration: Best Practices and Pitfalls to Avoid
  • Building a Scalable Search Architecture
  • An Introduction to Data Mesh
  • Asynchronous HTTP Requests With RxJava

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: