Meu nome é Dmitry. E quero falar sobre como nossa equipe chegou à final do hackathon do Urban Tech Challenge na pista de Big Data. Devo dizer imediatamente que este não é o primeiro hackathon em que participei, e não o primeiro em que ganho prêmios. A esse respeito, na minha história, quero expressar algumas observações e conclusões gerais sobre o setor de hackathon como um todo e dar meu ponto de vista, em oposição às críticas negativas que apareceram na rede logo após o final do Urban Tech Challenge (por exemplo,
este ).
Então, primeiro, algumas observações gerais.
1. É surpreendente que muitas pessoas pensem ingenuamente que um hackathon é um tipo de competição esportiva onde os melhores programadores vencem. Isto não é verdade. Não considero casos em que os próprios organizadores do hackathon não sabem o que querem (vi isso também). Mas, como regra, uma empresa que organiza um hackathon persegue seus objetivos. A lista deles pode ser diferente: pode ser uma solução técnica para alguns problemas, a busca de novas idéias e pessoas, etc. Esses objetivos geralmente determinam o formato do evento, seu horário, online / offline, como as tarefas serão formuladas (e se serão ou não formuladas), se haverá uma revisão de código no hackathon, etc. As equipes e o que eles fizeram são avaliadas precisamente desse ponto de vista. E as equipes que melhor alcançam o ponto necessário pela empresa vencem e muitas chegam a esse ponto completamente inconscientemente e acidentalmente, pensando que realmente participam de uma competição esportiva. Minhas observações mostram que, para motivar os participantes, os organizadores devem criar pelo menos a aparência de um ambiente esportivo e de igualdade de condições; caso contrário, eles receberão uma onda de negatividade, como na revisão acima. Mas nós nos perdemos.
2. Daí a seguinte conclusão. Os organizadores estão interessados nos participantes que chegam ao hackathon com suas próprias idéias, às vezes até um estágio de correspondência on-line é especialmente organizado para isso. Isso permite soluções de saída mais fortes. O conceito de "seu próprio trabalho" é muito relativo; qualquer programador experiente pode acumular milhares de linhas de código de seus projetos antigos no primeiro commit. E será um tempo de operação pré-preparado? Mas, em qualquer caso, a regra se aplica, que eu expressei na forma de um meme famoso:
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 tópico específico ou trabalho já concluído antes do início do hackathon. Sim, não é esporte. Sim, isso pode não compensar o esforço (aqui todos decidem codificar três semanas à noite por um prêmio de 100 mil, dividido por toda a equipe, e mesmo com o risco de não conseguir). Mas, muitas vezes, essa é a única chance de avançar.
3. Seleção da equipe. Como observei nos bate-papos do hackathon, muitas pessoas encaram esse problema com leviandade (embora essa seja a decisão mais importante que determinará seu resultado no hackathon). Em muitos campos de atividade (tanto nos esportes quanto nos hackathons), vi que pessoas fortes tendem a se unir com pessoas fortes, pessoas fracas com pessoas fracas, pessoas inteligentes com pessoas inteligentes, bem, em geral, você entende ... É o que acontece nas salas de bate-papo: programadores mais ou menos fortes imediatamente, as pessoas que não possuem nenhuma habilidade valiosa de hackathon ficam no bate-papo por um longo tempo e escolhem uma equipe de acordo com o princípio, se apenas alguém aceitou. Em algumas hackathons, a distribuição aleatória entre as equipes é praticada, e os organizadores afirmam que as equipes aleatórias mostram o resultado não pior do que as já estabelecidas. Mas, de acordo com minhas observações, as pessoas motivadas, via de regra, encontram a equipe em si, se alguém tiver que ser distribuído, muitas vezes muitas delas não vão ao hackathon.
Quanto à composição da equipe, é muito individual e altamente dependente da tarefa. Eu poderia dizer que a equipe mínima viável é um designer - front-end ou front-end - back-end. Mas também conheço casos em que equipes compostas apenas por front-end venceram, que anexaram um back-end simples ao node.js ou criaram um aplicativo móvel no React Native; ou apenas de beckenders que fizeram um layout simples. Em geral, tudo é muito individual e depende da tarefa. Meu plano para selecionar uma equipe para o hackathon era o seguinte: planejava montar uma equipe ou ingressar em uma equipe como designer de front-end-back-end (estou na frente). E rapidamente ele começou a conversar com um back-end python e um designer que aceitou o convite para se juntar a nós. Um pouco mais tarde, uma analista de negócios se juntou a nós, que já tinha a experiência de ganhar o hackathon, e isso resolveu o problema dela se juntar a nós. Após uma breve reunião, decidimos nos chamar U4 (URBAN 4, quatro urbanos) semelhantes aos quatro fantásticos. E eles até colocaram uma imagem correspondente no nosso canal de telegrama.
4. Escolha da tarefa. Como eu disse, você deve ter uma vantagem competitiva, a tarefa do hackathon é escolhida com base nisso. Procedendo a isso, analisando a
lista de tarefas e avaliando sua complexidade, decidimos em duas tarefas: um catálogo de empresas inovadoras do DPiIR e um bot de bate-papo da EFKO. A tarefa do Instituto de Desenvolvimento Industrial e Industrial foi escolhida pelo backender, a tarefa da EFKO foi escolhida por mim, porque teve experiência em escrever chatbots em node.js e DialogFlow. A tarefa da EFKO também envolveu ML, tenho alguma experiência, não muito grande, em ML. E de acordo com as condições do problema, pareceu-me que dificilmente era resolvido por meio do ML. Esse sentimento foi fortalecido quando fui à reunião do Urban Tech Challenge, onde os organizadores me mostraram um conjunto de dados da EFCO, 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, os clientes da tarefa desejavam uma taxa de sucesso na classificação de 90%. Como resultado, eu preparei a apresentação da solução sem ML, o backender preparou a apresentação de acordo com o catálogo e, juntos, depois de finalizadas as apresentações, as enviamos para o Urban Tech Challenge. Já nesta fase, o nível de motivação e contribuição de cada participante foi revelado. Nosso designer não participou das discussões, respondeu tardiamente e até mesmo preencheu informações sobre si mesmo na apresentação no último momento, em geral surgiram dúvidas.
Como resultado, realizamos a tarefa do Departamento de Construção e Design e não ficamos aborrecidos com o fato de não termos passado pela EFKO, pois a tarefa nos parecia, para dizer o mínimo, estranha.
5. Preparação para o hackathon. Quando finalmente se soube que fomos ao hackathon, começamos a preparar a peça. E aqui não peço que você comece a escrever código uma semana antes do início do hackathon. No mínimo, você deve ter um clichê pronto, com o qual possa trabalhar imediatamente sem precisar ajustar as ferramentas e sem esbarrar em bugs de qualquer tipo que decida tentar pela primeira vez em um hackathon. Conheço uma história sobre pescadores que vieram para o hackathon e passaram dois dias montando a montagem do projeto, então tudo deve ser preparado com antecedência. Deveríamos distribuir as tarefas da seguinte maneira: o bekender grava rastreadores que varrem a Internet e colocam todas as informações coletadas no banco de dados, escrevo a API no node.js, que solicita esse banco de dados e envia os dados para a frente. Nesse sentido, preparei o servidor com antecedência no express.js e preparei o frontend no react. Não uso o CRA, sempre personalizo o webpack para mim e sei muito bem quais riscos isso pode acarretar (lembramos da história sobre pescadores). Nesse momento, solicitei os espaços em branco da interface, ou pelo menos modelos do nosso designer, para ter uma idéia do que eu imporia. Em teoria, ele também deveria fazer seus preparativos e coordená-los conosco, mas nunca recebi uma resposta. Como resultado, peguei emprestado o design de um dos meus projetos antigos. E assim começou a ficar ainda mais rápido, pois todos os estilos desse projeto já estavam escritos. Daí a conclusão: o designer nem sempre é necessário na equipe))). Com esses desenvolvimentos, chegamos ao hackathon.
6. Trabalhe no hackathon. Vi minha equipe pela primeira vez apenas na abertura do hackathon no CDP. Nós nos conhecemos, discutimos a solução e as etapas do trabalho na tarefa. E embora, depois da abertura, tivéssemos que pegar ônibus para o Outubro Vermelho, voltamos para casa para dormir, depois de concordar em chegar a nossa casa às 9 horas. Porque Os organizadores, aparentemente, queriam tirar o máximo proveito dos participantes, então organizaram exatamente esse cronograma. Mas, na minha experiência, você normalmente pode codificar sem dormir uma noite. Quanto ao segundo, não tenho mais certeza. Hackathon é uma maratona, você precisa calcular e planejar adequadamente sua força. Além disso, tínhamos espaços em branco.
Portanto, depois de dormir, às 21h, estávamos sentados no sexto andar da Dewocracia. Então, nosso designer anunciou inesperadamente que não tinha laptop, que trabalharia em casa e que nos comunicaríamos por telefone. Esta foi a última gota. E assim passamos das quatro para as três, apesar de não termos mudado o nome da equipe. Novamente, isso não se tornou um golpe forte para nós, eu já tinha o design do projeto antigo. Em geral, no início, tudo correu bem e de acordo com o plano. Fizemos o upload de um conjunto de dados de empresas inovadoras dos organizadores no banco de dados (decidimos usar o neo4j). Comecei a digitar, depois assumi o node.js e os erros ocorreram. Eu nunca havia trabalhado com o neo4j antes, e primeiro procurei um driver funcional para esse banco de dados, depois descobri como a consulta é escrita e fiquei surpreso ao descobrir que esse banco de dados retorna entidades quando solicitadas, como uma matriz de objetos de nó e suas bordas. I.e. quando solicitei a organização pelo TIN e todos os dados contidos nele, em vez de um único objeto da organização, retornei uma longa variedade de objetos contendo dados sobre essa organização e o relacionamento entre eles. Escrevi um mapeador que percorreu toda a matriz e colou todos os objetos da organização em um único objeto. Mas na batalha, ao consultar um banco de dados de 8.000 organizações, ficou extremamente lento por cerca de 20 a 30 segundos. Pensei em otimização ... E então paramos a tempo e nos mudamos para o MongoDB, e levamos cerca de 30 minutos. No total, foram perdidas cerca de 5 horas no neo4j.
Lembre-se, nunca use uma tecnologia hackathon com a qual você não esteja familiarizado, pois pode haver surpresas. Mas, em geral, além desse fracasso, tudo correu conforme o planejado. E já na manhã de 9 de dezembro, tínhamos um aplicativo totalmente funcional. Durante o resto do dia, planejamos incluir recursos adicionais. No futuro, tudo correu relativamente bem, mas o bekender teve um monte de problemas com a proibição de seus rastreadores nos mecanismos de pesquisa, no spam de agregadores de entidades legais, que surgiram nos primeiros locais de resultados de pesquisa ao solicitar para cada empresa específica. Mas sobre isso ele dirá melhor. O primeiro recurso adicional que eu estraguei é uma pesquisa por nome completo CEO VKontakte. Demorou várias horas.
Então, na página da empresa em nosso aplicativo, apareceu o ava do diretor geral, um link para sua página VK e alguns outros dados. Foi uma boa cereja no bolo, embora possa não ter nos garantido uma vitória. Então, eu queria terminar algumas análises. Mas, após uma longa pesquisa de opções (havia muitas nuances com a interface do usuário), ele optou pela agregação mais simples de organizações por código de atividade econômica. Já à noite, nas últimas horas, eu estava preenchendo um espaço em branco para exibir produtos inovadores (a seção Produtos e serviços é suposta em nosso aplicativo), embora o back-end para isso não estivesse pronto. A base ao mesmo tempo estava inchada aos trancos e barrancos, os rastreadores continuaram trabalhando, o back-end experimentou a PNL para distinguir textos inovadores de textos não inovadores))). Mas já era hora da apresentação final.
7. Apresentação. Pela minha própria experiência, posso dizer que você deve começar a preparar uma apresentação em algum lugar 3-4 horas antes da entrega. Especialmente se o vídeo deveria estar nele, filmar e editar leva muito tempo. Deveríamos ter um vídeo. E tínhamos uma pessoa especial envolvida nisso e também resolvemos várias outras questões organizacionais. Nesse sentido, até o último momento, não estávamos distraídos da codificação.
8. Passo. Não gostei que as apresentações e a final fossem feitas em outro dia da semana (segunda-feira). Aqui, provavelmente, os organizadores continuaram a política de extrair o máximo dos participantes. Não planejava tirar folga do trabalho, queria chegar apenas à final, embora o restante da minha equipe tenha passado um fim de semana. No entanto, a imersão emocional no hackathon já era tão alta que, às 8 da manhã, escrevi para o bate-papo da minha equipe (trabalhando, não para o hackathon) que aproveitei o dia às minhas próprias custas e fui ao CDC para arremessos. Nosso problema acabou por ser muitos dados puros dos cientistas e isso afetou bastante a abordagem para resolvê-lo. 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 mecanismos de busca. Nós éramos a única equipe com um protótipo funcional. E sabíamos como resolver a tarefa. No final, vencemos a pista, embora tenhamos muita sorte de ter escolhido a tarefa menos competitiva. Olhando para os arremessos em outras faixas, percebemos que não teríamos chance lá. Eu também quero dizer que tivemos muita sorte com o júri, eles meticulosamente verificaram o código. E, a julgar pelas críticas, isso estava longe de acontecer em todas as faixas.
9. final. Depois de sermos chamados ao júri várias vezes para uma revisão do código, pensamos que finalmente havíamos resolvido todos os problemas e fomos jantar no Burger King. Lá, os organizadores nos ligaram novamente, tivemos que embalar pedidos às pressas e voltar.
O organizador mostrou em que sala entrar e, indo para lá, nos encontramos em um treinamento de falar em público para as equipes vencedoras. Os caras que deveriam se apresentar no palco estavam bem carregados, todos saíram como showmen de verdade.
E devo admitir que, na final, contra o pano de fundo das equipes mais fortes de outras pistas, parecíamos pálidas, a vitória na nomeação do cliente do estado merecidamente deixou a equipe do setor de tecnologia da pista. Eu acho que os principais fatores que contribuíram para a nossa vitória na pista foram: a disponibilidade de um espaço em branco pronto, devido ao qual pudemos criar rapidamente um protótipo, a presença de "destaques" no protótipo (procurar diretores gerais em redes sociais) e as habilidades de PNL de nosso back-end que também estão muito interessados no júri.
E, em conclusão, agradecimentos tradicionais a todos que nos apoiaram, ao júri de nossa pista, Evgeny Evgrafiev (o autor da tarefa que resolvemos no hackathon) e, é claro, aos organizadores do hackathon. Este foi talvez o maior e mais legal hackathon de todos os quais participei, resta apenas desejar que os caras mantenham uma marca tão alta e muito mais!