🥇Koodime–pitsat

Tere, Habr. Me korraldasime spontaanselt esimese sisemise hackathoni. Tahtsin jagada teiega oma muresid ja järeldusi selle kahe nädalase ettevalmistuse kohta, samuti projekte, mis selle käigus tekkisid.

Igav osa neile, kes huvituvad turundusest

Alustan väikese looga.

Aprilli algus. Meie kontoris toimub esimene hackathon MskDotNet Community. Tatuini lahing on käimas, meie galaktikas seekord. Laupäev. 20 meeskonda. Pizza. Kõik on väga kodune (tõendid). Õhupall R2-D2 piilub saalis. Meeskonnad kirjutavad kõige õiget algoritmi, et läbida kõige ohtlikum võidusõit kaardil. Me lükkame esimesed sõidud edasi. Küpsised ja kohv päästavad päeva. Ootasime korraldajatega, et laupäeval lahkub palju inimesi pärast lõuna. Aga ei. 12 tundi kodeerimist on möödas. Finaal. Midagi läheb katki, midagi ei käivitu. Kuid kõik on õnnelikud. Meie meeskond võidab. Oleme kahe korda õnnelikud.

Jagame rõõmu Slacks ja mulle tuleb mõte: "Peame korraldama oma hackathoni." Kirjutan oma CTO-le Sašale. Vaikus.

Hommik. Joon kohvi kontoris. Näen selja tagant tulemas Sashat. "Liza, see on suurepärane! 21. aprillil on meil oluline kuupäev. Alustame!" Mis? Nii kiiresti? Mida? Olen keset aprilli Syktyvkarisse praktikale sõitmas. Ja olgu selle kõigega. Teeme ära.

Kaks nädalat on jäänud. Ma pole kunagi olnud ainuüksi hacketoni korraldaja. Isegi mitte siseürituse puhul. Loe artikleid selle teema kohta. Kohutav. Vaja on mitu kuud. Vaja on mitu inimest. Tuleb välja mõelda mälestusesemed, auhinnad, tingimused, ajakava, kaasata inimesi, mõista eesmärki, eelarvet. Võib-olla isegi elutähenduses selguse saamiseks. Ma kindlasti ei saa hakkama. Ja kuni sina lugesid ja valmistusid, on juba nädal möödunud. On viimane aeg jätta artiklid kõrvale ja midagi ette võtta.

Siin on meie kontrollnimekiri siseürituse hacketoni läbiviimiseks ühe nädalaga.

Plaani: rahulikult istud ja kirjutad nimekirja sellest, mida on hacketoni jaoks vajalik teha. 30 minutit.
Ülesanne: osalejad esitavad ja valivad ise projektid, mida nad tahavad luua Google Sheetsis. Taustateenus, 2 tundi.
Ajakava: kirjutad kiire ajajaotuse, arvestades 3 pausi ja lõpetamist. 20 minutit.
Meeskonnad: postitat sõnum hackathonist koos CDO ajakava ja IT-kanalitega Slackis/e-kirjades jne ning lood eraldi kanali hackathoniks. Seal kõik jagunevad meeskondadesse, samas kui määramata jäänud teevad seda hackathoni esimeses 5 minutit. Taustateenus, 2 tundi.
Tee mudelid: mõtleme merchandise'i kahe arendajaga, saadame disainerile joonistamiseks, saad valmis. Taustaprojekt, 3 päeva.
Hackathon: tuled kontorisse, koordineerid alguses kõiki, teed oma asju, loed Redditi, räägid uhke näoga igast pausist värskest pitsast, pildistad päikeseloojangut, kuulutad finaali välja, häälestate koos ja valite võitja. 1 päev.
Tähtede all: muidugi mõtled pidevalt sellele, et kõik läheks hästi. Loomulikult ei näe kõik sinu sõnumit ja mõnega on parem isiklikult rääkida. Loomulikult, kui keegi sind aitaks, oleks kõik ka kaks korda lihtsam (mind aitas imeline Aljona).

Mugavam osa hackathoni kuupäevast

Miks 21. aprill? See päev on meie jaoks eriline. Täpselt aasta tagasi, 21. aprillil, kukkusime koormuse all esmakordselt pärast Föderaalse Reklaamikampaania käivitamist. Järgmisel päeval, pühapäeval, oli meie meeskond tööl alates kella 8. Siis lõime Trello's tahvli `sundayhackathon` ja algas nädal, mil töötasime vahetustega 12 tundi päevas. Olukord oli nii kriitiline, et meil ei olnud isegi aega süüa, ja meid toitsid teised meeskonna liikmed.

Rohkem detailset juttu saate lugeda Fjodor Ovčinnikovi lehelt (meie CEO). Alates sellest ajast on palju muutunud, kuid seda kuupäeva me kindlasti ei unusta.

Sel aastal otsustasime, et see sündmus väärib mälestamiseks jäädvustamist ning parimates traditsioonides korraldasime esmakordselt Dodo sisemise hackathon'i, mis kestis 10 tundi.

Selle hackathon'i projektide kõige vähem igav osa

Disclaimer: kõik kirjeldused on kirjutanud meie inimesed, seega ei ole teksti autorlus minu.

Oleg Lёrnigin (masinõpe)

Dima Kochnjev, Sasha Andronov (@alexandronov)

Soovisime luua närvivõrku, mis suudaks pildi pealt teada saada, milline pits on. Lõpuks tegime väga lihtsa ja mängulise – see tuvastab 10 pitsat, saime umbes päevaga (~10 tundi) asja toimimise osas päris hästi aru.

Me mõistsime, et tööstus on jõudnud tasemele, kus tavaline arendaja võib võtta valmis raamatukogud, lugeda dokumentatsiooni ja koolitada oma närvivõrku ilma sügavate teadmiste omamata. Ja see töötab piisavalt hästi reaalses probleemide lahendamiseks.

Kasutasime tööriistu:

imageai — mugav ja lihtne raamatukogu masinõppe ja nutika nägemise jaoks.
Proovisime kahte mudelit – ResNet50, Yolo.
Koodi kirjutasime loomulikult Pythonis.

Meil oli 11000 fotot, kuid nende seas osutus peaaegu 3/4 prügi. Jäänud piltides olid erinevad, sobimatud nurgad. Lõpuks valisime välja valmis mudeli (mis lihtsalt oskab pitsat leida) ja selle abil eemaldasime kõige halvemad. Seejärel, pildi nimetuses oli pitsanimi - nii korraldasime need kaustadesse, kuid selgus, et nimed ei lange kokku tegelikkusega ja tuli juba käsitsi puhastada. Lõpuks jäi umbes 500-600 fotot, mõistetavalt on see tühine kogus, kuid siiski oli seda piisavalt, et 10 pitsat üksteisest eristada.

Ketta treenimiseks kasutasime Azure'is odavaimat virtuaalmasinat NVIDIA Tesla K80-l. Sellel treenisime 100 ajast, kuid oli selge, et võrk oli juba pärast 50 ajast küllastunud, kuna andmestik oli liiga väike.

Tegelikult on kogu probleem hea andmete puudumine.

Me, võib-olla, segasime natuke termineid, kuid tuleb arvesse võtta, et meil pole üldse kogemust kõigi nende asjadega töötamisel.

GUI for NOOBS (pitsade tellimise konsool)

Misha Kumachyov (Ceridan), Zhena Bikkinin, Zhena Vasiliev

Me olime valmis loonud konsooli rakenduse prototüübi, mille abil saab tellida pitsat terminali või käsurea kaudu, või isegi integreerida selle deploy pipeline'i, et edukal väljalaskmisel tuua pitsat kontorisse.

Töö jagunes mitmeks osaks: uurisime, kuidas meie API mobiilirakendustele toimib, ja viisime kokku oma CLI kasutades oclif ja seadistasime loodud paketi avaldamise. Viimase ülesandega seotud mõned ebameeldivad minutid hakathon'i lõpus. Kõik töötas meil kohapeal ning isegi vanad avaldatud versioonid töötasid, kuid uued (kus oli lisatud rohkem ägedaid funktsioone ja emotikone) ei hakanud tööle. Me kulutasime umbes 40 minutit, et mõista, mis valesti läks, kuid lõpuks hakkas kõik maagiliselt ise töötama).

Meie maksimaalsed eesmärgid hakathon'iks olid tõeline pitsatellimus meie CLI kaudu. Testisime seda kümneid kordi katse keskkonnas, kuid mul olid siiski käed värisevad, kui ma tellimusi tootmisesse sisestasin.

Kokkuvõttes — me saime sellega hakkama!

CourierGo

Anton Bružmelëv (autor), Vanja Zverevi, Gleb Lesnikov (entropy), Andrej Sarafanov

Võtsime inspiratsiooni "Kuriiri rakendusest".

Eellugu ettevalmistusest.Alguses mõtlesin, millised funktsioonid võiks rakenduses olla? Tekkis selline funktsioonide nimekiri:

Rakendus logib sisse kohaletoimetamise kassasse koodi abil.
Rakenduses on kohe nähtavad saadaval olevad tellimused ja tellimused, mida tuleb võtta.
Kuriir märgib tellimuse ja võtab selle sõiduks.
Kuriirile kuvatakse arvutatud aeg ja kas ta jõuab kohale või mitte.
Klient näeb, et kuriir on teele asunud.
Kliendile hakkab kuvatakse kuriiri asukoht kaardil ja arvutatud aeg.
Kuriir saab rakendusest kirjutada kliendile vestluses.
Klient saab rakendusest kirjutada kuriirile vestluses.
Viie minuti jooksul enne saabumist saab klient sõnumi, et kuriir on lähedal, olge valmis.
Kuriir märgib rakenduses, et ta on kohal ja ootab.
Kuriir helistab rakendusest ühe klikkiga ja teatab, et (tuleb, on lähenemas jne).
Klient aktsepteerib tellimuse ja sisestab rakendusest või SMS-iga saadud PIN-koodi, et kinnitada kohaletoimetamist (nagu allkiri). Et kuriir ei saaks kohaletoimetamist enne tähtaega lõpetada, kui viibib.
Tellimus märgitakse süsteemis kohaletoimetatuks.

Lisaks paar alternatiivset stsenaariumi:

Kuller saab tellimuse märgata kui mitte kohale toimetatud ning valida põhjuse.
Kuller võib hilinemise korral ühe nupuvajutusega saata elektroonilise sertifikaadi SMS-i kaudu. Või sertifikaat saadetakse automaatselt, kui tarne tähtaega ei täideta.

Tunde perspektiivsuse ja projekti vajalikkusest laadis kindlasti energiat.

Järgmisel päeval käisime meeskonnaga lõunal ja arutasime, milline võiks olla rakenduse minimaalne funktsionaalsus.

Tulemuseks tekkis järgmine nimekiri asjadest, mida hackathonil pidime ära tegema:

Logi sisse kohaletoimetamise kassasse.
Kuva praegune asukoht.
Saata andmed välishaudele (koordinaadid, tellimus võetud, tellimus toimetatud).
Saada andmed välishaudele (kulleri praegused tellimused).
Saada teade, et tellimus on võetud toimetamiseks/toimetatud.
Kuva kulleri praegune asukoht kaardil veebisaidil.

Põhitöö, nagu tundus, seisnes tagaplaani loomises, rakenduse endi (pärast arutelusid valisime rakenduse arendamiseks ReactNative, täpsemalt ümber selle — expo.io, mis ei vaja kirjutada natiivset koodi). Backend'i osas oli alguses lootus Vanya Zverevi peale, kes oli meie teenuse ja k8s'i malli osas kogenud (mida ta endale ka võttis). ReactNative'i katsuda hakkasime mina ja Andrei Sarafanov.

Otsustasin kohe proovida luua töötavat repot projekti jaoks. Kell 12 öösel sattusin sellele, et ReactNative'is töötab geolokatsioon taustal halvasti, kui ei kirjuta natiivset koodi, ja olin pisut frustreeritud. Siis mõistsin, et loen mitte expo.io raamistikku, vaid ReactNative'i dokumentatsiooni. Lõpuks sain õhtuks juba aru, kuidas saada expo.io kaudu praegust asukohta ja joonistada eraldi ekraanid (nt sisselogimise, tellimuse kuvamiseks jne).

Hommikul hackathon'il meelitasime Gleb'i oma ülipotentsiaalsesse projekti. Kiirelt koostasime plaani, mida teha.

Tehtud viga, kui proovisime projekti malliga suhtlust korraldada mitte HTTP kaudu, vaid GRPC kaudu, kuna keegi ei osanud JavaScripti jaoks GRPC-klienti kokku panna. Lõpuks, kulutades sellele umbes poolteist tundi, loobusime sellest ideest. Selle tõttu asusid poisid ka backendis valmis GRPC-serveri ümber tegema WebApi peale. Poolteise tunni pärast saime lõpuks rakenduse suhtlemise backendiga seadistatud, imet. Kuid sel ajal lõpetas Gleb peaaegu k8s-is deploy'i ja lisaks automaatse deploy'i masterisse commitide põhjal. 🙂

Andmehoidjana valisime MySQL, et vähemalt andmebaasi osas ei riskiks (olid mõtted CosmosDb peale).

Kokkuvõttes:

Realisime kohalike koordinaatide salvestamise kullerist rakenduses andmebaasi.
Lisatud on RabbitMQ ja tellitud teated kulleri tellimuse võtmise kohta, et kuvada tellimus kohe rakenduses kullerile.
Alustasime tellimuse kohaletoimetamise aja salvestamist andmebaasi, pärast seda kui kuller vajutas rakenduses nuppu. Ei jõudnud lisada sündmuste edastamist tagasi Rabbiti, et tellimus on kohaletoimetatud.
Tehtud on kaartide kuvamine lehe currentorder peal, kus on kuvatud kulleri praegune asukoht. Kuid see funktsionaalsus jäi veidi poolikuks, kuna keskkonnas ei õnnestunud CORS-i seadistada, et saada koordinaate meie uuest teenusest.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Soovisime rakendada OpenID Connect pakkujat, kuna hetkel kasutame enda arendatud autentimise protokolli, mis toob kaasa mitmeid raskusi: kohandatud klienditeegid, ebamugav koostöö väliste partneritega ja võimalikud turvaprobleemid (ikka on OAuth2.0 ja OpenID Connect standardse rakenduse puhul ohutud, meie lahenduse osas pole ma kindel).

Oleme loonud eraldi teenuse, mis jäljendab isikuandmete salvestamisteenust, et luua väike Country-Agnostic autentimise teenuse mudel, mis käsitleks isikuandmeid eraldi teenuses (see looks tulevikus võimaluse luua üks teenus, mille abil saaks logida sisse mis tahes riigis ning samal ajal vastata GDPR-ile ja teistele seadustele). Selle osa tegime nagu teenusepakkuja ja seostasime need edukalt. Edasi pidi olema loodud API, mis oleks kaitstud teenusepakkuja väljastatud tokenitega, toetama nende introspektsiooni teenusepakkuja kaudu ja edastama kaitstud andmeid, kui päring vastas autoriseerimise poliitikatele (kontrollime, et kasutaja on autentitud Bearer skeemi järgi, tema tokenis on määratud ulatus ja kasutajal on luba, mis lubab kutse tegemist). See osa tehti samuti ära. Viimaseks komponendiks oli JavaScripti klient, kellele väljastati token, millega ta kutsus esile kaitstud API. Seda osa me teha ei jõudnud. See tähendab, et kogu funktsionaalne osa oli valmis, kuid esikülg, et demonstreerida kogu süsteemi toimimist, ei olnud valmis.

E-E-E (mäng)

Dima Afontšenko, Sasha Konovalov

Loome väikse mängu, kus sinised käed viskavad viili pitsale. Kui viskad viili valesti, ilmub ekraanile kurb tekst „Tagasi lükatud”, ja kui viil on õigesti visatud, siis kuulete juhuslikku fakti pitsa kohta.

Soovisime teha teise taseme tomatite viskamiseks, aga ei jõudnud.

Lühike jätk: kes võitis?

Enne hackathonit rääkisime noortega ja küsisin, millist auhinda nad sooviksid saada, kui nad võidavad. Selgus, et kõige väärtuslikum auhind oleks „tee produktsiooni”.

Seega oodake varsti meilt mängu, kus käed viskavad pepperoni pitsale.