Il mio nome è Dmitrij. E voglio parlare di come il nostro team è arrivato alle finali dell'hackathon Urban Tech Challenge sulla pista Big Data. Dirò subito che questo non è il primo hackathon a cui ho partecipato, e non il primo a cui ho vinto dei premi. A questo proposito, nel mio racconto voglio esprimere alcune osservazioni e conclusioni generali riguardanti l'industria degli hackathon nel suo complesso, e dare il mio punto di vista in contrapposizione alle recensioni negative apparse online subito dopo la fine dell'Urban Tech Challenge (per esempio ).
Quindi prima alcune osservazioni generali.
1. È sorprendente che molte persone pensino ingenuamente che un hackathon sia una sorta di competizione sportiva in cui vincono i migliori programmatori. Questo è sbagliato. Non prendo in considerazione i casi in cui gli stessi organizzatori dell'hackathon non sanno cosa vogliono (ho visto anche questo). Ma, di regola, l'azienda che organizza un hackathon persegue i propri obiettivi. Il loro elenco potrebbe essere diverso: potrebbe essere una soluzione tecnica ad alcuni problemi, una ricerca di nuove idee e persone, ecc. Questi obiettivi spesso determinano il formato dell'evento, la sua tempistica, online/offline, come verranno formulati i compiti (e se verranno formulati), se ci sarà una revisione del codice durante l'hackathon, ecc. Si valuta da questo punto di vista sia le squadre che quello che hanno fatto. E vincono quelle squadre che riescono meglio a raggiungere il punto di cui l'azienda ha bisogno, e molte arrivano a questo punto in modo completamente inconscio e per sbaglio, pensando di partecipare davvero a una competizione sportiva. Le mie osservazioni mostrano che per motivare i partecipanti, gli organizzatori dovrebbero creare almeno l'apparenza di un ambiente sportivo e di pari condizioni, altrimenti riceveranno un'ondata di negatività, come nella recensione sopra. Ma stiamo divagando.
2. Da qui la seguente conclusione. Gli organizzatori sono interessati che i partecipanti vengano all'hackathon con il proprio lavoro, a volte organizzano anche appositamente una fase di corrispondenza online per questo scopo. Ciò consente soluzioni di output più forti. Il concetto di “lavoro proprio” è molto relativo; qualsiasi sviluppatore esperto può accumulare migliaia di righe di codice dai suoi vecchi progetti nel suo primo commit. E si tratterà di uno sviluppo già preparato? Ma in ogni caso vale la regola che ho espresso sotto forma di un famoso meme:
Per vincere, devi avere qualcosa, una sorta di vantaggio competitivo: un progetto simile a quello che hai realizzato in passato, conoscenza ed esperienza su un argomento specifico o un lavoro già pronto svolto prima dell'inizio dell'hackathon. Sì, non è sportivo. Sì, forse questo non vale la pena (qui ognuno decide da solo se vale la pena programmare per 3 settimane di notte per un premio di 100mila, diviso tra l'intero team, e anche con il rischio di non riceverlo). Ma, spesso, questa è l’unica possibilità per andare avanti.
3. Selezione della squadra. Come ho notato nelle chat dell'hackathon, molti affrontano questo problema in modo piuttosto frivolo (sebbene questa sia la decisione più importante che determinerà il tuo risultato all'hackathon). In molti ambiti di attività (sia nello sport che negli hackathon) ho visto che le persone forti tendono a unirsi ai forti, i deboli ai deboli, gli intelligenti agli intelligenti, beh, in generale, hai capito... Questo è più o meno quello che succede nelle chat: i programmatori meno forti vengono subito presi, le persone che non hanno competenze utili per un hackathon rimangono a lungo nella chat e scelgono una squadra in base al principio che se solo qualcuno lo accettasse . In alcuni hackathon viene praticata l'assegnazione casuale alle squadre e gli organizzatori affermano che le squadre casuali non ottengono risultati peggiori di quelle esistenti. Ma secondo le mie osservazioni, le persone motivate, di regola, trovano una squadra da sole; se qualcuno deve essere assegnato, spesso molti di loro non vengono all'hackathon.
Per quanto riguarda la composizione della squadra, questa è molto individuale e dipende fortemente dal compito. Potrei dire che la composizione minima del team vitale è un designer - front-end o front-end - back-end. Ma conosco anche casi in cui hanno vinto team composti solo da front-end, che hanno aggiunto un semplice back-end in node.js o hanno realizzato un'applicazione mobile in React Native; o solo da backend che hanno realizzato layout semplici. In generale, tutto è molto individuale e dipende dal compito. Il mio piano per selezionare una squadra per l'hackathon era il seguente: pianificavo di mettere insieme una squadra o unirmi a una squadra come front-end - back-end - designer (io stesso sono un front-end). E abbastanza rapidamente ho iniziato a chattare con un backender Python e un designer che hanno accettato l'invito a unirsi a noi. Poco dopo si è unita a noi una ragazza, un'analista aziendale, che aveva già esperienza nella vincita di un hackathon, e questo ha deciso la questione della sua unione con noi. Dopo un breve incontro, abbiamo deciso di chiamarci U4 (URBAN 4, urban four) per analogia con i fantastici quattro. E hanno persino messo un'immagine corrispondente sull'avatar del nostro canale Telegram.
4. Selezione di un'attività. Come ho già detto, devi avere un vantaggio competitivo, in base a questo viene selezionato il compito per l'hackathon. Sulla base di questo, dopo aver guardato e valutandone la complessità, ci siamo concentrati su due compiti: un catalogo di imprese innovative di DPiIR e un chatbot di EFKO. Il compito di DPIiR è stato scelto dal backender, il compito di EFKO è stato scelto da me, perché aveva esperienza nella scrittura di chatbot in node.js e DialogFlow. L'attività EFKO ha coinvolto anche il ML; ho una certa esperienza, non molto estesa, in ML. E in base alle condizioni del problema, mi è sembrato improbabile che potesse essere risolto utilizzando gli strumenti ML. Questa sensazione si è rafforzata quando sono andato al meetup dell'Urban Tech Challenge, dove gli organizzatori mi hanno mostrato un set di dati su EFKO, dove c'erano circa 100 foto di layout di prodotto (scattate da diverse angolazioni) e circa 20 classi di errori di layout. E, allo stesso tempo, i committenti volevano raggiungere una percentuale di successo nella classificazione del 90%. Di conseguenza, ho preparato una presentazione della soluzione senza ML, il backender ha preparato una presentazione basata sul catalogo e insieme, dopo aver finalizzato le presentazioni, le abbiamo inviate all'Urban Tech Challenge. Già in questa fase è stato rivelato il livello di motivazione e di contributo di ciascun partecipante. Il nostro designer non ha preso parte alle discussioni, ha risposto in ritardo e all'ultimo momento ha persino inserito informazioni su se stesso nella presentazione, in generale sono sorti dubbi.
Di conseguenza, abbiamo superato il compito da DPiIR e non eravamo affatto turbati dal fatto di non aver superato l'EFKO, poiché il compito ci sembrava strano, per usare un eufemismo.
5. Preparazione per l'hackathon. Quando finalmente si è saputo che ci eravamo qualificati per l'hackathon, abbiamo iniziato a preparare i preparativi. E qui non sto sostenendo di iniziare a scrivere codice una settimana prima dell'inizio dell'hackathon. Come minimo dovresti avere pronto un boilerplate, con il quale puoi iniziare subito a lavorare, senza dover configurare strumenti e senza imbatterti nei bug di qualche lib che hai deciso di provare per la prima volta durante un hackathon. Conosco una storia di ingegneri angolari che sono venuti a un hackathon e hanno trascorso 2 giorni a preparare la costruzione del progetto, quindi tutto dovrebbe essere preparato in anticipo. Intendevamo distribuire le responsabilità come segue: il backender scrive crawler che scandagliano Internet e inseriscono tutte le informazioni raccolte nel database, mentre io scrivo un'API in node.js che interroga questo database e invia i dati in primo piano. A questo proposito ho preparato in anticipo un server utilizzando express.js e preparato un front-end in React. Non utilizzo CRA, personalizzo sempre il webpack per me e so molto bene quali rischi ciò può comportare (ricordate la storia degli sviluppatori angolari). A questo punto ho richiesto dei modelli di interfaccia o almeno dei mockup al nostro designer per avere un'idea di cosa avrei realizzato. In teoria dovrebbe anche fare i suoi preparativi e coordinarli con noi, ma non ho mai ricevuto risposta. Di conseguenza, ho preso in prestito il design da uno dei miei vecchi progetti. E ha iniziato a funzionare ancora più velocemente, poiché tutti gli stili per questo progetto erano già stati scritti. Da qui la conclusione: un designer non è sempre necessario in una squadra))). Siamo venuti all'hackathon con questi sviluppi.
6. Lavora all'hackathon. La prima volta che ho visto la mia squadra dal vivo è stato solo all'apertura dell'hackathon presso il Central Distribution Center. Ci siamo incontrati, abbiamo discusso la soluzione e le fasi di lavoro sul problema. E anche se dopo l'apertura dovevamo andare in autobus a Ottobre Rosso, siamo tornati a casa a dormire, concordando di arrivare sul posto entro le 9.00. Perché? Apparentemente gli organizzatori volevano ottenere il massimo dai partecipanti, quindi hanno organizzato proprio questo programma. Ma, secondo la mia esperienza, puoi programmare normalmente senza dormire per una notte. Per quanto riguarda il secondo, non ne sono più sicuro. Un hackathon è una maratona; devi calcolare e pianificare adeguatamente la tua forza. Inoltre, avevamo dei preparativi.
Così, dopo aver dormito, alle 9.00 eravamo seduti al sesto piano di Dewocracy. Poi il nostro designer ha annunciato inaspettatamente che non aveva un laptop e che avrebbe lavorato da casa e che avremmo comunicato telefonicamente. Questa era l'ultima cannuccia. E così siamo passati dal quattro al tre, anche se non abbiamo cambiato il nome della squadra. Anche in questo caso per noi non è stato un duro colpo, avevo già il design del vecchio progetto. In generale, all'inizio tutto è andato abbastanza bene e secondo i piani. Abbiamo caricato nel database (abbiamo deciso di utilizzare neo4j) un set di dati di aziende innovative degli organizzatori. Ho iniziato a scrivere, poi ho preso node.js e poi le cose hanno iniziato a funzionare male. Non avevo mai lavorato con neo4j prima e all'inizio stavo cercando un driver funzionante per questo database, poi ho capito come scrivere una query e poi sono rimasto sorpreso di scoprire che questo database, quando interrogato, restituisce entità nel forma di un array di oggetti nodo e dei loro bordi. Quelli. quando ho richiesto un'organizzazione e tutti i dati su di essa tramite TIN, invece di un oggetto dell'organizzazione, mi è stata restituita una lunga serie di oggetti contenenti dati su questa organizzazione e le relazioni tra loro. Ho scritto un mappatore che esaminava l'intero array e incollava tutti gli oggetti in base alla loro organizzazione in un unico oggetto. Ma in battaglia, quando si richiede un database di 8mila organizzazioni, viene eseguita in modo estremamente lento, circa 20-30 secondi. Ho iniziato a pensare all'ottimizzazione... Poi ci siamo fermati in tempo e siamo passati a MongoDB, e ci sono voluti circa 30 minuti. In totale, su neo4j sono state perse circa 5 ore.
Ricorda, non portare mai la tecnologia a un hackathon con cui non hai familiarità, potrebbero esserci sorprese. Ma in generale, a parte questo fallimento, tutto è andato secondo i piani. E già la mattina del 9 dicembre avevamo un'applicazione perfettamente funzionante. Per il resto della giornata abbiamo pianificato di aggiungervi ulteriori funzionalità. In futuro, per me tutto è andato relativamente bene, ma il backender ha avuto un sacco di problemi con il divieto dei suoi crawler nei motori di ricerca, nello spam di aggregatori di persone giuridiche, che sono arrivati ai primi posti nei risultati di ricerca quando hanno richiesto per ogni specifica azienda. Ma è meglio che lo racconti lui stesso. La prima funzionalità aggiuntiva che ho aggiunto è stata la ricerca per nome completo. Direttore generale di VKontakte. Ci sono volute diverse ore.
Quindi, sulla pagina dell'azienda nella nostra applicazione, è apparso l'avatar del direttore generale, un collegamento alla sua pagina VKontakte e alcuni altri dati. È stata una bella ciliegina sulla torta, anche se forse non ci ha regalato la vittoria. Quindi, volevo eseguire alcune analisi. Ma dopo una lunga ricerca di opzioni (c'erano molte sfumature nell'interfaccia utente), ho optato per l'aggregazione più semplice delle organizzazioni per codice di attività economica. Già la sera, nelle ultime ore, stavo predisponendo un template per la visualizzazione di prodotti innovativi (nella nostra applicazione dovrebbe esserci una sezione Prodotti e Servizi), anche se il backend non era pronto per questo. Allo stesso tempo, il database si stava gonfiando a passi da gigante, i crawler continuavano a funzionare, il backender sperimentava la PNL per distinguere i testi innovativi da quelli non innovativi))). Ma il momento della presentazione finale si stava già avvicinando.
7. Presentazione. Dalla mia esperienza, posso dire che dovresti iniziare a preparare una presentazione circa 3 o 4 ore prima della scadenza. Soprattutto se si tratta di video, le riprese e il montaggio richiedono molto tempo. Avremmo dovuto fare un video. E avevamo una persona speciale che si occupava di questo e risolveva anche una serie di altri problemi organizzativi. A questo proposito, non ci siamo distratti dalla programmazione fino all'ultimo momento.
8. Intonazione. Non mi è piaciuto che le presentazioni e le finali si siano svolte in un giorno feriale separato (lunedì). Qui, molto probabilmente, è continuata la politica degli organizzatori di spremere il massimo dai partecipanti. Non avevo intenzione di prendermi una pausa dal lavoro, volevo solo arrivare alla finale, anche se il resto della mia squadra si è preso un giorno libero. Tuttavia, l'immersione emotiva nell'hackathon era già così alta che alle 8 del mattino ho scritto nella chat del mio team (il team di lavoro, non il team dell'hackathon) che avrei trascorso la giornata a mie spese e sono andato alla centrale ufficio per le piazzole. Si è scoperto che il nostro problema aveva molti data scientist puri e ciò ha influenzato notevolmente l'approccio alla risoluzione del problema. Molti avevano un buon DS, ma nessuno aveva un prototipo funzionante, molti non riuscivano ad aggirare i divieti dei loro crawler nei motori di ricerca. Eravamo l'unica squadra con un prototipo funzionante. E sapevamo come risolvere il problema. Alla fine abbiamo vinto la pista, anche se siamo stati molto fortunati ad aver scelto la prova meno competitiva. Guardando i tiri degli altri tracciati ci siamo resi conto che lì non avremmo avuto alcuna possibilità. Voglio anche dire che siamo stati molto fortunati con la giuria: hanno controllato meticolosamente il codice. E, a giudicare dalle recensioni, ciò non è avvenuto in tutte le tracce.
9. Finale. Dopo essere stati chiamati più volte in giuria per la revisione del codice, noi, pensando di aver finalmente risolto tutti i problemi, siamo andati a pranzare al Burger King. Lì gli organizzatori ci hanno chiamato di nuovo, abbiamo dovuto fare velocemente le valigie e tornare indietro.
L'organizzatore ci ha mostrato in quale stanza dovevamo entrare e, entrando, ci siamo ritrovati a una sessione di allenamento per parlare in pubblico per le squadre vincitrici. I ragazzi che avrebbero dovuto esibirsi sul palco erano carichissimi, tutti uscivano come dei veri showmen.
E devo ammettere che in finale, sullo sfondo delle squadre più forti di altri circuiti, sembravamo pallidi; la vittoria nella nomina del cliente governativo è andata meritatamente alla squadra del percorso tecnologico immobiliare. Penso che i fattori chiave che hanno contribuito alla nostra vittoria in pista siano stati: la disponibilità di un pezzo grezzo già pronto, grazie al quale siamo stati in grado di realizzare rapidamente un prototipo, la presenza di "punti salienti" nel prototipo (ricerca di CEO sui social network) e le competenze di PNL del nostro backender, che hanno interessato molto anche la giuria.
E in conclusione, il tradizionale ringraziamento a tutti coloro che ci hanno supportato, alla giuria del nostro brano, Evgeniy Evgrafiev (l'autore del problema che abbiamo risolto all'hackathon) e ovviamente agli organizzatori dell'hackathon. Questo è stato forse l'hackathon più grande e più bello a cui abbia mai partecipato, posso solo augurare ai ragazzi di mantenere uno standard così elevato in futuro!
Fonte: habr.com