Hello, Habr. Spontán megtartottuk az első belső hackathonunkat. Úgy döntöttem, megosztom veletek fájdalmaimat és következtetéseimet az arra való felkészüléssel kapcsolatban 2 hét múlva, valamint a bevált projekteket.
Az unalmas rész a marketing iránt érdeklődőknek
Egy kis történettel kezdem.
Április eleje. Irodánkban zajlik az első MskDotNet Community hackathon. A Tatooine-i csata ezúttal javában zajlik galaxisunkban. Szombat. 20 csapat. Pizza. Minden nagyon őszinte (). Egy felfújható R2-D2 lebeg a csarnokban. A csapatok a legmegfelelőbb algoritmusokat írják le, hogy a legveszélyesebb versenyen haladjanak át a térképen. Áthelyezzük az első futamok indulását. A süti és a kávé életmentő. A szervezők és én arra számítottunk, hogy szombaton ebéd után sokan elmennek. De nem. 12 óra kódolás mögött. A végső. Valami leesik, valami nem indul el. De mindenki boldog. A mi csapatunk nyer. Duplán boldogok vagyunk.
Megosztom az örömömet a Slackben, és eszembe jut a gondolat: "Meg kell csinálnunk a saját hackathonunkat." Írok a Sasha szervizünknek. Csend.
Reggel. Kávét iszom az irodában. Látom, ahogy Sasha hátulról közeledik. „Lisa, ez nagyszerű! Fontos dátumunk van április 21-én. Csináljuk!" WTF!? Olyan gyorsan? A? Mit? Április közepén Sziktivkarba kell repülnem szakmai gyakorlatra. És a pokolba is! Gyerünk.
2 hét van hátra. Soha nem voltam egyetlen hackathon szervezője. Legyen belső. Olvastam cikkeket ebben a témában. Kemény. Több hónapig tart. Több emberre van szükség. Át kell gondolnia az árut, a nyereményeket, a feltételeket, az ütemezést, az érdeklődést, meg kell értenie a célt, a költségvetéseket. Vagy talán még rájön az élet értelmére. Biztosan nem érek rá időben. És miközben olvastál és készültél, már eltelt egy hét. Ideje elfelejteni a cikkeket, és elkezdeni valamit.
Nézze meg ellenőrzőlistánkat egy belső hackathon megtartásához 1 héten belül
- terv: Nyugodtan leülsz és írsz egy listát, hogy mit kell tenni a hackathonhoz. 30 perc.
- Feladat: A résztvevők javaslatokat tesznek és kiválasztják a létrehozni kívánt projekteket a Google Táblázatokban. Háttérfeladat, 2 óra.
- Menetrend: a térdére írsz egy rövid időbontást, 3 szünetet és a döntőt figyelembe véve. 20 perc.
- parancsok: tegyen közzé egy üzenetet a hackathonról ütemtervvel a szerviztől a Slack/mail/etc IT csatornáin, és hozzon létre egy külön csatornát a hackathon számára. Ebben mindenki csapatokra van osztva, akik bizonytalanok, ezt a hackathon első 5 percében teszik meg. Háttérfeladat, 2 óra.
- Zsemle: kitalálsz egy merch-et két fejlesztővel, odaadod a tervezőnek renderelésre, és készen megkapod. Háttérfeladat, 3 nap.
- Hackathon: bejössz az irodába, mindenkit koordinálsz az elején, intézed a dolgod, olvasol Reddit, fontos, hogy minden szünetet bejelents a friss pizzáról, lefényképezd a naplementét, kihirdeted a döntőt, közösen szavazz és kiválasztod a győztest. 1 nap.
- A csillag alatt: Persze állandóan arra gondolsz, hogy minden jól megy. Természetesen nem mindenki fogja látni az üzenetét, és jobb, ha valakivel személyesen beszél. Természetesen, ha valaki segít, minden kétszer könnyebb lesz (a csodálatos Alena segített nekem).
A kevésbé unalmas rész a hackathon randevúról
Miért április 21? Ez a nap jelentős számunkra. Pontosan egy éve, április 21-én a Szövetségi Reklámkampány kezdete utáni első hétvégén terhelés alá kerültünk. Másnap, vasárnap reggel 8 órától dolgozott csapatunk. Aztán Trellóban létrehoztunk egy sundayhackathon táblát, és elkezdődött egy hét műszakos munka, napi 12 órában. A helyzet annyira kritikus volt, hogy még enni sem volt időnk, és más csapatok srácaitól etettünk.
Részletesebb történetet itt olvashat (vezérigazgatónk). Azóta sokat változtunk, de most már biztosan nem felejtjük el a dátumot.
Idén úgy döntöttünk, hogy ezt az eseményt érdemes megörökíteni az utókor emlékezetében, és a legjobb hagyományokhoz híven megszerveztük a Dodo történetének első belső hackathonját, amely 10 órás volt.
A hackathon projektek legunalmasabb része
Jogi nyilatkozat: az összes leírást maguk a srácok írták, így a szöveg szerzője nem az enyém.
Oleg Learning (gépi tanulás)
Dima Kochnev, Sasha Andronov (@alexandronov)
Neurális hálózatot akartak készíteni, amely minden tudás nélkül meghatározza, hogy milyen pizza van egy fotón. Ennek eredményeként egy nagyon egyszerű és játékszerűt készítettünk - 10 pizzát ismer fel, nagyjából egy nap (~10 óra) alatt kitaláltuk, hogyan működik minden.
Konkrétan rájöttünk arra, hogy az iparág elérte azt a szintet, hogy egy átlagos fejlesztő kész könyvtárakat vehet át, elolvashatja a dokumentációt és képezheti a neurális hálózatát anélkül, hogy mélyen ismerné a témát. És elég jól fog működni a valódi problémák megoldásához.
Felhasznált eszközök:
- — kényelmes és egyszerű könyvtár a gépi tanuláshoz és a számítógépes látáshoz.
- Két modellt próbáltunk ki - ResNet50, Yolo.
- A kód természetesen Pythonban íródott.
11000 3 fotónk volt, de ezek majdnem 4/500-e szemétnek bizonyult, a többi pedig más, nem megfelelő szögből készült. Ennek eredményeként vettünk egy kész modellt (ami egyszerűen tudja, hogyan kell megtalálni a pizzát), és a segítségével szeparáltuk a szemetet. Ezután a fotó címében a pizza neve szerepelt - így mappákba rendeztük, de kiderült, hogy a nevek nem esnek egybe a valósággal, és a kezünkkel kellett kitakarítanunk. A végén nagyjából 600-10 fotó maradt, jól látszik, hogy ez elenyésző mennyiség, de azért ez is elég volt XNUMX pizza elkülönítéséhez.
A rács betanításához az Azure legolcsóbb virtuális gépét vettük igénybe egy NVIDIA Tesla K80-on. 100 korszakon keresztül edzettek rajta, de egyértelmű volt, hogy a hálózat 50 korszak után túltelített volt, amiatt, hogy volt egy kis adathalmaz.
Valójában az egész probléma a jó adatok hiánya.
Lehet, hogy kicsit összekevertük a fogalmakat, de figyelembe kell vennünk, hogy egyáltalán nincs tapasztalatunk mindezen ügyek kezelésében.
GUI for NOOBS (konzol pizza rendeléshez)
Misha Kumachev (), Zsenya Bikkinin, Zsenya Vasziljev
Összeállítottuk a strébereknek szánt konzolalkalmazás prototípusát, aminek köszönhetően a terminálon vagy a parancssoron keresztül rendelhet pizzát, vagy akár beépítheti a telepítési folyamatba, és sikeres megjelenés esetén pizzát is szállíthat az irodába.
A munka több részre oszlott: kitaláltuk, hogyan működik a mobilalkalmazásokhoz készült API-nk, saját CLI-t állítottunk össze a segítségével és beállítottuk az általunk összegyűjtött csomag közzétételét. Az utolsó feladat néhány kellemetlen percet jelentett a hackathon vége felé. Nálunk helyben minden működött, és még a csomag régi közzétett verziói is működtek, de az újak (amelyek még több remek funkciót és hangulatjeleket adtak hozzá) nem működtek. Körülbelül 40 percet töltöttünk azzal, hogy kitaláljuk, mi a hiba, de végül minden varázslatosan működött magától).
A hackathon maximális programja egy valódi pizzarendelés volt az irodába a CLI-n keresztül. Mindent tucatszor lefuttattunk a tesztpadon, de még mindig remegett a kezem, amikor parancsokat adtam be a termelésbe.
Ennek eredményeként végre megcsináltuk!
CourierGo
Anton Bruzsmelev (szerző), Vanya Zverev, Gleb Lesnikov (), Andrej Sarafanov
Megfogadtuk az „App for Courier” ötletét.
Háttér a felkészülésről.Kezdetben azon töprengtem, hogy milyen funkciók lehetnek az alkalmazásban? A következő funkciók listája jelent meg:
- Az alkalmazás a kóddal bejelentkezik a kézbesítő pénztárba.
- Az alkalmazás azonnal megjeleníti a rendelkezésre álló rendeléseket és a felvenni kívánt rendeléseket.
- A futár tudomásul veszi a rendelést és útra viszi.
- Megjelenik neki a becsült idő és az, hogy időben érkezik-e vagy sem.
- Megmutatja az ügyfélnek, hogy a futár elment.
- Az ügyfélnek megjelenik a futár pontja a térképen és a becsült idő.
- A futár chatben írhat az ügyfélnek az alkalmazásból.
- Az ügyfél chaten írhat a futárnak az alkalmazásból.
- Érkezés előtt öt perccel az ügyfél üzenetet kap, hogy a futár közel van, készüljön fel.
- A futár a jelentkezésben megjegyzi, hogy megérkezett és vár.
- A futár egy kattintással hív az alkalmazásból és jelenti, hogy (emelkedik, megérkezett stb.)
- Az ügyfél elfogadja a rendelést és PIN kódot ír be az alkalmazásból vagy SMS-ből a kézbesítés megerősítéséhez.(aláírásként) Hogy a futár késés esetén ne tudja előre teljesíteni a szállítást.
- A megrendelés a rendszerben kézbesítettnek van jelölve.
Plusz néhány alternatív forgatókönyv:
- A futár megjelölheti a rendelést nem kézbesítettnek, és kiválaszthatja az okot.
- Késés esetén a futár egy gombnyomással SMS-ben elektronikus igazolást tud kiállítani. Illetve az igazolás automatikusan megérkezik, ha a szállítási határidőt nem tartják be.
A projekt ígéretének és szükségességének érzése természetesen energizáló volt.
Másnap elmentünk ebédelni a csapattal és megbeszéltük, hogyan nézne ki az alkalmazás minimális funkcionalitása.
Ennek eredményeként a következő lista alakult ki arról, hogy mit kellett tenni a hackathonon:
- Jelentkezzen be a kézbesítő pénztárba.
- Az aktuális pozíció megjelenítése.
- Adatok küldése külső API-ra (koordináták, rendelés átvétele, megrendelés kézbesítése).
- Adatok fogadása külső API-ból (aktuális futárrendelések).
- Esemény küldése, amely jelzi, hogy a rendelést átvette szállításra/kiszállításra.
- Jelenítse meg a futár aktuális pozícióját a weboldalon található térképen.
A fő munka, amint úgy tűnt, a háttér, az alkalmazás létrehozásában rejlik (a megbeszélések után a ReactNative-ot választottuk az alkalmazás, vagy inkább a keretrendszer fejlesztéséhez - , amely lehetővé teszi, hogy egyáltalán ne írjon natív kódot). A háttérrel kapcsolatban kezdetben Vanya Zverevben volt remény, hiszen tapasztalt volt a mi szolgáltatássablonunkkal és a k8-asainkkal (mely munkát vállalt el). Andrey Sarafanov és én elvittük a ReactNative-t egy körbe.
Úgy döntöttem, hogy azonnal megpróbálok létrehozni egy működő tárolót magának a projektnek. Éjjel 12-kor jöttem rá, hogy ReactNative-ben nem működik jól a háttérben a földrajzi helymeghatározás, ha nem írsz natív kódot, kicsit csalódott voltam. Aztán elengedtem, amikor rájöttem, hogy nem az expo.io keretrendszerét olvasom, hanem a ReactNative-ét. Ennek eredményeként az este folyamán már megértettem, hogyan lehet az expo.io-ban lekérni az aktuális pozíciót, és külön képernyőket rajzolni (bejelentkezés, rendelés megjelenítése stb.).
Reggel a hackathonon rácsalták Glebet a szuper ígéretes projektjükre. Gyorsan kidolgozták a tervet, hogy mit kell tenni.
Hibát követtünk el, amikor a projektsablonnak megfelelően nem HTTP-n, hanem GRPC-n keresztül próbáltunk kommunikálni, mivel senki sem tudta, hogyan kell JavaScripthez GRPC klienst építeni. Végül, miután körülbelül másfél órát töltöttünk ezzel, elvetettük ezt az ötletet. Emiatt a háttérben dolgozó srácok elkezdték átdolgozni a kész szervert GRPC-ről WebApi-ra. Fél óra elteltével végre sikerült felépíteni a kommunikációt az alkalmazás és a háttérrendszer között, tessék. De ugyanakkor Gleb már majdnem befejezte a k8s-ba való telepítést, és plusz a mesterhez való kötelezés automatikus telepítését. 🙂
A MySQL-t választottuk tárhelynek, hogy ne kockáztassunk legalább az adatbázissal (a CosmosDb-vel kapcsolatban voltak gondolataink).
Összefoglalva:
- Megvalósult a futár aktuális koordinátáinak mentése az alkalmazásból az adatbázisba.
- Telepítettük a RabbitMQ-t, és feliratkoztunk a rendelés felvételéről szóló üzenetekre, hogy a futártól kapott rendelés azonnal megjelenjen az alkalmazásban.
- A megrendelés kézbesítési idejének mentését az adatbázisunkba kezdtük, miután a futár megnyomott egy gombot az alkalmazásban. Nem volt időnk egy esemény visszaküldését hozzáadni a rebbithez, hogy a rendelést kézbesítettük.
- A weboldalon az aktuális rendelés oldalon térképkijelzést készítettem a futár aktuális pozíciójával. Ez a funkció azonban egy kicsit befejezetlen maradt, mivel a CORS-t nem lehetett a környezetben úgy konfigurálni, hogy koordinátákat kapjon az új szolgáltatásunktól.
M87
Roma Bukin, Gosha Polevoy (), Artyom Trofimushkin
Egy OpenID Connect szolgáltatót szerettünk volna megvalósítani, mivel jelenleg saját tervezésű hitelesítési protokollt használunk, ami számos nehézséget okoz: egyedi klienskönyvtárak, kényelmetlen munkavégzés a külső partnerek részéről, esetleges biztonsági problémák (elvégre , az OAuth2.0 és az OpenID Connect a referencia megvalósításban biztonságosnak tekinthető, de nem vagyok biztos a megoldásunkban).
A személyes adatok tárolására szolgáló szolgáltatást emuláló külön szolgáltatást készítettünk annak érdekében, hogy egy hitelesítésszolgáltató kis Country-Agnostic modelljét hozzuk létre, amely a személyes adatok külön szolgáltatásához menne (ez a jövőben lehetővé tenné, hogy egy szolgáltatás legyen amelyre bármely országban be lehet jelentkezni fiókregisztrációval, és egyúttal megfelel a GDPR-nak és más szövetségi törvényeknek). Megcsináltuk ezt a részt, akárcsak a szolgáltató, és sikeresen összekapcsoltuk őket egymással. Ezt követően létre kellett hozni egy olyan API-t, amelyet a szolgáltató által kiadott tokenek védenek, támogatják a szolgáltatón keresztüli önvizsgálatukat, és védett adatokat adnak vissza, ha a kérelem megfelel az engedélyezési szabályzatnak (ellenőrizzük, hogy a felhasználó hitelesítése a Bearer séma szerint van-e , a tokenje egy bizonyos hatókört tartalmaz + y Maga a felhasználó rendelkezik olyan engedéllyel, amely lehetővé teszi a hívás lebonyolítását). Ez a rész is elkészült. Az utolsó komponens egy JavaScript kliens volt, amely egy tokent kapott, amivel védett API-t hívna. Nem volt időnk megcsinálni ezt a részt. Vagyis a teljes funkcionális rész készen állt, de a front-end rész nem volt kész a teljes rendszer működőképességének bemutatására.
E-E-E (játék)
Dima Afoncsenko, Sasha Konovalov
Készítettünk egy minijátékot a yunkán, ahol a nyüzsgő kezek kolbászt dobnak a pizzára. Ha rosszul tette fel a kolbászt, egy szomorú „Elutasítva” üzenet jelenik meg a képernyőn, és ha az összes kolbászt helyesen tette fel, egy véletlenszerű tény jelenik meg a pizzával kapcsolatban.
Szerettünk volna egy második szintet készíteni paradicsomdobálással, de nem volt időnk.
Rövid folytatás: ki nyert?
A hackathon előtt beszélgettünk a srácokkal, és megkérdeztem, milyen díjat szeretnének kapni, ha nyernek. Kiderült, hogy a legértékesebb jutalom az „út az élelemhez” lesz.
Ezért várható, hogy hamarosan bejelentünk egy játékot olyan kezekkel, amelyek paprikát tesznek a pizzára.
Amint azt egy figyelmes olvasó észrevehette, az „E-E-E (játék)” csapat nyert. Gratulálok srácok!
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Melyik projekt tetszett a legjobban?
-
Oleg Learning (gépi tanulás)
-
GUI a NOOBS-hoz
-
CourierGo
-
M87
-
E-E-E
5 felhasználó szavazott. 3 felhasználó tartózkodott.
Forrás: will.com