Oi Após um longo intervalo, decidimos voltar a Habr e queremos compartilhar a experiência de participar do hackathon. Em setembro, Moscou recebeu o
Diversity.Hack , cujos parceiros eram Dostavista, Waves e nós, New Cloud Technologies. A participação em um hackathon organizado pela Phystech.Genesis, um projeto da MIPT Business Incubator, foi a primeira e ao mesmo tempo uma experiência bem-sucedida de nossa empresa. Mas não vamos nos antecipar - vamos ver como tudo correu e que coisas interessantes os participantes conseguiram criar.
Como foi Diversity.Hack
208 pessoas de 44 equipes se reuniram para o hackathon no coworking GrowUp, que foi um recorde para os organizadores. Sobre como as equipes foram formadas, detalhes podem ser encontrados no
artigo da Phystech.Genesis. Os participantes resolveram uma das três tarefas propostas para cada empresa um pouco mais de um dia, tendo a oportunidade de passar a noite no local e com a comida dos organizadores. O fundo de prêmios de 300.000 rublos foi dividido igualmente entre as faixas. Além de gerar idéias e codificação, os participantes podem participar intensivamente de
como ganhar em hackathons .
No início do evento, todas as empresas parceiras descreveram as condições de suas tarefas - antes disso, apenas palavras gerais e um conjunto de tecnologias que os participantes tinham que usar eram conhecidos. As equipes distribuíram o tempo para o desenvolvimento do protótipo a seu critério, levando em consideração os
principais pontos : análise do mercado de idéias existentes, tempestade cerebral, determinação das principais características do protótipo, papéis dentro da equipe e codificação.
Entre os participantes estavam estudantes e especialistas experientes, caras muito promissores se encontraram. Como resultado, nós e outras empresas parceiras conseguimos desenhar novas idéias. Por exemplo, a Waves propôs o desenvolvimento de um aplicativo móvel usando a linguagem Ride e a Plataforma Waves. Para o serviço de entrega da Dostavista, as equipes desenvolveram um sistema para otimizar rotas de correio.
Sob a orientação de nossos colegas da New Cloud Technologies, foi necessário criar uma ferramenta conveniente (algoritmo, interface do usuário) para analisar alterações nos documentos ao comparar duas ou mais versões.
Por que exatamente essa tarefa?
Desde 2013, nossa empresa desenvolve o
MyOffice , um conjunto de aplicativos de escritório que são executados em todos os principais sistemas operacionais, incluindo dispositivos móveis. Inicialmente, tínhamos 7-8 opções de trabalho e, para escolher uma para a hackathon, até fizemos uma votação privada dentro da empresa. Entre as opções, por exemplo, comparar dois ou mais documentos (desenvolvimento da própria tecnologia e UX), comparação automatizada da qualidade da renderização de documentos (usando o exemplo de exportação para PDF de dois editores diferentes), havia também uma ideia relacionada à análise de fontes em um documento. Também queríamos dar uma tarefa para coletar informações de bate-papos sobre datas de reuniões para sua adição automática ao calendário do smartphone (interessante, por exemplo, para escrever bots no Telegram) e várias outras.
Como resultado, decidimos comparar dois ou mais documentos. Globalmente, a idéia é que, usando um pacote de escritório em seu computador, diferentes funcionários possam fazer suas próprias alterações no mesmo arquivo de origem. Você precisa criar uma tecnologia que permita comparar confortavelmente várias versões do mesmo documento e aceitar uma das edições propostas. As edições ainda precisam ser verificadas quanto à contradição umas com as outras, após as quais um único documento final será obtido.
Parece que essa tarefa pode ser relevante? Agora estão disponíveis várias nuvens nas quais todo o histórico de alterações é exibido - quem editou o quê e quando. No entanto, muitas empresas não permitem que documentos sejam armazenados na nuvem por motivos de segurança. Por esse ou qualquer outro motivo, as edições no arquivo podem ser feitas offline, sem o uso de uma nuvem, e então essa ou aquela versão do documento geralmente é enviada aos colegas por correio. As edições podem ser feitas por mais de uma pessoa e, como resultado das versões de documentos, são tantas as que inevitavelmente surgem confusão.
Portanto, somos confrontados com a necessidade de usar uma ferramenta para comparar simultaneamente mais de dois documentos. Mas azar! Simplesmente não havia soluções para esse problema no mercado, existem apenas serviços para comparar dois documentos e a opção existente não brilha com variedade. Portanto, existe o ABBYY Comparator, que pode comparar documentos não apenas em formato de texto, mas também em PDF, digitalizações e fotos. A desvantagem de usar este serviço pode ser seu custo. Outro serviço é o Text Compare! - e similares permitem que você insira texto em duas janelas especiais. E isso limita bastante as possibilidades - nem mesmo os arquivos podem ser baixados, mas apenas
Ctrl + C e
Ctrl + V !
Nossa empresa decidiu buscar uma cura para a “dor” de desenvolvedores talentosos de toda a Rússia, removendo a restrição no formato do documento. Propusemos o uso de html familiar - a estrutura em árvore do documento é convenientemente representada nele. Todos os participantes responderam a esta oferta. Estávamos interessados em obter a própria tecnologia de comparação, bem como uma interface conveniente e interativa.
Decisões da equipe vencedora
Em Habré, existem muitos artigos para entrevistas sobre como os participantes construíram um fluxo de trabalho durante um hackathon, como eles conseguiram vencer. Oito equipes resolveram o nosso problema, três dos quais ganharam prêmios: o primeiro recebeu o
ZenDocs , o segundo foi compartilhado pelo
SerotoninMix e
SegFault . Escolhemos os vencedores de acordo com os seguintes critérios: facilidade de uso da interface do usuário (sua interatividade e minimalismo), a qualidade dos vários casos dessa interface (como será a comparação das tabelas - alterações estruturais e de texto dentro, diagramas, imagens), o próprio algoritmo de comparação (complexidade de tempo capacidade de reconhecer diferentes tipos de edições). Um bom protótipo de trabalho foi considerado uma grande vantagem :)
As soluções de interface para a maioria das equipes se mostraram bastante semelhantes. Talvez isso sugira que as interfaces sejam amigáveis ao usuário se todos os desenvolvedores tiverem a mesma coisa. O detalhamento dos casos personalizados e a qualidade do protótipo diferiam - alguém conseguiu fazer mais, alguém menos.
No entanto, após a apresentação das soluções, o favorito foi claramente definido - acabou sendo a equipe do
ZenDocs , que enfatizou a parte algorítmica. Eles conduziram um estudo eficaz das abordagens disponíveis e
encontraram um artigo científico com um algoritmo para comparar árvores xml. Esse algoritmo se adapta bem a N documentos: se você comparar documentos em pares, como muitos outros algoritmos, a complexidade aumentará polinomialmente no número de documentos e, com essa abordagem, aumentará linearmente. O algoritmo retorna o ID dos elementos da árvore que foram alterados e o tipo de alteração é inserir, excluir, substituir.
É conveniente fornecer esse formato de resposta ao frontend - você não precisa processá-lo ainda mais. Imagens, linhas e colunas da tabela são blocos estruturais comuns de um documento, o mesmo que parágrafos; portanto, esse algoritmo permite detectar alterações na imagem, na estrutura da tabela ou em seu conteúdo, ou seja, ele lida com muitos casos de usuários, e esse é um critério de avaliação importante. A equipe propôs uma otimização adicional do algoritmo usando a árvore Merkle. Essa otimização permitirá verificar apenas as subárvores para as quais o hash foi alterado, o que acelera o algoritmo. O protótipo está disponível em:
https://zendocs.ruEscolher o segundo e o terceiro lugares foi mais difícil, porque três decisões dignas os reivindicaram. No final, decidimos pelo SerotoninMix e SegFault. Alguns deles eram melhores para interatividade, outros para navegação, e esta é uma situação normal: em dois dias é difícil desenvolver uma solução ideal. Algumas equipes implementaram quase completamente o algoritmo em um modelo simples, entre elas ZenDocs e SerotoninMix.
Nós destacamos o último, inclusive por sua abordagem criativa - apreciamos seu humor (eles chamaram seu projeto de “escritório NeMoy” e houve muitos momentos divertidos em sua apresentação) e ficamos impressionados com o fato de terem conseguido criar um protótipo completo.
Os caras da SegFault encontraram uma abordagem muito original. Ao desenvolver o protótipo, eles usaram o
Vue.js ; o servidor foi escrito em Python usando os algoritmos
Flask e
Docker ,
Word2Vec e
Crochemore . Depois de revisar um pouco os algoritmos, os participantes compararam o documento principal com todos os outros, destacando as partes comuns e diferentes. No ambiente criado, há um bloco de edição em que fragmentos de diferentes documentos são exibidos. Você pode selecionar um deles e editá-lo, se necessário. No painel de controle, você pode aceitar a edição ou exibir as aceitas anteriormente. A equipe também comparou imagens, comparando-as como
codificadas em
base64 e convertendo a imagem em formato
base64 , e elaborou um método de comparação de tabelas e exibição de alterações nelas.
Havia poucos designers no hackathon, e nossa tarefa para uma grande porcentagem consistia em criar protótipos da interface e criar layouts, que envolviam o uso de ferramentas como Sketch e Figma. A equipe Talestorm afundou em nossos corações, um dos participantes aprendeu a trabalhar do zero durante toda a noite.
Interação pós-hackathon
No final de setembro, ocorreu uma reunião de vencedores, representantes da New Cloud Technologies, incluindo o CEO
Dmitry Komissarov e Phystech.Genesis. Na reunião, eles discutiram as tarefas da empresa, nas quais os vencedores do hackathon podem participar. Estamos ansiosos para trabalhar com equipes!
