Me llamo Dmitry Y quiero hablar sobre cómo nuestro equipo llegó a la final del hackathon Urban Tech Challenge en la pista de Big Data. Debo decir de inmediato que este no es el primer hackathon en el que participé, y no el primero en el que gano premios. En este sentido, en mi historia quiero expresar algunas observaciones generales y conclusiones sobre la industria del hackathon en general, y dar mi punto de vista en lugar de las críticas negativas que aparecieron en la red justo después del final del Urban Tech Challenge (por ejemplo,
este ).
Entonces, primero, algunas observaciones generales.
1. Es sorprendente que mucha gente piense ingenuamente que un hackathon es una especie de competencia deportiva en la que ganan los mejores programadores. Esto no es asi. No considero los casos en que los organizadores del hackathon no saben lo que quieren (también vi esto). Pero, por regla general, una empresa que organiza un hackathon persigue sus objetivos. Su lista puede ser diferente: puede ser una solución técnica a algunos problemas, la búsqueda de nuevas ideas y personas, etc. Estos objetivos a menudo determinan el formato del evento, su momento, en línea / fuera de línea, cómo se formularán las tareas (y si se formularán), si habrá una revisión del código en el hackathon, etc. Tanto los equipos como lo que hicieron se evalúan precisamente desde este punto de vista. Y aquellos equipos que mejor llegan al punto que necesita la compañía ganan, y muchos llegan a este punto completamente inconsciente y accidentalmente, pensando que realmente participan en la competencia deportiva. Mis observaciones muestran que para motivar a los participantes, los organizadores deben crear al menos la apariencia de un ambiente deportivo y condiciones iguales, de lo contrario recibirán una ola de negatividad, como en la revisión anterior. Pero nos desviamos.
2. De ahí la siguiente conclusión. Los organizadores están interesados en que los participantes vengan al hackathon con sus propias ideas, a veces incluso una etapa de correspondencia en línea está especialmente preparada para esto. Esto permite soluciones de salida más fuertes. El concepto de "su propio trabajo" es muy relativo, cualquier programador experimentado puede acumular miles de líneas de código de sus antiguos proyectos en el primer commit. ¿Y será un tiempo de operación preparado previamente? Pero en cualquier caso, se aplica la regla, que expresé en forma de un famoso meme:
Para ganar debe tener algo, algún tipo de ventaja competitiva: un proyecto similar que haya realizado en el pasado, conocimiento y experiencia en un tema específico, o que ya haya terminado el trabajo realizado antes del inicio del hackathon. Sí, no es deporte. Sí, esto puede no devolver el esfuerzo (aquí todos deciden si codificar 3 semanas en la noche por un premio de 100 mil, dividido por todo el equipo, e incluso con el riesgo de no obtenerlo). Pero, a menudo, esta es la única oportunidad para salir adelante.
3. Selección del equipo. Como noté en los chats de hackathon, muchas personas toman este problema con bastante ligereza (aunque, esta es la decisión más importante que determinará su resultado en el hackathon). En muchos campos de actividad (tanto en deportes como en hackatones), vi que las personas fuertes tienden a unirse con las fuertes, las débiles con las débiles, las personas inteligentes con las inteligentes, bueno, en general, entiendes ... Esto es lo que sucede en las salas de chat: programadores más o menos fuertes De inmediato, las personas que no tienen habilidades valiosas para hackathon permanecen en el chat durante mucho tiempo y eligen un equipo con el principio de que solo alguien lo toma. En algunos hackatones, se practica la distribución aleatoria entre los equipos, y los organizadores afirman que los equipos aleatorios no muestran el resultado peor que los ya establecidos. Pero según mis observaciones, las personas motivadas, por regla general, encuentran el equipo por sí mismas, si alguien tiene que ser distribuido, a menudo muchos de ellos no acuden al hackathon.
En cuanto a la composición del equipo, es muy individual y altamente dependiente de la tarea. Podría decir que el equipo mínimo viable es un diseñador, front-end o front-end, back-end. Pero también conozco casos en los que ganaron equipos que constaban solo de front-endors, que adjuntaron un back-end simple a node.js, o hicieron una aplicación móvil en React Native; o solo de beckenders que hicieron un diseño simple. En general, todo es muy individual y depende de la tarea. Mi plan para seleccionar un equipo para el hackathon era el siguiente: planeaba reunir un equipo o unirme a un equipo como diseñador de front-end-back-end (yo mismo soy el líder). Y rápidamente comenzó a conversar con un servidor de Python y un diseñador que aceptó la invitación para unirse a nosotros. Un poco más tarde, una chica analista de negocios se unió a nosotros, que ya tenía la experiencia de ganar el hackathon, y esto decidió la cuestión de que se uniera a nosotros. Después de una breve reunión, decidimos llamarnos U4 (URBAN 4, cuatro urbanos) similar a los cuatro fantásticos. E incluso pusieron una imagen correspondiente en nuestro canal de telegramas.
4. Elección de la tarea. Como dije, deberías tener una ventaja competitiva, la tarea de hackathon se elige en base a esto. Partiendo de esto, después de mirar la
lista de tareas y evaluar su complejidad, nos decidimos por dos tareas: un catálogo de empresas innovadoras de DPiIR y un bot de chat de EFKO. La tarea del Instituto de Desarrollo Industrial e Industrial fue elegida por el remitente, la tarea de EFKO fue elegida por mí, porque tenía experiencia escribiendo chatbots en node.js y DialogFlow. La tarea de EFKO también involucró a ML, tengo una experiencia no muy grande en ML. Y de acuerdo con las condiciones del problema, me pareció que apenas se resolvió por medio de ML. Esta sensación se fortaleció cuando fui a la reunión de Urban Tech Challenge, donde los organizadores me mostraron un conjunto de datos de EFCO, donde había alrededor de 100 fotos de diseños de productos (tomados desde diferentes ángulos) y alrededor de 20 clases de errores de diseño. Y al mismo tiempo, los clientes de la tarea querían una tasa de éxito de clasificación del 90%. Como resultado, preparé la presentación de la solución sin ML, el backender preparó la presentación de acuerdo con el catálogo y, una vez finalizadas las presentaciones, las enviamos al Urban Tech Challenge. Ya en esta etapa, se reveló el nivel de motivación y contribución de cada participante. Nuestro diseñador no participó en las discusiones, respondió tarde e incluso completó información sobre sí mismo en la presentación en el último momento, en general surgieron dudas.
Como resultado, pasamos por la tarea del Departamento de Construcción y Diseño, y no nos molestó en absoluto que no pasamos por EFKO, ya que la tarea nos pareció, por decirlo suavemente, extraño.
5. Preparación para el hackathon. Cuando finalmente se supo que fuimos al hackathon, comenzamos a preparar la pieza de trabajo. Y aquí no te insto a que comiences a escribir código una semana antes del inicio del hackathon. Como mínimo, debe tener preparada una placa repetitiva, con la que pueda ponerse a trabajar de inmediato sin tener que ajustar las herramientas, y sin tropezar con errores de ningún tipo que decida probar por primera vez en un hackathon. Sé una historia sobre pescadores que vinieron al hackathon y pasaron 2 días preparando el ensamblaje del proyecto, por lo que todo debe prepararse con anticipación. Supusimos distribuir las tareas de la siguiente manera: el bekender escribe rastreadores que escanean Internet y colocan toda la información recopilada en la base de datos, escribo la API en node.js, que solicita esta base de datos y envía los datos al frente. En este sentido, preparé el servidor por adelantado en express.js, y preparé la interfaz para reaccionar. No uso CRA, siempre personalizo el paquete web para mí y sé muy bien qué riesgos puede implicar (recordamos la historia sobre los pescadores). En este momento, solicité los espacios en blanco de la interfaz, o al menos maquetas de nuestro diseñador, para tener una idea de lo que impondría. En teoría, él también debería hacer sus preparativos y coordinarlos con nosotros, pero nunca recibí una respuesta. Como resultado, tomé prestado el diseño de uno de mis viejos proyectos. Y así comenzó a ser aún más rápido, ya que todos los estilos para este proyecto ya estaban escritos. De ahí la conclusión: el diseñador no siempre es necesario en el equipo))). Con estos desarrollos, llegamos al hackathon.
6. Trabaja en el hackathon. La primera vez que vi a mi equipo fue en vivo en la apertura del hackathon en el CDP. Nos reunimos, discutimos la solución y las etapas del trabajo en la tarea. Y aunque después de la apertura tuvimos que tomar los autobuses a Octubre Rojo, nos fuimos a casa a dormir, habiendo acordado venir a nuestro lugar a las 9.00. Por qué Los organizadores, al parecer, querían exprimir al máximo a los participantes, por lo que organizaron tal horario. Pero, en mi experiencia, normalmente puedes codificar sin dormir una noche. En cuanto al segundo, ya no estoy seguro. Hackathon es un maratón, necesitas calcular y planificar adecuadamente tu fuerza. Además, tuvimos espacios en blanco.
Por lo tanto, después de dormir, a las 9.00 estábamos sentados en el sexto piso de la Dewocracy. Luego, nuestro diseñador anunció inesperadamente que no tenía una computadora portátil, que trabajaría desde su casa y que nos comunicaríamos por teléfono. Esta fue la gota que colmó el vaso. Y entonces pasamos de cuatro a tres, aunque no cambiamos el nombre del equipo. Nuevamente, esto no se convirtió en un duro golpe para nosotros, ya tenía el diseño del antiguo proyecto. En general, al principio todo salió bastante bien y de acuerdo al plan. Hemos cargado un conjunto de datos de empresas innovadoras de los organizadores en la base de datos (decidimos usar neo4j). Comencé a escribir, luego tomé node.js, y luego fallas. Nunca antes había trabajado con neo4j, y primero busqué un controlador que funcionara para esta base de datos, luego descubrí cómo se escribe la consulta, y luego me sorprendió descubrir que esta base de datos devuelve entidades cuando se solicita, como una matriz de objetos de nodo y sus bordes. Es decir Cuando solicité la organización por TIN y todos los datos que contiene, en lugar de un solo objeto de organización, devolví una larga variedad de objetos que contenían datos sobre esta organización y la relación entre ellos. Escribí un mapeador que atravesó toda la matriz y pegó todos los objetos de la organización en un solo objeto. Pero en la batalla, cuando se consultaba una base de datos de 8,000 organizaciones, era extremadamente lenta durante aproximadamente 20-30 segundos. Pensé en la optimización ... Y luego nos detuvimos a tiempo y nos mudamos a MongoDB, y nos llevó unos 30 minutos. Se perdió un total de aproximadamente 5 horas en neo4j.
Recuerde, nunca tome una tecnología de hackathon con la que no esté familiarizado, puede haber sorpresas. Pero, en general, aparte de este fracaso, todo salió según lo planeado. Y ya en la mañana del 9 de diciembre teníamos una aplicación totalmente funcional. Para el resto del día, planeamos darle funciones adicionales. En el futuro, todo salió relativamente bien, pero el anunciante tuvo muchos problemas con la prohibición de sus rastreadores en los motores de búsqueda, en el spam de los agregadores de entidades legales, que aparecieron en los primeros lugares de los resultados de búsqueda al solicitar cada compañía específica. Pero sobre esto lo dirá mejor. La primera característica adicional que arruiné es una búsqueda por nombre completo CEO VKontakte. Tomó varias horas.
Entonces, en la página de la compañía en nuestra aplicación apareció el ava del director general, un enlace a su página VK y algunos otros datos. Fue una buena guinda del pastel, aunque puede que no nos haya asegurado una victoria. Entonces, quería terminar algunos análisis. Pero después de una larga búsqueda de opciones (había muchos matices con la interfaz de usuario), se decidió por la agregación más simple de organizaciones por código de actividad económica. Ya en la noche, en las últimas horas, estaba haciendo un espacio en blanco para mostrar productos innovadores (la sección Productos y servicios se supone en nuestra aplicación), aunque el back-end para esto no estaba listo. Al mismo tiempo, la base se hinchó a pasos agigantados, los rastreadores continuaron trabajando, el back-end experimentó con PNL para distinguir los textos innovadores de los no innovadores))). Pero ya era hora de la presentación final.
7. Presentación. Desde mi propia experiencia, puedo decir que debe cambiar a preparar una presentación en algún lugar 3-4 horas antes de su entrega. Especialmente si se supone que el video debe estar en él, tomar y editar toma mucho tiempo. Se suponía que teníamos un video. Y teníamos una persona especial que estaba involucrada en esto, y también resolvió una serie de otros problemas de organización. En este sentido, hasta el último momento, no nos distrajimos de la codificación.
8. Pitch. No me gustó que las presentaciones y la final se hicieran en un día laborable separado (lunes). Aquí, lo más probable, los organizadores continuaron la política de exprimir al máximo a los participantes. No planeaba tomarme un descanso del trabajo, solo quería llegar a la final, aunque el resto de mi equipo se tomó un fin de semana. Sin embargo, la inmersión emocional en el hackathon ya era tan alta que a las 8 de la mañana escribí en el chat de mi equipo (trabajando, no en el equipo de hackathon) que me tomé el día a mi costa y fui al CDC para los lanzamientos. Nuestro problema resultó ser una gran cantidad de datos de científicos puros y esto afectó en gran medida el enfoque para resolver el problema. Muchos tenían un buen DS, pero nadie tenía un prototipo que funcionara, muchos no podían evitar las prohibiciones de sus rastreadores en los motores de búsqueda. Éramos el único equipo con un prototipo funcional. Y supimos cómo resolver la tarea. Al final, ganamos la pista, aunque tuvimos mucha suerte de haber elegido la tarea menos competitiva. Al observar los tonos en otras pistas, nos dimos cuenta de que no tendríamos ninguna posibilidad allí. También quiero decir que tuvimos mucha suerte con el jurado, revisaron meticulosamente el código. Y, a juzgar por las críticas, esto estaba lejos de suceder en todas las pistas.
9. La final. Después de que fuimos convocados varias veces al jurado para una revisión del código, pensamos que finalmente habíamos resuelto todos los problemas y fuimos a cenar a Burger King. Allí, los organizadores nos volvieron a llamar, tuvimos que empacar apresuradamente los pedidos y regresar.
El organizador mostró a qué habitación entrar y, yendo allí, nos encontramos en un entrenamiento de oratoria para los equipos ganadores. Los chicos que se suponía que actuarían en el escenario estaban bien cargados, todos salieron como verdaderos showman.
Y debo admitir que, en la final, en el contexto de los equipos más fuertes de otras pistas, nos vimos pálidos, la victoria en la nominación del cliente estatal merecidamente dejó al equipo de la tecnología de bienes raíces de la pista. Creo que los factores clave que contribuyeron a nuestra victoria en la pista fueron: la disponibilidad de un espacio en blanco listo para usar, por lo que pudimos hacer rápidamente un prototipo, la presencia de "puntos destacados" en el prototipo (búsqueda de directores generales en redes sociales) y las habilidades de PNL de nuestro defensor quienes también están muy interesados en el jurado.
Y en conclusión, gracias tradicionales a todos los que nos apoyaron, al jurado de nuestra canción, Evgeny Evgrafiev (el autor de la tarea que resolvimos en el hackathon) y, por supuesto, a los organizadores del hackathon. Este fue quizás el hackathon más grande y genial de todos los que participé, ¡solo queda desear que los chicos mantengan una marca tan alta y más!