Kodim - pizza

Oi Habr. Realizamos espontaneamente a primeira hackatona interna. Decidi compartilhar com vocês minhas dores e conclusões sobre a preparação para isso em duas semanas, bem como os projetos que resultaram.



A parte chata para os interessados ​​em marketing


Vou começar com uma pequena história.

O começo de abril. A primeira comunidade hackathon MskDotNet é realizada em nosso escritório. A batalha por Tatooine está em pleno andamento, desta vez em nossa galáxia. Sábado 20 equipes. Pizza Tudo é muito sincero ( provas ). O R2-D2 inflável aparece ao redor do corredor. As equipes escrevem os algoritmos mais corretos para passar a corrida mais perigosa do mapa. Mudamos o lançamento das primeiras corridas. Biscoitos e café economizam. Os organizadores e eu esperávamos que no sábado muitos fossem embora depois do jantar. Mas não. 12 horas de codificação atrasada. O final. Algo cai, algo não começa. Mas todo mundo está feliz. Nossa equipe vence. Nós somos duplamente felizes.

Compartilho minha alegria no Slack e a idéia me vem à cabeça: "Precisamos fazer nossa própria hackathon". Estou escrevendo para a nossa estação de serviço Sasha. O silêncio.

Manhã Eu tomo café no escritório. Eu vejo Sasha vindo por trás. “Lisa, isso é ótimo! Temos uma data importante em 21 de abril. Vamos fazer isso! WTF!? Tão rápido Hein? O que? Preciso viajar para Syktyvkar para um estágio em meados de abril. Sim, e para o inferno com ele! Vamos lá.

Permanece 2 semanas. Eu nunca fui o único organizador de um hackathon. Que seja interno. Eu li artigos sobre esse tópico. Estanho. Demora alguns meses. Precisa de algumas pessoas. É necessário refletir sobre o mercado, prêmios, condições, cronograma, interesse, entender a meta, orçamentos. Ou talvez até descobrir o significado da vida. Definitivamente não terei tempo. E enquanto você lê e se prepara, uma semana se passou. É hora de pontuar nos artigos e começar a fazer alguma coisa.

Assista a nossa lista de verificação interna de hackathon de uma semana
  • Plano : sente-se em silêncio e escreva uma lista do que precisa ser feito para o hackathon. 30 minutos
  • Objetivo : os próprios participantes propõem e escolhem os projetos que desejam criar no Planilhas Google. Tarefa em segundo plano, 2 horas .
  • Horário : no joelho, você escreve uma pequena quebra no tempo, levando em consideração três quebras e a final. 20 minutos
  • Equipes : você publica uma mensagem sobre o hackathon com a programação da estação de serviço nos canais de TI no Slack / mail / etc e cria um canal separado para o hackathon. Nele, todos são divididos em equipes e os fazem indecisos nos primeiros 5 minutos do hackathon. Tarefa em segundo plano, 2 horas .
  • Vantagens : você cria uma mercadoria com dois desenvolvedores, fornece uma renderização ao designer e se prepara. Tarefa em segundo plano, 3 dias .
  • Hackathon : você vem ao escritório, coordena tudo no início, cuida dos seus negócios, lê o Reddit, informa cada intervalo sobre pizza fresca, tira uma foto do pôr do sol, anuncia a final, anuncia a final, vota em conjunto e escolhe o vencedor. 1 dia
  • Sob o asterisco : é claro, você constantemente pensa que tudo correu bem. Obviamente, nem todos verão sua mensagem e é melhor conversar com alguém pessoalmente. Claro que, se alguém o ajudar, tudo ficará duas vezes mais fácil (a maravilhosa Alena me ajudou).


A parte menos chata sobre a data do hackathon


Por que 21 de abril? Este dia é significativo para nós. Exatamente há um ano, em 21 de abril, ficamos sob carga durante o primeiro fim de semana após o início da Campanha Federal de Publicidade. No dia seguinte, domingo, nossa equipe estava trabalhando das 8 da manhã. Em seguida, criamos uma prancha de sundayhackathon no Trello e começamos uma semana de turno de 12 horas por dia. A situação era tão crítica que não tínhamos tempo nem para comer e fomos alimentados por caras de outras equipes.



Você pode ler uma história mais detalhada na página de Fedor Ovchinnikov (nosso CEO). Desde então, mudamos muito, mas agora definitivamente não vamos esquecer a data.

Este ano, decidimos que esse evento deveria ser imortalizado na memória da posteridade e, nas melhores tradições, organizamos o primeiro hackathon interno da história do Dodo, que durou 10 horas.

A parte mais chata dos projetos de hackathon


Isenção de responsabilidade: todas as descrições foram escritas pelos próprios caras, portanto a autoria do texto não é minha.

Oleg Lörning (aluguel de carros)


Dima Kochnev, Sasha Andronov (@alexandronov)

Eles queriam criar uma rede neural que determinasse que tipo de pizza está na foto sem nenhum conhecimento. Como resultado, eles fizeram um muito simples e de brinquedo - ele reconhece 10 pizzas, descobriu como tudo funciona, o quanto é possível em um dia (~ 10 horas).



Em particular, percebemos que o setor chegou ao ponto em que um desenvolvedor comum pode pegar bibliotecas prontas, ler documentação e treinar sua rede neural sem profundo conhecimento do assunto. E funcionará bem o suficiente para resolver problemas reais.

Ferramentas usadas:
  • O imageai é uma biblioteca simples e conveniente para trabalhar com aprendizado de máquina e visão computacional.
  • Dois modelos tentaram - ResNet50, Yolo.
  • O código foi escrito, é claro, em python.

Tínhamos 11.000 fotos, mas quase 3/4 delas eram lixo, e as demais mostravam ângulos diferentes e inadequados. Como resultado, pegamos o modelo finalizado (que apenas sabe encontrar pizza) e, com sua ajuda, separamos o máximo de lixo. Além disso, no nome da foto estava o nome da pizza - é assim que as colocamos em pastas, mas os nomes não coincidem com a realidade e tivemos que limpá-la com as mãos. Como resultado, cerca de 500 a 600 fotos permaneceram, é claro que essa é uma quantidade insignificante, mas, no entanto, isso foi suficiente para separar 10 pizzas uma da outra.

Para treinar a grade, eles usaram a máquina virtual mais barata no Azure no NVIDIA Tesla K80. Foi treinado em 100 épocas, mas ficou claro que a rede estava saturada após 50 épocas, devido ao fato de haver um pequeno conjunto de dados.

Na verdade - o problema todo é a falta de bons dados.



Podemos ter nos misturado um pouco em termos, mas devemos ter em mente que geralmente não temos experiência em trabalhar com todos esses assuntos.

GUI para NOOBS (console para pedir pizza)


Misha Kumachev ( Ceridan ), Zhenya Bikkinin, Zhenya Vasiliev

Reunimos um aplicativo de console de protótipo para geeks, graças ao qual você pode pedir pizza pelo terminal ou pela linha de comando ou até mesmo integrá-lo ao pipeline de implantação e, com uma versão bem-sucedida, entregar pizza ao escritório.



O trabalho foi dividido em várias partes: organizamos nossa API para aplicativos móveis, montamos nossa própria CLI usando oclif e configuramos a publicação do pacote que montamos. A última tarefa foi associada a vários minutos desagradáveis ​​no final do hackathon. Tudo funcionou para nós localmente e até as versões antigas publicadas do pacote funcionaram, mas as novas (nas quais foram adicionados mais recursos e emoticons interessantes) se recusaram a funcionar. Passamos 40 minutos para descobrir o que deu errado, mas no final tudo funcionou magicamente).

Nosso programa máximo de hackathon foi um pedido real de pizza para o escritório através de nossa CLI. Dirigimos tudo uma dúzia de vezes no banco de testes, mas minhas mãos ainda tremiam quando marquei equipes no prod.



Como resultado - ainda conseguimos!



Correio ir


Anton Bruzhmelyov (autor), Vanya Zverev, Gleb Lesnikov ( entropia ), Andrey Sarafanov

Adotamos a ideia de "Solicitação de correio".

Antecedentes sobre a preparação.
Inicialmente, eu descobri, mas quais recursos podem estar no aplicativo? Algo assim apareceu:
  • O aplicativo efetua login no balcão de check-out por código.
  • O aplicativo mostra imediatamente os pedidos disponíveis, dos quais você precisa para receber pedidos.
  • O correio anota o pedido e faz a viagem.
  • Ele é mostrado o tempo estimado e ele tem tempo ou não.
  • O cliente mostra que o correio saiu.
  • O cliente começa a mostrar o ponto de correio no mapa e o tempo estimado.
  • O correio pode escrever para o cliente em um bate-papo a partir do aplicativo.
  • O cliente pode escrever um correio para conversar a partir do aplicativo.
  • Cinco minutos antes da chegada, o cliente recebe uma mensagem de que o correio está próximo, prepare-se.
  • O correio observa no aplicativo que ele parou e estava esperando.
  • O correio liga da aplicação com um clique e informa que (ele se levanta, sobe, etc.)
  • O cliente aceita o pedido e insere um código PIN do aplicativo ou SMS para confirmar a entrega. (Como assinatura) Para que o correio não possa concluir a entrega com antecedência se estiver atrasado.
  • O pedido é marcado como entregue no sistema.


Além de alguns cenários alternativos:
  • O correio pode marcar o pedido como não entregue e escolher um motivo.
  • Correio, se você estiver atrasado, poderá emitir um certificado eletrônico de um botão via SMS. Ou o certificado vem automaticamente se o tempo de entrega não for respeitado.

O senso de promessa e necessidade deste projeto certamente cobrou.

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

Como resultado, a seguinte lista do que tinha que ser feito no hackathon foi formada:
  • Faça login na caixa de entrega.
  • Exibir posição atual.
  • Envie dados para uma API externa (coordenadas, atendeu ao pedido, entregou o pedido).
  • Obtenha dados da API externa (pedidos de correio atuais).
  • Enviar um evento que recebi / entregue uma ordem de entrega.
  • Exiba a posição atual do correio em um mapa no site.

O trabalho principal, como eu vi, foi criar o back-end, o aplicativo em si (após discussões, escolhemos o ReactNative para desenvolver o aplicativo, ou melhor, vinculá- lo ao expo.io , que permite não escrever código nativo). Em termos de back-end, havia inicialmente uma esperança para Vanya Zverev, como experiente em trabalhar com nosso modelo de serviço e k8s (que tipo de trabalho ele assumiu). ReactNative levou eu e Andrei Sarafanov.

Decidi tentar criar imediatamente um repositório de trabalho para o próprio projeto. Às 12 noites, me deparei com o fato de que a geolocalização em segundo plano não funciona bem no ReactNative; se você não escreve código nativo, ficou um pouco frustrado. Em seguida, foi lançado quando percebi que estava lendo a documentação não da estrutura expo.io, mas do ReactNative. Como resultado, durante a noite já estava claro para mim como obter a posição atual no expo.io e desenhar telas separadas (para login, exibição de pedidos etc.).



De manhã no hackathon, Gleb foi atraído para o seu projeto promissor. Eles rapidamente estabeleceram um plano do que precisa ser feito.



Eles cometeram um erro quando, de acordo com o modelo do projeto, tentaram fazer a comunicação não por HTTP, mas por GRPC, pois ninguém sabia como construir um cliente GRPC para JavaScript. Como resultado, tendo passado cerca de uma hora e meia nisso, eles abandonaram essa ideia. Por causa disso, os caras e as costas começaram a refazer o servidor final do GRPC para a WebApi. Após meia hora, finalmente, conseguimos configurar a comunicação do aplicativo com o back-end, eis que ele está pronto. Mas, ao mesmo tempo, Gleb quase terminou a implantação em k8s e mais ações automáticas, comprometendo-se com o mestre. :)

Como repositório, escolhemos o MySQL para não arriscar nem a base (havia pensamentos sobre o CosmosDb).



Em resumo:

  • Implementado salvando as coordenadas de correio atuais do aplicativo no banco de dados.
  • Eles ferraram o RabbitMQ e assinaram mensagens sobre o correio receber o pedido para exibir imediatamente o pedido do correio no aplicativo.
  • Começamos a economizar tempo para a entrega do pedido em nosso banco de dados, depois que o correio clicou em um botão no aplicativo. Não tivemos tempo para adicionar o envio do evento de volta ao rebit, indicando que o pedido foi entregue.
  • Eu fiz uma exibição de mapa na página de pedido atual no site com a posição de correio atual. Mas essa funcionalidade permaneceu um pouco inacabada, pois o ambiente não pôde configurar o CORS para obter as coordenadas de nosso novo serviço.

M87


Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Queríamos implementar o provedor OpenID Connect, porque no momento usamos um protocolo de autenticação de nosso próprio design, e isso cria várias dificuldades: bibliotecas personalizadas do cliente, trabalho inconveniente de parceiros externos e possivelmente problemas de segurança (afinal, OAuth2.0 e OpenID Connect na implementação de referência pode ser considerado seguro, mas quanto à nossa solução - não tenho certeza).



Fizemos um serviço separado emulando um serviço de armazenamento de dados pessoais para criar um pequeno modelo do provedor de autenticação independente de país que iria para um serviço separado de dados pessoais (isso permitiria no futuro ter um serviço com o qual você poderia fazer login com sua conta registro em qualquer país e, ao mesmo tempo, cumpra o GDPR e outras leis federais). Fizemos essa parte, como o provedor, e os vinculamos com êxito. Em seguida, precisávamos criar uma API que fosse protegida por tokens emitidos pelo provedor, oferecer suporte à introspecção por meio do provedor e enviar dados protegidos se a solicitação atender às políticas de autorização (verificamos que o usuário está autenticado usando o esquema Bearer, seu token contém um determinado escopo o próprio usuário tem permissões que permitem fazer a chamada). Esta parte também foi concluída. O último componente era um cliente JavaScript ao qual seria emitido um token, com o qual chamaria uma API segura. Não conseguimos fazer essa parte. Ou seja, toda a parte funcional estava pronta, mas a parte do front-end não estava pronta para demonstrar a operacionalidade de todo o sistema.

Uh (igruha)


Sasha Konovalov, Dima Afonchenko

Fizemos um mini-brinquedo em um pequeno, onde alças brincalhões colocam salsicha na pizza. Se você jogou uma lingüiça incorretamente, a triste mensagem “Rejeitada” aparece na tela e, se a lingüiça inteira for jogada corretamente, um fato aleatório sobre a pizza será exibido.



Eles queriam chegar ao segundo nível com uma propagação de tomates, mas não tiveram tempo.



Breve continuação: quem ganhou?


Antes do hackathon, conversamos com os caras e perguntei que prêmio eles gostariam de receber se vencessem. Acabou que o caminho para a comida seria o prêmio mais valioso.



Portanto, em breve esperamos de nós o anúncio do jogo com alças no topo de pepperoni na pizza.

Como um leitor atento pôde perceber, a equipe “E-E-E (igruha)” venceu. Parabéns pessoal!

Source: https://habr.com/ru/post/pt449344/


All Articles