Mijn naam is Dmitry. En ik wil het hebben over hoe ons team de finale bereikte van de Urban Tech Challenge hackathon op het Big Data-circuit. Ik zeg meteen dat dit niet de eerste hackathon is waaraan ik heb deelgenomen, en niet de eerste waarin ik prijzen heb gewonnen. In dit opzicht wil ik in mijn verhaal enkele algemene observaties en conclusies uiten over de hackathon-industrie als geheel, en mijn standpunt geven in tegenstelling tot de negatieve recensies die onmiddellijk na het einde van de Urban Tech Challenge online verschenen (bijvoorbeeld voorbeeld ).
Daarom eerst enkele algemene observaties.
1. Het is verrassend dat nogal wat mensen naïef denken dat een hackathon een soort sportwedstrijd is waarbij de beste programmeurs winnen. Dit is fout. Ik houd geen rekening met gevallen waarin hackathon-organisatoren zelf niet weten wat ze willen (dat heb ik ook gezien). Maar in de regel streeft het bedrijf dat een hackathon organiseert zijn eigen doelen na. Hun lijst kan verschillen: het kan een technische oplossing zijn voor sommige problemen, een zoektocht naar nieuwe ideeën en mensen, enz. Deze doelen bepalen vaak het format van het evenement, de timing ervan, online/offline, hoe de taken zullen worden geformuleerd (en of ze überhaupt zullen worden geformuleerd), of er een code review zal plaatsvinden tijdens de hackathon, etc. Vanuit dit perspectief worden zowel de teams als wat ze deden beoordeeld. En de teams die het beste het punt bereiken dat het bedrijf nodig heeft, winnen, en velen komen volledig onbewust en per ongeluk op dit punt terecht, in de veronderstelling dat ze echt deelnemen aan een sportcompetitie. Uit mijn observaties blijkt dat organisatoren, om deelnemers te motiveren, op zijn minst de schijn van een sportomgeving en gelijke omstandigheden moeten creëren, anders krijgen ze een golf van negativiteit te verwerken, zoals in de bovenstaande recensie. Maar we dwalen af.
2. Vandaar de volgende conclusie. De organisatoren zijn geïnteresseerd in deelnemers die met eigen werk naar de hackathon komen, soms organiseren ze hiervoor zelfs speciaal een online correspondentiepodium. Dit zorgt voor sterkere outputoplossingen. Het concept van ‘eigen werk’ is zeer relatief; elke ervaren ontwikkelaar kan in zijn eerste commit duizenden regels code uit zijn oude projecten verzamelen. En zal dit een vooraf voorbereide ontwikkeling zijn? Maar in ieder geval geldt de regel, die ik heb uitgedrukt in de vorm van een beroemde meme:
Om te winnen moet je iets hebben, een soort concurrentievoordeel: een soortgelijk project dat je in het verleden hebt gedaan, kennis en ervaring op een specifiek onderwerp, of een kant-en-klaar werk dat vóór de start van de hackathon is gedaan. Ja, het is niet sportief. Ja, dit is misschien niet de moeite waard (hier beslist iedereen zelf of het de moeite waard is om 3 weken 's nachts te coderen voor een prijs van 100 duizend, verdeeld over het hele team, en zelfs met het risico dat je deze niet ontvangt). Maar vaak is dit de enige kans om vooruit te komen.
3. Teamselectie. Zoals ik in hackathon-chats heb opgemerkt, benaderen velen deze kwestie nogal frivool (hoewel dit de belangrijkste beslissing is die je resultaat op de hackathon zal bepalen). Op veel gebieden van activiteit (zowel in de sport als in hackathons) heb ik gezien dat sterke mensen de neiging hebben zich te verenigen met de sterken, de zwakken met de zwakken, de slimme met de slimme, nou ja, over het algemeen begrijp je het idee... Dit is grofweg wat er gebeurt in chats: minder sterke programmeurs worden meteen opgepakt, mensen die geen vaardigheden hebben die waardevol zijn voor een hackathon blijven lang in de chat hangen en kiezen een team op basis van het principe dat als iemand het maar zou doen . Bij sommige hackathons wordt willekeurige toewijzing aan teams geoefend, en de organisatoren beweren dat willekeurige teams niet slechter presteren dan bestaande teams. Maar volgens mijn observaties vinden gemotiveerde mensen in de regel zelf een team; als er iemand moet worden toegewezen, komen velen van hen vaak niet naar de hackathon.
De samenstelling van het team is zeer individueel en sterk afhankelijk van de taak. Ik zou kunnen zeggen dat de minimaal haalbare teamsamenstelling een ontwerper - front-end of front-end - back-end is. Maar ik ken ook gevallen waarin teams die alleen uit front-enders bestonden, wonnen, die een eenvoudige back-end toevoegden in node.js, of een mobiele applicatie maakten in React Native; of alleen van backenders die een eenvoudige lay-out hebben gemaakt. Over het algemeen is alles heel individueel en afhankelijk van de taak. Mijn plan voor het selecteren van een team voor de hackathon was als volgt: ik was van plan een team samen te stellen of me aan te sluiten bij een team zoals front-end - back-end - designer (ik ben zelf front-end). En vrij snel begon ik te chatten met een python-backender en een ontwerper die de uitnodiging accepteerde om met ons mee te doen. Even later voegde zich een meisje, een bedrijfsanalist, die al ervaring had met het winnen van een hackathon, bij ons, en dit besliste de vraag of ze bij ons zou komen. Na een korte ontmoeting besloten we onszelf U4 (URBAN 4, urban four) te noemen, naar analogie met de fantastische vier. En ze hebben zelfs een bijbehorende foto op de avatar van ons telegramkanaal gezet.
4. Een taak selecteren. Zoals ik al zei moet je een concurrentievoordeel hebben, op basis hiervan wordt de taak voor de hackathon geselecteerd. Op basis hiervan, na gekeken te hebben en toen we hun complexiteit beoordeelden, kwamen we tot twee taken: een catalogus van innovatieve ondernemingen van DPiIR en een chatbot van EFKO. De taak van DPIiR is gekozen door de backender, de taak van EFKO is door mij gekozen, omdat had ervaring met het schrijven van chatbots in node.js en DialogFlow. Bij de EFKO-taak was ook ML betrokken; ik heb enige, niet erg uitgebreide, ervaring met ML. En gezien de omstandigheden van het probleem leek het mij onwaarschijnlijk dat het met ML-tools zou worden opgelost. Dit gevoel werd versterkt toen ik naar de Urban Tech Challenge meetup ging, waar de organisatoren mij een dataset over EFKO lieten zien, met ongeveer 100 foto's van productlay-outs (genomen vanuit verschillende hoeken) en ongeveer 20 klassen met lay-outfouten. En tegelijkertijd wilden degenen die de opdracht gaven een classificatiesucces van 90% behalen. Als resultaat heb ik een presentatie van de oplossing zonder ML voorbereid, de backender heeft een presentatie voorbereid op basis van de catalogus en samen, nadat we de presentaties hadden afgerond, stuurden we ze naar de Urban Tech Challenge. Al in dit stadium werd het niveau van motivatie en bijdrage van elke deelnemer onthuld. Onze ontwerper nam niet deel aan de discussies, reageerde laat en vulde zelfs op het allerlaatste moment informatie over zichzelf in de presentatie in, over het algemeen ontstonden er twijfels.
Als gevolg hiervan hebben we de taak van DPiIR doorgegeven en waren we helemaal niet boos dat we de EFKO niet hadden gehaald, omdat de taak ons op zijn zachtst gezegd vreemd leek.
5. Voorbereiden op de hackathon. Toen uiteindelijk bekend werd dat we ons hadden gekwalificeerd voor de hackathon, zijn we begonnen met de voorbereidingen. En hier pleit ik er niet voor om een week voor de start van de hackathon code te gaan schrijven. Je zou op zijn minst een boilerplate bij de hand moeten hebben, waarmee je meteen aan de slag kunt, zonder dat je tools hoeft te configureren, en zonder tegen bugs aan te lopen in een of andere lib die je voor het eerst besloot te proberen tijdens een hackathon. Ik ken een verhaal over hoekige ingenieurs die naar een hackathon kwamen en twee dagen bezig waren met het opzetten van de projectbuild, dus alles moet van tevoren worden voorbereid. Het was onze bedoeling om de verantwoordelijkheden als volgt te verdelen: de backender schrijft crawlers die het internet afstruinen en alle verzamelde informatie in de database plaatsen, terwijl ik in node.js een API schrijf die deze database bevraagt en de gegevens naar voren stuurt. In dit opzicht heb ik vooraf een server voorbereid met express.js en in reactie een front-end voorbereid. Ik gebruik geen CRA, ik pas webpack altijd voor mezelf aan en ik weet heel goed welke risico's dit met zich mee kan brengen (denk aan het verhaal over hoekige ontwikkelaars). Op dit punt vroeg ik interface-sjablonen of op zijn minst mockups aan onze ontwerper om een idee te krijgen van wat ik zou ontwerpen. In theorie zou hij ook zelf voorbereidingen moeten treffen en deze met ons moeten afstemmen, maar daar heb ik nooit antwoord op gekregen. Als gevolg hiervan heb ik het ontwerp geleend van een van mijn oude projecten. En het begon nog sneller te werken, omdat alle stijlen voor dit project al waren geschreven. Vandaar de conclusie: een ontwerper is niet altijd nodig in een team))). Met deze ontwikkelingen kwamen wij naar de hackathon.
6. Werk mee aan de hackathon. De eerste keer dat ik mijn team live zag was pas bij de opening van de hackathon op het Centraal Distributiecentrum. We ontmoetten elkaar, bespraken de oplossing en de fasen van het werken aan het probleem. En hoewel we na de opening met de bus naar Red October moesten, gingen we naar huis om te slapen, met de afspraak dat we om 9.00 uur ter plaatse zouden zijn. Waarom? De organisatoren wilden blijkbaar het maximale uit de deelnemers halen, dus stelden ze precies zo'n schema op. Maar mijn ervaring is dat je normaal kunt coderen zonder één nacht te slapen. Wat de tweede betreft, ik ben er niet meer zeker van. Een hackathon is een marathon; je moet je kracht goed berekenen en plannen. Bovendien hadden we voorbereidingen.
Daarom zaten we na het uitslapen om 9.00 uur op de zesde verdieping van Dewocracy. Toen maakte onze ontwerper onverwachts bekend dat hij geen laptop had en dat hij thuis zou werken, en dat we telefonisch zouden communiceren. Dit was de laatste druppel. En zo zijn we van een vier naar een drie gegaan, al hebben we de teamnaam niet veranderd. Nogmaals, dit was geen grote klap voor ons; ik had het ontwerp al van het oude project. Over het algemeen verliep alles aanvankelijk vrij vlot en volgens plan. We hebben een dataset van innovatieve bedrijven van de organisatoren in de database geladen (we besloten neo4j te gebruiken). Ik begon met typen, nam vervolgens node.js op, en toen begon het mis te gaan. Ik had nog nooit met neo4j gewerkt, en eerst was ik op zoek naar een werkende driver voor deze database, daarna ontdekte ik hoe ik een query moest schrijven, en toen was ik verrast om te ontdekken dat deze database, wanneer er een query naar wordt uitgevoerd, entiteiten retourneert in de vorm van een array van knooppuntobjecten en hun randen. Die. toen ik via TIN een organisatie en alle gegevens daarover opvroeg, kreeg ik in plaats van één organisatieobject een lange reeks objecten terug met gegevens over deze organisatie en de relaties daartussen. Ik schreef een mapper die de hele array doornam en alle objecten volgens hun organisatie in één object plakte. Maar in de strijd werd bij het opvragen van een database van 8 organisaties extreem langzaam uitgevoerd, ongeveer 20 - 30 seconden. Ik begon na te denken over optimalisatie... En toen stopten we op tijd en schakelden over naar MongoDB, en het kostte ons ongeveer 30 minuten. In totaal ging er ongeveer 4 uur verloren op neo5j.
Denk eraan: neem nooit technologie mee naar een hackathon waar je niet bekend mee bent; er kunnen verrassingen zijn. Maar over het algemeen verliep alles, afgezien van deze mislukking, volgens plan. En al op de ochtend van 9 december hadden we een volledig werkende applicatie. Voor de rest van de dag waren we van plan om er extra functies aan toe te voegen. In de toekomst verliep alles relatief soepel voor mij, maar de backender had een heleboel problemen met het verbieden van zijn crawlers in zoekmachines, in de spam van aggregators van rechtspersonen, die op de eerste plaatsen van de zoekresultaten kwamen bij het aanvragen voor elk specifiek bedrijf. Maar het is beter dat hij er zelf over vertelt. De eerste extra functie die ik heb toegevoegd, was zoeken op volledige naam. Algemeen directeur van VKontakte. Het duurde enkele uren.
Dus op de bedrijfspagina in onze applicatie verscheen een avatar van de algemeen directeur, een link naar zijn VKontakte-pagina en enkele andere gegevens. Het was een mooie kers op de taart, al heeft het ons misschien niet de overwinning opgeleverd. Vervolgens wilde ik wat analyses uitvoeren. Maar na lang zoeken naar opties (er waren veel nuances met de gebruikersinterface), kwam ik uit op de eenvoudigste aggregatie van organisaties op basis van economische activiteitencode. Al 's avonds, in de afgelopen uren, was ik een sjabloon aan het uitwerken voor het weergeven van innovatieve producten (in onze applicatie zou er een sectie Producten en Diensten moeten zijn), hoewel de backend hier niet klaar voor was. Tegelijkertijd groeide de database met grote sprongen, de crawlers bleven werken, de backender experimenteerde met NLP om innovatieve teksten van niet-innovatieve teksten te onderscheiden))). Maar de tijd voor de eindpresentatie naderde al.
7. Presentatie. Uit eigen ervaring kan ik zeggen dat je ongeveer 3 tot 4 uur vóór de deadline moet overstappen op het voorbereiden van een presentatie. Vooral als het om video gaat, kost het opnemen en bewerken ervan behoorlijk wat tijd. We zouden een video hebben. En we hadden een bijzonder persoon die zich hiermee bezig hield, en ook nog een aantal andere organisatorische vraagstukken oploste. In dit opzicht hebben we ons tot het allerlaatste moment niet afgeleid van het coderen.
8. Toonhoogte. Ik vond het niet leuk dat de presentaties en finales op een aparte weekdag (maandag) plaatsvonden. Hier werd hoogstwaarschijnlijk het beleid van de organisatoren voortgezet om het maximale uit de deelnemers te persen. Ik was niet van plan vrij te nemen van mijn werk, ik wilde alleen naar de finale komen, ook al nam de rest van mijn team een vrije dag. De emotionele onderdompeling in de hackathon was echter al zo hoog dat ik om 8 uur in de chat van mijn team (het werkteam, niet het hackathonteam) schreef dat ik de dag op eigen kosten in beslag nam, en naar de centrale ging kantoor voor staanplaatsen. Ons probleem bleek veel pure datawetenschappers te hebben, en dit had grote invloed op de aanpak van het oplossen van het probleem. Velen hadden een goede DS, maar niemand had een werkend prototype, velen konden de verboden van hun crawlers in zoekmachines niet omzeilen. Wij waren het enige team met een werkend prototype. En we wisten hoe we het probleem moesten oplossen. Uiteindelijk hebben we het circuit gewonnen, al hadden we het geluk dat we voor de minst competitieve taak kozen. Toen we naar de velden op andere circuits keken, beseften we dat we daar geen kans zouden hebben. Ik wil ook zeggen dat we heel veel geluk hebben gehad met de jury; ze hebben de code minutieus gecontroleerd. En, afgaande op de recensies, gebeurde dit niet in alle nummers.
9. Finale. Nadat we meerdere keren naar de jury waren geroepen voor een code review, gingen we, in de veronderstelling dat we eindelijk alle problemen hadden opgelost, lunchen bij Burger King. Daar belden de organisatoren ons weer, we moesten snel onze bestellingen inpakken en teruggaan.
De organisator liet ons zien in welke kamer we moesten gaan, en toen we binnenkwamen, bevonden we ons bij een training voor spreken in het openbaar voor de winnende teams. De jongens die op het podium moesten optreden waren goed opgeladen, iedereen kwam eruit als echte showmannen.
En ik moet toegeven dat we er in de finale, tegen de achtergrond van de sterkste teams van andere circuits, bleek uitzagen; de overwinning bij de nominatie voor overheidsklanten ging terecht naar het team van het vastgoedtechnologiecircuit. Ik denk dat de belangrijkste factoren die hebben bijgedragen aan onze overwinning op het circuit waren: de beschikbaarheid van een kant-en-klare blanco, waardoor we snel een prototype konden maken, de aanwezigheid van ‘hoogtepunten’ in het prototype (zoeken naar CEO’s op sociale netwerken) en de NLP-vaardigheden van onze backender, die ook de jury enorm interesseerden.
En tot slot traditionele dank aan iedereen die ons heeft gesteund, de jury van onze track, Evgeniy Evgrafiev (de auteur van het probleem dat we tijdens de hackathon hebben opgelost) en natuurlijk de organisatoren van de hackathon. Dit was misschien wel de grootste en coolste hackathon waar ik ooit aan heb deelgenomen, ik kan alleen maar wensen dat de jongens in de toekomst zo’n hoge standaard blijven behouden!
Bron: www.habr.com