Mi nombre es Dmitry. Y quiero hablar sobre cómo nuestro equipo llegó a la final del hackathon Urban Tech Challenge en la pista de Big Data. Diré de inmediato que este no es el primer hackathon en el que participo ni el primero en el que obtuve premios. En este sentido, en mi historia quiero expresar algunas observaciones y conclusiones generales sobre la industria del hackathon en su conjunto, y dar mi punto de vista en contraposición a las críticas negativas que aparecieron en línea inmediatamente después del final del Urban Tech Challenge (por ejemplo ).
Primero algunas observaciones generales.
1. Es sorprendente que mucha gente piense ingenuamente que un hackathon es una especie de competición deportiva en la que ganan los mejores programadores. Esto está mal. No considero los casos en los que los propios organizadores del hackathon no saben lo que quieren (yo también lo he visto). Pero, por regla general, la empresa que organiza un hackathon persigue sus propios objetivos. Su lista puede ser diferente: podría ser una solución técnica a algunos problemas, una búsqueda de nuevas ideas y personas, etc. Estos objetivos a menudo determinan el formato del evento, su calendario, 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. Desde este punto de vista se valora tanto los equipos como lo que hicieron. Y ganan aquellos equipos que mejor llegan al punto que la empresa necesita, y muchos llegan a este punto de forma completamente inconsciente y por accidente, pensando que realmente están participando en una competición 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 reseña anterior. Pero estamos divagando.
2. De ahí la siguiente conclusión. Los organizadores están interesados en que los participantes acudan al hackathon con su propio trabajo, a veces incluso organizan especialmente una etapa de correspondencia en línea para este fin. Esto permite soluciones de producción más sólidas. El concepto de “trabajo propio” es muy relativo; cualquier desarrollador experimentado puede acumular miles de líneas de código de sus proyectos antiguos en su primera confirmación. ¿Y será este un desarrollo preparado previamente? Pero en cualquier caso se aplica la regla que expresé en forma de un famoso meme:
Para ganar, debes tener algo, algún tipo de ventaja competitiva: un proyecto similar que hiciste en el pasado, conocimiento y experiencia en un tema específico, o un trabajo ya hecho antes del inicio del hackathon. Sí, no es deportivo. Sí, puede que no valga la pena el esfuerzo realizado (aquí cada uno decide por sí mismo si vale la pena codificar durante 3 semanas por la noche para obtener un premio de 100 mil, dividido entre todo el equipo, e incluso con el riesgo de no conseguirlo). Pero, a menudo, ésta es la única oportunidad de salir adelante.
3. Selección del equipo. Como noté en los chats de hackathon, muchos abordan este tema de manera bastante frívola (aunque esta es la decisión más importante que determinará su resultado en el hackathon). En muchas áreas de actividad (tanto en deportes como en hackathons) he visto que las personas fuertes tienden a unirse con los fuertes, los débiles con los débiles, los inteligentes con los inteligentes, bueno, en general, se entiende la idea... Esto es más o menos lo que sucede en los chats: los programadores menos fuertes son inmediatamente captados, las personas que no tienen ninguna habilidad valiosa para un hackathon permanecen en el chat durante mucho tiempo y eligen un equipo basándose en el principio de que si alguien lo aceptara . En algunos hackatones se practica la asignación aleatoria de equipos y los organizadores afirman que los equipos aleatorios no se desempeñan peor que los existentes. Pero según mis observaciones, las personas motivadas, por regla general, encuentran un equipo por su cuenta; si es necesario asignar a alguien, a menudo muchos de ellos no vienen al hackathon.
En cuanto a la composición del equipo, ésta es muy individual y depende en gran medida de la tarea. Podría decir que la composición mínima viable del equipo es un diseñador - front-end o front-end - back-end. Pero también conozco casos en los que ganaron equipos formados únicamente por front-end, que agregaron un back-end simple en node.js o crearon una aplicación móvil en React Native; o solo de patrocinadores 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 formar un equipo o unirme a un equipo como diseñador front-end - back-end (yo mismo soy front-end). Y rápidamente comencé a charlar con un backender de Python y un diseñador que aceptó la invitación para unirse a nosotros. Un poco más tarde, se unió a nosotros una chica, una analista de negocios, que ya tenía experiencia ganando un hackathon, y esto decidió la cuestión de si se unía a nosotros. Después de una breve reunión, decidimos llamarnos U4 (URBAN 4, cuatro urbanos) por analogía con los cuatro fantásticos. E incluso pusieron la imagen correspondiente en el avatar de nuestro canal de Telegram.
4. Seleccionar una tarea. Como ya dije, debes tener una ventaja competitiva, en base a esto se selecciona la tarea para el hackathon. En base a esto, habiendo mirado Y evaluando su complejidad, nos decidimos por dos tareas: un catálogo de empresas innovadoras de DPiIR y un chatbot de EFKO. La tarea de DPIiR fue elegida por el backender, la tarea de EFKO fue elegida por mí, porque Tenía experiencia escribiendo chatbots en node.js y DialogFlow. La tarea EFKO también involucró ML; tengo cierta experiencia, no muy extensa, en ML. Y según las condiciones del problema, me pareció que era poco probable que se resolviera con herramientas de ML. Este sentimiento se fortaleció cuando asistí a la reunión Urban Tech Challenge, donde los organizadores me mostraron un conjunto de datos sobre EFKO, donde había alrededor de 100 fotografías de diseños de productos (tomadas desde diferentes ángulos) y alrededor de 20 clases de errores de diseño. Y, al mismo tiempo, quienes ordenaron la tarea querían alcanzar una tasa de éxito en la clasificación del 90%. Como resultado, preparé una presentación de la solución sin ML, el backender preparó una presentación basada en el catálogo y juntos, después de finalizar las presentaciones, las enviamos al Urban Tech Challenge. Ya en esta etapa se reveló el nivel de motivación y aporte 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 la tarea de DPiIR y no nos molestó en absoluto no haber pasado el EFKO, ya que la tarea nos parecía extraña, por decirlo suavemente.
5. Preparándose para el hackathon. Cuando finalmente se supo que nos habíamos clasificado para el hackathon, comenzamos a preparar la preparación. Y aquí no estoy recomendando comenzar a escribir código una semana antes del inicio del hackathon. Como mínimo, debes tener listo un modelo estándar con el que puedas comenzar a trabajar inmediatamente, sin tener que configurar herramientas y sin encontrarte con errores de alguna biblioteca que decidiste probar por primera vez en un hackathon. Conozco una historia sobre ingenieros angulares que asistieron a un hackathon y pasaron 2 días configurando la construcción del proyecto, por lo que todo debe estar preparado con anticipación. Teníamos la intención de distribuir las responsabilidades de la siguiente manera: el backend escribe rastreadores que rastrean Internet y colocan toda la información recopilada en la base de datos, mientras que yo escribo una API en node.js que consulta esta base de datos y envía los datos al frente. En este sentido, preparé un servidor de antemano usando express.js y preparé una interfaz en reacción. No uso CRA, siempre personalizo el paquete web y sé muy bien los riesgos que esto puede suponer (recuerde la historia de los desarrolladores angulares). En este punto, solicité plantillas de interfaz o al menos maquetas a nuestro diseñador para tener una idea de lo que diseñaría. En teoría, él también debería hacer sus propios preparativos y coordinarlos con nosotros, pero nunca recibí respuesta. Como resultado, tomé prestado el diseño de uno de mis proyectos anteriores. Y empezó a funcionar aún más rápido, ya que todos los estilos para este proyecto ya estaban escritos. De ahí la conclusión: no siempre se necesita un diseñador en un equipo))). Llegamos al hackathon con estas novedades.
6. Trabaja en el hackathon. La primera vez que vi a mi equipo en vivo fue recién en la inauguración del hackathon en el Centro de Distribución Central. Nos reunimos, discutimos la solución y las etapas de trabajo en el problema. Y aunque después de la inauguración tuvimos que ir en autobús al Octubre Rojo, nos fuimos a dormir a casa, acordando llegar al lugar a las 9.00 horas. ¿Por qué? Al parecer, los organizadores querían sacar el máximo provecho de los participantes, por lo que organizaron ese calendario. Pero, según mi experiencia, puedes codificar normalmente sin dormir durante una noche. En cuanto al segundo, ya no estoy seguro. Un hackathon es un maratón, necesitas calcular y planificar adecuadamente tu fuerza. Además, teníamos preparativos.
Por eso, después de dormir, a las 9.00 estábamos sentados en el sexto piso de Dewocracy. Entonces, nuestro diseñador anunció inesperadamente que no tenía computadora portátil y que trabajaría desde casa y nos comunicaríamos por teléfono. Esta fue la última gota. Y así pasamos de un cuatro a un tres, aunque no cambiamos el nombre del equipo. Una vez más, esto no fue un gran golpe para nosotros, ya tenía el diseño del proyecto anterior. En general, al principio todo salió bastante bien y según lo previsto. Cargamos en la base de datos (decidimos usar neo4j) un conjunto de datos de empresas innovadoras de los organizadores. Comencé a componer, luego tomé Node.js y luego las cosas empezaron a fallar. Nunca antes había trabajado con neo4j, y al principio estaba buscando un controlador que funcionara para esta base de datos, luego descubrí cómo escribir una consulta y luego me sorprendió descubrir que esta base de datos, cuando se consulta, devuelve entidades en el forma de una matriz de objetos de nodo y sus bordes. Aquellos. cuando solicité una organización y todos los datos que contiene por TIN, en lugar de un objeto de la organización, me devolvieron una gran variedad de objetos que contienen datos sobre esta organización y las relaciones entre ellos. Escribí un mapeador que revisó toda la matriz y pegué todos los objetos según su organización en un solo objeto. Pero en la batalla, al solicitar una base de datos de 8 mil organizaciones, se ejecutó extremadamente lentamente, entre 20 y 30 segundos. Empecé a pensar en la optimización... Y luego nos detuvimos a tiempo y cambiamos a MongoDB, y nos llevó unos 30 minutos. En total, se perdieron unas 4 horas en neo5j.
Recuerda, nunca lleves tecnología a un hackathon con la que no estés familiarizado, puede haber sorpresas. Pero, en general, aparte de este fracaso, todo salió según lo previsto. Y ya en la mañana del 9 de diciembre teníamos una aplicación en pleno funcionamiento. Durante el resto del día planeamos agregarle funciones adicionales. En el futuro, todo salió relativamente bien para mí, pero el backender tuvo muchos problemas con la prohibición de sus rastreadores en los motores de búsqueda, en el spam de agregadores de personas jurídicas que ocupaban los primeros lugares en los resultados de búsqueda al solicitar para cada empresa específica. Pero es mejor que él mismo lo cuente. La primera característica adicional que agregué fue la búsqueda por nombre completo. Director General de VKontakte. Pasaron varias horas.
Entonces, en la página de la empresa en nuestra aplicación apareció un avatar del director general, un enlace a su página de VKontakte y algunos otros datos. Fue una bonita guinda del pastel, aunque puede que no nos haya dado la victoria. Luego, quise realizar algunos análisis. Pero después de una larga búsqueda de opciones (había muchos matices con la interfaz de usuario), me decidí por la agregación más simple de organizaciones por código de actividad económica. Ya por la noche, en las últimas horas, estaba diseñando una plantilla para mostrar productos innovadores (en nuestra aplicación se supone que hay una sección de Productos y Servicios), aunque el backend no estaba preparado para ello. Al mismo tiempo, la base de datos crecía a pasos agigantados, los rastreadores continuaron funcionando, el backend experimentó con PNL para distinguir textos innovadores de los no innovadores))). Pero ya se acercaba el momento de la presentación final.
7. Presentación. Por mi propia experiencia, puedo decir que debes empezar a preparar una presentación unas 3 o 4 horas antes de la fecha prevista. Especialmente si se trata de vídeo, su filmación y edición lleva bastante tiempo. Se suponía que íbamos a tener un vídeo. Y teníamos una persona especial que se ocupaba de esto y también resolvía otros problemas organizativos. En este sentido, no nos distrajimos de la codificación hasta el último momento.
8. Lanzamiento. No me gustó que las presentaciones y las finales se realizaran en un día laborable aparte (lunes). Aquí, probablemente, continuó la política de los organizadores de exprimir al máximo a los participantes. No tenía intención de ausentarme del trabajo, sólo quería venir a la final, aunque el resto de mi equipo se tomó el día libre. Sin embargo, la inmersión emocional en el hackathon ya era tan alta que a las 8 am escribí en el chat de mi equipo (el equipo de trabajo, no el equipo del hackathon) que me tomaba el día por mi cuenta, y me dirigí a la central. Oficina para parcelas. Resultó que en nuestro problema había muchos científicos de datos 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 funcional, muchos no podían eludir las prohibiciones de sus rastreadores en los motores de búsqueda. Éramos el único equipo con un prototipo funcional. Y supimos cómo solucionar el problema. Al final ganamos la pista, aunque tuvimos mucha suerte de elegir la prueba menos competitiva. Al mirar los campos de otras pistas, nos dimos cuenta de que allí no tendríamos ninguna posibilidad. También quiero decir que tuvimos mucha suerte con el jurado: revisaron meticulosamente el código. Y, a juzgar por las críticas, esto no sucedió en todas las pistas.
9. Final. Después de que nos llamaron varias veces al jurado para revisar el código, nosotros, pensando que finalmente habíamos resuelto todos los problemas, fuimos a almorzar a Burger King. Allí nos volvieron a llamar los organizadores, tuvimos que hacer las maletas rápidamente y regresar.
El organizador nos mostró en qué sala teníamos que entrar y, al entrar, nos encontramos en una sesión de entrenamiento de oratoria para los equipos ganadores. Los chicos que debían actuar 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, palidecimos; la victoria en la nominación de clientes gubernamentales fue merecidamente para el equipo de la pista de tecnología inmobiliaria. Creo que los factores clave que contribuyeron a nuestra victoria en la pista fueron: la disponibilidad de un espacio en blanco listo para usar, gracias al cual pudimos hacer rápidamente un prototipo, la presencia de "aspectos destacados" en el prototipo (búsqueda de CEO en las redes sociales) y las habilidades de PNL de nuestro backender, que también interesó mucho al jurado.
Y para concluir, el tradicional agradecimiento a todos los que nos apoyaron, al jurado de nuestra pista, a Evgeniy Evgrafiev (el autor del problema que resolvimos en el hackathon) y, por supuesto, a los organizadores del hackathon. Este fue quizás el hackathon más grande y genial en el que he participado, ¡solo puedo desearles a los muchachos que mantengan un estándar tan alto en el futuro!
Fuente: habr.com