🥇Kodējam–pica

Sveiki, Habr. Mēs spontāni rīkojām savu pirmo iekšējo hakatonu. Nolēmu padalīties ar savām sāpēm un secinājumiem par tā sagatavošanu divu nedēļu laikā, kā arī ar projektiem, kas tapuši.

Šī daļa ir garlaicīga tiem, kuri interesējas par mārketingu.

Sāku ar mazu stāstu.

Aprīļa sākums. Mūsu birojā notiek pirmais hakatons MskDotNet kopienai. Cīņa par Tatuīnu ir pilnā sparā, šoreiz mūsu galaktikā. Sestdiena. 20 komandas. Pica. Viss ir ļoti sirsnīgi (pierādījumi). Inflatable R2-D2 uzmirdz zālē. Komandas raksta vispareizākos algoritmus, lai veiktu visbīstamāko sacensību kartē. Pārvietojam pirmajās sacensībās startu. Sīkumi un kafija glābj. Mēs ar organizatoriem gaidījām, ka sestdien daudzi dosies prom pēc pusdienām. Bet nē. 12 stundas kodēšanas ir aiz muguras. Fināls. Kaut kas atslēdzas, kaut kas nepalaižas. Bet visi ir laimīgi. Uzvar mūsu komanda. Mēs esam divtik laimīgi.

Dalos ar prieku Slack un man prātā ienāk ideja: "Jāizveido savs hakatons." Rakstu mūsu CTO Sasham. Klusums.

Rīts. Dzeru kafiju birojā. Redzu, ka no aizmugures tuvojas Sashas. "Liza, tas taču ir lieliski! Mums tieši 21. aprīlī ir svarīga datums. Davai, darīsim!" WTF!? Tik ātri? Ko? Man jādodas uz Syktyvkar stažēties aprīļa vidū. Bet kas ar to? Lai notiek.

Atlicis 2 nedēļas. Es nekad neesmu bijusi hakatona vienīgā organizatore. Lai arī iekšējā. Lasu rakstus par šo tēmu. Šausmas. Nepieciešami daži mēneši. Nepieciešami daži cilvēki. Jāizdomā merch, balvas, nosacījumi, grafiks, jāinteresē, jāizprot mērķis, budžeti. Varbūt pat jāizpēta dzīves jēga. Es noteikti nenokļūšu laikus. Un kamēr tu lasīji un gatavojies, nedēļa jau ir pagājusi. Laiks aizmirst par rakstiem un sākt kaut ko darīt.

Uzmanību — mūsu kontrolsaraksts iekšējā hakatona rīkošanai 1 nedēļas laikā

Plāns: mierīgi sēdies un saraksti, kas ir jāizdara hakatonam. 30 minūtes.
Uzdevums: dalībnieki paši piedāvā un izvēlas projektus, kurus vēlas izveidot Google Sheets. Fona uzdevums, 2 stundas.
Grafiks: uz ceļgaliem raksti īsu laika sadalījumu, ņemot vērā 3 pārtraukumus un finālu. 20 minūtes.
Komandas: publicē paziņojumu par hakatonu ar grafiku no CTO IT kanālos Slack/pasta/utt. un izveido atsevišķu kanālu hakatonam. Tajā visi sadalās komandās, bet neskaidri nodalītie to izdarīs pirmajās 5 minūtēs hakatona. Fona uzdevums, 2 stundas.
Bonusi: izdomā merch ar diviem izstrādātājiem, nodod dizainerim zīmēšanai, saņem gatavo. Fona uzdevums, 3 dienas.
Hackatons: ierodies birojā, koordinē visus sākumā, darbojies savās lietās, lasi Reddit, nopietnā veidā katrā pārtraukumā paziņo par svaigu picu, fotografē saulrietu, paziņo par finālu, kopīgi balso un izvēlies uzvarētāju. 1 diena.
Zvaigznītes simptomātika: protams, tu pastāvīgi domā par to, lai viss notiktu labi. Protams, ne visi redzēs tavu ziņojumu, un dažiem labāk parunāt klātienē. Protams, ja kāds tev palīdzēs, viss kļūs divreiz vienkāršāk (man palīdzēja lieliskā Aljona).

Mazāk garlaicīgā daļa par hackatona datumu

Kāpēc 21. aprīlis? Šī diena ir svarīga mums. Tieši pirms gada, 21. aprīlī, mēs sabruka zem slodzes pirmajās brīvdienās pēc Federālā Reklāmas Kampaņas sākuma. Nākamajā dienā, svētdienā, mūsu komanda strādāja no 8 rītā. Toreiz mēs izveidojām Trello dēli sundayhackathon un aizsākām nedēļu maiņu darbā pa 12 stundām dienā. Situācija bija tik kritiska, ka nebija laika pat ēst, un mūs baroja citu komandu puiši.

Sīkāku stāstu var izlasīt Fjodora Očinnikova lapā (mūsu izpilddirektors). Kopš tā laika mēs daudz ko mainījām, bet šo datumu noteikti neaizmirsīsim.

Šogad mēs nolēmām, ka šim notikumam jādod piemiņas nozīme un labākajās tradīcijās rīkojām pirmo vēsturē Dodo iekšējo hackatonu, kurš ilga 10 stundas.

Visinteresantākā daļa par hackatona projektiem

Izskaidrojums: visus aprakstus rakstījuši paši puiši, tāpēc tekstu autorība nav mana.

Oļegs Lērnings (mašīnmācība)

Dima Kočnevs, Sasha Andronovs (@alexandronov)

Vēlējāmies izveidot neirotīklu, kas spētu noteikt, kas ir pica fotoattēlā bez jebkādām zināšanām. Beigās izveidojām ļoti vienkāršu un rotaļu – tā atpazīst 10 picu veidus, apmēram sapratām, kā viss darbojas, cik iespējams vienā dienā (~10 stundas).

Īpaši, mēs sapratām, ka nozare ir sasniegusi līmeni, kad parasts izstrādātājs var izmantot gatavas bibliotēkas, izlasīt dokumentāciju un apmācīt savu neirotīklu bez dziļām priekšzināšanām. Un tas darbosies pietiekami labi, lai risinātu reālas problēmas.

Rīki, ko izmantojām:

imageai — ērta un vienkārša bibliotēka mašīnmācīšanās un datorredzes darbam.
Mēs izmēģinājām divas modeļus – ResNet50, Yolo.
Kodu, saprotams, rakstījām Python valodā.

Mums bija 11000 fotoattēlu, bet gandrīz 3/4 no tiem izrādījās nederīgi, bet atlikušajos bija dažādi, nepiemēroti skati. Galu galā mēs paņēmām gatavu modeli (kas vienkārši prot atrast picu) un ar tā palīdzību izsvērt visus atkritumus. Turklāt, fotogrāfiju nosaukumā bija picu nosaukums — tā mēs tās sakārtojām mapēs, bet izrādījās, ka nosaukumi nesakrīt ar realitāti, un bija jāiztīra ar rokām. Galu galā palika apmēram 500-600 fotoattēlu; skaidrs, ka tas ir niecīgs skaits, taču tomēr tā bija pietiekami, lai atšķirtu 10 picas.

Lai apmācītu tīklu, ņēmām lētāko virtuālo mašīnu Azure ar NVIDIA Tesla K80. Uz tās apmācījām 100 epohas, bet bija redzams, ka tīkla pārselēšana notika jau pēc 50 epohām, jo datu kopums bija mazs.

Principā - visa problēma ir labu datu trūkumā.

Mēs, iespējams, nedaudz sajaucām terminus, bet jāņem vērā, ka mums nav pieredzes darbā ar visām šīm lietām.

GUI for NOOBS (konsoles rīks picu pasūtīšanai)

Miša Komačevs (Ceridan), Ženija Bikiņins, Ženija Vasiļevs

Mēs izveidojām prototipu konsoles lietojumprogrammai geikiem, ar kuru var pasūtīt picu caur termināli vai komandrindu, vai pat iekļaut to izvietošanas procesā, lai, veiksmīgi veicot izlaidumu, piegādātu picu birojā.

Darbs tika sadalīts vairākās daļās: mēs pētot, kā darbojas mūsu API mobilajām lietojumprogrammām, izstrādājām savu CLI ar oclif un konfigurējām izveidotā pakotnes publicēšanu. Ar pēdējo uzdevumu tuvākā hakatona beigām saistījās dažas nepatīkamas minūtes. Mums viss strādāja lokāli un pat vecās publicētās pakotnes versijas darbojās, bet jaunas (kurās bija pievienotas vairāk foršas funkcijas un emocijzīmes) atteicās darboties. Mēs pavadījām apmēram 40 minūtes, lai saprastu, kas notika, bet galu galā viss maģiski pats darbojās).

Mūsu maksimālais mērķis hakatonā bija īsts picu pasūtījums birojā caur mūsu CLI. Mēs desmit reizes visu pārbaudījām testēšanas vidē, bet man tomēr trīcēja rokas, kad es ievadīju komandas produkcijā.

Kā rezultāts — mēs tomēr to izdarījām!

CourierGo

Antons Bružmeljovs (autors), Vanja Zvereva, Gļebs Lesņikovs (entropy), Andrejs Sarafanovs

Mēs ņēmām ideju "Kurjera lietotne".

Iepriekšējā stāsta par sagatavošanos.Sākumā es padomāju, kādas vispār funkcijas varētu būt lietotnē? Apmēram šāds funkcionalitātes saraksts radās:

Lietotne piesakās pie piegādes kases ar kodu.
Lietotnē tūlīt redzami pieejamie pasūtījumi, pasūtījumi, kurus jāņem.
Kurjers atzīmē pasūtījumu un ņem to ceļojumā.
Viņam tiek parādīts aprēķinātais laiks un vai viņš paspēs.
Klientam tiek parādīts, ka kurjers ir izbraucis.
Klientam sāk parādīt kurjera punktu kartē un aprēķināto laiku.
Kurjers var uzrakstīt klientam čatā no lietotnes.
Klients var uzrakstīt kurjeram čatā no lietotnes.
Piecām minūtēm pirms ierašanās klientam nāk ziņa, ka kurjers tuvojas, esiet gatavi.
Kurjers atzīmē lietotnē, ka viņš ir pienācis un gaida.
Kurjers zvana no lietotnes ar vienu klikšķi un informē, ka (nāk, ir pienācis utt.)
Klients apstiprina pasūtījumu un ievada PIN kodu no lietotnes vai SMS apstiprinājuma. (kā paraksts) Lai kurjers nevarētu pabeigt piegādi iepriekš, ja kavējas.
Pasūtījums tiek atzīmēts sistēmā kā piegādāts.

Plus pāris alternatīvu scenāriju:

Kurjers var atzīmēt pasūtījumu kā nepiegādātu un izvēlēties iemeslu.
Ja kurjers kavējas, viņš var ar vienu pogu izsniegt elektronisku sertifikātu caur SMS. Vai sertifikāts automātiski tiek nosūtīts, ja tiek neievērots piegādes laiks.

Savukārt šī projekta perspektivitāte un nepieciešamība, protams, iedrošināja.

Nākamajā dienā devāmies ar komandu pusdienās un apspriedām, kā izskatīsies minimālais lietotnes funkcionalitāte.

Galu galā izveidojās šāds saraksts ar to, kas bija jāpaspēj uz kundības pasākumu:

Piesakās pie piegādes kases.
Parādīt pašreizējo atrašanās vietu.
Nosūtīt datus uz ārēju API (koordinātas, paņēma pasūtījumu, piegādāja pasūtījumu).
Saņemt datus no ārējā API (pašreizējie kurjera pasūtījumi).
Nosūtīt notikumu, ka paņēmām pasūtījumu piegādei/delivery.
Parādīt kurjera pašreizējo atrašanās vietu kartē mājaslapā.

Galvenais darbs, kā mēs redzējām, bija jāveic backend izveidē, pašas lietotnes (pēc diskusijām izvēlējāmies ReactNative lietotnes izstrādei, precīzāk - apvalkam ap to - expo.io, ļaujot vispār neizmantot nativā koda rakstīšanu). Aizmugures plānā sākotnēji bija cerības uz Vani Zverevu, kā pieredzējušu darbā ar mūsu pakalpojumu šablonu un k8s (kāda darbs uz sevi viņš arī uzņēmās). ReactNative ņēmām pamēģināt es un Andrejs Sarafanova.

Es nolēmu uzreiz izveidot darba repozitoriju pašam projektam. Pusnaktī es sapratu, ka ReactNative slikti strādā ar ģeolokāciju fonā, ja neizplānou nativu kodu, nedaudz frustējos. Pēc tam atlaidos, kad sapratu, ka lasu dokumentāciju nevis expo.io ietvaram, bet ReactNative. Gala rezultātā vakarā man jau bija skaidrs, kā iegūt eksponēto atrašanās vietu un uzzīmēt atsevišķas ekrānus (pieteikšanai, pasūtījuma attēlošanai utt.).

No rīta hakatonā pievilinājām Glebam pievienoties mūsu perspektīvam projektam. Ātri uzrakstījām plānu, kas jādara.

Mēs pieļāvām kļūdu, mēģinot saskaņā ar projekta šablonu veidot saziņu nevis caur HTTP, bet caur GRPC, jo neviens nezināja, kā izveidot GRPC klientu JavaScript. Gala rezultātā, pavadot apmēram pusotru stundu, mēs atteicāmies no šīs idejas. Tāpēc puiši uz aizmuguri arī sāka pārbūvēt gatavo serveri no GRPC uz WebApi. Pusstundas laikā mēs beidzot varējām konfigurēt lietojumprogrammas saziņu ar aizmuguri, ak vai. Bet tajā pašā laikā Gļebs gandrīz pabeidza izvietošanu k8s un automātisko izvietošanu pēc apņemšanās uz galveno.

Kā datu krātuvi mēs izvēlējāmies MySQL, lai neriskētu vismaz ar datubāzi (bija doma par CosmosDb).

Rezultātā:

Ieviesām kurjera pašreizējā koordinātu saglabāšanu no lietojumprogrammas datu bāzē.
Pievienojām RabbitMQ un pierakstījāmies uz ziņojumiem par pasūtījuma saņemšanu ar kurjera palīdzību, lai tūlīt attēlotu pasūtījumu kurjeram programmā.
Sākām saglabāt datu bāzē laiku par pasūtījuma piegādi, pēc tam, kad kurjers nospiež pogu programmā. Neizdevās pievienot ziņojuma nosūtīšanu atpakaļ uz rīci par to, ka pasūtījums ir piegādāts.
Es izveidoju kartes attēlošanu lapā currentorder mājaslapā ar kurjera pašreizējo atrašanās vietu. Tomēr šī funkcionalitāte palika nedaudz nepabeigta, jo vidē neizdevās konfigurēt CORS, lai iegūtu koordinātas no mūsu jaunā pakalpojuma.

M87

Roma Bukins, Goša Polevijs (georgepolevoy), Artyom Trofimushkin

Mēs vēlējāmies izveidot OpenID Connect sniedzēju, jo šobrīd mēs izmantojam mūsu pašu izstrādāto autentifikācijas protokolu, kas rada virkni grūtību: pielāgotas klientu bibliotēkas, neērta sadarbība ar ārējiem partneriem, iespējamas drošības problēmas (galu galā OAuth2.0 un OpenID Connect etalona izpildē uzskatāmas par drošām, bet par mūsu risinājumu — neesmu pārliecināts).

Mēs izveidojām atsevišķu pakalpojumu, kas emulē personālo datu glabāšanas pakalpojumu, lai izveidotu nelielu valsts neatkarīgu autentifikācijas sniedzēja modeli, kas iegūtu personīgos datus no atsevišķa pakalpojuma (tas nākotnē dotu iespēju izmantot vienu pakalpojumu, ar kuru iespējams pieteikties ar kontu jebkurā valstī un vienlaikus ievērot GDPR un citus likumus). Šo daļu mēs izstrādājām, kā arī sniedzēju, un veiksmīgi tos savienojām savā starpā. Tālāk vajadzēja izveidot API, kas būtu aizsargāts ar sniedzēja izsniegtajiem žetoniem, atbalstītu to introspekciju caur sniedzēju un atdotu aizsargātos datus, ja pieprasījums atbilstu autorizācijas politikām (pārbaudām, vai lietotājs ir autentificēts pēc Bearer shēmas, vai viņa žetonā ir noteikts scope + vai pašam lietotājam ir atļauja veikt šo izsaukumu). Šī daļa arī bija pabeigta. Pēdējais komponents bija JavaScript klients, kuram tiktu izsniegts žetons, ar kura palīdzību tas izsauktos aizsargāto API. Šo daļu mēs nepaspējām izstrādāt. Tātad visa funkcionālā daļa bija gatava, bet nebija izstrādāta priekšējā daļa, lai demonstrētu visas sistēmas darbību.

E-E-E (spēlīte)

Dima Afončenko, Saša Konovalovs

Mēs izveidojām mini-spēli uz Unity, kur aktīvās rokas uzsita desiņu uz pizzas. Ja tu nepareizi uzsiti desiņu, ekrānā parādās skumja uzraksts "Noraidīts", bet, ja visa desiņa ir uzsista pareizi, tad parādās nejaušs fakts par pizzu.

Vēlējāmies izveidot otro līmeni ar tomātu uzsistīšanu, bet nepaspējām.

Īss turpinājums: kurš uzvarēja?

Pirms hackathon mēs runājām ar puišiem un es jautāju, kādu balvu viņi vēlētos saņemt, ja uzvarētu. Izrādījās, ka visvērtīgākā balva būtu "ceļš uz ražošanu".

Tāpēc drīz gaidiet no mums spēles paziņojumu ar rociņām, kas uzdarbojas ar pepperoni uz picas.