Chámome Dmitry. E quero falar de como o noso equipo chegou ás finais do hackathon Urban Tech Challenge na pista de Big Data. Enseguida direi que este non é o primeiro hackathon no que participei, nin o primeiro no que levei premios. Neste sentido, na miña historia quero expresar algunhas observacións e conclusións xerais sobre a industria do hackathon no seu conxunto, e dar o meu punto de vista en contraposición ás críticas negativas que apareceron en liña inmediatamente despois do final do Urban Tech Challenge (por exemplo ).
Entón, primeiro algunhas observacións xerais.
1. É sorprendente que bastantes persoas pensen inxenuamente que un hackathon é algún tipo de competición deportiva onde gañan os mellores programadores. Isto está mal. Non considero casos nos que os propios organizadores de hackathon non saben o que queren (tamén vin). Pero, por regra xeral, a empresa que organiza un hackathon persegue os seus propios obxectivos. A súa lista pode ser diferente: podería ser unha solución técnica a algúns problemas, unha busca de novas ideas e persoas, etc. Estes obxectivos adoitan determinar o formato do evento, a súa temporalización, en liña/offline, como se formularán as tarefas (e se se formularán en absoluto), se haberá unha revisión do código no hackathon, etc. Tanto os equipos como o que fixeron son valorados dende este punto de vista. E gañan os equipos que mellor chegan ao punto que a empresa necesita, e moitos chegan a este de forma totalmente inconsciente e por accidente, pensando que realmente están a participar nunha competición deportiva. As miñas observacións mostran que, para motivar aos participantes, os organizadores deben crear polo menos a aparencia dun ambiente deportivo e condicións de igualdade, se non, recibirán unha onda de negatividade, como na revisión anterior. Pero divagamos.
2. De aí a seguinte conclusión. Os organizadores están interesados en que os participantes veñan ao hackathon co seu propio traballo, ás veces incluso organizan especialmente unha etapa de correspondencia en liña para este fin. Isto permite solucións de saída máis fortes. O concepto de "traballo propio" é moi relativo; calquera desenvolvedor experimentado pode acumular miles de liñas de código dos seus antigos proxectos no seu primeiro compromiso. E será este un desenvolvemento previamente preparado? Pero en calquera caso, aplícase a regra, que expresei en forma de famoso meme:
Para gañar, debes ter algo, algún tipo de vantaxe competitiva: un proxecto similar ao que fixeches no pasado, coñecementos e experiencia nun tema concreto, ou un traballo feito antes do inicio do hackathon. Si, non é deportivo. Si, isto pode non valer o esforzo dedicado (aquí, cada un decide por si mesmo se paga a pena codificar durante 3 semanas pola noite por un premio de 100 mil, repartido entre todo o equipo, e mesmo co risco de non conseguilo). Pero, moitas veces, esta é a única oportunidade de saír adiante.
3. Selección do equipo. Como notei nos chats de hackathon, moitos abordan este tema de forma bastante frívola (aínda que esta é a decisión máis importante que determinará o teu resultado no hackathon). En moitas áreas de actividade (tanto nos deportes como nos hackathons) vin que as persoas fortes adoitan unirse cos fortes, os débiles cos débiles, os intelixentes cos intelixentes, bueno, en xeral, xa entendes... Isto é máis ou menos o que ocorre nos chats: os programadores menos fortes son inmediatamente atrapados, as persoas que non teñen habilidades valiosas para un hackathon colgan no chat durante moito tempo e elixen un equipo co principio de que se alguén o tomase. . Nalgúns hackathons, practícase a asignación aleatoria a equipos e os organizadores afirman que os equipos aleatorios non funcionan peor que os existentes. Pero segundo as miñas observacións, as persoas motivadas, por regra xeral, atopan un equipo pola súa conta; se hai que asignar a alguén, moitas veces, moitas delas non chegan ao hackathon.
En canto á composición do equipo, esta é moi individual e moi dependente da tarefa. Podería dicir que a composición mínima do equipo viable é un deseñador - front-end ou front-end - back-end. Pero tamén coñezo casos nos que gañaron equipos formados só por front-enders, que engadiron un back-end simple en node.js ou fixeron unha aplicación móbil en React Native; ou só de backenders que fixeron un deseño sinxelo. En xeral, todo é moi individual e depende da tarefa. O meu plan para seleccionar un equipo para o hackathon era o seguinte: planeaba montar un equipo ou unirme a un equipo como front-end - back-end - deseñador (eu son un front-end). E moi axiña comecei a falar cun backender de Python e un deseñador que aceptou a invitación para unirse a nós. Un pouco máis tarde, uniuse a nós unha rapaza, analista de negocios, que xa tiña experiencia gañando un hackathon, e isto decidiu o tema de que se unise a nós. Despois dunha pequena reunión, decidimos chamarnos U4 (URBAN 4, urban four) por analoxía cos catro fantásticos. E ata puxeron unha imaxe correspondente no avatar da nosa canle de telegram.
4. Selección dunha tarefa. Como xa dixen, debes ter unha vantaxe competitiva, a tarefa para o hackathon selecciónase en función diso. En base a isto, mirando e avaliando a súa complexidade, decidímonos en dúas tarefas: un catálogo de empresas innovadoras de DPiIR e un chatbot de EFKO. A tarefa de DPIiR escolleuna o backender, a tarefa de EFKO escolleina eu, porque tiña experiencia escribindo chatbots en node.js e DialogFlow. A tarefa de EFKO tamén implicou ML; Teño algunha experiencia, non moi ampla, en ML. E segundo as condicións do problema, pareceume que era improbable que se resolvía usando ferramentas de ML. Esta sensación reforzouse cando fun ao encontro Urban Tech Challenge, onde os organizadores me mostraron un conxunto de datos sobre EFKO, onde había unhas 100 fotos de deseños de produtos (tomadas desde diferentes ángulos) e unhas 20 clases de erros de deseño. E, ao mesmo tempo, os que encargaron a tarefa querían acadar unha taxa de éxito de clasificación do 90%. Como resultado, preparei unha presentación da solución sen ML, o backender preparou unha presentación baseada no catálogo e xuntos, despois de finalizar as presentacións, enviámolas ao Urban Tech Challenge. Xa nesta fase deuse a coñecer o nivel de motivación e contribución de cada participante. O noso deseñador non participou nas discusións, respondeu tarde e mesmo encheu información sobre si mesmo na presentación no último momento, en xeral, xurdiron dúbidas.
Como resultado, pasamos a tarefa de DPiIR, e non nos molestaba nada que non aprobasemos a EFKO, xa que a tarefa nos parecía estraña, por dicilo suavemente.
5. Preparación para o hackathon. Cando por fin se soubo que estabamos clasificados para o hackathon, comezamos a preparar a preparación. E aquí non estou a defender comezar a escribir código unha semana antes do comezo do hackathon. Como mínimo, deberías ter un boilerplate preparado, co que poidas comezar a traballar inmediatamente, sen ter que configurar ferramentas e sen topar con erros dalgún lib que decidiches probar por primeira vez nun hackathon. Coñezo unha historia sobre enxeñeiros angulares que viñeron a un hackathon e pasaron 2 días configurando a construción do proxecto, polo que todo debería estar preparado con antelación. Pretendemos distribuír as responsabilidades do seguinte xeito: o backender escribe rastreadores que percorren Internet e coloca toda a información recollida na base de datos, mentres eu escribo unha API en node.js que consulta esta base de datos e envía os datos á fronte. Neste sentido, preparei un servidor con antelación usando express.js e preparei un front-end en react. Non uso CRA, sempre personalizo o paquete web para min e sei moi ben cales son os riscos que isto pode supoñer (lembra a historia dos desenvolvedores angulares). Neste momento, pedínlle modelos de interface ou polo menos maquetas ao noso deseñador para ter unha idea do que estaría expoñendo. En teoría, tamén debería facer os seus propios preparativos e coordinalos connosco, pero nunca recibín resposta. Como resultado, tomei prestado o deseño dun dos meus antigos proxectos. E comezou a funcionar aínda máis rápido, xa que todos os estilos para este proxecto xa estaban escritos. De aí a conclusión: non sempre se necesita un deseñador nun equipo))). Chegamos ao hackathon con estes desenvolvementos.
6. Traballar no hackathon. A primeira vez que vin ao meu equipo en directo foi só na apertura do hackathon no Centro de Distribución Central. Reunímonos, comentamos a solución e as fases de traballo do problema. E aínda que despois da inauguración tivemos que ir en autobús ata Outubro Vermello, fomos a durmir a casa, acordando chegar ao lugar ás 9.00 horas. Por que? Ao parecer, os organizadores querían sacarlle o máximo proveito aos participantes, polo que organizaron ese horario. Pero, na miña experiencia, pode codificar normalmente sen durmir unha noite. En canto ao segundo, xa non estou seguro. Un hackathon é un maratón; cómpre calcular e planificar adecuadamente a súa forza. Ademais, tivemos preparativos.
Por iso, despois de durmir, ás 9.00 estabamos sentados no sexto piso de Dewocracy. Entón o noso deseñador anunciou inesperadamente que non tiña un portátil e que traballaría desde a casa e que nos comunicaríamos por teléfono. Esta foi a última gota. E así pasamos dun catro a un tres, aínda que non cambiamos o nome do equipo. Unha vez máis, non foi un gran golpe para nós, xa tiña o deseño do antigo proxecto. En xeral, ao principio todo foi bastante ben e segundo o plan. Cargamos na base de datos (decidimos usar neo4j) un conxunto de datos de empresas innovadoras dos organizadores. Comecei a escribir, logo empreguei node.js e despois as cousas comezaron a fallar. Nunca traballara con neo4j antes, e ao principio estaba a buscar un controlador que funcione para esta base de datos, despois descubrín como escribir unha consulta e despois sorprendeume descubrir que esta base de datos, cando se consulta, devolve entidades no forma dunha matriz de obxectos nodos e os seus bordos. Eses. cando solicitei unha organización e todos os datos dela mediante TIN, en lugar dun obxecto de organización, devolvéronme unha longa variedade de obxectos que contiñan datos sobre esta organización e as relacións entre eles. Escribín un mapeador que percorreu toda a matriz e peguei todos os obxectos segundo a súa organización nun só obxecto. Pero na batalla, ao solicitar unha base de datos de 8 mil organizacións, executouse moi lentamente, uns 20 - 30 segundos. Comecei a pensar na optimización... E despois paramos a tempo e cambiamos a MongoDB, e tardamos uns 30 minutos. En total, perdéronse unhas 4 horas en neo5j.
Lembra, nunca leves tecnoloxía a un hackathon que non esteas familiarizado, pode haber sorpresas. Pero, en xeral, a parte deste fracaso, todo foi segundo o previsto. E xa na mañá do 9 de decembro tiñamos unha aplicación a pleno rendemento. Durante o resto do día, planeamos engadirlle funcións adicionais. No futuro, todo foi relativamente ben para min, pero o backender tivo unha morea de problemas coa prohibición dos seus rastreadores nos buscadores, no spam de agregadores de persoas xurídicas, que chegou nos primeiros lugares dos resultados da busca ao solicitar para cada empresa concreta. Pero é mellor que el o conte el mesmo. A primeira función adicional que engadín foi a busca por nome completo. Director Xeral de VKontakte. Levou varias horas.
Entón, na páxina da empresa na nosa aplicación apareceu un avatar do director xeral, unha ligazón á súa páxina VKontakte e outros datos. Foi unha boa guinda do pastel, aínda que quizais non nos dera a vitoria. Entón, quería realizar algunhas análises. Pero despois dunha longa busca de opcións (había moitos matices coa IU), decidín a agregación máis sinxela de organizacións por código de actividade económica. Xa pola noite, nas últimas horas, estiven elaborando un modelo para mostrar produtos innovadores (na nosa aplicación suponse que hai unha sección de Produtos e Servizos), aínda que o backend non estaba preparado para iso. Ao mesmo tempo, a base de datos foi inchando a pasos agigantados, os rastreadores continuaron traballando, o backender experimentou con NLP para distinguir textos innovadores dos non innovadores))). Pero xa se achegaba o momento da presentación final.
7. Presentación. Desde a miña propia experiencia, podo dicir que debería cambiar a preparar unha presentación unhas 3 ou 4 horas antes da súa data. Especialmente se se trata de vídeo, a súa gravación e edición leva bastante tempo. Deberiamos ter un vídeo. E tivemos unha persoa especial que se ocupou diso, e tamén resolveu outros problemas de organización. Neste sentido, non nos distraimos da codificación ata o último momento.
8. Lanzamento. Non me gustou que as presentacións e as finais se celebrasen nun día de semana separado (luns). Aquí, moi probablemente, continuou a política dos organizadores de espremer o máximo de participantes. Non pensaba tomar tempo libre do traballo, só quería chegar á final, aínda que o resto do meu equipo levouse o día libre. Porén, a inmersión emocional no hackathon xa era tan alta que ás 8 da mañá escribín no chat do meu equipo (o equipo de traballo, non o equipo de hackathon) que me levaba o día pola miña conta, e fun á central. oficina para parcelas. O noso problema resultou ter moitos científicos de datos puros, e isto afectou moito o enfoque para resolver o problema. Moitos tiñan un bo DS, pero ninguén tiña un prototipo funcionando, moitos non podían sortear as prohibicións dos seus rastreadores nos buscadores. Eramos o único equipo cun prototipo funcionando. E soubemos resolver o problema. Ao final, gañamos a pista, aínda que tivemos a gran sorte de escoller a tarefa menos competitiva. Mirando os campos noutras pistas, decatámonos de que alí non teríamos ningunha oportunidade. Tamén quero dicir que tivemos moita sorte co xurado, que comprobaron meticulosamente o código. E, a xulgar polas críticas, isto non ocorreu en todas as pistas.
9. Final. Despois de que nos chamaran ao xurado varias veces para unha revisión do código, nós, pensando que por fin resolveramos todos os problemas, fomos xantar a Burger King. Alí os organizadores chamáronnos de novo, tivemos que facer axiña os pedidos e volver.
O organizador indicounos a que sala necesitabamos entrar e, ao entrar, atopámonos nun adestramento para falar en público dos equipos gañadores. Os rapaces que debían actuar no escenario estaban ben cargados, todos saíron como auténticos showmen.
E teño que recoñecer que, na final, co pano de fondo dos equipos máis fortes doutras pistas, parecíamos pálidos; a vitoria na designación de clientes do goberno foi merecidamente para o equipo da pista inmobiliaria. Creo que os factores clave que contribuíron á nosa vitoria na pista foron: a dispoñibilidade dun branco listo, polo que puidemos facer rapidamente un prototipo, a presenza de "destacados" no prototipo (busca de CEOs nas redes sociais) e as habilidades PNL do noso backender , que tamén interesou moito ao xurado.
E para rematar, tradicional agradecemento a todos os que nos apoiaron, ao xurado da nosa pista, Evgeniy Evgrafiev (o autor do problema que resolvemos no hackathon) e por suposto aos organizadores do hackathon. Este foi quizais o hackathon máis grande e xenial no que participei, só podo desexarlles aos rapaces que manteñan un nivel tan alto no futuro!
Fonte: www.habr.com