Store a history of our participation in programming competitions

[saifulwebid]

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]

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]

@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]

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 😂)

[fauh45]

Thinking about it again I think it is quite overkill to have a noSQL DB somewhere 😂 , 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]

Yaa just use this repository as our own "NoSQL DB" 😄

[saifulwebid]

Yeay ~

Now for the data structure, any suggestions @fauh45?

[fauh45]

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]

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]

{
  "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 😂 sorry for the noob-ish thinking 🙏 .

[saifulwebid]

Questions:

1. I wonder: why you choose to create a .details instead of putting .place, .year, and others on the root object?
2. Why you choose to store .year instead of .date?
3. 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]

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 😂 .

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 😬

Woops, forgot to make it a plural. Noted!

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

🙏 Thanks a lot for this 😂 👍

[saifulwebid]

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:

1. On using .details, instead of directly putting the .details.* fields on the root object;
2. 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]

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 😄

[imamfzn]

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 🙏 😂

[saifulwebid]

@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]

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

[saifulwebid]

Sure - good luck for your upcoming exams 🎉🎊

[fauh45]

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]

Let's use members then 👍

[fauh45]

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]

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]

{
  "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]

Nice - bungkus!

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

[fauh45]

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]

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]

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

[saifulwebid]

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

[fauh45]

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

[saifulwebid]

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]

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

[saifulwebid]

Yup - shoot two issues with one PR 😉

[saifulwebid]

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