Meu nome é Dmitry. E quero falar sobre como nossa equipe chegou à final do hackathon Urban Tech Challenge na pista Big Data. Direi desde já que este não é o primeiro hackathon em que participo, e nem o primeiro em que ganhei prêmios. A este respeito, na minha história quero expressar algumas observações e conclusões gerais sobre a indústria do hackathon como um todo, e dar o meu ponto de vista em oposição às críticas negativas que apareceram online imediatamente após o final do Urban Tech Challenge (por exemplo ).
Então, primeiro algumas observações gerais.
1. É surpreendente que muitas pessoas pensem ingenuamente que um hackathon é algum tipo de competição esportiva onde os melhores programadores vencem. Isto está errado. Não considero casos em que os próprios organizadores do hackathon não sabem o que querem (eu também vi isso). Mas, via de regra, a empresa que organiza um hackathon persegue seus próprios objetivos. A lista deles pode ser diferente: pode ser uma solução técnica para alguns problemas, uma busca por novas ideias e pessoas, etc. Esses objetivos geralmente determinam o formato do evento, seu momento, online/offline, como as tarefas serão formuladas (e se serão formuladas), se haverá uma revisão de código no hackathon, etc. Tanto as equipas como o que fizeram são avaliados deste ponto de vista. E vencem as equipes que melhor atingirem o ponto que a empresa precisa, e muitos chegam a esse ponto de forma totalmente inconsciente e por acidente, pensando que estão realmente participando de uma competição esportiva. As minhas observações mostram que para motivar os participantes, os organizadores devem criar pelo menos a aparência de um ambiente desportivo e de condições de igualdade, caso contrário receberão uma onda de negatividade, como na análise acima. Mas nós divagamos.
2. Daí a seguinte conclusão. Os organizadores têm interesse em que os participantes venham ao hackathon com seus próprios trabalhos, às vezes até organizam especialmente uma etapa de correspondência online para esse fim. Isso permite soluções de saída mais fortes. O conceito de “trabalho próprio” é muito relativo; qualquer desenvolvedor experiente pode acumular milhares de linhas de código de seus projetos antigos em seu primeiro commit. E este será um desenvolvimento pré-preparado? Mas em qualquer caso, aplica-se a regra que expressei na forma de um famoso meme:
Para vencer, você deve ter algo, algum tipo de vantagem competitiva: um projeto semelhante que você fez no passado, conhecimento e experiência em um tema específico, ou um trabalho pronto feito antes do início do hackathon. Sim, não é esportivo. Sim, pode não valer a pena o esforço despendido (aqui cada um decide por si se vale a pena programar 3 semanas à noite por um prêmio de 100 mil, dividido entre toda a equipe, e mesmo com o risco de não conseguir). Mas, muitas vezes, esta é a única chance de progredir.
3. Seleção da equipe. Como percebi nos chats do hackathon, muitos abordam esse assunto de maneira bastante frívola (embora essa seja a decisão mais importante que determinará seu resultado no hackathon). Em muitas áreas de atividade (tanto no desporto como em hackathons) tenho visto que pessoas fortes tendem a unir-se com os fortes, os fracos com os fracos, os inteligentes com os inteligentes, bem, em geral, já percebeste... Isso é mais ou menos o que acontece nos chats: programadores menos fortes são imediatamente contratados, pessoas que não possuem nenhuma habilidade valiosa para um hackathon ficam no chat por um longo tempo e escolhem uma equipe com base no princípio de que se alguém aceitasse . Em alguns hackathons, é praticada a atribuição aleatória de equipes, e os organizadores afirmam que as equipes aleatórias não têm desempenho pior do que as existentes. Mas, de acordo com minhas observações, pessoas motivadas, via de regra, encontram uma equipe por conta própria; se alguém precisa ser designado, então, muitas vezes, muitos deles não comparecem ao hackathon.
Quanto à composição da equipa, esta é muito individual e altamente dependente da tarefa. Eu poderia dizer que a composição mínima viável da equipe é de designer – front-end ou front-end – back-end. Mas também conheço casos em que venceram equipes formadas apenas por front-enders, que adicionaram um back-end simples em node.js ou fizeram um aplicativo móvel em React Native; ou apenas de backenders que fizeram layout simples. Em geral tudo é muito individual e depende da tarefa. Meu plano para selecionar uma equipe para o hackathon foi o seguinte: planejei montar uma equipe ou ingressar em uma equipe como front-end - back-end - designer (eu também sou front-end). E rapidamente comecei a conversar com um backender python e um designer que aceitou o convite para se juntar a nós. Um pouco mais tarde, uma garota, uma analista de negócios, que já tinha experiência em vencer um hackathon, se juntou a nós, e isso decidiu a questão de ela se juntar a nós. Após uma breve reunião, decidimos nos autodenominar U4 (URBAN 4, urbano quatro) por analogia com o Quarteto Fantástico. E até colocaram uma foto correspondente no avatar do nosso canal de telegramas.
4. Selecionando uma tarefa. Como já falei, você deve ter uma vantagem competitiva, a tarefa do hackathon é selecionada com base nisso. Com base nisso, tendo olhado e avaliando a sua complexidade, decidimos por duas tarefas: um catálogo de empresas inovadoras do DPiIR e um chatbot da EFKO. A tarefa do DPIiR foi escolhida pelo backender, a tarefa do EFKO foi escolhida por mim, pois tinha experiência em escrever chatbots em node.js e DialogFlow. A tarefa EFKO também envolveu ML; tenho alguma experiência, não muito extensa, em ML. E de acordo com as condições do problema, pareceu-me que dificilmente seria resolvido com ferramentas de ML. Esse sentimento foi reforçado quando fui ao encontro do Urban Tech Challenge, onde os organizadores me mostraram um conjunto de dados sobre EFKO, onde havia cerca de 100 fotos de layouts de produtos (tiradas de diferentes ângulos) e cerca de 20 classes de erros de layout. E, ao mesmo tempo, quem encomendou a tarefa queria atingir uma taxa de sucesso de classificação de 90%. Como resultado, preparei uma apresentação da solução sem ML, o backender preparou uma apresentação baseada no catálogo e juntos, após finalizarmos as apresentações, enviamos para o Urban Tech Challenge. Já nesta fase foi revelado o nível de motivação e contributo de cada participante. Nosso designer não participou das discussões, respondeu com atraso e até preencheu informações sobre si mesmo na apresentação no último momento, em geral surgiram dúvidas.
Como resultado, passamos na tarefa do DPiIR e não ficamos nem um pouco chateados por não termos passado no EFKO, já que a tarefa nos parecia estranha, para dizer o mínimo.
5. Preparando-se para o hackathon. Quando finalmente soubemos que estávamos qualificados para o hackathon, começamos a preparar a preparação. E aqui não estou defendendo começar a escrever código uma semana antes do início do hackathon. No mínimo, você deve ter um padrão pronto, com o qual poderá começar a trabalhar imediatamente, sem precisar configurar ferramentas e sem esbarrar em bugs de alguma biblioteca que você decidiu experimentar pela primeira vez em um hackathon. Conheço uma história sobre engenheiros angulares que vieram para um hackathon e passaram 2 dias configurando a construção do projeto, então tudo deve ser preparado com antecedência. Pretendíamos distribuir as responsabilidades da seguinte forma: o backender escreve crawlers que vasculham a Internet e colocam todas as informações coletadas no banco de dados, enquanto eu escrevo uma API em node.js que consulta esse banco de dados e envia os dados para o front. Nesse sentido, preparei previamente um servidor usando express.js e preparei um front-end em reação. Não uso CRA, sempre customizo o webpack para mim e sei muito bem quais riscos isso pode representar (lembre-se da história dos desenvolvedores angulares). Nesse ponto, solicitei templates de interface ou pelo menos maquetes ao nosso designer para ter uma ideia do que estaria traçando. Em teoria, ele também deveria fazer seus próprios preparativos e coordená-los conosco, mas nunca recebi resposta. Como resultado, peguei emprestado o design de um dos meus projetos antigos. E começou a funcionar ainda mais rápido, pois todos os estilos desse projeto já estavam escritos. Daí a conclusão: nem sempre é necessário um designer em uma equipe))). Chegamos ao hackathon com esses desenvolvimentos.
6. Trabalhe no hackathon. A primeira vez que vi minha equipe ao vivo foi apenas na abertura do hackathon no Centro de Distribuição Central. Nos reunimos, discutimos a solução e as etapas de trabalho no problema. E embora depois da inauguração tivéssemos que ir de ônibus até o Outubro Vermelho, voltamos para casa dormir, combinando chegar ao local por volta das 9.00h. Por que? Os organizadores aparentemente queriam tirar o máximo proveito dos participantes, então organizaram exatamente esse cronograma. Mas, na minha experiência, você pode codificar normalmente sem dormir por uma noite. Quanto ao segundo, não tenho mais certeza. Um hackathon é uma maratona, você precisa calcular e planejar adequadamente sua força. Além disso, tivemos preparativos.
Portanto, depois de dormir, às 9.00h estávamos sentados no sexto andar da Dewocracia. Então nosso designer anunciou inesperadamente que não tinha laptop e que trabalharia em casa, e nos comunicaríamos por telefone. Esta foi a gota d’água. E assim passamos de quatro para três, embora não tenhamos mudado o nome do time. Novamente, isso não foi um grande golpe para nós; eu já tinha o design do projeto antigo. Em geral, no início tudo correu bem e conforme o planejado. Carregamos no banco de dados (decidimos usar o neo4j) um conjunto de dados de empresas inovadoras dos organizadores. Comecei a compor, depois comecei a usar o node.js e então as coisas começaram a falhar. Eu nunca tinha trabalhado com neo4j antes e no começo estava procurando um driver funcional para esse banco de dados, depois descobri como escrever uma consulta e fiquei surpreso ao descobrir que esse banco de dados, quando consultado, retorna entidades no forma de uma matriz de objetos de nó e suas arestas. Aqueles. quando solicitei uma organização e todos os dados dela por TIN, em vez de um objeto de organização, recebi uma longa série de objetos contendo dados sobre essa organização e os relacionamentos entre eles. Eu escrevi um mapeador que percorreu todo o array e colou todos os objetos de acordo com sua organização em um único objeto. Mas na batalha, ao solicitar um banco de dados de 8 mil organizações, foi executado de forma extremamente lenta, cerca de 20 a 30 segundos. Comecei a pensar em otimização... E então paramos no tempo e mudamos para o MongoDB, e demoramos cerca de 30 minutos. No total, cerca de 4 horas foram perdidas no neo5j.
Lembre-se, nunca leve tecnologia para um hackathon com o qual você não esteja familiarizado, pois pode haver surpresas. Mas, no geral, tirando esse fracasso, tudo correu conforme o planejado. E já na manhã do dia 9 de dezembro tínhamos um aplicativo totalmente funcional. Durante o resto do dia planejamos adicionar recursos adicionais a ele. No futuro, tudo correu relativamente bem para mim, mas o backender teve um monte de problemas com o banimento de seus crawlers em buscadores, no spam de agregadores de pessoas jurídicas, que ocupavam os primeiros lugares dos resultados de busca ao solicitar para cada empresa específica. Mas é melhor que ele mesmo conte sobre isso. O primeiro recurso adicional que adicionei foi a pesquisa por nome completo. Diretor Geral do VKontakte. Demorou várias horas.
Assim, na página da empresa em nosso aplicativo apareceu um avatar do diretor geral, um link para sua página VKontakte e alguns outros dados. Foi uma bela cereja no bolo, embora possa não ter nos dado a vitória. Então, eu queria fazer algumas análises. Mas depois de uma longa busca de opções (havia muitas nuances com a IU), decidi pela agregação mais simples de organizações por código de atividade econômica. Já à noite, nas últimas horas, estava traçando um template para exibição de produtos inovadores (em nosso aplicativo deveria haver uma seção de Produtos e Serviços), embora o backend não estivesse preparado para isso. Ao mesmo tempo, o banco de dados cresceu aos trancos e barrancos, os rastreadores continuaram a funcionar, o backender experimentou PNL para distinguir textos inovadores de não inovadores))). Mas o momento da apresentação final já se aproximava.
7. Apresentação. Pela minha própria experiência, posso dizer que você deve passar a preparar uma apresentação cerca de 3 a 4 horas antes do prazo. Principalmente se envolver vídeo, sua filmagem e edição demoram bastante. Deveríamos ter um vídeo. E tivemos uma pessoa especial que tratou disso e também resolveu uma série de outras questões organizacionais. Nesse sentido, não nos distraímos da codificação até o último momento.
8. Arremesso. Não gostei que as apresentações e finais fossem realizadas em outro dia da semana (segunda-feira). Aqui, muito provavelmente, a política dos organizadores de extrair o máximo dos participantes continuou. Não planejei tirar folga do trabalho, só queria ir para a final, embora o resto da minha equipe tenha tirado o dia de folga. Porém, a imersão emocional no hackathon já era tão grande que às 8h escrevi no chat da minha equipe (a equipe de trabalho, não a equipe do hackathon) que estava tirando o dia às minhas custas, e fui para a central escritório para arremessos. Descobrimos que nosso problema tinha muitos cientistas de dados puros, e isso afetou muito a abordagem para resolver o problema. Muitos tinham um bom DS, mas ninguém tinha um protótipo funcional, muitos não conseguiam contornar as proibições de seus rastreadores nos motores de busca. Éramos a única equipe com um protótipo funcional. E sabíamos como resolver o problema. No final, vencemos a pista, embora tenhamos tido muita sorte por termos escolhido a tarefa menos competitiva. Olhando os arremessos de outras pistas, percebemos que ali não teríamos chance. Também quero dizer que tivemos muita sorte com o júri: eles verificaram meticulosamente o código. E, a julgar pelos comentários, isso não aconteceu em todas as faixas.
9. Final. Depois de termos sido chamados várias vezes ao júri para uma revisão do código, nós, pensando que finalmente havíamos resolvido todos os problemas, fomos almoçar no Burger King. Lá os organizadores nos chamaram novamente, tivemos que embalar rapidamente nossos pedidos e voltar.
O organizador nos mostrou em qual sala precisávamos entrar e, ao entrar, nos encontramos em um treinamento de oratória para as equipes vencedoras. Os caras que deveriam se apresentar no palco estavam bem carregados, todos saíram como verdadeiros showmen.
E devo admitir que na final, tendo como pano de fundo as equipes mais fortes de outras pistas, parecíamos pálidos: a vitória na indicação de cliente governamental foi merecidamente para a equipe da pista de tecnologia imobiliária. Acho que os principais fatores que contribuíram para a nossa vitória na pista foram: a disponibilidade de um blank pronto, com o qual conseguimos fazer um protótipo rapidamente, a presença de “destaques” no protótipo (busca de CEOs nas redes sociais) e as competências em PNL do nosso backender, que também interessaram muito ao júri.
E para finalizar, o tradicional agradecimento a todos aqueles que nos apoiaram, ao júri da nossa pista, Evgeniy Evgrafiev (autor do problema que resolvemos no hackathon) e claro aos organizadores do hackathon. Este foi talvez o maior e mais legal hackathon do qual já participei, só posso desejar que a galera mantenha um padrão tão alto no futuro!
Fonte: habr.com