pizza kodim

Hola Habr. Realizamos espontáneamente el primer hackathon interno. Decidí compartir con ustedes mis dolores y conclusiones sobre cómo prepararme en 2 semanas, así como los proyectos que resultaron.

La parte aburrida para los interesados ​​en marketing.

Empezaré con una pequeña historia.

Principios de abril. Nuestra oficina organiza el primer hackathon de la comunidad MskDotNet. La batalla por Tatooine está en pleno apogeo, esta vez en nuestra galaxia. Sábado. 20 equipos. Pizza. es todo muy conmovedorpruebas). Un R2-D2 inflable se cierne sobre la habitación. Los equipos escriben los algoritmos más correctos para pasar la carrera más peligrosa del mapa. Adelantamos el lanzamiento de las primeras carreras. Ahorre galletas y café. Los organizadores y yo esperábamos que el sábado mucha gente se marchara después del almuerzo. Pero no. 12 horas de codificación detrás. El final. Algo se cae, algo no empieza. Pero todos están felices. Nuestro equipo gana. Estamos doblemente felices.

Comparto mi alegría en Slack y me viene a la mente la idea: "Necesitamos hacer nuestro propio hackathon". Le escribo a nuestra estación de servicio Sasha. Silencio.

Mañana. Tomo café en la oficina. Veo a Sasha acercándose por detrás. "Lisa, ¡esto es genial! El 21 de abril es una fecha importante para nosotros. ¡Vamos a hacerlo! ¿¡Qué carajo!? ¿Tan rapido? ¿A? ¿Qué? Necesito volar a Syktyvkar para realizar prácticas a mediados de abril. ¡Sí, al diablo con él! Vamos.

Quedan 2 semanas. Nunca he sido el único organizador de un hackathon. Dejar e interno. Leo artículos sobre este tema. Estaño. Se necesitan varios meses. Se necesitan varias personas. Es necesario pensar en el merchandising, los premios, las condiciones, el cronograma, interesarse, entender el objetivo, los presupuestos. Y tal vez incluso comprenda el significado de la vida. Definitivamente no lo lograré. Y mientras leías y te preparabas, ya había pasado una semana. Es hora de anotarse en los artículos y empezar a hacer algo.

Consulte nuestra lista de verificación de hackathon interno de 1 semana

• plan: siéntate tranquilamente y escribe una lista de lo que hay que hacer para el hackathon. Minutos 30.
• Tarea: Los propios participantes proponen y seleccionan los proyectos que quieren crear en Google Sheets. Tarea en segundo plano, 2 horas.
• Horario: en tu rodilla escribes un breve desglose del tiempo, teniendo en cuenta 3 descansos y el final. Minutos 20.
• Equipos: publicar un mensaje sobre un hackathon con un horario de la estación de servicio en los canales de TI en Slack/mail/etc y crear un canal separado para el hackathon. En él, todos se dividen en equipos, y los indecisos lo hacen en los primeros 5 minutos del hackathon. Tarea en segundo plano, 2 horas.
• bollos: creas un producto con dos desarrolladores, se lo entregas al diseñador para que lo renderice y lo preparas. Tarea en segundo plano, 3 días..
• Hackatón: vienes a la oficina, coordinas a todos al principio, te ocupas de tus asuntos, lees Reddit, lo más importante es que informas de cada descanso sobre pizza fresca, fotografías la puesta de sol, anuncias la final, votas juntos y eliges al ganador. día 1.
• Bajo el asterisco: Por supuesto, piensas constantemente en que todo vaya bien. Por supuesto, no todos verán tu mensaje y es mejor hablar con algunos en persona. Por supuesto, si alguien te ayuda, todo será 2 veces más fácil (me ayudó la maravillosa Alena).

La parte menos aburrida de la fecha del hackathon

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

Puedes leer una historia más detallada en La página de Fyodor Ovchinnikov (nuestro director general). Desde entonces hemos cambiado mucho, pero ahora definitivamente no olvidaremos la fecha.

Este año decidimos que este evento debería quedar inmortalizado en la memoria de la posteridad y, siguiendo las mejores tradiciones, organizamos el primer hackathon interno en la historia de Dodo, que duró 10 horas.

La parte más aburrida de los proyectos de hackathon

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

Oleg Lerning (aprendizaje automático)

Dima Kochnev, Sasha Andronov (@alexandronov)

Queríamos crear una red neuronal que determinara qué tipo de pizza aparece en la foto sin ningún conocimiento. Como resultado, hicieron uno muy simple y de juguete: reconoce 10 pizzas, descubrió aproximadamente cómo funciona todo, en la medida de lo posible en un día (~ 10 horas).

En particular, nos dimos cuenta de que la industria ha alcanzado un nivel en el que un desarrollador común y corriente puede tomar bibliotecas ya preparadas, leer la documentación y entrenar su propia red neuronal sin un conocimiento profundo del tema. Y funcionará lo suficientemente bien como para resolver problemas reales.

Herramientas utilizadas:

• imagenai es una biblioteca cómoda y sencilla para trabajar con aprendizaje automático y visión por computadora.
• Los modelos probaron dos: ResNet50, Yolo.
• El código fue escrito, por supuesto, en Python.

Teníamos 11000 fotografías, pero entre ellas, casi 3/4 resultaron ser basura y el resto, ángulos diferentes e inapropiados. Como resultado, tomamos un modelo ya hecho (que simplemente sabe cómo encontrar pizza) y con su ayuda separamos la basura. Además, el nombre de la foto era el nombre de la pizza, así que la clasificamos en carpetas, pero resultó que los nombres no coincidían con la realidad y aquí tuvimos que limpiarla con las manos. Como resultado, quedaron entre 500 y 600 fotografías, está claro que es una cantidad insignificante, pero aún así resultó ser suficiente para separar 10 pizzas entre sí.

Para entrenar la red, tomamos la máquina virtual más barata en Azure en NVIDIA Tesla K80. Fue entrenado en 100 épocas, pero estaba claro que la red estaba sobresaturada después de 50 épocas, debido al hecho de que había un pequeño conjunto de datos.

En realidad, todo el problema es la falta de buenos datos.

Quizás nos hayamos confundido un poco en los términos, pero debemos tener en cuenta que generalmente no tenemos experiencia en trabajar con todos estos casos.

GUI para NOOBS (consola de pedidos de pizza)

Misha Kumachev (Ceridán), Zhenya Bikkinin, Zhenya Vasiliev

Hemos creado un prototipo de aplicación de consola para geeks, gracias al cual puede pedir pizza a través de la terminal o la línea de comando, o incluso incrustarla en el proceso de implementación y, tras un lanzamiento exitoso, entregar pizza en la oficina.

El trabajo se dividió en varias partes: descubrimos cómo funciona nuestra API para aplicaciones móviles, construimos nuestra propia CLI usando ocif y configurar la publicación del paquete que reunimos. La última tarea tuvo varios minutos desagradables hacia el final del hackathon. Todo funcionó localmente para nosotros e incluso las versiones antiguas publicadas del paquete funcionaron, pero las nuevas (que agregaron características y emoticones más interesantes) se negaron a funcionar. Pasamos unos 40 minutos para descubrir qué salió mal, pero al final todo funcionó mágicamente por sí solo).

Nuestro programa para el hackathon máximo fue un pedido de pizza real a la oficina a través de nuestra CLI. Ejecutamos todo en el banco de pruebas una docena de veces, pero todavía me temblaban las manos cuando escribí comandos en la picana.

Como resultado, ¡todavía lo logramos!

MensajeroGo

Anton Bruzhmelev (autor), Vanya Zverev, Gleb Lesnikov (entropía), Andrey Sarafanov

Tomaron la idea de "Solicitud de mensajería".

Antecedentes sobre la preparación.Inicialmente, descubrí qué funciones puede haber en la aplicación. Apareció una lista de características como esta:

• La aplicación inicia sesión en la caja de entrega utilizando el código.
• La aplicación muestra inmediatamente los pedidos disponibles, los pedidos que deben realizarse.
• El mensajero anota el pedido y se lo lleva de viaje.
• Se le muestra el tiempo estimado y si tiene tiempo o no.
• El cliente demuestra que el mensajero se ha ido.
• El cliente comienza a mostrar el punto de mensajería en el mapa y el tiempo estimado.
• El mensajero puede escribir al cliente en un chat desde la aplicación.
• El cliente podrá escribir al mensajero en el chat de la aplicación.
• Cinco minutos antes de la llegada, el cliente recibe un mensaje de que el mensajero está cerca, prepárate.
• El mensajero anota en la solicitud que ha llegado y está esperando.
• El mensajero llama desde la aplicación con un clic e informa que (levantándose, acercándose, etc.)
• El cliente acepta el pedido e introduce el código pin de la aplicación o SMS para confirmar la entrega (a modo de firma) para que el mensajero no pueda completar la entrega con antelación si llega tarde.
• El pedido queda marcado como entregado en el sistema.

Además de un par de escenarios alternativos:

• El mensajero puede marcar el pedido como no entregado y seleccionar un motivo.
• El mensajero, si llega tarde, puede emitir un certificado electrónico mediante SMS con un solo botón. O el certificado llega automáticamente si no se cumple el plazo de entrega.

Naturalmente, el sentimiento de las perspectivas y la necesidad de este proyecto fue estimulante.

Al día siguiente, fui a almorzar con el equipo y discutí cómo sería la funcionalidad mínima de la aplicación.

Como resultado, se formó la siguiente lista de lo que se debía hacer en el hackathon:

• Inicie sesión en la caja de entrega.
• Mostrar la posición actual.
• Enviar datos a api externa (coordenadas, tomar el pedido, entregar el pedido).
• Obtenga datos de una API externa (pedidos de mensajería actuales).
• Envíe un evento sobre el hecho de que recibió el pedido para su entrega / entrega.
• Muestra la posición actual del mensajero en el mapa del sitio.

Al parecer, el trabajo principal era crear el backend, la aplicación en sí (después de las discusiones, elegimos ReactNative para desarrollar la aplicación, o mejor dicho, el enlace que está encima de ella). expo.io, lo que le permite no escribir código nativo en absoluto). En cuanto al backend, inicialmente había esperanzas para Vanya Zverev, ya que tenía experiencia trabajando con nuestra plantilla de servicio y k8s (trabajo que asumió). Andrey Sarafanov y yo conmovimos a ReactNative.

Decidí intentar crear inmediatamente un repositorio funcional para el proyecto en sí. A las 12 de la noche me encontré con el hecho de que la geolocalización en segundo plano no funciona bien en ReactNative, si no escribes código nativo, me sentí un poco frustrado. Luego lo solté cuando me di cuenta de que estaba leyendo la documentación no del framework expo.io, sino de ReactNative. Como resultado, por la noche ya tenía claro cómo obtener la posición actual en expo.io y dibujar pantallas separadas (para iniciar sesión, mostrar pedidos, etc.).

Por la mañana, en el hackathon, atrajeron a Gleb a su proyecto súper prometedor. Rápidamente se les ocurrió un plan de qué hacer.

Cometieron un error cuando, de acuerdo con la plantilla del proyecto, intentaron comunicarse 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. Como resultado, después de dedicar aproximadamente una hora y media a esto, abandonaron esta idea. Debido a esto, los chicos de atrás comenzaron a rehacer el servidor terminado de GRPC a WebApi. Después de media hora, finalmente pudimos configurar la comunicación entre la aplicación y el backend, he aquí. Pero al mismo tiempo, Gleb casi terminó la implementación en k8 y además la implementación automática al comprometerse con el maestro. 🙂

Como almacenamiento, elegimos MySQL para no arriesgarnos al menos con la base de datos (se pensó en CosmosDb).

En resumen:

• Implementado guardar las coordenadas actuales del mensajero desde la aplicación a la base de datos.
• Jodimos a RabbitMQ y nos suscribimos a mensajes sobre el pedido que estaba tomando el mensajero para mostrar inmediatamente el pedido del mensajero en la aplicación.
• Comenzamos a guardar el tiempo de entrega del pedido en la base de datos después de que el mensajero presionó el botón en la aplicación. No tuvimos tiempo de agregar el envío de un evento al rebbit de que se entregó el pedido.
• Hice una visualización de mapa en la página de pedido actual en el sitio con la posición actual del mensajero. Pero esta funcionalidad quedó un poco inacabada, ya que no fue posible configurar CORS en el entorno para recibir coordenadas de nuestro nuevo servicio.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artem Trofimushkin

Queríamos implementar un proveedor OpenID Connect, ya que actualmente utilizamos nuestro propio protocolo de autenticación, y esto crea una serie de dificultades: bibliotecas cliente personalizadas, trabajo inconveniente de socios externos, posiblemente problemas de seguridad (después de todo, OAuth2.0 y OpenID Conectarse en la implementación de referencia puede considerarse seguro, pero no estoy seguro de nuestra solución).

Creamos un servicio separado que emula un servicio de almacenamiento de datos personales para crear un modelo pequeño de un proveedor de autenticación independiente del país que buscaría datos personales en un servicio separado (esto haría posible en el futuro tener un servicio con que se puede iniciar sesión con una cuenta registrada en cualquier país y al mismo tiempo cumplir con el RGPD y otras leyes federales). Hicimos esta parte, al igual que el proveedor, y los vinculamos entre sí con éxito. A continuación, era necesario crear una API que estuviera protegida por los tokens que emite el proveedor, respaldara su introspección a través del proveedor y devolviera datos seguros si la solicitud cumpliera con las políticas de autorización (verificamos que el usuario esté autenticado de acuerdo con las Esquema portador, su token contiene un alcance determinado + el propio usuario tiene un permiso que permite realizar la llamada). Esta parte también se ha completado. El último componente era un cliente JavaScript al que se le daría un token para llamar a una API segura. No pudimos hacer esta parte. Es decir, toda la parte funcional estaba lista, pero la parte front-end no estaba lista para demostrar el rendimiento de todo el sistema.

EEE (juguete)

Dima Afonchenko, Sasha Konovalov

Hicimos un minijuguete sobre un yunque en el que unas manos juguetonas pusieron una salchicha sobre una pizza. Si coloca la salchicha incorrectamente, aparece en la pantalla la triste inscripción "Rechazado", y si toda la salchicha se coloca correctamente, aparece un dato aleatorio sobre la pizza.

Querían pasar al segundo nivel lanzando tomates, pero no tuvieron tiempo.

Secuela corta: ¿quién ganó?

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

Por lo tanto, esperemos que pronto anunciemos un juego con bolígrafos que arrojan pepperoni a la pizza.

Como pudo comprobar un lector atento, ganó el equipo "E-E-E (juguete)". ¡Felicidades chicos!

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Qué proyecto te gustó más?

• Oleg Lerning (aprendizaje automático)

• GUI para NOOBS

• MensajeroGo

• M87

• Uh-uh

5 usuarios votaron. 3 usuarios se abstuvieron.

Fuente: habr.com