Olá, Habr. Realizamos espontaneamente nosso primeiro hackathon interno. Resolvi compartilhar com vocês minhas dores e conclusões sobre a preparação para isso em 2 semanas, bem como os projetos que acabaram sendo realizados.
A parte chata para quem se interessa por marketing
Vou começar com uma pequena história.
Início de abril. O primeiro hackathon da comunidade MskDotNet está acontecendo em nosso escritório. A Batalha de Tatooine está em pleno andamento em nossa galáxia desta vez. Sábado. 20 equipes. Pizza. Tudo é muito sincero (). Um R2-D2 inflável flutua pelo corredor. As equipes escrevem os algoritmos mais corretos para passar na corrida mais perigosa do mapa. Estamos adiantando o lançamento das primeiras corridas. Biscoitos e café são salva-vidas. Os organizadores e eu esperávamos que muitas pessoas saíssem depois do almoço de sábado. Mas não. 12 horas de codificação atrasadas. O final. Algo cai, algo não começa. Mas todos estão felizes. Nosso time vence. Estamos duplamente felizes.
Estou compartilhando minha alegria no Slack e a ideia me vem à mente: “Precisamos fazer nosso próprio hackathon”. Estou escrevendo para nosso posto de gasolina Sasha. Silêncio.
Manhã. Tomo café no escritório. Vejo Sasha se aproximando por trás. “Lisa, isso é ótimo! Temos uma data importante em 21 de abril. Vamos fazê-lo!" O que é!? Tão rápido? A? O que? Preciso voar para Syktyvkar para um estágio em meados de abril. E para o inferno com isso! Vamos.
Faltam 2 semanas. Nunca fui o único organizador de um hackathon. Que seja interno. Eu li artigos sobre esse assunto. Difícil. Demora vários meses. São necessárias várias pessoas. Você precisa pensar em mercadorias, prêmios, condições, cronograma, juros, entender o objetivo, orçamentos. Ou talvez até descubra o sentido da vida. Definitivamente não chegarei a tempo. E enquanto você lia e se preparava, já havia se passado uma semana. É hora de esquecer os artigos e começar a fazer alguma coisa.
Veja nossa checklist para realizar um hackathon interno em 1 semana
- Plano: Você se senta com calma e escreve uma lista do que precisa ser feito para o hackathon. Minutos 30.
- Tarefa: os participantes propõem e escolhem os projetos que desejam criar no Planilhas Google. Tarefa em segundo plano, 2 horas.
- Programar: no joelho você escreve um pequeno intervalo de tempo, levando em consideração 3 intervalos e o final. Minutos 20.
- Equipes: publicar uma mensagem sobre o hackathon com programação do posto de atendimento nos canais de TI no Slack/mail/etc e criar um canal separado para o hackathon. Nele todos são divididos em equipes, e quem está indeciso faz isso nos primeiros 5 minutos do hackathon. Tarefa em segundo plano, 2 horas.
- pãezinhos: você cria o produto com dois desenvolvedores, entrega ao designer para renderização e o recebe pronto. Tarefa em segundo plano, 3 dias.
- Hackathon: você vem ao escritório, coordena todos no início, cuida dos seus negócios, lê o Reddit, o mais importante é anunciar cada intervalo sobre pizza fresca, tirar fotos do pôr do sol, anunciar a final, votar juntos e escolher o vencedor. Dia 1.
- Sob o asterisco: Claro, você pensa constantemente que tudo vai bem. É claro que nem todos verão sua mensagem e é melhor conversar pessoalmente com alguns. Claro que se alguém te ajudar tudo vai ficar 2 vezes mais fácil (a maravilhosa Alena me ajudou).
A parte menos chata da data do hackathon
Por que 21 de abril? Este dia é significativo para nós. Há exatamente um ano, no dia 21 de abril, ficamos sobrecarregados no primeiro fim de semana após o início da Campanha Publicitária Federal. No dia seguinte, domingo, nossa equipe esteve no trabalho a partir das 8h. Depois criamos um quadro do Sundayhackathon no Trello e começou uma semana de trabalho em turnos, 12 horas por dia. A situação era tão crítica que nem tivemos tempo de comer e fomos alimentados por caras de outros times.
Você pode ler uma história mais detalhada em (nosso CEO). Desde então mudamos muito, mas agora com certeza não esqueceremos a data.
Este ano, decidimos que valia a pena perpetuar este evento na memória da posteridade e, dentro das melhores tradições, organizamos o primeiro hackathon interno da história do Dodo, que durou 10 horas.
A parte mais chata dos projetos hackathon
Disclaimer: todas as descrições foram escritas pelos próprios rapazes, portanto a autoria do texto não é minha.
Oleg Learning (aprendizado de máquina)
Dima Kochnev, Sasha Andronov (@alexandronov)
Eles queriam fazer uma rede neural que determinasse que tipo de pizza está em uma foto, sem qualquer conhecimento. Como resultado, fizemos um bem simples e de brinquedo - ele reconhece 10 pizzas, descobrimos aproximadamente como tudo funciona, na medida do possível em um dia (~10 horas).
Em particular, percebemos que a indústria atingiu um nível onde um desenvolvedor comum pode pegar bibliotecas prontas, ler a documentação e treinar sua rede neural sem conhecimento profundo do assunto. E funcionará bem o suficiente para resolver problemas reais.
Ferramentas usadas:
- — uma biblioteca conveniente e simples para trabalhar com aprendizado de máquina e visão computacional.
- Tentamos dois modelos - ResNet50, Yolo.
- O código foi escrito, é claro, em Python.
Tínhamos 11000 mil fotos, mas quase 3/4 delas eram lixo, e o restante tinha ângulos diferentes e inadequados. Como resultado, pegamos um modelo pronto (que simplesmente sabe encontrar pizza) e com sua ajuda separamos o lixo. A seguir, o título da foto incluía o nome da pizza - então separamos em pastas, mas descobrimos que os nomes não correspondiam à realidade e tivemos que limpar com as mãos. No final sobraram cerca de 500-600 fotos, é claro que é uma quantidade insignificante, mas mesmo assim foi o suficiente para separar 10 pizzas umas das outras.
Para treinar a grade, pegamos a máquina virtual mais barata do Azure em um NVIDIA Tesla K80. Eles treinaram nela por 100 épocas, mas ficou claro que a rede estava supersaturada após 50 épocas, devido ao fato de haver um pequeno conjunto de dados.
Na verdade, todo o problema é a falta de dados confiáveis.
Podemos ter confundido um pouco os termos, mas devemos levar em conta que não temos nenhuma experiência em trabalhar com todos esses assuntos.
GUI para NOOBS (console para pedir pizza)
Misha Kumachev (), Zhenya Bikkinin, Zhenya Vasiliev
Montamos um protótipo de aplicativo de console para geeks, graças ao qual você pode pedir pizza através do terminal ou linha de comando, ou mesmo integrá-lo ao pipeline de implantação e, após o lançamento bem-sucedido, entregar pizza no escritório.
O trabalho foi dividido em várias partes: descobrimos como funciona nossa API para aplicações mobile, montamos nossa própria CLI usando e configuramos a publicação do pacote que coletamos. A última tarefa envolveu alguns minutos desagradáveis no final do hackathon. Tudo funcionou localmente para nós, e até as versões antigas publicadas do pacote funcionaram, mas as novas (que adicionaram mais recursos e emoticons interessantes) se recusaram a funcionar. Passamos cerca de 40 minutos tentando descobrir o que deu errado, mas no final tudo funcionou magicamente sozinho).
Nosso programa máximo para o hackathon foi um verdadeiro pedido de pizza para o escritório através do nosso CLI. Executamos tudo uma dúzia de vezes na bancada de testes, mas minhas mãos ainda tremiam quando digitei comandos em produção.
Como resultado, finalmente conseguimos!
CourierGo
Anton Bruzhmelev (autor), Vanya Zverev, Gleb Lesnikov (), Andrey Sarafanov
Pegamos a ideia de um “App para Courier”.
Antecedentes sobre a preparação.Inicialmente, me perguntei que tipo de recursos poderiam estar no aplicativo. A seguinte lista de funcionalidades surgiu:
- O aplicativo faz login na caixa registradora de entrega usando o código.
- O aplicativo mostra imediatamente os pedidos disponíveis e os pedidos que precisam ser atendidos.
- O mensageiro anota o pedido e o leva na viagem.
- Ele vê o tempo estimado e se está na hora certa ou não.
- Mostra ao cliente que o mensageiro saiu.
- O cliente começa a ver o ponto do entregador no mapa e o tempo estimado.
- O mensageiro pode escrever para o cliente no chat do aplicativo.
- O cliente pode escrever para o entregador via chat do aplicativo.
- Cinco minutos antes da chegada, o cliente recebe uma mensagem informando que o estafeta está próximo, esteja preparado.
- O mensageiro anota no aplicativo que chegou e está aguardando.
- O mensageiro liga do aplicativo com um clique e informa que (está subindo, chegou, 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 transportador não possa concluir a entrega antecipadamente caso se atrase.
- O pedido é marcado como entregue no sistema.
Além de alguns cenários alternativos:
- O transportador pode marcar o pedido como não entregue e selecionar o motivo.
- Se você se atrasar, o transportador poderá emitir um certificado eletrônico via SMS com um botão. Ou o certificado chega automaticamente caso o prazo de entrega não seja cumprido.
O sentimento de promessa e necessidade deste projeto foi, obviamente, energizante.
No dia seguinte fomos almoçar com a equipe e discutimos como seriam as funcionalidades mínimas do aplicativo.
Como resultado, foi formada a seguinte lista do que deveria ser feito no hackathon:
- Faça login na caixa registradora de entrega.
- Exibir a posição atual.
- Enviar dados para uma API externa (coordenadas, pedido recebido, pedido entregue).
- Receba dados de API externa (pedidos de correio atuais).
- Envie um evento indicando que você aceitou o pedido para entrega/entregue.
- Exiba a posição atual do mensageiro no mapa do site.
O trabalho principal, ao que parecia, estava na criação do backend, do próprio aplicativo (após discussões, escolhemos ReactNative para desenvolver o aplicativo, ou melhor, o framework para ele - , o que permite que você não escreva nenhum código nativo). Em termos de backend, inicialmente havia esperança em Vanya Zverev, pois ele tinha experiência em trabalhar com nosso modelo de serviço e k8s (trabalho que assumiu). Andrey Sarafanov e eu demos uma volta no ReactNative.
Decidi tentar criar imediatamente um repositório funcional para o próprio projeto. Às 12 da noite 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, fiquei um pouco frustrado. Aí desisti quando percebi que estava lendo a documentação não do framework expo.io, mas do ReactNative. Com isso, ao longo da noite já entendi como obter a posição atual no expo.io e desenhar telas separadas (para login, exibição de pedidos, etc.).
De manhã, no hackathon, eles atraíram Gleb para seu projeto superpromissor. Eles rapidamente elaboraram um plano do que precisava ser feito.
Cometemos um erro quando, de acordo com o modelo do projeto, tentamos nos comunicar não via HTTP, mas sim via GRPC, pois ninguém sabia construir um cliente GRPC para JavaScript. No final, depois de gastar cerca de uma hora e meia nisso, abandonamos a ideia. Por causa disso, o pessoal do back-end começou a refazer o servidor finalizado de GRPC para WebApi. Depois de meia hora, finalmente conseguimos estabelecer a comunicação entre o aplicativo e o backend, vejam só. Mas, ao mesmo tempo, Gleb estava quase terminando a implantação no k8s e mais a implantação automática de um commit no master. 🙂
Escolhemos o MySQL como armazenamento para não correr riscos pelo menos com o banco de dados (pensamos no CosmosDb).
Em resumo:
- Implementado o salvamento das coordenadas atuais do mensageiro do aplicativo no banco de dados.
- Instalamos o RabbitMQ e assinamos mensagens sobre o entregador retirando um pedido para exibir imediatamente o pedido do entregador no aplicativo.
- Começamos a salvar o tempo de entrega do pedido em nosso banco de dados depois que o entregador pressionou um botão no aplicativo. Não tivemos tempo de adicionar o envio de um evento de volta ao rebbit de que o pedido foi entregue.
- Fiz uma exibição de mapa na página do pedido atual no site com a posição atual do entregador. Mas esta funcionalidade ficou um pouco inacabada, pois não foi possível configurar o CORS no ambiente para receber coordenadas do nosso novo serviço.
M87
Roma Bukin, Gosha Polevoy (), Artem Trofimushkin
Queríamos implementar um provedor OpenID Connect, pois no momento utilizamos um protocolo de autenticação de nossa própria concepção, o que cria uma série de dificuldades: bibliotecas clientes customizadas, trabalho inconveniente por parte de parceiros externos, possíveis problemas de segurança (afinal , OAuth2.0 e OpenID Connect na implementação de referência podem ser considerados seguros, mas não tenho certeza sobre nossa solução).
Fizemos um serviço separado emulando um serviço de armazenamento de dados pessoais, a fim de criar um pequeno modelo independente de país de um provedor de autenticação que iria para um serviço separado para dados pessoais (isso tornaria possível no futuro ter um serviço com qual se poderia fazer login com um registro de conta em qualquer país e, ao mesmo tempo, cumprir o GDPR e outras leis federais). Fizemos essa parte, assim como o provedor, e os vinculamos com sucesso. Em seguida, foi necessário criar uma API que fosse protegida por tokens emitidos pelo provedor, apoiasse sua introspecção através do provedor e retornasse dados protegidos caso a solicitação atendesse às políticas de autorização (verificamos se o usuário está autenticado de acordo com o esquema Bearer , seu token contém um determinado escopo + y O próprio usuário possui uma permissão que permite que a chamada seja feita). Esta parte também foi concluída. O último componente era um cliente JavaScript, ao qual seria fornecido um token, com a ajuda do qual chamaria uma API protegida. Não tivemos tempo para fazer esta parte. Ou seja, toda a parte funcional estava pronta, mas a parte front-end não estava pronta para demonstrar a funcionalidade de todo o sistema.
E-E-E (brinquedo)
Dima Afonchenko, Sasha Konovalov
Fizemos um minibrinquedo na yunka onde mãos brincalhonas jogam linguiça na pizza. Se colocar a linguiça incorretamente, uma triste mensagem “Rejeitada” aparece na tela, e se toda a linguiça foi colocada corretamente, aparece um fato aleatório sobre a pizza.
Queríamos fazer um segundo nível jogando tomates, mas não tivemos tempo.
Curta continuação: quem ganhou?
Antes do hackathon conversamos com a galera e perguntei qual prêmio eles gostariam de receber se ganhassem. Descobriu-se que o prêmio mais valioso seria “o caminho para a comida”.
Portanto, espere que em breve anunciemos um jogo com mãos que colocam pimenta na pizza.
Como um leitor atento deve ter notado, a equipe “E-E-E (brinquedo)” venceu. Parabéns pessoal!
Apenas usuários registrados podem participar da pesquisa. por favor
Qual projeto você gostou mais?
-
Oleg Learning (aprendizado de máquina)
-
GUI para NOOBS
-
CourierGo
-
M87
-
Uh-uh
5 usuários votaram. 3 usuários se abstiveram.
Fonte: habr.com