🥇Codificando–pizza

Hola, Habr. Hemos realizado un primer hackatón interno espontáneamente. Decidí compartir con ustedes mis frustraciones y aprendizajes sobre la preparación para ello durante 2 semanas, así como los proyectos que surgieron.

Parte aburrida para aquellos interesados en marketing

Comenzaré con una pequeña historia.

A principios de abril. En nuestra oficina se lleva a cabo el primer hackatón de MskDotNet Community. La batalla por Tatooine está en pleno apogeo, en nuestra galaxia esta vez. Sábado. 20 equipos. Pizza. Todo muy acogedor (pruebas). Un R2-D2 inflable merodea por el salón. Los equipos escriben los algoritmos más correctos para completar la carrera más peligrosa del mapa. Retrasamos el inicio de las primeras carreras. Las galletas y el café salvan el día. Los organizadores y yo esperábamos que muchos se fueran el sábado después del almuerzo. Pero no. 12 horas de codificación han pasado. Final. Algo se descompone, algo no arranca. Pero todos están felices. Nuestro equipo gana. Estamos felices el doble.

Comparto la alegría en Slack y se me ocurre la idea: "Necesitamos hacer nuestro propio hackatón". Le escribo a nuestro CTO, Sasha. Silencio.

Mañana. Tomo café en la oficina. Veo a Sasha acercándose por detrás. "Liza, ¡esto es genial! Justo tenemos una fecha importante el 21 de abril. ¡Hagámoslo!" ¿Qué? ¿Tan rápido? ¿Eh? Tengo que volar a Syktyvkar para una pasantía a mediados de abril. ¡Y que demonios! Hagámoslo.

Quedan 2 semanas. Nunca he sido la organizadora única de un hackatón. Aunque sea interno. Leo artículos sobre el tema. Es complicado. Se necesita varios meses. Se necesita varias personas. Hay que pensar en el merchandising, los premios, las condiciones, la programación, interesar, entender la meta, los presupuestos. Tal vez hasta entender el sentido de la vida. No llegaré a tiempo. Y mientras leías y te preparabas, ya ha pasado una semana. Es el momento perfecto para ignorar los artículos y empezar a hacer algo.

Aquí tienen nuestra lista de verificación para organizar un hackatón interno en 1 semana

Plan: simplemente te sientas y escribes una lista de lo que necesitas hacer para el hackatón. 30 minutos.
Tarea: los participantes proponen y eligen por sí mismos los proyectos que quieren crear en Google Sheets. Tarea de fondo, 2 horas.
Horarios: de manera improvisada escribes una breve distribución del tiempo considerando 3 pausas y la final. 20 minutos.
Comandos: publicas un mensaje sobre el hackatón con el horario de parte del CTO en los canales de IT en Slack/correo/etc. y creas un canal separado para el hackatón. En él, todos se dividen en equipos, y los indecisos lo hacen en los primeros 5 minutos del hackatón. Tarea de fondo, 2 horas.
Beneficios.: estás ideando merchandising con dos desarrolladores, se lo entregas a un diseñador para su diseño, y recibes el resultado. Tarea de fondo, 3 días.
Hackatón: llegas a la oficina, coordinas a todos al principio, te ocupas de tus asuntos, lees Reddit, con un aire serio informas cada pausa sobre la nueva pizza, fotografías el atardecer, anuncias la final, votáis juntos y elijes al ganador. 1 día.
Bajo la estrella: por supuesto, piensas constantemente en que todo salga bien. Claro, no todos verán tu mensaje y es mejor hablar personalmente con algunos. Por supuesto, si alguien te ayuda, todo será dos veces más fácil (me ayudó la maravillosa Alena).

La parte menos aburrida sobre la fecha del hackatón

¿Por qué el 21 de abril? Este día es significativo para nosotros. Hace exactamente un año, el 21 de abril, colapsamos bajo carga durante el primer fin de semana tras el inicio de la Campaña Federal de Publicidad. Al día siguiente, el domingo, nuestro equipo estaba trabajando desde las 8 de la mañana. Entonces creamos en Trello el tablero sundayhackathon y comenzó una semana de trabajo por turnos de 12 horas al día. La situación era tan crítica que no teníamos tiempo ni para comer y nos alimentaban chicos de otros equipos.

Puedes leer un relato más detallado en la página de Fyodor Ovchinnikov (nuestro CEO). Desde entonces, hemos cambiado mucho, pero nunca olvidaremos esta fecha.

Este año decidimos que este evento merece ser recordado por las generaciones futuras y, en la mejor tradición, organizamos el primer hackatón interno de Dodo en la historia, que duró 10 horas.

La parte menos aburrida sobre los proyectos del hackatón

Descargo de responsabilidad: todas las descripciones fueron escritas por los chicos, así que la autoría del texto no es mía.

Oleg Learning (aprendizaje automático)

Dima Kochnev, Sasha Andronov (@alexandronov)

Querían hacer una red neuronal que identificara qué pizza había en la fotografía sin ningún conocimiento previo. Al final hicieron una muy simple y juguetona: reconoce 10 pizzas, aproximadamente entendimos cómo funciona todo, en lo posible durante un día (~10 horas).

En particular, entendimos que la industria ha avanzado hasta el punto en que un desarrollador común puede usar bibliotecas listas, leer la documentación y entrenar su red neuronal sin conocimientos profundos del tema. Y funcionará lo suficientemente bien para resolver problemas reales.

Herramientas que utilizaron:

imageai Una biblioteca conveniente y fácil de usar para trabajar con aprendizaje automático y visión por computadora.
Probamos dos modelos: ResNet50 y Yolo.
El código se escribió, por supuesto, en Python.

Teníamos 11000 fotos, pero casi 3/4 resultaron ser basura, y en las restantes había diferentes ángulos inapropiados. Al final, tomamos un modelo preentrenado (que simplemente sabe encontrar pizza) y con su ayuda separamos los peores. Además, en el nombre de la foto había el nombre de la pizza; así organizamos por carpetas, pero resultó que los nombres no coincidían con la realidad y tuvimos que limpiar manualmente. Al final, quedaron alrededor de 500-600 fotos, que, aunque son pocas, resultaron ser suficientes para distinguir 10 pizzas entre sí.

Para entrenar la red, usamos la máquina virtual más barata en Azure con NVIDIA Tesla K80. La entrenamos durante 100 épocas, pero se notó que la red se saturó después de 50 épocas, debido a que el conjunto de datos era pequeño.

En realidad, todo el problema está en la falta de buenos datos.

Quizás nos equivocamos un poco en los términos, pero hay que tener en cuenta que no tenemos experiencia en trabajar con estos asuntos.

GUI para NOOBS (consola para ordenar pizza)

Misha Kumachev (Ceridan), Zhenya Bikinin, Zhenya Vasiliev

Creamos un prototipo de aplicación de consola para frikis, que permite pedir pizza a través de la terminal o línea de comandos, o incluso integrarlo en el pipeline de despliegue y entregar pizza a la oficina tras un lanzamiento exitoso.

El trabajo se dividió en varias partes: entendimos cómo funciona nuestra API para aplicaciones móviles, construimos nuestro propio CLI con la ayuda de oclif y configuramos la publicación del paquete que creamos. La última tarea presentó algunos momentos incómodos hacia el final del hackathon. Todo funcionaba localmente y incluso funcionaban las versiones antiguas publicadas del paquete, pero las nuevas (que habían agregado más funciones geniales y emojis) se negaban a funcionar. Pasamos unos 40 minutos tratando de entender qué salió mal, pero al final, todo funcionó mágicamente por sí mismo).

Nuestro objetivo máximo del hackathon era hacer un pedido real de pizza en la oficina a través de nuestra CLI. Hicimos pruebas decenas de veces en el entorno de prueba, pero aún así me temblaban las manos cuando introducía comandos en producción.

Como resultado, ¡lo logramos!

CourierGo

Anton Bruzhmelov (autor), Vanya Zverev, Gleb Lesnikov (entropy), Andrei Sarafanov

Tomamos la idea de "Aplicación para mensajeros".

Historia de la preparación.Inicialmente pensé, ¿cuáles podrían ser las características de la aplicación? Surgió aproximadamente esta lista de funcionalidades:

La aplicación se autentica en la terminal de entrega con un código.
En la aplicación se ven de inmediato los pedidos disponibles, los pedidos que deben ser recogidos.
El mensajero marca el pedido y lo toma en el viaje.
Se le muestra el tiempo estimado y si llegará a tiempo o no.
Al cliente se le muestra que el mensajero ha salido.
Al cliente comienza a mostrarse la ubicación del mensajero en el mapa y el tiempo estimado.
El mensajero puede escribir al cliente en el chat desde la aplicación.
El cliente puede escribir al mensajero en el chat desde la aplicación.
Cinco minutos antes de la llegada, el cliente recibe un mensaje de que el mensajero está cerca, estén listos.
El mensajero marca en la aplicación que ha llegado y está esperando.
El mensajero llama desde la aplicación con un clic y dice que (está subiendo, llegó, etc.)
El cliente acepta el pedido e introduce el pin del aplicativo o del SMS para confirmar la entrega. (como firma) Para que el mensajero no pueda completar la entrega antes de tiempo si se retrasa.
El pedido se marca en el sistema como entregado.

Además de un par de escenarios alternativos:

El mensajero puede marcar el pedido como no entregado y elegir la razón.
Si se retrasa, el mensajero puede otorgar un certificado electrónico con un solo clic mediante SMS. O el certificado llega automáticamente si no se cumple el plazo de entrega.

La sensación de potencial y necesidad de este proyecto, por supuesto, me entusiasmó.

Al día siguiente, fuimos a almorzar con el equipo y discutimos cómo se vería la funcionalidad mínima de la aplicación.

Al final, se formó la siguiente lista de lo que debíamos lograr en el hackathon:

Inicio de sesión en la terminal de entrega.
Mostrar la ubicación actual.
Enviar datos a una API externa (coordenadas, tomó el pedido, entregó el pedido).
Obtener datos de una API externa (pedidos actuales del mensajero).
Enviar un evento de que tomó el pedido de entrega/que lo entregó.
Mostrar la ubicación actual del mensajero en el mapa en el sitio web.

El trabajo principal, como se veía, estaba en crear el backend de la aplicación (después de las discusiones, eligieron ReactNative para el desarrollo de la aplicación, más bien la envoltura sobre él — expo.io, lo que permite no escribir código nativo en absoluto). En el plan del backend, inicialmente había esperanzas en Vanya Zverev, por su experiencia con nuestra plantilla de servicio y k8s (el trabajo que asumió). Yo y Andrey Sarafanov tomamos ReactNative para experimentarlo.

Decidí intentar crear un repositorio de trabajo para el proyecto de inmediato. A medianoche me di cuenta de que la geolocalización en ReactNative funcionaba mal en segundo plano si no se escribía código nativo, lo que me frustró un poco. Luego me relajé cuando comprendí que estaba leyendo la documentación del marco de expo.io y no de ReactNative. Al final de la noche ya tenía claro cómo obtener la ubicación actual en expo.io y diseñar pantallas separadas (para el inicio de sesión, visualización de pedidos, etc.).

Por la mañana, en el hackathon, convencimos a Gleb para unirse a nuestro proyecto de gran potencial. Rápidamente esbozamos un plan de lo que necesitaba hacerse.

Cometimos un error al intentar hacer la comunicación no a través de HTTP, sino a través de GRPC, ya que nadie sabía cómo construir un cliente GRPC para JavaScript. Al final, después de gastar aproximadamente una hora y media en esto, abandonamos la idea. Debido a esto, el equipo en el backend empezó a reestructurar el servidor existente de GRPC a WebApi. Después de media hora, finalmente pudimos configurar la comunicación de la aplicación con el backend, ¡qué maravilla! Pero al mismo tiempo, Gleb estaba casi finalizando el despliegue en k8s y además el autodespliegue con el commit en master. 🙂

Seleccionamos MySQL como almacenamiento para no arriesgarnos con la base (se pensó en CosmosDb).

En resumen:

Implementamos el almacenamiento de las coordenadas actuales del mensajero desde la aplicación en la base de datos.
Conectamos RabbitMQ y nos suscribimos a los mensajes sobre la toma de pedidos por parte del mensajero, para mostrar inmediatamente el pedido en la aplicación del mensajero.
Empezamos a guardar en la base de datos el tiempo de entrega del pedido, después de que el mensajero presionaba el botón en la aplicación. No tuvimos tiempo de añadir el envío del evento de vuelta a Rabbit indicando que el pedido había sido entregado.
Hice que se mostrara el mapa en la página currentorder del sitio con la ubicación actual del mensajero. Pero esta funcionalidad quedó un poco incompleta, ya que en el entorno no pudimos configurar CORS para obtener coordenadas de nuestro nuevo servicio.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Queríamos implementar un proveedor de OpenID Connect, ya que actualmente utilizamos un protocolo de autenticación desarrollado internamente, lo que genera una serie de dificultades: bibliotecas de clientes personalizadas, inconvenientes para los socios externos y posibles problemas de seguridad (al final, OAuth2.0 y OpenID Connect en su implementación estándar se pueden considerar seguros, pero en cuanto a nuestra solución, no estoy seguro).

Creamos un servicio separado que emula un servicio de almacenamiento de datos personales, para crear un pequeño modelo de proveedor de autenticación Country-Agnostic, que buscara datos personales en un servicio separado (esto a largo plazo permitiría tener un solo servicio, a través del cual se podría iniciar sesión con una cuenta de cualquier país, cumpliendo al mismo tiempo con el GDPR y otras leyes locales). Esta parte la hicimos, así como el proveedor, y logramos vincularlos exitosamente. Luego necesitábamos desarrollar una API que estuviera protegida por los tokens que emite el proveedor, mantener su introspección a través del proveedor y devolver datos protegidos, si la solicitud cumple con las políticas de autorización (verificamos que el usuario esté autenticado según el esquema Bearer, que su token contenga un determinado scope y que el propio usuario tenga permiso para realizar la llamada). Esta parte también fue ejecutada. El último componente era un cliente JavaScript al que se le otorgaría un token, con el cual llamaría a la API protegida. Esta parte no logramos hacer. Es decir, toda la parte funcional estaba lista, pero no se había preparado la parte frontal para demostrar la operatividad de todo el sistema.

E-E-E (juego)

Dima Afonchenko, Sasha Konovalov

Creamos un mini-juego en Unity donde manos ágiles colocan salchichas sobre una pizza. Si colocas mal la salchicha, aparece el mensaje triste "Rechazado" en la pantalla, y si toda la salchicha está colocada correctamente, aparece un dato aleatorio sobre la pizza.

Queríamos hacer un segundo nivel con tomates, pero no tuvimos tiempo.

Continuación breve: ¿quién ganó?

Antes del hackatón, hablamos con los chicos y les pregunté qué premio les gustaría recibir si ganaban. Resultó que el premio más valioso sería "el camino a producción".

Por lo tanto, en breve esperen un anuncio de nuestro juego con controladores que lanzan pepperonis sobre la pizza.