A nevem Dmitrij. És arról szeretnék beszélni, hogy csapatunk hogyan jutott be a döntőbe az Urban Tech Challenge hackathonon a Big Data pályán. Azonnal elmondom, hogy nem ez az első hackathon, amelyen részt vettem, és nem az első, amelyen díjakat nyertem. Ezzel kapcsolatban történetemben szeretnék hangot adni néhány általános megfigyelésnek és következtetésnek a hackathon iparág egészére vonatkozóan, és kifejteni a saját álláspontomat, szemben azokkal a negatív kritikákkal, amelyek közvetlenül az Urban Tech Challenge befejezése után jelentek meg az interneten (pl. példa ).
Tehát először néhány általános megfigyelés.
1. Meglepő, hogy jó néhányan naivan azt hiszik, hogy a hackathon valamiféle sportverseny, ahol a legjobb kódolók nyernek. Ez rossz. Nem veszek figyelembe olyan eseteket, amikor a hackathon szervezői maguk sem tudják, mit akarnak (ezt én is láttam). De általában a hackathont szervező cég a saját céljait követi. Ezek listája eltérő lehet: lehet technikai megoldás bizonyos problémákra, új ötletek és emberek keresése stb. Ezek a célok sokszor meghatározzák az esemény formátumát, időpontját, online/offline, a feladatok megfogalmazásának módját (és hogy egyáltalán megfogalmazódnak-e), lesz-e kód áttekintés a hackathonon stb. Mind a csapatokat, mind az általuk végzetteket ebből a szempontból értékelik. És azok a csapatok nyernek, amelyek a legjobban eltalálják azt a pontot, amelyre a cégnek szüksége van, és sokan teljesen öntudatlanul és véletlenül jutnak el idáig, azt gondolva, hogy valóban sportversenyen vesznek részt. Észrevételeim azt mutatják, hogy a résztvevők motiválása érdekében a szervezőknek legalább a sportkörnyezet és az egyenlő feltételek látszatát kell megteremteniük, ellenkező esetben a fenti áttekintéshez hasonlóan negatív hullámot kapnak. De elkalandozunk.
2. Ebből következik a következő következtetés. A szervezők érdeklik, hogy a résztvevők saját munkájukkal érkezzenek a hackathonra, esetenként külön online levelezős szakaszt is szerveznek erre a célra. Ez erősebb kimeneti megoldásokat tesz lehetővé. A „saját munka” fogalma nagyon relatív, minden tapasztalt fejlesztő több ezer sornyi kódot gyűjthet régi projektjeiből az első commit során. És ez egy előre elkészített fejlesztés lesz? De mindenesetre érvényes a szabály, amit egy híres mém formájában fejeztem ki:
Ahhoz, hogy nyerj, rendelkezned kell valamivel, valamiféle versenyelőnnyel: egy hasonló projekttel, amit korábban csináltál, egy adott témában szerzett tudással és tapasztalattal, vagy a hackathon kezdete előtt kész munkával. Igen, ez nem sport. Igen, lehet, hogy ez nem éri meg a ráfordított erőfeszítést (itt mindenki maga dönti el, hogy megéri-e éjszakánként 3 hétig kódolni egy 100 ezres nyereményért, amelyet a teljes csapat között osztanak el, és még azzal a kockázattal is, hogy nem kapja meg). De gyakran ez az egyetlen esély a továbbjutásra.
3. Csapatválasztás. Ahogy a hackathon chaten észrevettem, sokan elég komolytalanul közelítik meg ezt a kérdést (bár ez a legfontosabb döntés, ami meghatározza a hackathon eredményét). Számos tevékenységi területen (mind a sportban, mind a hackathonokon) azt tapasztaltam, hogy az erős emberek hajlamosak egyesülni az erősekkel, a gyengék a gyengékkel, az okosak az okosokkal, nos, általánosságban érthető... A chaten nagyjából ez történik: a kevésbé erős programozókat azonnal lecsapják, a hackathonhoz értékes képességekkel nem rendelkezők sokáig a chaten lógnak, és azon az elven választanak csapatot, hogy ha valaki elvállalná. . Egyes hackathonokon a véletlenszerű csapatok beosztását gyakorolják, és a szervezők azt állítják, hogy a véletlenszerű csapatok nem teljesítenek rosszabbul, mint a meglévők. De megfigyeléseim szerint a motivált emberek általában maguktól találnak csapatot, ha valakit be kell osztani, akkor gyakran sokan nem jönnek el a hackathonra.
Ami a csapat összetételét illeti, ez nagyon egyéni és nagymértékben függ a feladattól. Mondhatnám, hogy a minimális életképes csapatösszetétel egy tervező - front-end vagy front-end - back-end. De tudok olyan esetekről is, amikor csak front-endőkből álló csapatok nyertek, akik egy egyszerű back-endet adtak hozzá a node.js-ben, vagy készítettek mobilalkalmazást a React Native-ben; vagy csak az egyszerű elrendezést végző backenderektől. Általában minden nagyon egyéni, és a feladattól függ. A tervem a csapat kiválasztásával a hackathonra a következő volt: Úgy terveztem, hogy összeállítok egy csapatot, vagy csatlakozom egy csapathoz, például front-end - back-end - designer (magam is front-end vagyok). És elég gyorsan elkezdtem csevegni egy python backenderrel és egy tervezővel, aki elfogadta a meghívást, hogy csatlakozzon hozzánk. Kicsit később csatlakozott hozzánk egy lány, üzleti elemző, akinek már volt tapasztalata hackathonon, és ez eldöntötte a csatlakozás kérdését. Rövid találkozás után úgy döntöttünk, hogy a fantasztikus négyes analógiájára U4-nek (URBAN 4, urban four) nevezzük magunkat. És még egy megfelelő képet is tettek a távirati csatornánk avatarjára.
4. Feladat kiválasztása. Mint már mondtam, versenyelőnyben kell lenni, ez alapján választjuk ki a hackathon feladatát. Ez alapján, miután megnézte és összetettségüket felmérve két feladat mellett döntöttünk: a DPiIR innovatív vállalkozások katalógusa és az EFKO chatbotja. A DPIiR feladatát a backender, az EFKO feladatát én választottam, mert tapasztalattal rendelkezett chatbotok írásában a node.js és a DialogFlow programban. Az EFKO feladat az ML-t is érintette, van némi, nem túl kiterjedt tapasztalatom az ML-ben. A probléma körülményei szerint pedig úgy tűnt számomra, hogy nem valószínű, hogy az ML eszközökkel megoldható. Ez az érzés erősödött, amikor elmentem az Urban Tech Challenge találkozóra, ahol a szervezők megmutattak egy adatkészletet az EFKO-ról, ahol körülbelül 100 fotó volt a termékelrendezésekről (különböző szögekből készült), és körülbelül 20 osztályú elrendezési hiba volt. Ugyanakkor a feladatot megrendelők 90%-os minősítési sikert akartak elérni. Ennek eredményeként elkészítettem a megoldás prezentációját ML nélkül, a backender a katalógus alapján prezentációt készített, majd közösen, a prezentációk véglegesítése után elküldtük az Urban Tech Challenge-re. Már ebben a szakaszban kiderült az egyes résztvevők motiváltsági szintje és hozzájárulása. Tervezőnk nem vett részt a megbeszéléseken, későn válaszolt, sőt az utolsó pillanatban töltötte ki magáról az előadásban az információkat, általában kétségek merültek fel.
Ennek eredményeként a DPiIR-től sikeresen teljesítettük a feladatot, és egyáltalán nem bántuk meg, hogy nem sikerült az EFKO, hiszen a feladat finoman szólva is furcsának tűnt számunkra.
5. Felkészülés a hackathonra. Amikor végre kiderült, hogy kvalifikáltunk a hackathonra, elkezdtük a felkészülést. És itt nem azt javaslom, hogy egy héttel a hackathon kezdete előtt kezdjünk el kódot írni. Minimálisan készen kell állnia egy kazánlemezre, amellyel azonnal elkezdhet dolgozni anélkül, hogy eszközöket kellene konfigurálnia, és anélkül, hogy beleütközne néhány lib hibájába, amelyet egy hackathonon döntöttél el először. Ismerek egy történetet a szögletes mérnökökről, akik eljöttek egy hackathonra, és 2 napot töltöttek a projekt felépítésével, szóval mindenre előre kell készülni. A felelősséget a következőképpen terveztük megosztani: a backender bejárókat ír, amelyek az internetet kutatják, és az összes összegyűjtött információt az adatbázisba helyezik, én pedig a node.js-ben írok egy API-t, amely lekérdezi ezt az adatbázist, és elküldi az adatokat. Ezzel kapcsolatban előre elkészítettem egy szervert az express.js használatával, és a react-ban elkészítettem egy front-endet. Nem használok CRA-t, mindig magamra szabom a webpack-et, és nagyon jól tudom, hogy ez milyen kockázatokat rejthet magában (emlékezzünk a szögletes fejlesztőkről szóló történetre). Ezen a ponton felületsablonokat vagy legalább maketteket kértem tervezőnktől, hogy legyen elképzelésem arról, mit fogok elhelyezni. Elméletileg neki is meg kellene tennie a saját előkészületeit és egyeztetnie velünk, de választ soha nem kaptam. Ennek eredményeként a dizájnt az egyik régi projektemből kölcsönöztem. És ez még gyorsabban kezdett működni, mivel ehhez a projekthez már minden stílust megírtak. Innen a következtetés: a tervezőre nem mindig van szükség egy csapatban))). Ezekkel a fejlesztésekkel érkeztünk a hackathonhoz.
6. Dolgozzon a hackathonon. Először csak a hackathon megnyitóján láttam élőben a csapatomat a Központi Elosztó Központban. Találkoztunk, megbeszéltük a megoldást és a probléma megoldásának lépéseit. És bár a nyitás után busszal kellett mennünk a Vörös Októberbe, hazamentünk aludni, megbeszélve, hogy 9.00-ra megérkezünk a helyszínre. Miért? A szervezők láthatóan a legtöbbet akarták kihozni a résztvevőkből, ezért pont ilyen menetrendet alakítottak ki. De tapasztalataim szerint normálisan kódolhat anélkül, hogy egy éjszakát aludna. Ami a másodikat illeti, már nem vagyok benne biztos. A hackathon egy maraton, megfelelően kell számolnod és meg kell tervezned az erődet. Ráadásul voltak előkészületeink is.
Ezért, miután elaludtunk, 9.00-kor a Dewocracy hatodik emeletén ültünk. Aztán tervezőnk váratlanul bejelentette, hogy nincs laptopja, és otthonról fog dolgozni, majd telefonon fogunk kommunikálni. Ez volt az utolsó csepp a pohárban. Így aztán négyesről hármasra fordultunk, bár a csapat nevét nem változtattuk meg. Ez megint nem volt nagy csapás számunkra, már megvolt a terv a régi projektből. Általában eleinte minden simán és a tervek szerint ment. Az adatbázisba feltöltöttük (a neo4j mellett döntöttünk) a szervezők innovatív cégek adatkészletét. Elkezdtem szedni, majd felvettem a node.js fájlt, és a dolgok elkezdtek elromlani. Korábban soha nem dolgoztam neo4j-vel, és először kerestem egy működő illesztőprogramot ehhez az adatbázishoz, aztán rájöttem, hogyan írjak le egy lekérdezést, majd meglepődve tapasztaltam, hogy ez az adatbázis lekérdezéskor a rendszerben lévő entitásokat adja vissza. csomópontobjektumok és éleik tömbjének formája. Azok. Amikor egy szervezetet és a rajta lévő összes adatot TIN-számmal kértem, egy szervezeti objektum helyett objektumok hosszú tömbjét kaptam vissza, amelyek adatokat tartalmaztak erről a szervezetről és a köztük lévő kapcsolatokról. Írtam egy leképezőt, amely végigment a teljes tömbön, és az összes objektumot a felépítésüknek megfelelően egy objektumba ragasztotta. Ám a csatában, amikor 8 ezer szervezet adatbázisát kérték, rendkívül lassan, körülbelül 20-30 másodperc alatt hajtották végre. Elkezdtem gondolkodni az optimalizáláson... Aztán időben megálltunk, és átváltottunk a MongoDB-re, és ez körülbelül 30 percig tartott. Összesen körülbelül 4 óra veszett el a neo5j-n.
Ne feledje, soha ne vigye el a technológiát egy olyan hackathonra, amelyet nem ismer, mert előfordulhatnak meglepetések. De általában, ezt a kudarcot leszámítva, minden a terv szerint ment. És már december 9-én reggel volt egy teljesen működő jelentkezésünk. A nap hátralévő részében azt terveztük, hogy további funkciókat adunk hozzá. A jövőben nekem viszonylag simán ment minden, de a backendernek egy rakás problémája volt a bejáróinak keresőmotorokban való kitiltásával, jogi személyek aggregátorainak spamjével, ami kéréskor a keresési eredmények első helyére került. minden egyes cég esetében. De jobb, ha ő maga mesél róla. Az első további funkció, amit hozzáadtam, a teljes név szerinti keresés volt. A VKontakte vezérigazgatója. Több óráig tartott.
Tehát alkalmazásunkban a cég oldalán megjelent a főigazgató avatarja, egy hivatkozás a VKontakte oldalára és néhány egyéb adat. Szép cseresznye volt a tortán, bár lehet, hogy nem ez adta a győzelmet. Aztán egy kis elemzést akartam futtatni. De a lehetőségek hosszas keresése után (sok árnyalat volt az UI-val) a szervezetek legegyszerűbb, gazdasági tevékenység kódja szerinti összesítésénél döntöttem. Már este, az utolsó órákban kiraktam egy sablont az innovatív termékek megjelenítéséhez (alkalmazásunkban állítólag van egy Termékek és Szolgáltatások rovat), bár a háttérrendszer erre nem készült. Ugyanakkor az adatbázis ugrásszerűen duzzadt, a bejárók tovább dolgoztak, a backender az NLP-vel kísérletezett, hogy megkülönböztesse az innovatív szövegeket a nem innovatív szövegektől))). De már közeledett a végső bemutató ideje.
7. Bemutató. Saját tapasztalatom alapján azt mondhatom, hogy körülbelül 3-4 órával az esedékesség előtt érdemes áttérni egy prezentáció elkészítésére. Főleg, ha videóról van szó, a forgatás és a vágás elég sok időt vesz igénybe. Videót kellett volna készítenünk. És volt egy különleges emberünk, aki ezzel foglalkozott, és számos egyéb szervezési kérdést is megoldott. Ezzel kapcsolatban az utolsó pillanatig nem vontuk el figyelmünket a kódolásról.
8. Hangmagasság. Nem tetszett, hogy a bemutatók és a döntők külön hétköznapon (hétfőn) voltak. Itt nagy valószínűséggel folytatódott a szervezők azon politikája, hogy a maximumot kicsikarják a résztvevőkből. Nem terveztem szabadságot kivenni a munkából, csak a döntőbe akartam jönni, bár a csapatom többi tagja kivette a napot. A hackathonban azonban már akkora volt az érzelmi elmélyülés, hogy reggel 8-kor beírtam a csapatom chatjébe (a munkacsoport, nem a hackathon csapata), hogy saját költségemen töltöm a napot, és elmentem a központiba. iroda helyek számára. A problémánkról kiderült, hogy sok tiszta adattudós volt, és ez nagyban befolyásolta a probléma megoldásának megközelítését. Sokaknak jó volt a DS-je, de senkinek sem volt működő prototípusa, sokan nem tudták megkerülni a keresőkben bejárójuk tiltását. Mi voltunk az egyetlen csapat, amelynek működő prototípusa volt. És tudtuk, hogyan kell megoldani a problémát. A pályát végül megnyertük, bár nagy szerencsénk volt, hogy a legkevésbé versenyfeladatot választottuk. Más pályákon a pályákat nézve rájöttünk, hogy ott esélyünk sem lesz. Azt is szeretném elmondani, hogy nagy szerencsénk volt a zsűrivel, alaposan ellenőrizték a kódot. És a vélemények alapján ez nem minden pályán történt.
9. Végleges. Miután többször is behívtak minket a zsűrihez kódellenőrzésre, úgy gondoltuk, hogy végre minden kérdést megoldottunk, elmentünk a Burger Kingbe ebédelni. Ott megint hívtak minket a szervezők, gyorsan össze kellett csomagolni a rendeléseinket és visszamennünk.
A szervező megmutatta, melyik terembe kell bemennünk, majd belépve a győztes csapatok nyilvános beszéd edzésén találtuk magunkat. A srácok, akiknek a színpadon kellett volna fellépniük, jól feltöltődtek, mindenki igazi showmenként jött ki.
És be kell vallanom, a döntőben, más pályák legerősebb csapatainak hátterében, sápadtan néztünk ki, az állami megrendelői jelölésen a győzelmet teljesen megérdemelten az ingatlantechnológiai pálya csapata szerezte meg. Úgy gondolom, hogy a pályán elért győzelmünk kulcsfontosságú tényezői a következők voltak: egy kész blank elérhetősége, aminek köszönhetően gyorsan tudtunk prototípust készíteni, a „kiemelések” jelenléte a prototípusban (vezérigazgatók keresése közösségi oldalakon) és backenderünk NLP-készségei, amelyek a zsűrit is nagyon érdekelték.
Végezetül pedig hagyományos köszönet mindazoknak, akik támogattak minket, pályánk zsűrijének, Jevgenyij Evgrafievnek (a probléma szerzőjének, amit a hackathonon megoldottunk) és természetesen a hackathon szervezőinek. Talán ez volt a legnagyobb és legmenőbb hackathon, amin valaha részt vettem, csak azt tudom kívánni a srácoknak, hogy a jövőben is tartsanak ilyen magas színvonalat!
Forrás: will.com