ANTROSIOS BA PROGRAMAVIMO VARŽYBOS

2015 03 10 · 3 minutės

2015 m. kovo 10 d. vyko antrosios Baltic Amadeus komandinės programavimo varžybos. Aštuonios komandos, kiekviena sudaryta iš keturių žmonių, rašė programas, kurios dienos pabaigoje rungėsi tarpusavyje žaisdamos Tron Light Cycles žaidimą. Titas buvo vienas iš teisėjų ir toliau pateikiami jo įspūdžiai iš renginio.

Pasiruošimas

Šių varžybų akcentu buvo tai, kad galutinėje rungtyje dalyvavo vien tik kompiuteriai ir programos, ir joks žmogaus įsikišimas nebuvo toleruojamas.

Tačiau, norint turėti visiškai automatizuotus žaidimus, reikia stabilios programinės sąsajos, kad programos galėtų lengvai keistis reikiamais duomenimis, ir grafinės sąsajos, nes gi neįdomu žmonėms tik į skaičiukus loguose žiūrėti.

Taigi iniciatyvinė grupė (Antanas, Tomaš ir Titas) pasidalijome sritimis ir pradėjome dirbti. Antanas apsiėmė daryti serverinę dalį, Tomaš – UI toolsus (Debug Client ir Admin), man teko parašyti žaidybinį klientą Java priemonėmis, naudojant AJAX užklausas.

Logika tokia – Tomaš’as naudos SOAP web service’us, taigi pratestuos iš tos pusės, o aš įsitikinsiu, kad ir kitomis, nei .NET technologijomis per Ajax bus galima įvykdyti užduotį.

Ir antras labai svarbus tikslas – reikia man tiksliai (kiek tai įmanoma) matuoti laiką, kiek užtrunka parašyti tokį klientą. Juk komandoms programavimui bus skirtos tik 4 valandos, reikia įsitikinti, kad tiek laiko užteks.

Taigi, prisiminęs išmoktas pamokas per pirmąsias programuotojų varžybas, nusprendžiau, kad eisiu tuo keliu, kuris galėtų užtikrinti rezultatą, o tai reiškia paprastas, tiesmukiškas programavimas, be sudėtingų struktūrų ar abstrakcijų, nebijant įhardcodinti tam tikrų reikšmių ir kitokios „negerosios” programavimo praktikos, kurių paprastai vengiame kasdieniuose projektuose.

Laikrodis paleistas, ir kuriu projektą nuo nulio.

00:30:00 – 00:30:00 – Neveikia Json užklausos, nors HTTP POST’ai eina normaliai, bet atsakymas grįžta HTTP 403

01:15:00 – Su Tomašo pagalba Json jau veikia, pasirodo problema buvo, kad aš bandžiau naudoti Json RPC, o reikėjo seną gerą Ajax formatą pritaikyti

02:00:00 – Vis dar nepavyksta padaryti CompleteLogin, nesutampa ChallengeResponse’ai (mano apskaičiuotas su tuo, kurio tikisi serveris)

02:15:00 – Trumpas žvilgsnis į serverio kodą ir jau viskas veikia, pasirodo man buvo pateikę blogą challengeResponse skaičiavimo formulę, užteko įdėti gerą ir viskas važiuoja. (Taip pat pasižymėjau pastabą, kad dokumentacijoje reikės patikrinti šią vietą)

03:00:00 – Jau pavyksta susikurti žaidėją, bet va su žaidimo pradžios laukimu yra niuansas – nes jei žaidimas dar nevyksta serveris žaidimo ID grąžina null, o naudotai Java JSON bibliotekai tai labai nepatinka. Sutarėme jog tokiu atveju grąžins -1.

04:00:00 – po dar kelių bugų serverio pusėje pataisymo, jau programa sugeba pradėti žaisti ir padaryti ėjimą, tiesa algoritmas labai paprastas.

04:40:00 – iki galo įgyvendintas žaidimo flow’as, programa moka pasijungti ir sužaisti iki galo ir tvarkingai išeiti iš užbaigto žaidimo. Tiesa, nėra crash recovery.

05:15:00 – Jau yra ir crash recovery tad klientas formaliai užbaigtas.

06:30:00 – Refaktorinau kodą, padariau multithread ir programa gali žaisti už 1-9 žaidėjus vienu metu.

~07:00:00 – Dar vienas patobulinimas – parametrizuota programa, galima nurodyti žaidėjų skaičių, servą prie kurio jungtis, loginimo lygį, ir užlaikymus prieš pradedant žaisti, bei tarp ėjimų (užlaikymų reikia dėl bonusų/baudos taškų skaičiavimo ištestavimo).

Taigi vienas žmogus, pradėjęs nuo nulio, ir be išankstinio pasiruošimo, per grubiai 5.5h parašė veikiančią programą. Keturių žmonių komandai tikrai turi būti įveikiama užduotis sutilpti ir į keturias valandas. Tuo labiau kad pažiūrėjus į sugaištus laikus matėsi, jog daugiausiai laiko praleidau kovodamas su techniniais iššūkiais: web servisų iškvietimais, autentikacijos raktų skaičiavimu ir pan. Savo žaidimo algoritmui sugaišau vos 15 min. Algoritmas buvo toks – eik kur laisva, prioritetai: į viršų, į apačią, į dešinę, į kairę.

Šio mūsų turnyro pagrindinis tikslas buvo, kad žmonės daugiau laiko sugaištų prie algoritmų o ne prie techninių integracijų, tad nutarėme ne tik gerokai anksčiau paviešinti užduotis, bet ir suteikti serverio API (apkarpytus) ir pagalbines programas, kad komandos galėtų išbandyti prisijungimus ir pereiti per visus integracinius uždavinius ir per patį konkursą negaištų tam per daug laiko.

Eiga

Jau per pačias pirmas minutes buvo matyti, kurios komandos stengėsi ir iš anksto ruošėsi, o kurios tik vietoje pradėjo aiškintis.

Pirma kliūtis buvo GIT serveris. Nors informacija apie prisijungimą iš išorės buvo visiems pateikta iš anksto, beveik niekas nebuvo pabandęs to atlikti, todėl kilo nesklandumų su self-signed certificate’u.

Džiugu buvo matyti, kad komandos sąžiningai laikėsi taisyklių ir nebuvo kopijuojamas iš anksto paruoštas kodas.

Didelis déjà vu: kelios komandos pradėjo programavimą nuo interface’ų aprašymų, kas iš karto galvoje uždegė raudoną lemputę – juk per pirmas programavimo varžybas tai buvo pagrindinė priežastis, dėl kurio daug komandų programos veikė blogai – bandydami padaryti „teisingai pagal OOP taisykles”, neįvertino laiko poreikio ir nespėjo.

Taip pat užkliuvo darbo organizavimas – vienos komandos iš anksto pasidalijo, kas prie kokios srities dirbs: komunikacija su serveriu, žaidimo algoritmas, žemėlapių ruošimas ir t.t. Kitos gi vietoje bandė organizuotis: ko mums dabar reikia? A šito – kas jį darys? Nors mes praktikuojame Agile, bet Agile turi struktūrizuotą planavimo procesą o ne ad-hoc užduočių pasimėtymus.

Neramumą sukėlė ir tai, kad praėjus pusei skirto laiko, dar ne visos komandos buvo pabandžiusios programiškai pasijungti prie serverio. Kaip vėliau paaiškėjo, vienai komandai tai buvo lemiamas veiksnys, nes visas jų algoritmas buvo nieko vertas, kai nepavyksta atlikti pradinio autentifikavimo.

Teisėjai sukėlė paniką, kai likus vienai valandai pranešė, jog gali būti žemėlapiai be išorinių sienų. Per klausimų-atsakymų sesiją niekam nekilo mintis paklausti apie tokią galimybę, bet mes privalėjome apie tai įspėti, nes buvo paruoštų žemėlapių būtent tokiam scenarijui.

Rezultatai tokie: viena komanda visiškai neparengė veikiančios programos, trys komandos iškrito pačiame pirmame rate dėl techninių problemų: pastrigdavo programa, ar iš karto nuvažiuodavo į sieną.

Nugalėjo komanda, antrą kartą iš eilės programavusi Progress kalba, naudodami paprastą procedūrinį programavimą. Nors tai ne ta pati komanda, kuri nugalėjo pirmose programavimo varžybose, bet principai tie patys.

Išvados

Renginys praėjo gana sklandžiai, ypač sparčiai antroji – būtent žaidimo dalis, kas yra priešingybė pirmoms programavimo varžybos. Taip įvyko dėl visiškai automatizuotų programų.

Ne visi dar supranta programavimo varžybų pagrindinius tikslus. Tai kūrybiškumo skatinimas, noras kad daugiau dalyvių susipažintų su iki šiol nenaudotomis technologijomis (web service’ai šiais metais), išmoktų planuoti ir prioretizuoti užduotis esant ypač įtemptam grafikui (vos keturios valandos užduočiai atlikti) ir skatinti komandos narių tarpusavio bendradarbiavimą streso sąlygomis. Juk buvo komandų, sudarytų ne vien iš developių, ir jos labai gerai pasirodė. Kodėl? Čia reikėtų jų paklausti, kaip joms pavyko viską organizuoti ir dėl visko sutarti.

Šių metų varžybos kilstelėjo kartelę, kitais metais reikės daugiau pavargti, kad renginys būtų dar patrauklesnis – ypač žiūrovams. Manau gal tik 20% įmonės darbuotojų liko savo darbo vietose, ir neatėjo pažiūrėti, kai jau vyko antras etapas – programų dvikovos.

Serverio ir pagalbinių programų išeities kodai yra BA GitHub’e (https://github.com/BalticAmadeus/EnjoyTron). Daug kam ten tikrai bus naudinga mokomoji medžiaga, pvz., kaip sinchronizuoti raundų pradžias/pabaigas. Tai būtų labai gražus R&D pratęsimas – mokytis iš kitų programų.