Kodim-pizza

Ola Habr. Celebramos espontaneamente o primeiro hackathon interno. Decidín compartir con vós as miñas dores e conclusións sobre a preparación para iso en 2 semanas, así como os proxectos que resultaron.

A parte aburrida para os interesados ​​no marketing

Vou comezar cunha pequena historia.

Comezos de abril. A nosa oficina acolle o primeiro hackathon da comunidade MskDotNet. A batalla por Tatooine está en pleno apoxeo, esta vez na nosa galaxia. sábado. 20 equipos. Pizza. É todo moi conmovedorprobas). Un inchable R2-D2 asoma pola sala. Os equipos escriben os algoritmos máis correctos para superar a carreira máis perigosa do mapa. Apostamos o lanzamento das primeiras carreiras. Aforra galletas e café. Os organizadores e mais eu esperabamos que moita xente marchara despois do xantar do sábado. Pero non. 12 horas de codificación atrás. A final. Algo cae, algo non comeza. Pero todos están contentos. O noso equipo gaña. Estamos dobremente felices.

Comparto a miña alegría en Slack e vénme á cabeza a idea: "Necesitamos facer o noso propio hackathon". Escribo á nosa estación de servizo Sasha. Silencio.

Mañá. Tomo café na oficina. Vexo que Sasha se achega por detrás. "Lisa, isto é xenial! O 21 de abril é unha data importante para nós. Fagámolo! WTF!? Moi rápido? A? Que? Necesito voar a Syktyvkar para facer prácticas a mediados de abril. Si, ao carallo con el! Imos.

Quedan 2 semanas. Nunca fun o único organizador dun hackathon. Deixa e interna. Lin artigos sobre este tema. Estaño. Leva varios meses. Precísanse varias persoas. Debes pensar na mercadoría, premios, condicións, programar, interesarte, comprender o obxectivo, os orzamentos. E quizais ata comprender o sentido da vida. Definitivamente non o conseguirei. E mentres estabas lendo e preparando xa pasou unha semana. É hora de puntuar nos artigos e comezar a facer algo.

Consulta a nosa lista de verificación de hackaton interno dunha semana

• Planificar: senta tranquilamente e escribe unha lista do que hai que facer para o hackathon. Minutos 30.
• Tarefa: Os propios participantes propoñen e seleccionan os proxectos que queren crear en Google Sheets. Tarefa de fondo, 2 horas.
• Horario: de xeonllos escribes un pequeno desglose do tempo, tendo en conta 3 descansos e o final. Minutos 20.
• Comandos: publica unha mensaxe sobre un hackathon cunha programación da estación de servizo en canles de TI en Slack/mail/etc e crea unha canle separada para o hackathon. Nela, todos están divididos en equipos, e os indecisos fano nos primeiros 5 minutos do hackathon. Tarefa de fondo, 2 horas.
• Bollos: creas mercadoría con dous desenvolvedores, dásllo ao deseñador para que o renderice e prepárao. Tarefa en segundo plano, 3 días.
• Hackathon: chegas á oficina, coordinas a todos ao principio, realizas os teus negocios, le Reddit, é importante informar de cada descanso sobre pizza fresca, fotografas a posta de sol, anuncias a final, votas xuntos e elixes o gañador. Día 1.
• Baixo o asterisco: Por suposto, pensas constantemente en que todo vai ben. Por suposto, non todos verán a túa mensaxe e é mellor falar con algúns en persoa. Por suposto, se alguén che axuda, todo será 2 veces máis sinxelo (a marabillosa Alena axudoume).

A parte menos aburrida da cita do hackathon

Por que o 21 de abril? Este día é significativo para nós. Hai exactamente un ano, o 21 de abril, caemos baixo carga durante a primeira fin de semana despois do inicio da Campaña Federal de Publicidade. Ao día seguinte, domingo, o noso equipo estivo a traballar dende as 8 da mañá. Despois creamos o taboleiro do sundayhackathon en Trello e comezamos unha semana de traballo por quendas de 12 horas diarias. A situación era tan crítica que nin sequera tivemos tempo para comer e fomos alimentados por rapaces doutros equipos.

Podes ler unha historia máis detallada en Páxina de Fiódor Ovchinnikov (o noso CEO). Desde entón, cambiamos moito, pero agora definitivamente non esqueceremos a data.

Este ano decidimos que este evento quede inmortalizado na memoria da posteridade e, na mellor tradición, organizamos o primeiro hackathon interno da historia de Dodo, que durou 10 horas.

A parte máis aburrida dos proxectos de hackathon

Descargo de responsabilidade: todas as descricións foron escritas polos propios mozos, polo que a autoría do texto non é miña.

Oleg Lerning (aprendizaxe automática)

Dima Kochnev, Sasha Andronov (@alexandronov)

Queriamos facer unha rede neuronal que determinase que tipo de pizza na foto sen coñecemento. Como resultado, fixeron un moi sinxelo e de xoguete: recoñece 10 pizzas, descubriu aproximadamente como funciona todo, na medida do posible nun día (~ 10 horas).

En particular, decatámonos de que a industria alcanzou un nivel no que un desenvolvedor común pode tomar bibliotecas preparadas, ler a documentación e adestrar a súa propia rede neuronal sen un coñecemento profundo do tema. E funcionará o suficientemente ben como para resolver problemas reais.

Ferramentas utilizadas:

• imaxes é unha biblioteca cómoda e sinxela para traballar coa aprendizaxe automática e a visión por ordenador.
• Os modelos probaron dous: ResNet50, Yolo.
• O código foi escrito, por suposto, en python.

Tiñamos 11000 fotos, pero entre elas, case 3/4 resultaron ser lixo e, no resto, ángulos diferentes e inadecuados. Como resultado, collemos un modelo preparado (que só sabe atopar pizza) e coa súa axuda separamos o propio lixo. Ademais, o nome da foto era o nome da pizza, así que a clasificamos en cartafoles, pero resultou que os nomes non coincidían coa realidade e aquí tivemos que limpalo coas mans. Como resultado, quedaron preto de 500-600 fotos, está claro que esta é unha cantidade insignificante, pero, con todo, isto resultou ser suficiente para separar 10 pizzas unhas das outras.

Para adestrar a rede, tomamos a máquina virtual máis barata de Azure en NVIDIA Tesla K80. Adestrouse en 100 épocas, pero estaba claro que a rede estaba sobresaturada despois de 50 épocas, debido ao feito de que había un pequeno conxunto de datos.

En realidade, todo o problema é a falta de bos datos.

Quizais nos confundamos un pouco nos termos, pero debemos ter en conta que xeralmente non temos experiencia en traballar con todos estes casos.

GUI para NOOBS (consola de pedidos de pizza)

Misha Kumachev (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

Creamos un prototipo de aplicación de consola para geeks, grazas á cal podes pedir pizza a través do terminal ou da liña de comandos, ou incluso incorporala no proceso de implantación e, tras o lanzamento exitoso, entregar pizza na oficina.

O traballo dividiuse en varias partes: descubrimos como funciona a nosa API para aplicacións móbiles, creamos a nosa propia CLI usando oclif e configurar a publicación do paquete que montamos. A última tarefa tivo varios minutos desagradables cara ao final do hackathon. Todo funcionou localmente para nós e incluso as versións antigas publicadas do paquete funcionaron, pero as novas (que engadiron funcións e emoticonas máis interesantes) negáronse a funcionar. Pasamos uns 40 minutos para descubrir o que pasou mal, pero ao final todo funcionou máxicamente por si só).

O noso programa para o hackathon máximo foi un pedido de pizza real á oficina a través do noso CLI. Corremos todo no banco de probas unha ducia de veces, pero aínda me tremían as mans cando marcaba ordes no prod.

Como resultado, aínda o fixemos!

CourierGo

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

Tomaron a idea de "Solicitude de correo".

Antecedentes sobre a preparación.Inicialmente, descubrín que funcións pode haber na aplicación? Unha lista de características xurdiu como esta:

• A aplicación inicia sesión na caixa de entrega mediante o código.
• A aplicación mostra inmediatamente os pedidos dispoñibles, os pedidos que hai que tomar.
• O mensaxeiro anota o pedido e lévao de viaxe.
• Móstraselle o tempo estimado e se ten tempo ou non.
• O cliente mostra que o correo marchou.
• O cliente comeza a mostrar o punto de mensaxería no mapa e o tempo estimado.
• O correo pode escribirlle ao cliente nun chat desde a aplicación.
• O cliente pode escribir ao correo nun chat desde a aplicación.
• Cinco minutos antes da chegada, o cliente recibe unha mensaxe de que o correo está preto, estea preparado.
• O mensaxeiro sinala na aplicación que chegou e está esperando.
• O mensaxeiro chama desde a aplicación cun só clic e informa de que (subíndose, achegándose, etc.)
• O cliente acepta o pedido e introduce o código PIN da aplicación ou SMS para confirmar a entrega (como sinatura) Para que o mensaxeiro non puidese completar a entrega con antelación se chega tarde.
• O pedido está marcado como entregado no sistema.

Ademais dun par de escenarios alternativos:

• O mensaxeiro pode marcar o pedido como non entregado e seleccionar un motivo.
• O correo, en caso de atraso, pode emitir un certificado electrónico por SMS cun só botón. Ou o certificado chega automaticamente se non se cumpre o prazo de entrega.

O sentimento das perspectivas e da necesidade deste proxecto, por suposto, foi energizante.

Ao día seguinte, fun xantar co equipo e discutín como sería a funcionalidade mínima da aplicación.

Como resultado, formouse a seguinte lista do que había que facer no hackathon:

• Inicia sesión na caixa de entrega.
• Mostra a posición actual.
• Enviar datos a API externa (coordenadas, tomou o pedido, entregou o pedido).
• Obter datos da API externa (pedidos actuais de mensaxería).
• Enviar un evento sobre o feito de que tomou o pedido para a súa entrega / entrega.
• Mostra a posición actual do correo no mapa do sitio.

O traballo principal, segundo parecía, era crear o backend, a aplicación en si (despois das discusións, escollemos ReactNative para desenvolver a aplicación, ou mellor dito, a ligazón por riba dela - expo.io, o que lle permite non escribir código nativo en absoluto). En canto ao backend, inicialmente había esperanza para Vanya Zverev, xa que tiña experiencia traballando co noso modelo de servizo e k8s (o traballo que asumiu). ReactNative foi tocado por min e Andrey Sarafanov.

Decidín tentar crear inmediatamente un repositorio de traballo para o propio proxecto. Ás 12 da noite, atopeime co feito de que a xeolocalización en segundo plano non funciona ben en ReactNative, se non escribes código nativo, estaba un pouco frustrado. Entón solteime cando me decatei de que estaba lendo a documentación non do framework expo.io, senón de ReactNative. Como resultado, pola noite xa me quedou claro como conseguir a posición actual en expo.io e debuxar pantallas separadas (para iniciar sesión, mostrar pedidos, etc.).

Pola mañá, no hackathon, atraeron a Gleb ao seu proxecto súper prometedor. Axiña elaboraron un plan de que facer.

Cometeron un erro cando, de acordo co modelo do proxecto, intentaron comunicarse non por HTTP, senón por GRPC, xa que ninguén sabía como construír un cliente GRPC para JavaScript. Como resultado, despois de dedicar aproximadamente hora e media a isto, abandonaron esta idea. Por iso, os mozos da parte traseira comezaron a refacer o servidor acabado de GRPC a WebApi. Despois de media hora, por fin, puidemos establecer a comunicación entre a aplicación e o backend, velaí. Pero ao mesmo tempo, Gleb case rematou de implementarse en k8s e, ademais, a implementación automática mediante o compromiso co mestre. 🙂

Como almacenamento, escollemos MySQL para non arriscar polo menos coa base de datos (había pensamentos sobre CosmosDb).

En resumo:

• Implementouse gardando as coordenadas actuais do correo desde a aplicación á base de datos.
• Fomos RabbitMQ e subscribimos a mensaxes sobre o pedido que está a recibir o correo para mostrar inmediatamente o pedido do correo na aplicación.
• Comezamos a gardar o tempo de entrega do pedido na base de datos despois de que o correo preme o botón da aplicación. Non tivemos tempo para engadir o envío dun evento ao rebbit de que se entregou o pedido.
• Fixen unha visualización do mapa na páxina de pedido actual do sitio coa posición actual do correo. Pero esta funcionalidade quedou un pouco sen rematar, xa que non era posible configurar CORS no entorno para recibir coordenadas do noso novo servizo.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Queriamos implementar un provedor de OpenID Connect, xa que nestes momentos utilizamos o noso propio protocolo de autenticación, e isto xera unha serie de dificultades: bibliotecas de clientes personalizadas, traballos incómodos de socios externos, posiblemente problemas de seguridade (despois de todo, OAuth2.0 e OpenID). Conectar na implementación de referencia pódese considerar segura, pero non estou seguro da nosa solución).

Fixemos un servizo separado que emula un servizo de almacenamento de datos persoais para crear un pequeno modelo de provedor de autenticación independente do país que pasaría os datos persoais a un servizo separado (isto faría posible no futuro ter un servizo con que se podería iniciar sesión cunha gravación de conta en calquera país, e ao mesmo tempo cumprir co GDPR e outras leis federais). Fixemos esta parte, igual que o provedor, e ligámolas con éxito entre si. A continuación, foi necesario facer unha API que estivese protexida polos tokens que emita o provedor, apoiar a súa introspección a través do provedor e devolver datos seguros se a solicitude cumprise as políticas de autorización (comprobamos que o usuario estea autenticado segundo o Esquema de portador, o seu token contén un certo alcance + o propio usuario ten un permiso que permite facer a chamada). Esta parte tamén foi rematada. O último compoñente foi un cliente JavaScript ao que se lle daría un token co que chamar a unha API segura. Non puidemos facer esta parte. É dicir, toda a parte funcional estaba lista, pero a parte frontal non estaba preparada para demostrar o rendemento de todo o sistema.

E-E-E (xoguete)

Dima Afonchenko, Sasha Konovalov

Fixemos un mini-xoguete nun cachorro onde unhas mans xurdidas puxeron unha salchicha nunha pizza. Se colocas a salchicha de forma incorrecta, aparece a triste inscrición "Rexeitado" na pantalla e, se a salchicha completa se bota correctamente, aparece un feito aleatorio sobre a pizza.

Querían facer o segundo nivel con tirar tomates, pero non tiveron tempo.

Breve secuela: quen gañou?

Antes do hackathon, falamos cos rapaces e preguntei que premio lles gustaría recibir se gañaban. Resultou que o premio máis valioso será "o camiño do prod".

Polo tanto, espera de nós en breve o anuncio dun xogo con bolígrafos que botan pepperoni na pizza.

Como puido notar un lector atento, gañou o equipo "E-E-E (xoguete)". Parabéns rapaces!

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Que proxecto che gustou máis?

• Oleg Lerning (aprendizaxe automática)

• GUI para NOOBS

• CourierGo

• M87

• Uh-uh

Votaron 5 usuarios. 3 usuarios abstivéronse.

Fonte: www.habr.com