🥇Codando–pizza

Olá, Habr. Realizamos espontaneamente nosso primeiro hackathon interno. Decidi compartilhar com você minhas dificuldades e conclusões sobre a preparação para isso em duas semanas, assim como os projetos que surgiram.

A parte chata para quem se interessa por marketing

Vou começar com uma pequena história.

Início de abril. Nosso escritório está sediando o primeiro hackathon da MskDotNet Community. A batalha por Tatooine está a todo vapor, nesta galáxia desta vez. Sábado. 20 equipes. Pizza. Tudo muito acolhedor (os proofs). Um R2-D2 inflável aparece pela sala. As equipes estão escrevendo os algoritmos mais corretos para superar a corrida mais perigosa do mapa. A partida é adiada. Biscoitos e café salvam. Nós, com os organizadores, estávamos esperando que muitos saíssem no sábado após o almoço. Mas não. 12 horas de codificação se passaram. Final. Algo cai, algo não liga. Mas todos estão felizes. Nossa equipe vence. Estamos felizes em dobro.

Compartilho a alegria no Slack e uma ideia vem à mente: “Precisamos fazer nosso hackathon”. Escrevo para nosso CTO Sasha. Silêncio.

Manhã. Estou tomando café no escritório. Vejo Sasha se aproximando pelas costas. “Liza, isso é ótimo! Temos uma data importante em 21 de abril. Vamos fazer!” WTF!? Tão rápido? Hã? O que? Preciso viajar para Syktyvkar para o estágio no meio de abril. E que se dane! Vamos lá.

Faltam 2 semanas. Eu nunca fui a organizadora única de um hackathon. Mesmo que seja interno. Estou lendo artigos sobre o tema. Terrível. Precisa de vários meses. Precisa de várias pessoas. Tem que planejar merchandise, prêmios, condições, cronograma, envolver pessoas, entender o objetivo, orçamentos. E talvez até descobrir o sentido da vida. Com certeza não vou conseguir a tempo. E enquanto você lia e se preparava, uma semana já passou. É hora de parar de ler artigos e começar a fazer algo.

Aqui está nossa checklist para realizar um hackathon interno em 1 semana

Plano: sente-se tranquilamente e escreve uma lista do que precisa ser feito para o hackathon. 30 minutos.
Tarefa: os participantes propõem e escolhem os projetos que querem criar no Google Sheets. Tarefa de fundo, 2 horas.
Cronograma: escreva rapidamente um esboço de tempo considerando 3 intervalos e a finalização. 20 minutos.
Equipes: publique uma mensagem sobre o hackathon com o cronograma do CTO nos canais de TI no Slack/email/etc. e crie um canal separado para o hackathon. Nele, todos se dividem em equipes, enquanto os indecisos fazem isso nos primeiros 5 minutos do hackathon. Tarefa de fundo, 2 horas.
Vantagens: você cria um merch com dois desenvolvedores, entrega ao designer para ilustração e recebe o produto final. Tarefa em segundo plano, 3 dias.
Hackathon: você chega ao escritório, coordena todos no início, cuida das suas tarefas, lê Reddit, com um ar importante, informa sobre a nova pizza a cada pausa, fotografa o pôr do sol, anuncia a final e todos votam juntos para escolher o vencedor. 1 dia.
Sob a estrela: claro, você está constantemente pensando em como tudo vai correr bem. Naturalmente, nem todos verão sua mensagem e é melhor falar pessoalmente com alguns. Sem dúvida, se alguém estiver te ajudando, tudo ficará 2 vezes mais fácil (minha ajudante foi a incrível Alena).

Parte menos chata sobre a data do hackathon

Por que 21 de abril? Este dia é significativo para nós. Exatamente um ano atrás, em 21 de abril, caímos sob carga durante o primeiro fim de semana após o lançamento da Campanha Publicitária Federal. No dia seguinte, domingo, nossa equipe estava trabalhando desde as 8 da manhã. Naquela época, criamos um quadro no Trello chamado sundayhackathon e começou uma semana de trabalho em turnos de 12 horas por dia. A situação estava tão crítica que não tínhamos nem tempo para comer, e fomos alimentados por pessoas de outras equipes.

Você pode ler uma conta mais detalhada em na página de Fyodor Ovchinnikov (nosso CEO). Desde então, mudamos muito, mas com certeza não esqueceremos mais essa data.

Este ano decidimos que este evento deve ser eternizado na memória das gerações futuras e, seguindo as melhores tradições, organizamos o primeiro hackathon interno da história da Dodo, que durou 10 horas.

A parte mais interessante sobre os projetos do hackathon

Disclaimer: todas as descrições foram escritas pelos próprios rapazes, então a autoria do texto não é minha.

Oleg Learning (aprendizado de máquina)

Dima Kochnyov, Sasha Andronov (@alexandronov)

Queríamos fazer uma rede neural que identificasse qual pizza está na foto sem nenhum conhecimento prévio. No final, fizemos algo bem simples e de brinquedo – ela reconhece 10 pizzas, e conseguimos entender como tudo funciona, pelo menos o que é possível em um dia (~10 horas).

Em particular, entendemos que a indústria chegou a um ponto em que qualquer desenvolvedor pode usar bibliotecas prontas, ler a documentação e treinar sua rede neural sem conhecimentos aprofundados na área. E ela funcionará de forma suficientemente boa para resolver problemas reais.

Ferramentas que usamos:

imageai — uma biblioteca conveniente e simples para trabalhar com aprendizado de máquina e visão computacional.
Testamos dois modelos – ResNet50 e Yolo.
O código foi escrito, como não poderia deixar de ser, em Python.

Tínhamos 11.000 fotos, mas quase 3/4 delas eram lixo, e entre as restantes havia diferentes ângulos inadequados. No final, pegamos um modelo pronto (que simplemente consegue encontrar pizzas) e, com a ajuda dele, separávamos o que era mais relevante. Além disso, no nome da foto constava o nome da pizza — assim fizemos a organização em pastas, mas descobrimos que os nomes não correspondiam à realidade e tivemos que corrigir manualmente. Restaram cerca de 500-600 fotos, é claro que isso é um número insignificante, mas mesmo assim, foi o suficiente para distinguir 10 pizzas uma da outra.

Para treinar a rede, pegamos a máquina virtual mais barata da Azure com NVIDIA Tesla K80. Nela, treinamos por 100 épocas, mas era evidente que a rede já estava saturada após 50 épocas, devido ao pequeno conjunto de dados.

A verdadeira questão reside na ausência de bons dados.

Talvez tenhamos confundido um pouco os termos, mas é importante considerar que não temos experiência com tudo isso.

GUI for NOOBS (console para pedido de pizza)

Misha Kumachev (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

Criamos um protótipo de aplicativo de console para entusiastas, que permite pedir pizza através do terminal ou linha de comando, ou até mesmo integrá-lo em um pipeline de implantação e entregar pizzas no escritório após um lançamento bem-sucedido.

O trabalho se dividiu em várias partes: entendemos como funciona nossa API para aplicativos móveis, criamos nosso próprio CLI usando oclif e configuramos a publicação do pacote que desenvolvemos. Com a última tarefa, tivemos alguns momentos desagradáveis perto do final do hackathon. Tudo funcionava localmente e até as versões antigas do pacote publicadas funcionavam, mas as novas (que tinham mais recursos legais e emoticons) não funcionavam. Gastamos cerca de 40 minutos tentando descobrir o que havia dado errado, mas, no final, tudo funcionou magicamente sozinho).

Nossa ambição no hackathon era fazer um pedido real de pizza no escritório através do nosso CLI. Testamos várias vezes em um ambiente de testes, mas ainda assim eu estava nervoso ao digitar os comandos em produção.

Como resultado — nós conseguimos!

CourierGo

Anton Bruzhmelëv (autor), Vanya Zverev, Gleb Lesnikov (entropia), Andrey Sarafanov

Pegamos a ideia de "Aplicativo para entregadores".

História de preparação.Inicialmente, eu pensei em quais funcionalidades poderiam haver no aplicativo. Surgiu aproximadamente a seguinte lista de funcionalidades:

O aplicativo faz login na central de entregas por código.
No aplicativo, os pedidos disponíveis e os pedidos que precisam ser aceitos são imediatamente visíveis.
O entregador marca o pedido e o aceita para a viagem.
Ele é informado sobre o tempo estimado e se consegue ou não cumprir.
O cliente é notificado de que o entregador saiu.
O cliente começa a ver a localização do entregador no mapa e o tempo estimado.
O entregador pode enviar mensagens ao cliente pelo chat do aplicativo.
O cliente pode enviar mensagens ao entregador pelo chat do aplicativo.
Cinco minutos antes da chegada, o cliente recebe uma mensagem de que o entregador está próximo, fique preparado.
O entregador marca no aplicativo que chegou e está esperando.
O entregador pode ligar pelo aplicativo com um clique e informar que (está subindo, chegou, etc.)
O cliente aceita o pedido e insere o código PIN do aplicativo ou SMS para confirmar a entrega (como assinatura). Isso impede que o entregador conclua a entrega antecipadamente, caso atrase.
O pedido é marcado no sistema como entregue.

Além de alguns cenários alternativos:

O entregador pode marcar o pedido como não entregue e escolher o motivo.
O entregador, em caso de atraso, pode enviar um certificado eletrônico por SMS com um clique. Ou o certificado chega automaticamente ao não cumprimento do prazo de entrega.

A sensação de potencial e necessidade deste projeto definitivamente animou.

No dia seguinte, fomos almoçar com a equipe e discutimos como seria a funcionalidade mínima do aplicativo.

No final, formou-se a seguinte lista do que deveria ser feito no hackathon:

Login na central de entregas.
Mostrar a localização atual.
Enviar dados para uma API externa (coordenadas, aceitou o pedido, entregou o pedido).
Obter dados de uma API externa (pedidos atuais do entregador).
Enviar um evento informando que aceitou o pedido para entrega/entregou.
Mostrar a localização atual do entregador no mapa do site.

O trabalho principal, como parecia, estava em criar o backend do aplicativo (após discussões, escolhemos o ReactNative para o desenvolvimento do aplicativo, mais precisamente, uma camada sobre ele — expo.io, permitindo não precisar escrever código nativo). No plano de backend, havia inicialmente a esperança em Vanya Zverev, como alguém experiente em trabalhar com nosso modelo de serviço e k8s (que trabalho ele assumiu). Eu e Andrei Sarafanov ficamos encarregados de dar uma olhada no ReactNative.

Decidi tentar criar imediatamente um repositório de trabalho para o próprio projeto. À meia-noite, percebi que a geolocalização no ReactNative funciona mal em segundo plano, se não escrever código nativo, fiquei um pouco frustrado. Mas depois relaxei quando percebi que estava lendo a documentação do framework expo.io, e não do ReactNative. No final da noite, já tinha entendido como obter a localização atual no expo.io e desenhar telas separadas (para login, exibição do pedido, etc.).

De manhã, no hackathon, atraímos Gleb para nosso projeto super promissor. Rápido, fizemos um esboço do plano do que precisava ser feito.

Cometemos um erro ao tentar estabelecer comunicação não através de HTTP, mas sim através de GRPC, conforme o modelo do projeto, já que ninguém sabia como construir um cliente GRPC para JavaScript. No final, após gastar cerca de uma hora e meia, abandonamos essa ideia. Por causa disso, o pessoal começou a reestruturar o servidor existente de GRPC para WebApi. Após meia hora, finalmente conseguimos configurar a comunicação do aplicativo com o backend, oh maravilha. Mas ao mesmo tempo Gleb quase finalizava o deploy no k8s e também o autodeploy por commit na master. 🙂

Escolhemos o MySQL como armazenamento para não correr riscos com a base (tivemos pensamentos sobre CosmosDb).

No final:

Implementamos a salvaguarda das coordenadas atuais do entregador a partir do aplicativo na base de dados.
Conectamos o RabbitMQ e nos inscrevemos nas mensagens sobre a aceitação do pedido pelo entregador, para exibir imediatamente o pedido ao entregador no aplicativo.
Começamos a salvar na nossa base o tempo de entrega do pedido, após o entregador clicar no botão no aplicativo. Não conseguimos adicionar o envio de um evento de volta para o Rabbit informando que o pedido foi entregue.
Eu implementei a exibição do mapa na página currentorder no site com a localização atual do entregador. Mas essa funcionalidade ficou um pouco inacabada, pois não conseguimos configurar o CORS ao obter as coordenadas do nosso novo serviço.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artem Trofimushkin

Nós queríamos implementar um provedor OpenID Connect, pois atualmente estamos usando um protocolo de autenticação desenvolvido internamente, o que gera uma série de dificuldades: bibliotecas de cliente personalizadas, trabalho inconveniente com parceiros externos e possíveis problemas de segurança (afinal, OAuth2.0 e OpenID Connect em sua implementação de referência podem ser considerados seguros, mas quanto à nossa solução — não estou certo).

Criamos um serviço separado que emula um serviço de armazenamento de dados pessoais, para criar um pequeno modelo de provedor de autenticação agnóstico em relação ao país, que buscaria os dados pessoais em um serviço separado (isso, a longo prazo, permitiria ter um único serviço, com o qual seria possível fazer login com uma conta de qualquer país, enquanto estariam em conformidade com a GDPR e outras leis). Esta parte foi concluída, bem como o provedor, e os ligamos com sucesso. Em seguida, era necessário criar uma API que seria protegida por tokens emitidos pelo provedor, suportando sua introspecção através do provedor e entregando dados protegidos, se a solicitação atendesse às políticas de autorização (verificamos se o usuário está autenticado pelo esquema Bearer, se seu token contém um determinado escopo + se o próprio usuário tem permissão para realizar a chamada). Esta parte também foi concluída. O último componente era um cliente JavaScript, que receberia um token, com o qual chamaria a API protegida. Esta parte não conseguimos concluir. Ou seja, toda a parte funcional estava pronta, mas a parte de front-end para demonstrar a funcionalidade de todo o sistema não ficou pronta.

E-E-E (joguinho)

Dima Afonchenko, Sasha Konovalov

Fizemos um mini-jogo em Unity onde mãos ágeis lançam salsichas em uma pizza. Se você lançar a salsicha de maneira errada, aparece na tela a triste mensagem 'Rejeitado', e se toda a salsicha for lançada corretamente, um fato aleatório sobre pizza aparece.

Queríamos fazer um segundo nível lançando tomates, mas não conseguimos.

Continuação rápida: quem venceu?

Antes do hackathon, conversamos com o pessoal e eu perguntei qual prêmio eles gostariam de receber se ganhassem. Aparentemente, o prêmio mais valioso seria 'a passagem para a produção'.

Portanto, em breve aguardem o anúncio do jogo com as mãos que lançam pepperoni na pizza.