Store a history of our participation in programming competitions

saifulwebid commented 3 years ago

We want to store the history of our participation in various programming competitions in a JSON file, maybe on data/competitions.json (feel free to suggest a file name).

However, I'm still unsure on the data structure. Feel free to discuss. In my mind, we may want to store the competition name, where and when it took place, the team list participating in both preliminary and final stages, and the members' IDs (see #7).

{
    "name": "ACM-ICPC Multi-Provincial Mikroskil 2015"
    // ... dunno. Please discuss here in this issue first.
}

fauh45 commented 3 years ago

I think doing it like in a noSQL kind of way would be good. Something like

{
    "name": "ACM-ICPC Multi-Provincial Mikroskil 2015"
    "participant": [
        {
            "ID": "171524026",
            "position": "3rd" // or maybe using integers
        },
        // ... more here
}

would be clear enough to read, and easy enough to handle the data.

p.s. and also if you guys want I can provisioned a AWS DynamoDB table for this and maybe #7

saifulwebid commented 3 years ago

@fauh45 I think a DB somewhere will be overkill, as then we’ll need to setup an account and make sure it will last for eternity 😂

How about keeping them in JSON files as we already did on Kattis, Codeforces, and Atcoder data? People can submit PRs to this repository if they need to add more info - this way we also introduce Git to Encode members.

What do you think @imamfzn?

imamfzn commented 3 years ago

I agree with @saifulwebid , JSON and git should be enough.

we just have a small of data
we can easily migrate our JSON into NoSQL in the future (but i don't think we need it :joy:)

fauh45 commented 3 years ago

Thinking about it again I think it is quite overkill to have a noSQL DB somewhere :joy: , also the point made by @saifulwebid by having CP member do a PR to add their info would be a great way to introduce them to git!

imamfzn commented 3 years ago

Yaa just use this repository as our own "NoSQL DB" :smile:

saifulwebid commented 3 years ago

Yeay ~

Now for the data structure, any suggestions @fauh45?

fauh45 commented 3 years ago

I think doing it like in a noSQL kind of way would be good. Something like

{
    "name": "ACM-ICPC Multi-Provincial Mikroskil 2015"
    "participant": [
        {
            "ID": "171524026",
            "position": "3rd" // or maybe using integers
        },
        // ... more here
   ]
}

@saifulwebid I think that'll do the job just fine, as I would think we only care about what event did we go in to in correlation of who goes there. and how they do right?

And a bit of simple modification of using array inside of the participant array would do it for teams. Is it good enough?

saifulwebid commented 3 years ago

And a bit of simple modification of using array inside of the participant array would do it for teams. Is it good enough?

Can you write it explicitly on how the JSON will look like for teams? Think of this as an RPL/DB task on designing data schema. 😄🙏

Let's see what I think we should capture:

name of the competition
where and when it took place
participants -- there were competitions like Agricode that participants compete individually, and there are ICPCs which have teams participating instead of individuals
if someone/some team participated only until the preliminary stage, I'd like to capture them too to show our appreciation for them ... but we should indicate it in the history that they only participated until the preliminary stage (and optionally show their rank on that stage)
anything else? you may add ...

fauh45 commented 3 years ago

{
  "name": "Competition name goes here",
  "details": {
    "place": "Where the competition is",
    "year": "Year of the competition",
    "link": "Competition link",
    "stages": [
      {
        "level": 1,
        "name": "Prelim"
      },
      {
        "level": 2,
        "name": "Semi"
      }
    ],
    "reward": [
      {
        "type": "Prize type, like money/physical/etc",
        "place": "1st/2nd/etc",
        "value": "Monetary value or something equal"
      }
    ]
  },
  "paticipant": [
    {
      "name": "Team name goes here",
      "member_ids": [
        "191524026"
      ],
      "result": [
        {
          "level": 1,
          "position": "1st/69th/etc"
        }
      ]
    }
  ]
}

@saifulwebid I think this is as extensive that I can think of, for some of the concern

participants -- there were competitions like Agricode that participants compete individually, and there are ICPCs which have teams participating instead of individuals

In case of individual participant—in this schema—I can just put it into the array of member in the team item, and make the team name their name. Just to make the schema global for all type of participation, as this would simplify data processing.

And data processing wise, if the member array length is just 1, I can just treat them as an individual entry to that competition, even in a competition which allows for teams and individual entry.

if someone/some team participated only until the preliminary stage, I'd like to capture them too to show our appreciation for them ... but we should indicate it in the history that they only participated until the preliminary stage (and optionally show their rank on that stage)

With this I would just go through level in the participant attribute, team item. Then check on the competition details of which stage is the higher one. Or if you want to just make it even more simpler, I can just keep the highest one.

Also,

Think of this as an RPL/DB task on designing data schema.

I've just started DB on this semester :joy: sorry for the noob-ish thinking :pray: .

saifulwebid commented 3 years ago

Questions:

I wonder: why you choose to create a .details instead of putting .place, .year, and others on the root object?
Why you choose to store .year instead of .date?
Which one do you prefer: .participants.*.members or keep it .participants.*.member_ids?

Little suggestion: let's make it .participants instead of .paticipant 😬

And data processing wise, if the member array length is just 1, I can just treat them as an individual entry to that competition, even in a competition which allows for teams and individual entry.

I like it. What do you think @imamfzn?

I've just started DB on this semester 😂 sorry for the noob-ish thinking 🙏 .

*cc-ing your lecturer in the background ... 😂

Just kidding. It's a good start! 🎉🎊

fauh45 commented 3 years ago

I wonder: why you choose to create a .details instead of putting .place, .year, and others on the root object?

I guess my only reason for this are a cleaner organisation of the competition data itself, there's no other reason to put the .details on the root object :joy: .

Why you choose to store .year instead of .date?

The idea of putting .date instead would actually be better. Maybe put store it as an ISO 8061 standard here?

Which one do you prefer: .participants.*.members or keep it .participants.*.member_ids?

At least for me keeping the ids are much better than keeping a double record of the member details itself. What I think is details of members might change and he/she could be competing a lot so the record need to be changed a lot.

And the fact that there are duplicate data on a relatively static item is not that good (?)

Little suggestion: let's make it .participants instead of .paticipant :grimacing:

Woops, forgot to make it a plural. Noted!

Just kidding. It's a good start! :tada: :confetti_ball:

:pray: Thanks a lot for this :joy: :+1:

saifulwebid commented 3 years ago

The idea of putting .date instead would actually be better. Maybe put store it as an ISO 8061 standard here?

Agreed; as we will deal with JavaScript, it will also helps to use ISO 8601: https://stackoverflow.com/a/15952652.

At least for me keeping the ids are much better than keeping a double record of the member details itself. What I think is details of members might change and he/she could be competing a lot so the record need to be changed a lot.

Oh, sorry for not being clear enough; I just merely comment about the naming. I agree on using IDs instead of embedding the participant detail directly.

I need comment from @imamfzn about these two:

On using .details, instead of directly putting the .details.* fields on the root object;
On the name .member_ids instead of .members, with the value being an array of IDs

Also, I would like to make a proposal to make the only required fields being .name and .participants.*.member_ids. This way, at the very least, we can backfill data from ... let's say, 2013, without requiring people to remember all the details. What do you think? @fauh45 @imamfzn

fauh45 commented 3 years ago

Also, I would like to make a proposal to make the only required fields being .name and .participants.*.member_ids. This way, at the very least, we can backfill data from ... let's say, 2013, without requiring people to remember all the details. What do you think?

I absolutely agreed with you @saifulwebid , having some data is better than having none :smile:

imamfzn commented 3 years ago

Hmm, IMO just put all of competition attributes to the root object, because this object is represent competition data. I have no idea about members vs member_ids, but i aggree to just put ids instead of embedding member detail. Can we have a standard for naming this object ? Like use RESTful standard maybe. I mean just use a standard that commonly used.

Sorry for late response :pray: :joy:

saifulwebid commented 3 years ago

@fauh45 still interested to make this happen? 😄

You got one suggestion from @imamfzn - after that let's wrap this up if you're still energized for it 😂

fauh45 commented 3 years ago

For sure! Got sidelined with another projects, and now UAS is on the line, maybe after that?

saifulwebid commented 3 years ago

Sure - good luck for your upcoming exams 🎉🎊

fauh45 commented 3 years ago

Alright UAS all done, thanks for that btw!

Hmm, IMO just put all of competition attributes to the root object, because this object is represent competition data. I have no idea about members vs member_ids, but i aggree to just put ids instead of embedding member detail. Can we have a standard for naming this object ? Like use RESTful standard maybe. I mean just use a standard that commonly used.

Sorry for late response

I think members might be better naming wise, but I don't think it is quite representative of what the data is, no? But if you want to make it into a standard I guess members is better this way.

What do you guys think? @saifulwebid @imamfzn

saifulwebid commented 3 years ago

Let's use members then 👍

fauh45 commented 3 years ago

We might have a consensus then? I think we also need an example to begin with, just to make it easier for others to add

saifulwebid commented 3 years ago

I think we can use this as an example: https://jtk.polban.ac.id/2019/07/tiga-mahasiswa-jtk-sabet-juara-4-di-kompetisi-acm-icpc-ideafuse-2019/.

fauh45 commented 3 years ago

{
  "name": "ACM-ICPC Ideafuse 2019",
  "place": "STMIK Mikroskill Medan, Sumatra Utara",
  "year": 2019,
  "link": "https://icpc.global/regionals/finder/Indonesia-IDEAFUSE-Multi-Provincial-2019",
  "stages": [
    {
      "level": 1,
      "name": "Prelim"
    },
    {
      "level": 2,
      "name": "Semi"
    },
    {
      "level": 3,
      "name": "Finals"
    }
  ],
  "participants": [
    {
      "name": "LetkolMuntu",
      "members": ["16...", "17...", "17..."],
      "results": [
        {
          "level": 3,
          "position": "4th"
        }
      ]
    }
  ]
}

Data aren't really that complete or accurate, but I think that should be final?

saifulwebid commented 3 years ago

Nice - bungkus!

Non-blocking suggestion: how if we change .link to .links and make it an array?

fauh45 commented 3 years ago

Right then, how should we "formalized" it?

Non-blocking suggestion: how if we change .link to .links and make it an array?

Yep should works better too

saifulwebid commented 3 years ago

Submitting a PR containing our participation in ACM-ICPC Ideafuse 2019 as a seed will do 😊

After that we can throw that PR to Encode CP group in LINE to trigger further contributions 😉

fauh45 commented 3 years ago

Little problem, I need to search up their NIM, I honestly don't know haha

saifulwebid commented 3 years ago

Hm, I guess Himakom should have a data of it, no?

fauh45 commented 3 years ago

Yea don't think they have a centralized source for all of it

saifulwebid commented 3 years ago

Got an idea - let's assign them UUIDs for a while so we don't get blocked on NIM 😄

They can always submit pull requests to correct it.

fauh45 commented 3 years ago

Ah good idea actually, should we do it with #7 too?

saifulwebid commented 3 years ago

Yup - shoot two issues with one PR 😉

saifulwebid commented 3 years ago

Future contributors: please follow #13 to contribute on solving this issue.

jtkencode / cp-leaderboard

Store a history of our participation in programming competitions #8