Pozdravljeni, Habr. Spontano smo izvedli prvi interni hackathon. Odločil sem se, da z vami delim svoje bolečine in zaključke o pripravah na to v 2 tednih, pa tudi o projektih, ki so se izkazali za.
Dolgočasen del za tiste, ki jih zanima marketing
Začel bom z majhno zgodbo.
Začetek aprila. V naši pisarni poteka prvi hackathon skupnosti MskDotNet. Bitka za Tatooine je tokrat v naši galaksiji v polnem teku. sobota 20 ekip. Pizza. Vse je zelo iskreno (). Po dvorani lebdi napihljiv R2-D2. Ekipe napišejo najbolj pravilne algoritme, da prestanejo najnevarnejšo dirko na zemljevidu. Prestavljamo začetek prvih dirk. Piškotki in kava so reševalci. Z organizatorji smo pričakovali, da bo v soboto po kosilu veliko ljudi odšlo. Vendar ne. Zadaj je 12 ur kodiranja. Konec. Nekaj odpade, nekaj se ne zažene. Ampak vsi so srečni. Naša ekipa zmaga. Srečni smo dvojno.
Delim svoje veselje v Slacku in na misel mi pride ideja: "Moramo narediti svoj hackathon." Pišem našemu servisu Sasha. Tišina.
jutro. Pijem kavo v pisarni. Vidim Sašo, kako se približuje od zadaj. »Lisa, to je super! 21. aprila imamo pomemben datum. Naredimo to!" WTF!? Tako hitro? A? Kaj? Sredi aprila moram odleteti v Syktyvkar na prakso. In k hudiču! dajmo.
še 2 tedna. Nikoli nisem bil edini organizator hackathona. Naj bo interno. Prebral sem članke na to temo. Težko. Traja več mesecev. Potrebujemo več ljudi. Razmisliti morate o trgovskem blagu, nagradah, pogojih, urniku, zanimanju, razumeti cilj, proračune. Ali morda celo ugotoviti smisel življenja. Definitivno ne bom uspel pravočasno. In ko ste brali in se pripravljali, je minil že en teden. Čas je, da pozabite na članke in začnete nekaj delati.
Oglejte si naš kontrolni seznam za izvedbo internega hackathona čez 1 teden
- načrt: Mirno se usedeš in napišeš seznam, kaj je treba narediti za hackathon. 30 minut.
- Naloga: Udeleženci predlagajo in izberejo projekte, ki jih želijo ustvariti v Google Preglednicah. Osnovna naloga, 2 uri.
- Vozni red: na koleno napišete kratko razčlenitev časa, upoštevajoč 3 odmore in finale. 20 minut.
- Ekipe: objavite sporočilo o hackathonu z urnikom servisa v IT kanalih v Slack/mail/etc in ustvarite ločen kanal za hackathon. V njem so vsi razdeljeni v ekipe, neodločeni pa to storijo v prvih 5 minutah hackathona. Osnovna naloga, 2 uri.
- Žemlje: z dvema razvijalcema si omislite blago, ga daste oblikovalcu v upodabljanje in prejmete pripravljeno. Osnovna naloga, 3 dni.
- Hackathon: prideš v pisarno, vse uskladiš na začetku, se lotiš svojih opravkov, bereš Reddit, pomembno napoveš vsako pavzo o sveži pici, slikaš sončni zahod, razglasiš finale, skupaj glasuješ in izbereš zmagovalca. 1 dan.
- Pod zvezdico: Seveda nenehno razmišljate o tem, da bo vse dobro. Seveda ne bodo vsi videli vašega sporočila in bolje je, da se z nekaterimi pogovorite osebno. Seveda, če vam nekdo pomaga, bo vse postalo 2-krat lažje (meni je pomagala čudovita Alena).
Manj dolgočasen del o datumu hackathona
Zakaj 21. april? Ta dan je za nas pomemben. Natanko pred enim letom, 21. aprila, smo prvi vikend po začetku zvezne oglaševalske kampanje padli pod obremenitev. Naslednji dan, v nedeljo, je bila naša ekipa v službi že od 8. ure zjutraj. Nato smo v Trellu ustvarili tablo sundayhackathon in začel se je teden izmenskega dela, 12 ur na dan. Situacija je bila tako kritična, da sploh nismo imeli časa jesti in so nas hranili fantje iz drugih ekip.
Podrobnejšo zgodbo si lahko preberete na (naš generalni direktor). Od takrat smo se zelo spremenili, a zdaj datuma zagotovo ne bomo pozabili.
Letos smo se odločili, da je ta dogodek vreden ohraniti v spominu zanamcev in smo v najboljših tradicijah organizirali prvi interni hackathon v zgodovini Dodo, ki je trajal 10 ur.
Najbolj dolgočasen del o hackathon projektih
Izjava o omejitvi odgovornosti: vse opise so napisali fantje sami, zato avtorstvo besedila ni moje.
Oleg Učenje (strojno učenje)
Dima Kočnev, Saša Andronov (@alexandronov)
Želeli so izdelati nevronsko mrežo, ki bi brez znanja ugotavljala, kakšna pica je na fotografiji. Posledično smo naredili zelo preprosto in igračko - prepozna 10 pic, približno smo ugotovili, kako vse deluje, kolikor je to mogoče v enem dnevu (~10 ur).
Predvsem smo ugotovili, da je industrija dosegla raven, ko lahko navaden razvijalec vzame že pripravljene knjižnice, prebere dokumentacijo in uri svojo nevronsko mrežo brez poglobljenega poznavanja teme. In delovalo bo dovolj dobro za reševanje resničnih problemov.
Uporabljena orodja:
- — priročna in preprosta knjižnica za delo s strojnim učenjem in računalniškim vidom.
- Preizkusili smo dva modela - ResNet50, Yolo.
- Koda je bila seveda napisana v Pythonu.
Imeli smo 11000 fotografij, a se jih je skoraj 3/4 izkazalo za smeti, ostale pa so imele drugačne, neprimerne kote. Kot rezultat smo vzeli že pripravljen model (ki preprosto ve, kako najti pico) in z njegovo pomočjo ločili smeti. Nato je naslov fotografije vseboval ime pice - zato smo jo razvrstili v mape, vendar se je izkazalo, da imena ne sovpadajo z resničnostjo in smo jo morali pospraviti z rokami. Na koncu je ostalo približno 500-600 fotografij, jasno je, da je to nepomembna količina, vendar je bilo to dovolj, da se loči 10 pic eno od druge.
Za usposabljanje omrežja smo vzeli najcenejši virtualni stroj v Azure na NVIDIA Tesla K80. Na njem so se urili 100 epoh, vendar je bilo jasno, da je bilo omrežje po 50 epohah prenasičeno zaradi dejstva, da je bil nabor podatkov majhen.
Pravzaprav je celoten problem pomanjkanje dobrih podatkov.
Morda smo malo pomešali pojme, a moramo upoštevati, da z vsemi temi zadevami nimamo nikakršnih izkušenj.
GUI za NOOBS (konzola za naročanje pice)
Miša Kumačev (), Zhenya Bikkinin, Zhenya Vasiliev
Sestavili smo prototip konzolne aplikacije za geeke, zahvaljujoč kateri lahko naročite pico prek terminala ali ukazne vrstice ali pa jo celo integrirate v namestitveni cevovod in po uspešni izdaji pico dostavite v pisarno.
Delo je bilo razdeljeno na več delov: ugotovili smo, kako deluje naš API za mobilne aplikacije, sestavili svoj CLI z uporabo in konfigurirali objavo paketa, ki smo ga zbrali. Zadnja naloga je vključevala nekaj neprijetnih minut proti koncu hackathona. Pri nas je vse delovalo lokalno in tudi stare objavljene različice paketa so delovale, nove (ki so dodale več kul funkcij in emotikonov) pa niso delovale. Približno 40 minut smo poskušali ugotoviti, kaj je šlo narobe, a na koncu je vse čarobno delovalo samo od sebe).
Naš največji program za hackathon je bilo pravo naročilo pice v pisarno prek našega CLI. Na testni napravi smo vse pognali ducatkrat, a so se mi roke še vedno tresle, ko sem vnašal ukaze v proizvodnji.
Kot rezultat, nam je končno uspelo!
CourierGo
Anton Bruzhmelev (avtor), Vanya Zverev, Gleb Lesnikov (), Andrej Sarafanov
Prevzeli smo idejo o "aplikaciji za kurirja".
Ozadje priprave.Sprva sem se spraševal, kakšne funkcije bi lahko bile v aplikaciji? Pojavil se je naslednji seznam funkcij:
- Aplikacija se s kodo prijavi v dostavno blagajno.
- Aplikacija takoj prikaže razpoložljiva naročila in naročila, ki jih je treba sprejeti.
- Kurir naročilo zabeleži in odnese na pot.
- Prikaže se mu predviden čas in ali je točen ali ne.
- Stranki pokaže, da je kurir odšel.
- Stranki se začne prikazovati točka kurirja na zemljevidu in predviden čas.
- Kurir lahko piše stranki v klepetu iz aplikacije.
- Stranka lahko piše kurirju prek klepeta iz aplikacije.
- Pet minut pred prihodom stranka prejme sporočilo, da je kurir blizu, bodite pripravljeni.
- Kurir v prijavi zapiše, da je prišel in čaka.
- Kurir pokliče iz aplikacije z enim klikom in sporoči, da (vstaja, je prispel itd.)
- Stranka sprejme naročilo in za potrditev dostave vnese PIN kodo iz aplikacije ali SMS (kot podpis), tako da kurir ne more dokončati dostave vnaprej, če zamuja.
- Naročilo je v sistemu označeno kot dostavljeno.
In še nekaj alternativnih scenarijev:
- Kurir lahko naročilo označi kot nedostavljeno in izbere razlog.
- Če zamujate, vam kurir z enim gumbom izda elektronsko potrdilo preko SMS-a. Ali pa potrdilo prispe samodejno, če rok dostave ni upoštevan.
Občutek obetavnosti in nujnosti tega projekta je bil seveda spodbuden.
Naslednji dan smo šli z ekipo na kosilo in se pogovarjali o tem, kako bi izgledala minimalna funkcionalnost aplikacije.
Kot rezultat je nastal naslednji seznam tega, kar je bilo treba narediti na hackathonu:
- Prijava v dostavno blagajno.
- Prikaz trenutnega položaja.
- Pošljite podatke v zunanji API (koordinate, prejeto naročilo, dostavljeno naročilo).
- Prejemanje podatkov iz zunanjega API-ja (trenutna kurirska naročila).
- Pošljite dogodek, ki nakazuje, da ste naročilo sprejeli v dostavo/dostavljeno.
- Prikažite trenutni položaj kurirja na zemljevidu na spletni strani.
Glavno delo, kot se je zdelo, je bilo ustvarjanje zaledja, same aplikacije (po pogovorih smo izbrali ReactNative za razvoj aplikacije oziroma ogrodja zanjo – , ki vam omogoča, da sploh ne pišete izvorne kode). Kar zadeva zaledje, je bilo sprva upanje v Vanjo Zvereva, saj je imel izkušnje z delom z našo storitveno predlogo in k8s (to delo je prevzel). Z Andrejem Sarafanovim sva preizkusila ReactNative.
Odločil sem se, da poskusim takoj ustvariti delujoč repozitorij za sam projekt. Ob 12 ponoči sem naletel na dejstvo, da geolokacija v ozadju ne deluje dobro v ReactNative, če ne pišeš izvorne kode, sem bil malo razočaran. Potem sem popustil, ko sem ugotovil, da ne berem dokumentacije ogrodja expo.io, ampak ReactNative. Posledično sem tekom večera že razumel, kako dobiti trenutno pozicijo v expo.io in risati ločene zaslone (za prijavo, prikaz naročila itd.).
Zjutraj na hackathonu so Gleba zvabili v svoj super obetaven projekt. Hitro so naredili načrt, kaj je treba narediti.
Naredili smo napako, ko smo v skladu s predlogo projekta poskušali komunicirati ne preko HTTP, ampak preko GRPC, saj nihče ni znal zgraditi odjemalca GRPC za JavaScript. Na koncu, ko smo za to porabili približno uro in pol, smo to idejo opustili. Zaradi tega so fantje na zadnji strani začeli predelati končni strežnik iz GRPC v WebApi. Po pol ure nam je končno uspelo vzpostaviti komunikacijo med aplikacijo in zaledjem, glej ga zlomka. Toda hkrati je Gleb skoraj dokončal uvajanje na k8s in plus samodejno uvajanje predaje v master. 🙂
Za shrambo smo izbrali MySQL, da ne bi tvegali vsaj z bazo (razmišljali smo o CosmosDb).
Če povzamemo:
- Implementirano shranjevanje trenutnih koordinat kurirja iz aplikacije v bazo.
- Namestili smo RabbitMQ in se naročili na sporočila o prevzemu kurirja, da se naročilo kurirja takoj prikaže v aplikaciji.
- Čas dostave naročila smo začeli shranjevati v našo bazo po tem, ko je kurir pritisnil gumb v aplikaciji. Nismo imeli časa, da bi dodali pošiljanje dogodka nazaj v rebbit, da je bilo naročilo dostavljeno.
- Na strani trenutnega naročila na spletni strani sem naredil prikaz zemljevida s trenutnim položajem kurirja. Toda ta funkcionalnost je ostala nekoliko nedokončana, saj ni bilo mogoče konfigurirati CORS v okolju za prejemanje koordinat iz naše nove storitve.
M87
Roma Bukin, Gosha Polevoy (), Artjom Trofimuškin
Želeli smo implementirati ponudnika OpenID Connect, saj trenutno uporabljamo protokol za preverjanje pristnosti lastne zasnove, kar povzroča številne težave: prilagojene odjemalske knjižnice, neprijetno delo s strani zunanjih partnerjev, morebitne varnostne težave (navsezadnje , OAuth2.0 in OpenID Connect v referenčni izvedbi se lahko štejeta za varna, vendar nisem prepričan o naši rešitvi).
Naredili smo ločeno storitev, ki posnema storitev za shranjevanje osebnih podatkov, da bi ustvarili majhen Country-Agnostic model ponudnika avtentikacije, ki bi šel v ločeno storitev za osebne podatke (to bi v prihodnosti omogočilo eno storitev z v katero bi se lahko prijavili z registracijo računa v kateri koli državi in hkrati spoštovali GDPR in druge zvezne zakone). Ta del smo opravili mi, tako kot ponudnik, in jih med seboj uspešno povezali. Nato je bilo treba ustvariti API, ki bi bil zaščiten z žetoni, izdanimi s strani ponudnika, podpiral njihovo introspekcijo prek ponudnika in vračal zaščitene podatke, če bi zahteva zadostila avtorizacijskim politikam (preverimo, ali je uporabnik avtentikiran po nosilni shemi , njegov žeton vsebuje določen obseg + y Uporabnik sam ima dovoljenje, ki omogoča klic). Tudi ta del je bil dokončan. Zadnja komponenta je bil JavaScript odjemalec, ki bi dobil žeton, s pomočjo katerega bi poklical zaščiten API. Nismo imeli časa za ta del. Se pravi, celoten funkcionalni del je bil pripravljen, sprednji del pa ni bil pripravljen za prikaz funkcionalnosti celotnega sistema.
E-E-E (igrača)
Dima Afončenko, Saša Konovalov
Na junki smo naredili mini igračo, kjer hitre roke mečejo klobaso na pico. Če klobaso nadenete nepravilno, se na zaslonu prikaže žalostno sporočilo »Zavrnjeno«, in če je bila vsa klobasa pravilno nataknjena, se prikaže naključno dejstvo o pici.
Želeli smo narediti drugo stopnjo z metanjem paradižnikov, a nismo imeli časa.
Kratko nadaljevanje: kdo je zmagal?
Pred hackathonom smo se pogovarjali s fanti in vprašal sem, kakšno nagrado bi radi prejeli, če zmagajo. Izkazalo se je, da bo najdragocenejša nagrada »pot do hrane«.
Zato pričakujte, da bomo kmalu objavili igro z rokami, ki dajo feferone na pico.
Kot je morda opazil pozoren bralec, je zmagala ekipa "E-E-E (igrača)". Čestitke fantje!
V anketi lahko sodelujejo samo registrirani uporabniki. , prosim.
Kateri projekt vam je bil najbolj všeč?
-
Oleg Učenje (strojno učenje)
-
GUI za NOOBS
-
CourierGo
-
M87
-
E-E-E
Glasovalo je 5 uporabnikov. 3 uporabnika sta se vzdržala.
Vir: www.habr.com