er en internasjonal bevegelse som arrangerer profesjonelle konkurranser for ungdom under 22 år.
Den internasjonale finalen arrangeres annethvert år. I år var det siste lokalet (den siste finalen var i 2017 i Abu Dhabi, den neste blir i 2021 i Shanghai).
WorldSkills Championships er verdens største mesterskap i profesjonelle ferdigheter. De startet med blåsnippyrker, og de siste årene har mer og mer oppmerksomhet blitt rettet mot «fremtidens yrker», inkludert IT-disipliner, som en egen enorm klynge ble tildelt ved mesterskapet i Kazan.
I IT-blokken er det en kompetanse (en spesifikk "sport") kalt "IT Software Solutions for Business".
I hver konkurranse er den tillatte listen over brukt verktøy begrenset. Og hvis for eksempel for "landskapsdesign" listen over mulige verktøy er begrenset (selvfølgelig uten å angi en eksplisitt produsent eller farge), så i kompetansen "Programvareløsninger for bedrifter" listen over aksepterte teknologier som deltakerne kan bruke er strengt begrenset, og indikerer spesifikke teknologier og spesifikke plattformer (.NET og Java med et spesifikt sett med rammeverk).
Posisjonen til 1C i dette spørsmålet er som følger: informasjonsteknologi er et veldig dynamisk område, nye teknologier og utviklingsverktøy dukker stadig opp i verden. Fra vårt ståsted er det riktig å la spesialister bruke de verktøyene de ønsker og er vant til å jobbe med.
Høsten 2018 hørte WorldSkills-ledelsen oss. Nå måtte vi teste metodikken for å inkludere nye teknologier i konkurranser. Det er ikke enkelt.
1C:Enterprise-plattformen ble inkludert på infrastrukturlisten til mesterskapet i Kazan og en eksperimentell plattform for IT Software Solutions for Business Sandbox ble organisert.
Vær oppmerksom på at det offisielle språket i mesterskapet er engelsk. Alt materiale med resultater av å løse oppgaver (kildekoder, medfølgende dokumentasjon, programvaregrensesnitt) skulle også overføres på dette språket. Til tross for noens tvil (fortsatt!), kan du skrive på engelsk i 1C.
9 unge gutter fra 8 land (Filippinene, Taiwan, Korea, Finland, Marokko, Russland, Kasakhstan, Malaysia) deltok i konkurransen på denne siden.
Juryen – et team av eksperter – ble ledet av en ekspert fra Filippinene, Joey Manansala.
Eksperter fra Finland, UAE, Costa Rica, Korea, Russland og Taiwan var representert.
Hver for seg merker vi at deltakere fra Russland (Pavkin Kirill, Sultanova Aigul) og Kasakhstan (Vitovsky Ludwig) bestemte seg for å bruke 1C:Enterprise-plattformen som en del av konkurransen. Resten av deltakerne brukte .NET for desktop og Android Studio for mobilutvikling. Det er interessant at deltakerne som valgte 1C er veldig unge (Kirill er elev ved en skole i Stavropol, i år gikk han i 11. klasse, Aigul er en høyskolestudent, Kazan, Tatarstan), mens motstanderne deres var mye mer erfarne ( for eksempel en deltaker fra Korea - vinner av 2013 WorldSkills-mesterskapet i Leipzig; alle har erfaring med å delta i WorldSkills og flere års yrkeserfaring i bransjen).
Tatt i betraktning at deltakerne under konkurransen brukte ulike moderne teknologier, hadde vi sjansen til å teste 1C:Enterprise-plattformen i virkelige kampforhold, for å sammenligne både kvaliteten på løsningene som ble oppnådd med hjelpen og utviklingshastigheten oppnådd med bruken.
Separat bemerker vi at innenfor rammen av den spesielle IT Software Solutions for Business Sandbox-plattformen, fullførte deltakerne de samme oppgavene som deltakerne i hovedplattformen IT Software Solutions for Business.
Oppgaven i seg selv er en kompleks oppgave for å automatisere en bestemt virksomhet; i år var eksemplet på en virksomhet det fiktive selskapet KazanNeft.
legende
Kazan Oil er en av de største oljebedriftene i republikken Tatarstan, som opererer som en nasjonal markedsaktør og en internasjonalt anerkjent merkevare på dette feltet. Hovedkontoret til selskapet, som spesialiserer seg på feltleting, produksjon, produksjon, raffinering, transport og salg og distribusjon av olje, petroleumsprodukter og naturgass, ligger i Kazan (Russland).
Siden selskapet implementerer en strategi for rask utvidelse og etablering av nye kontorer i hele Russland, bestemte selskapets ledelse å introdusere ny programvare for forretningsautomatisering rettet mot å vedlikeholde og administrere visse operasjoner.
Mesterskapsforhold
Oppgaver ble gitt til deltakerne i form av moduler (sesjoner) med krav om å gjennomføre dem på en begrenset tid. Det var totalt 7 moduler. Tre økter for løsning på en stasjonær – 2.5 timer hver. Tre økter - klient-serverutvikling, hvor klienten var en mobilapplikasjon, og kommunikasjon mellom klient og server ble utført via WEB-API. Dette tok 3.5 timer. Siste økt – oppgaver om omvendt utvikling av eksisterende programvare, 2.5 timer. Som en del av reverse engineering måtte deltakerne, basert på informasjonen de fikk, designe strukturen til applikasjonsdatabasen (ved å bygge et ER-diagram), analysere scenarier for bruk av systemet (ved å bygge et use case-diagram), og også utvikle og designe grensesnittet til programvareløsningen i henhold til de angitte funksjonskravene.
De viktigste utviklingsplattformene som ble brukt var .NET (C#) og Java (inkludert Android Studio for mobilutvikling). Den eksperimentelle SandBox brukte .NET, Java og 1C:Enterprise versjon 8.3.13.
På slutten av hver økt vurderte ekspertene resultatet – et ferdig gjennomførbart prosjekt som implementerer oppgavene som ble satt i begynnelsen av økten.
Det særegne ved oppgavene er deres "vitalitet" - mange krav og begrenset tid. De fleste problemene er ikke spesielle olympiadeproblemer, men er svært nær reelle industrielle problemer – spesialister møter dem hver dag. Men det er mange oppgaver, og tiden er begrenset. Deltakeren må løse det maksimale antallet problemer som vil ha størst nytte for virksomheten. Det er slett ikke et faktum at en kompleks oppgave fra et algoritmisk synspunkt vil ha større vekt enn en elementær. For eksempel er det viktigere for en virksomhet å lage et fungerende regnskapssystem med tre tabeller enn et vakkert rapporteringsskjema med komplekse algoritmer, noe som er helt unødvendig uten disse tabellene.
Vi ba vinneren av konkurransen, en deltaker fra Russland, Kirill Pavkin, om å fortelle oss mer om hva oppgavene var og hvordan han stilte seg til løsningen deres.
Nedenfor er en beskrivelse av oppgaven, Kirills egen historie om hvordan han løste oppgaven. Vi ba også Vitaly Rybalka, en 1C-ansatt og en av IT Solutions for Business Sandbox-ekspertene, om å kommentere Kirills løsninger.
Som en del av oppdraget var det nødvendig å automatisere aktivitetene til flere typer brukere:
- Ansvarlig for regnskapsføring av selskapets eiendeler
- Ansvarlig for uplanlagte reparasjoner og planlagt vedlikehold av selskapets eiendeler
- Innkjøpsansvarlige for komponenter og forbruksvarer
- Oljeleting og oljeproduksjonsavdelinger
- Toppledelsen trengte analytiske rapporter
Økt 1
Fra et aktivasynspunkt (for eksempel en bilflåte) var det nødvendig å implementere deres regnskap (etablere nye, redigere gjeldende), hurtigsøk og ulike typer filtre for å vise informasjon, flytte eiendeler mellom selskapets divisjoner og grupper av eiendeler selv. Hold en historie med slike bevegelser og gi analyser om dem i fremtiden. Eiendelsregnskap ble hovedsakelig implementert for mobile brukergrupper.
Cyril: En interessant deloppgave var implementeringen av knapper i aktivalisten. For å løse dette brukte vi en dynamisk liste: vi skriver en vilkårlig forespørsel, og når vi mottar data på serveren, tildeler vi navigasjonslenker til bilder fra bildebiblioteket til de nødvendige feltene.
Etter konvensjon kan bilder knyttes til en ressurs på to måter: ta et bilde (multimedia) og velg fra galleriet (dialog for filvalg).
Noen former måtte tegnes på nytt når skjermen ble rotert:
Når vi endrer skjermparametere, endrer vi synligheten til knappegrupper.
Underholdende, men enkle oppgaver inkluderer filtre i en dynamisk liste, søk i to felt (nummer og navn) og generering av et aktivaserienummer.
Ekspertkommentar: fra synspunktet til løsningen på 1C:Enterprise-plattformen er oppgaven ganske klar. I tillegg til selve opprettelsen av mobilapplikasjonen, var det nødvendig å ta seg av overføring av data fra DBMS "server" (MS SQL på skrivebordet) til mobilapplikasjonen og tilbake. For dette formålet ble mekanismene til eksterne datakilder og http-tjenester brukt i "proxy-applikasjonen" på skrivebordet. For selve mobilplattformen ga visning av bilder i en dynamisk liste økt kompleksitet.
Økt 2
Det var nødvendig å etablere reparasjonsstyring for selskapets eiendeler. Som en del av denne oppgaven var det nødvendig å opprettholde en liste over forespørsler om reparasjoner (etter avdelinger og grupper), ta hensyn til prioriteringer for reparasjoners haster, planlegge en reparasjonsplan i samsvar med prioriteringer, bestille nødvendige komponenter og ta hensyn til eksisterende. En interessant deloppgave var at noen komponenter hadde en utløpsdato; hvis en del allerede er bestilt for en gitt eiendel og fristen ikke har utløpt, er det ikke nødvendig å kjøpe den samme delen på nytt for denne eiendelen. Reparasjonsgrensesnittet ble utviklet for skrivebordskomponenten i selskapets programvare.
Det var også nødvendig å lage et ikke-trivielt autorisasjonsskjema for to roller: ansvarlig person og serviceleder. Det særegne er at du etter autorisasjon automatisk må velge en av rollene.
Listeskjemaet tilgjengelig for ansvarlig person er presentert nedenfor:
Cyril: Bare uthevingen av ventende tjenesteforespørsler kan utheves her. Løst ved betinget formatering i en dynamisk liste.
Ved å klikke på knappen nederst på skjermen kan brukeren gå til følgende skjema:
Fra et 1C-synspunkt er det ikke noe komplisert i denne formen.
Skjemaet tilgjengelig for servicelederen er nedenfor:
Dette skjemaet er sortert etter prioritet og forespørselsdato. Ved å klikke på knappen nedenfor kan brukeren gå til skjemaet for den valgte forespørselen:
I tillegg til idiotsikring, foreslo dette skjemaet å implementere en liste over reservedeler for reparasjoner. Deloppgaven er interessant fordi delene har en utløpsdato. Dette betyr at hvis en nødsituasjon allerede har oppstått med denne eiendelen og en del ble bestilt for den, hvis gyldighetsperiode ikke er utløpt, kan den brukes på nytt. Dette skal vises til brukeren.
Ekspertkommentar: her plasserte Kirill selv aksentene korrekt. Fra synspunktet om implementering på 1C:Enterprise-plattformen, er det ikke noe ekstremt komplisert. Det var nødvendig med en nøye analyse av vilkårene for regnskap og bruk av reservedeler og kompetent gjennomføring av oppgaven som helhet. I tillegg var det nødvendig å registrere tjenesteforespørsler på riktig måte. Hovedvanskeligheten var kun tidspresset på 2.5 timer.
I tillegg, som i mobilutvikling, måtte deltakeren kompetent innhente data fra en ekstern DBMS (MS SQL).
Økt 3
For vedlikehold (vedlikehold) ble det foreslått å implementere en langsiktig planleggingstjeneste. En interessant funksjon her var kravet om å lage en vedlikeholdsplan for eiendeler i henhold til timing - for eksempel annenhver måned den 3. På samme måte, ifølge en kvantitativ indikator - for eksempel i henhold til bilens kilometerteller (oljeskift hver 5000 km, dekkskift hver 20000 XNUMX km). Vedlikeholdslederen skal ha mottatt en praktisk mobilapplikasjon som dynamisk viser en liste over forfalt, nåværende og fullført vedlikehold for en spesifisert periode. I tillegg måtte hver type vedlikehold males i farger etter spesielt avtalte regler. Mobilapplikasjonen skulle sørge for opprettelse av nye vedlikeholdsplaner og merking av de som allerede er fullført direkte i verkstedene med rask oppdatering av denne informasjonen på serveren.
Cyril: Det finnes to typer reparasjoner: tidsbasert og kjøringsbasert. Variasjon er tillatt innenfor hver. For eksempel skal reparasjoner etter planen skje hver fredag, den 13. i måneden, eller hver 20,000 kilometer. En oppgave anses som fullført hvis det er et hakemerke til høyre for den.
Det ble gitt en betingelse for sortering av oppgaver i listen. Hver linje bør også utheves i farger avhengig av forholdene.
Ved å klikke på knappen nedenfor kan du opprette en ny tjenesteplan:
De obligatoriske feltene vises avhengig av den valgte diagramtypen. Hvis vi har valgt en ukentlig tidsplan, vil vi bli vist to felt: ukenummer og ukedag. For eksempel på tirsdager hver 3. uke.
Ekspertkommentar: som i forrige mobilutvikling på 1C:Enterprise-plattformen, her er oppgaven globalt delt inn i 2 komponenter - kommunikasjon med "serveren" via web-api og kompetent visning av en dynamisk liste med betinget design og filtrering (seleksjon) av data. I tillegg var det interessant å implementere kravet om å redegjøre for reparasjoner både etter periode og etter kvantitativ indikator.
Økt 4
For komponenter og forbruksvarer var det nødvendig å ta hensyn til varelager, planlegge utgifter og fremtidige kjøp. I tillegg dukket det opp partiregnskap her, men ikke for alle varer. Alt dette måtte administreres innenfor flere varehus, inkludert mottak, utgifter og bevegelse. I henhold til oppgavens vilkår var det nødvendig å sikre kontroll med balanser og unngå konflikter ved arbeid med løpende beholdninger. Innkjøpsansvarlige jobber i desktopversjonen av programvaren.
Hovedskjemaet er vist nedenfor:
Cyril: I tillegg til å sortere fra tilstanden, ble det foreslått å gi brukeren mulighet til å sortere tilfeldig. På 1C trenger du ikke engang tenke på det. Feltet med antall deler skal markeres med grønt for fakturaer.
I denne økten ble de bedt om å kontrollere de gjenværende varene på lager. Så den tilsvarende meldingen skal vises når du prøver å slette fakturaen. Her husker vi plattformspesialisteksamenen. Formen på fakturaen er som følger:
Hver del har en karakteristikk som avgjør om den skal tilordnes en bestemt batch. For slike reservedeler er det viktig å angi batchnummeret i alle dokumenter. Dette er en tilleggsmåling ved overvåking av delerrester. De kan også flyttes mellom varehus:
Skjemaet skiller seg fra det forrige bare ved at du i stedet for kunden må angi lageret som leveringen skal utføres fra. Valglisten for partiet blir automatisk kompilert etter at delen er valgt. Brukeren kan generere en rapport om reservedelsbalanser:
Her kan vi se gjenværende varer på valgt lager. Avmerkingsboksene til høyre for lageret lar deg konfigurere filtrering og sortering. Listen har ikke en eksplisitt lodddeling for de delene den er påkrevd for. Saldoene for hvert batchnummer for den valgte reservedelen kan ses ved å bruke navigasjonslenken til høyre.
Ekspertkommentar: i denne økten (modulen) dukket batchregnskap opp for første gang. Deltakerne ble pålagt å redegjøre for forbruksvarer og varer ikke bare for seg selv, men også etter parti. Generelt er oppgaven perfekt for 1C:Enterprise-plattformen – men det hele måtte utvikles fra bunnen av og fullføres på 2.5 timer.
Økt 5
I den femte økten ble vi tildelt funksjonaliteten til brønnledelse. For letegrupper var det nødvendig å lage en mobilapplikasjon som skulle redegjøre for olje- eller gassproduksjonsbrønner. Her var det nødvendig å motta en liste over gjeldende brønner fra serveren og vise den valgte brønnen grafisk etter lag (jord, sand, stein, olje), under hensyntagen til dybden til hvert lag. I tillegg måtte applikasjonen tillate å oppdatere informasjon om brønnen og legge til nye brønner. For denne applikasjonen stiller kunden spesielle driftsbetingelser i offline- og onlinemodus (kontroll av kommunikasjon med serveren) - kontrollerer kommunikasjonen med serveren hvert 5. sekund og endrer funksjonaliteten til applikasjonen avhengig av serverens tilgjengelighet.
Cyril: Når du velger en brønn, vises et søylediagram som fremhever lagene opp til olje- eller gassforekomstene. For hvert lag lagres dets navn, farge og forekomstområde. På grunn av designfunksjonene hjelper ikke diagrammene som er innebygd i plattformen, men regnearkdokumentet takler oppgaven perfekt. Brønner kan opprettes og endres:
Bortsett fra flere idiotsikker beskyttelse, var det ingenting interessant med denne formen.
Deretter ble det foreslått å kontrollere tilkoblingen til serveren. Vi prøver å koble til hvert 5. sekund. Hvis det ikke fungerer, begrenser vi funksjonaliteten til applikasjonen og viser en melding.
Ekspertkommentar: Oppgaven til denne økten er interessant først og fremst på grunn av dens grafiske muligheter. Deltakere som brukte 1C:Enterprise-plattformen løste det på to forskjellige måter - noen ved hjelp av en diagrammekanisme, andre ved hjelp av et regnearkdokument. Hver metode har sine fordeler og ulemper. Som en del av avgjørelsen under WorldSkills-mesterskapet var tiden nøkkelen (husk tidsbegrensningen igjen). En separat interessant oppgave er å pinge serveren hvert 5. sekund og endre oppførselen til mobilapplikasjonen avhengig av serverens tilgjengelighet eller utilgjengelighet.
Økt 6
Det ble foreslått å opprette et arbeidsområde for toppledelsen – Dashboard. På en skjerm var det nødvendig å vise selskapets generelle ytelsesindikatorer for en spesifisert periode i grafisk og tabellform. Hovedskjemaet er kostnadsrapporten:
I tillegg til Dashboard, var det nødvendig å implementere distribusjon av reservedeler for reparasjoner av eiendeler ved bruk av FIFO/LIFO/«Billigst går først»-avskrivningsmetoder.
Ved distribusjon ble det tatt hensyn til batchregnskap, balansekontroll og beskyttelse mot uautoriserte brukerhandlinger («fool protection») benyttet.
Cyril: For å løse ble verditabeller med programvaregenerering av kolonner brukt, siden det kan være et vilkårlig antall av dem:
- Den første tabellen er ansvarlig for de totale kostnadene til avdelinger per måned. De mest ulønnsomme og lønnsomme divisjonene er markert med henholdsvis rødt og grønt.
- Den andre tabellen viser de dyreste og mest brukte delene for hver måned. Hvis det er flere deler som oppfyller kriteriene, skal de vises i én celle, atskilt med komma.
- De dyreste eiendelene (i form av reservedelskostnader) vises i den første raden i den tredje tabellen. Den andre linjen viser divisjonen som eiendelen ovenfor tilhører. Hvis det er to dyreste eiendeler med samme kostnader, bør de vises i samme celle, atskilt med komma.
Diagrammene ble vist ved hjelp av de innebygde mekanismene på plattformen, og fylt ut programmatisk ved hjelp av spørringer.
Det ble også foreslått å implementere støtte til flerspråklighet. Programmet laster XML-filer med lokalisering av grensesnittelementer, og skjemaet skal tegnes på nytt ved valg av språk i nedtrekkslisten.
Når du klikker på knappen i nedre venstre hjørne av skjermen, åpnes lagerstyringsskjemaet:
I dette skjemaet begynner vi endelig å bruke deler på reparasjoner. Her finner vi først delene vi trenger for å reparere eiendelen. Basert på de valgte feltene og distribusjonsmetoden (FIFO, LIFO eller minstepris), vises treffene som er funnet eller en melding hvis det ikke er treff. Du kan deretter merke delene som ment å reparere den eiendelen. Balansekontroll er relevant for gjeldende økt. Hvis vi allerede har tildelt detaljer, kan de ikke lenger bli funnet.
Ekspertkommentar: veldig interessant økt. Den utnytter mulighetene til 1C:Enterprise-plattformen maksimalt – her er kompetent arbeid med virtuelle tabeller av akkumuleringsregistre, og programmatisk arbeid med skjemaelementer (for det første - tabeller, for det andre - overskrifter), og diagrammer. Og til og med LIFO/FIFO ved analyse av inventar, resultat-/tapanalyse osv.
Økt 7
På slutten av oppgaven (sesjon 7) leverte kunden programvare (exe-fil) for prosjektaktiviteter og en kort video om arbeidet med det. Det var nødvendig å utføre reverse engineering og, basert på dette, lage 2 diagrammer: et use case-diagram og et entity-relationship-diagram. I tillegg ble det stilt noen krav for å lage programvare i fremtiden - det var nødvendig å lage et grensesnittoppsett i henhold til disse kravene.
I følge konkurransevilkårene var det kun MS Visio som var pålagt å lage diagrammer.
Ekspertkommentar: i denne økten ble funksjonene til 1C:Enterprise-plattformen praktisk talt ikke brukt. Diagrammer for konkurransebetingelsene ble laget i MS Visio. Men en prototype av grensesnittet kan lages i en tom 1C-informasjonsbase.
Generelle notater
I begynnelsen av hver økt ble det foreslått å importere data ved hjelp av et SQL-skript. Dette var den største ulempen med å bruke 1C sammenlignet med C#, siden vi brukte minst en halvtime på å destillere data til eksterne datakilder, lage våre egne tabeller og flytte rader fra eksterne kilder inn i tabellene våre. Resten trengte bare å klikke på Utfør-knappen i Microsoft SQL Studio.
Av åpenbare grunner er det ikke en god idé å lagre data på en mobilenhet. Derfor opprettet vi en serverbase under mobile økter. De lagret data der og ga tilgang til dem via http-tjenester.
Ekspertkommentar: 1C/ikke-1C-balansen er interessant her - mens 1C:Enterprise-programmerere brukte mye tid på å koble til en ekstern DBMS (Kirill nevnte dette separat ovenfor), C#/Java (Android Studio for mobilutvikling) brukte tid på andre områder - grensesnitt, skrive mer kode. Derfor var resultatene av hver økt uforutsigbare og ekstremt interessante for alle eksperter. Og denne intrigen forble til slutten - bare se på finalebordet med vinnere med poengfordeling.
Kirill fullførte historien :)
Avslutningsvis bør det huskes at utøveren ikke trengte å "bare programmere oppgaven i henhold til de tekniske spesifikasjonene" - han måtte analysere oppgaven, velge blokker for implementering av underoppgaver, designe dem og bestemme nøyaktig hva han ville være i stand til å implementere fra dette på ekstremt korte tildelte tid. Alle de 4 dagene måtte jeg opptre under sterkt tidspress, og startet ofte hver påfølgende økt fra bunnen av. Selv en voksenspesialist med mange års erfaring i bransjen vil ha store problemer med å fullføre den tildelte oppgaven for økten 100 % innen avsatt tid.
Det vedtatte vurderingssystemet fortjener spesiell omtale.
For hver økt utvikler oppgaveforfatterne et komplekst system med kriterier, inkludert kontroll av funksjonalitet, korrekt drift, krav til applikasjonsgrensesnittet, og til og med å følge en stilguide spesielt gitt til deltakerne av selskapet de utvikler sine løsninger for.
Evalueringskriteriene er veldig fingranulerte - med den totale kostnaden for sesjonsoppgaven på titalls poeng, kan oppfyllelse av et eller annet kriterium gi deltakeren tideler av et poeng. Dette oppnår et ekstremt høyt og objektivt nivå for å evaluere resultatene til hver deltaker i konkurransen.
Funn
De endelige resultatene var imponerende.
I en bitter kamp vant Kirill Pavkin fra Russland, som brukte 1C:Enterprise-plattformen. Kirill er 17 år gammel, han er fra Stavropol.
Bokstavelig talt tideler av et poeng skilte vinneren fra hans forfølgere. Andreplassen ble tatt av en deltaker fra Taiwan. Den samlede tabellen over de seks beste resultatene ser slik ut:
Selvfølgelig vant Kirill takket være hans talent, kunnskap og ferdigheter.
Vi legger imidlertid merke til at alle tre deltakerne som brukte 1C:Enterprise-plattformen som verktøy ble inkludert i topp fem – som er en ubetinget bekreftelse på verdensnivået til 1C:Enterprise-teknologi.
Etter resultatene av konkurransen ble vinnerne premiert på KazanExpo mediesenter; gutta mottok rene gullmedaljer (i samsvar med deres plass) og pengepremier. Gutta fikk også sertifikater som tillot dem å gjennomgå et internship ved 1C.
Kilde: www.habr.com