Em dic Dmitry. I vull parlar de com el nostre equip va arribar a la final del hackató Urban Tech Challenge a la pista de Big Data. De seguida diré que aquest no és el primer hackathon en què vaig participar, ni el primer en què vaig guanyar premis. En aquest sentit, a la meva història vull expressar algunes observacions i conclusions generals sobre el conjunt de la indústria de l'hackathon, i donar el meu punt de vista en contraposició a les crítiques negatives que van aparèixer en línia immediatament després de la finalització de l'Urban Tech Challenge (per exemple ).
Per tant, primer unes observacions generals.
1. Sorprèn que molta gent pensi ingènuament que un hackathon és una mena de competició esportiva on guanyen els millors programadors. Això està malament. No considero casos en què els mateixos organitzadors de hackathon no saben què volen (jo també ho he vist). Però, per regla general, l'empresa que organitza un hackathon persegueix els seus propis objectius. La seva llista pot ser diferent: podria ser una solució tècnica a alguns problemes, una recerca de noves idees i persones, etc. Aquests objectius sovint determinen el format de l'esdeveniment, la seva temporalització, en línia/fora de línia, com es formularan les tasques (i si es formularan en absolut), si hi haurà una revisió de codi a l'hackathon, etc. Tant els equips com el que van fer es valoren des d'aquest punt de vista. I els equips que millor arriben al punt que l'empresa necessita guanyen, i molts arriben a aquest punt de manera totalment inconscient i per casualitat, pensant que realment estan participant en una competició esportiva. Les meves observacions mostren que per motivar els participants, els organitzadors haurien de crear almenys l'aspecte d'un entorn esportiu i condicions iguals, en cas contrari rebran una onada de negativitat, com a la revisió anterior. Però divaguem.
2. D'aquí la següent conclusió. Els organitzadors estan interessats en que els participants vinguin a la hackathon amb el seu propi treball, de vegades fins i tot organitzen especialment una etapa de correspondència en línia per a aquest propòsit. Això permet solucions de sortida més fortes. El concepte de "treball propi" és molt relatiu; qualsevol desenvolupador experimentat pot acumular milers de línies de codi dels seus antics projectes en el seu primer commit. I aquest serà un desenvolupament prèviament preparat? Però en qualsevol cas, s'aplica la regla, que vaig expressar en forma d'un famós meme:
Per guanyar, has de tenir alguna cosa, algun tipus d'avantatge competitiu: un projecte similar al que vas fer en el passat, coneixements i experiència en un tema concret, o un treball fet abans de l'inici del hackathon. Sí, no és esportiu. Sí, potser no val la pena l'esforç invertit (aquí, cadascú decideix per si mateix si val la pena codificar durant 3 setmanes a la nit per un premi de 100 mil, repartits entre tot l'equip, i fins i tot amb el risc de no aconseguir-lo). Però, sovint, aquesta és l'única oportunitat per tirar endavant.
3. Selecció de l'equip. Com he observat als xats de hackathon, molts aborden aquest tema de manera bastant frívola (tot i que aquesta és la decisió més important que determinarà el vostre resultat a l'hackathon). En molts àmbits d'activitat (tant en els esports com en els hackatons) he vist que la gent forta tendeix a unir-se amb els forts, els febles amb els febles, els intel·ligents amb els intel·ligents, bé, en general, s'entén la idea... Això és aproximadament el que passa als xats: els programadors menys forts són immediatament atrapats, les persones que no tenen cap habilitat valuosa per a un hackathon es pengen al xat durant molt de temps i trien un equip amb el principi que si només algú ho prengués . En alguns hackathons, es practica l'assignació aleatòria als equips, i els organitzadors afirmen que els equips aleatoris no funcionen pitjor que els existents. Però segons les meves observacions, les persones motivades, per regla general, troben un equip pel seu compte; si s'ha d'assignar algú, sovint molts d'ells no acudeixen al hackathon.
Pel que fa a la composició de l'equip, aquesta és molt individual i molt dependent de la tasca. Podria dir que la composició mínima de l'equip viable és un dissenyador: front-end o front-end - back-end. Però també conec casos en què van guanyar equips formats només per front-enders, que van afegir un back-end senzill a node.js o van fer una aplicació mòbil a React Native; o només de backenders que van fer un disseny senzill. En general, tot és molt individual i depèn de la tasca. El meu pla per seleccionar un equip per al hackathon era el següent: tenia previst formar un equip o unir-me a un equip com front-end - back-end - dissenyador (jo mateix sóc front-end). I bastant ràpidament vaig començar a xerrar amb un backender de Python i un dissenyador que va acceptar la invitació per unir-se a nosaltres. Una mica més tard, una noia, analista de negocis, que ja tenia experiència guanyant un hackathon, es va unir a nosaltres, i això va decidir el tema de la seva incorporació a nosaltres. Després d'una breu reunió, vam decidir anomenar-nos U4 (URBAN 4, urban four) per analogia amb els quatre fantàstics. I fins i tot van posar una imatge corresponent a l'avatar del nostre canal de telegram.
4. Selecció d'una tasca. Com ja he dit, has de tenir un avantatge competitiu, la tasca per al hackathon es selecciona en funció d'això. En base a això, després d'haver mirat i avaluant la seva complexitat, ens vam establir en dues tasques: un catàleg d'empreses innovadores de DPiIR i un chatbot d'EFKO. La tasca de DPIiR va ser escollida pel backender, la tasca d'EFKO la vaig triar jo, perquè tenia experiència escrivint chatbots a node.js i DialogFlow. La tasca EFKO també implicava ML; tinc una mica d'experiència, no molt àmplia, en ML. I segons les condicions del problema, em va semblar que era poc probable que es resolgués amb eines de ML. Aquesta sensació es va reforçar quan vaig anar a la trobada Urban Tech Challenge, on els organitzadors em van mostrar un conjunt de dades sobre EFKO, on hi havia unes 100 fotos de dissenys de productes (preses des de diferents angles) i unes 20 classes d'errors de disseny. I, al mateix temps, els que van ordenar la tasca volien aconseguir una taxa d'èxit de classificació del 90%. Com a resultat, vaig preparar una presentació de la solució sense ML, el backender va preparar una presentació basada en el catàleg i entre tots, després de finalitzar les presentacions, les vam enviar a l'Urban Tech Challenge. Ja en aquesta etapa es va revelar el nivell de motivació i contribució de cada participant. El nostre dissenyador no va participar en les discussions, va respondre tard i fins i tot va omplir informació sobre ell mateix a la presentació a l'últim moment, en general, van sorgir dubtes.
Com a resultat, vam aprovar la tasca de DPiIR, i no ens vam molestar gens perquè no vam aprovar l'EFKO, ja que la tasca ens va semblar estranya, per dir-ho suaument.
5. Preparació per al hackató. Quan finalment es va saber que ens havíem classificat per a l'hackathon, vam començar a preparar la preparació. I aquí no defenso començar a escriure codi una setmana abans de l'inici del hackathon. Com a mínim, hauríeu de tenir un boilerplate a punt, amb el qual podeu començar a treballar immediatament, sense haver de configurar eines i sense topar amb errors d'alguna lib que heu decidit provar per primera vegada en un hackathon. Conec una història sobre enginyers angulars que van venir a un hackathon i van passar 2 dies configurant la construcció del projecte, així que tot s'hauria de preparar amb antelació. Teníem la intenció de distribuir les responsabilitats de la següent manera: el backender escriu rastrejadors que rastregen Internet i posa tota la informació recopilada a la base de dades, mentre que jo escric una API a node.js que consulta aquesta base de dades i envia les dades al davant. En aquest sentit, vaig preparar un servidor per endavant amb express.js i vaig preparar un front-end en react. No faig servir CRA, sempre personalitzo el paquet web per a mi i sé molt bé quins riscos pot suposar (recordeu la història dels desenvolupadors angulars). En aquest moment, vaig demanar plantilles d'interfície o almenys maquetes al nostre dissenyador per tenir una idea de què estaria dissenyant. En teoria, també hauria de fer els seus propis preparatius i coordinar-los amb nosaltres, però mai vaig rebre resposta. Com a resultat, vaig agafar en préstec el disseny d'un dels meus projectes antics. I va començar a funcionar encara més ràpid, ja que tots els estils d'aquest projecte ja havien estat escrits. D'aquí la conclusió: no sempre es necessita un dissenyador en un equip))). Hem vingut a la hackathon amb aquests desenvolupaments.
6. Treballar a la hackathon. La primera vegada que vaig veure el meu equip en directe va ser només a l'obertura del hackathon al Centre de Distribució Central. Ens vam reunir, vam discutir la solució i les etapes de treball del problema. I tot i que després de l'obertura havíem d'anar amb bus fins a Octubre Roig, vam anar a dormir a casa, acordant arribar al lloc a les 9.00. Per què? Pel que sembla, els organitzadors volien treure el màxim profit dels participants, així que van organitzar aquest programa. Però, segons la meva experiència, podeu codificar normalment sense dormir una nit. Pel que fa al segon, ja no n'estic segur. Un hackathon és una marató; cal calcular i planificar adequadament la vostra força. A més, teníem preparatius.
Per tant, després de dormir, a les 9.00 estàvem asseguts al sisè pis de Dewocracy. Aleshores, el nostre dissenyador va anunciar inesperadament que no tenia un ordinador portàtil i que treballaria des de casa, i que ens comunicaríem per telèfon. Aquesta va ser la darrera gota. I així vam passar d'un quatre a un tres, tot i que no vam canviar el nom de l'equip. De nou, això no va ser un gran cop per a nosaltres; ja tenia el disseny de l'antic projecte. En general, al principi tot va anar molt bé i segons el previst. Vam carregar a la base de dades (vam decidir utilitzar neo4j) un conjunt de dades d'empreses innovadores dels organitzadors. Vaig començar a escriure, després vaig agafar node.js i les coses van començar a fallar. Mai havia treballat amb neo4j abans, i al principi estava buscant un controlador que funcioni per a aquesta base de dades, després vaig descobrir com escriure una consulta i després em va sorprendre descobrir que aquesta base de dades, quan es consulta, retorna entitats a la base de dades. forma d'una matriu d'objectes node i les seves vores. Aquells. quan vaig sol·licitar una organització i totes les dades d'aquesta per TIN, en comptes d'un objecte d'organització, em van retornar una gran varietat d'objectes que contenien dades sobre aquesta organització i les relacions entre ells. Vaig escriure un mapeador que va recórrer tota la matriu i va enganxar tots els objectes segons la seva organització en un objecte. Però en la batalla, quan es va demanar una base de dades de 8 mil organitzacions, es va executar molt lentament, uns 20-30 segons. Vaig començar a pensar en l'optimització... I després ens vam aturar a temps i vam canviar a MongoDB, i vam trigar uns 30 minuts. En total, es van perdre unes 4 hores a neo5j.
Recordeu que no porteu mai la tecnologia a un hackató amb el qual no esteu familiaritzat, pot haver-hi sorpreses. Però, en general, a part d'aquest fracàs, tot va anar segons el previst. I ja el matí del 9 de desembre teníem una aplicació totalment funcionant. Durant la resta del dia teníem previst afegir-hi funcions addicionals. En el futur, tot va anar relativament bé per a mi, però el backender va tenir un munt de problemes amb la prohibició dels seus rastrejadors als motors de cerca, en el correu brossa d'agregadors de persones jurídiques, que va arribar als primers llocs dels resultats de la cerca en sol·licitar per a cada empresa concreta. Però és millor que ho expliqui ell mateix. La primera funció addicional que vaig afegir va ser la cerca per nom complet. Director general de VKontakte. Va trigar diverses hores.
Així, a la pàgina de l'empresa de la nostra aplicació, va aparèixer un avatar del director general, un enllaç a la seva pàgina VKontakte i algunes altres dades. Va ser una bona cirera al pastís, tot i que potser no ens ha donat la victòria. Aleshores, volia fer algunes anàlisis. Però després d'una llarga recerca d'opcions (hi havia molts matisos amb la IU), em vaig decidir per l'agregació més senzilla d'organitzacions per codi d'activitat econòmica. Ja al vespre, en les últimes hores, estava dissenyant una plantilla per mostrar productes innovadors (a la nostra aplicació se suposa que hi hauria una secció de Productes i Serveis), tot i que el backend no estava preparat per a això. Al mateix temps, la base de dades augmentava a passos de gegant, els rastrejadors van continuar treballant, el backender va experimentar amb PNL per distingir els textos innovadors dels no innovadors))). Però ja s'acostava l'hora de la presentació final.
7. Presentació. Des de la meva pròpia experiència, puc dir que hauríeu de canviar a la preparació d'una presentació unes 3 o 4 hores abans del termini. Sobretot si es tracta de vídeo, la seva gravació i edició requereix molt de temps. Havíem de tenir un vídeo. I vam tenir una persona especial que s'ocupava d'això i també va resoldre una sèrie d'altres problemes organitzatius. En aquest sentit, no ens vam distreure de la codificació fins a l'últim moment.
8. Pitch. No em va agradar que les presentacions i les finals es fessin un dia feiner a part (dilluns). Aquí, molt probablement, va continuar la política dels organitzadors d'esprémer el màxim dels participants. No pensava prendre temps lliure de la feina, només volia arribar a la final, tot i que la resta del meu equip es va agafar el dia lliure. Tanmateix, la immersió emocional a l'hackathon ja era tan alta que a les 8 del matí vaig escriure al xat del meu equip (l'equip de treball, no l'equip d'hackathon) que m'estava agafant el dia pel meu compte, i vaig anar a la central. oficina per parcel·les. El nostre problema va resultar tenir molts científics de dades pures, i això va afectar molt l'enfocament per resoldre el problema. Molts tenien un bon DS, però ningú no tenia un prototip funcionant, molts no van poder evitar les prohibicions dels seus rastrejadors als motors de cerca. Érem l'únic equip amb un prototip funcionant. I vam saber com resoldre el problema. Al final vam guanyar la pista, tot i que vam tenir la gran sort d'escollir la tasca menys competitiva. Mirant els camps d'altres vies, ens vam adonar que allà no tindríem cap possibilitat. També vull dir que vam tenir molta sort amb el jurat, que van comprovar meticulosament el codi. I, a jutjar per les crítiques, això no va passar a totes les pistes.
9. Final. Després que ens van cridar diverses vegades al jurat per a una revisió del codi, nosaltres, pensant que finalment havíem resolt tots els problemes, vam anar a dinar a Burger King. Allà els organitzadors ens van tornar a trucar, vam haver de fer les comandes ràpidament i tornar.
L'organitzador ens va ensenyar a quina sala havíem d'entrar i, en entrar, ens vam trobar en un entrenament per parlar en públic dels equips guanyadors. Els nois que havien d'actuar a l'escenari estaven ben carregats, tothom va sortir com autèntics showmen.
I he de reconèixer que a la final, amb el teló de fons dels equips més forts d'altres pistes, ens veiem pàl·lids; la victòria en la nominació de client del govern va ser merescudament per a l'equip de la pista de tecnologia immobiliària. Crec que els factors clau que van contribuir a la nostra victòria a la pista van ser: la disponibilitat d'un blank preconfeccionat, gràcies al qual vam poder fer un prototip ràpidament, la presència de "destacats" al prototip (cerca de CEOs). a les xarxes socials) i les habilitats en PNL del nostre backender , que també va interessar molt al jurat.
I com a conclusió, les tradicionals gràcies a tots els que ens van donar suport, al jurat de la nostra pista, Evgeniy Evgrafiev (l'autor del problema que vam resoldre a l'hackathon) i per descomptat als organitzadors del hackathon. Aquest va ser potser el hackathon més gran i fantàstic en el qual he participat, només puc desitjar que els nois mantinguin un nivell tan alt en el futur!
Font: www.habr.com