No reino de Far Far Away ... Comecei minha história sobre o hackathon em Wrike, porque o Hackathon é como um conto de fadas: entusiastas se reúnem para dar vida a suas idéias. Uma idéia está sendo lançada, como uma flecha fabulosa, e então ela pode cair no quintal do boiardo ou desaparecer no pântano da vida cotidiana. E, como em um conto de fadas, é sempre emocionante. Não é fácil montar uma equipe em muito pouco tempo, transformar um produto em uma idéia e até mostrá-lo de forma que pessoas honestas o surpreendam.
Mas, falando sério, quero compartilhar a experiência de participar do hackathon, onde desenvolvemos nossa realidade aumentada (AR). Vou falar sobre como tentamos encontrar um AR SDK pronto para a nossa tarefa, mas não conseguimos. Como resultado, eles decidiram escrever AR eles mesmos e acabou.
O ditado
Eu realmente amo hackathons: participei de várias, tive que fazer isso sozinho e, se possível, participarei.
Hackathons geralmente são mantidos por organizações específicas, e isso funciona para a marca de RH da empresa. Os objetivos podem ser diferentes: uma história sobre uma empresa ou produto, contratar um grau variável de agressividade, organizar uma comunidade temática, procurar novas idéias (
apesar dos exércitos de seus próprios especialistas em produtos, pode ser útil obter um monte de idéias de sonhadores com uma visão clara da área de atuação ), etc. d.
Para os participantes, esta é uma oportunidade de se familiarizar com a empresa, porque muitas vezes um hackathon é o seu reflexo, e a partir disso é possível tirar conclusões sobre a cozinha interna. Para entender os processos da empresa, você pode ver como ele organiza o hackathon: quais são as restrições para os projetos que participam do hackathon (
escopo de tarefas, área de assunto, tecnologia, ferramentas, etc. ); nível do evento; critérios e transparência da parte competitiva; arbitragem - composição e qualidade; Quais são as regras e métodos para formar equipes. Em geral, as empresas são divididas entre aqueles que realizam hackathons (
internos ou públicos ) e aqueles que não realizam. Eu prefiro quem gasta, porque estas são empresas mais abertas.
Eu próprio vou a hackathons não por vitória, mas por participação. Eu estou pensando:
- Experimente novas tecnologias. Em um hackathon de "comida", pegamos o Flutter e escrevemos um aplicativo para ios e android. Embora nenhum de nós tenha experimentado Flutter antes, sabíamos como dardo .
- Para conhecer e trabalhar com novas pessoas , então, depois de um dos hackathons da “cidade”, chamei um cúmplice do projeto hackathon para trabalhar em minha equipe para o trabalho principal, do qual nunca me arrependi. Hackathon é uma ótima maneira de testar um camarada em ação.
- Para fazer algo que eu realmente preciso. No hackathon interno, eles cortaram o aplicativo, que foi usado no trabalho.
- Apenas obtenha emoções positivas da criação. Eu realmente gosto da atmosfera hackathon!
Portanto, estou feliz em participar dos hackers de wrike (
este ano foi o terceiro hackathon interno ), onde criamos e aprimoramos ainda mais o wrike: alguns dos projetos anteriores de hackathon já vivem em nosso produto e outros estão nos backlogs de equipes. A escala também é inspiradora, apesar do hackathon ser interno, cerca de 30 equipes são recrutadas (
mais de 100 pessoas ) - todas com novas idéias legais.
No hackathon de 2018, decidi tentar trabalhar com o
AR . No
MVP, eu queria fazer tarefas irregulares (
nome, status, artistas etc. ) exibidas na tela de um telefone celular quando você passa o mouse sobre um código gráfico com o identificador de tarefa criptografado e também adiciona a capacidade de alterar o status e atribuir / remover tarefas de si mesmo. Há uma ideia, há um hackathon, a equipe também não se envolveu. No dia marcado, tudo mudou.
Eu perguntei cinza
Não me preparo particularmente para hackathons em termos de configuração do ambiente (
pesquisando SDKs e estruturas; instalando software; configurando etc. ), escrevendo código com antecedência etc., mas apenas elaborando idéias, recursos e pensando no que fazer em que ordem etc. Portanto, a equipe consultou e decidiu que escreveríamos em Java (eles escrevem
nativamente para Android ), e havia uma hipótese de que provavelmente havia muitas bibliotecas AR prontas. Nosso plano: pegue um SDK conveniente, adicione a
API do
Wrike e, em seguida, concentre-se em escrever a lógica do nosso aplicativo. Portanto, nossa primeira tarefa foi encontrar um Java AR SDK conveniente, que permite:
- Desenhe algo em uma determinada superfície virtual.
- Integrar / já contém um scanner de elementos gráficos dinâmicos ( código de barras, QR, etc. ).
- Trabalhe com um limiar baixo ( estamos no hackathon, precisamos rapidamente ): há uma demonstração, há documentação, há uma versão gratuita / de teste.
Parece uma tarefa bastante simples. E começamos a classificar as opções com base em artigos como "
Top SDK de realidade aumentada em 2018 "
Primeiro, analisamos o Google. Eles abriram o "
Início Rápido ", fizeram tudo de acordo com as instruções, o lançaram e eis que tudo funciona: os Androids aparecem na minha mesa, que também podem ser movidos. A sensação de que encontramos a "base" para a nossa aplicação. Mas, depois do desapontamento, o
reconhecimento de imagem não funciona como precisamos: só pode haver uma imagem, ela deve estar claramente visível e deve ser do banco de dados de imagens conhecidas anteriormente (
e precisamos ter nosso próprio marcador exclusivo para cada tarefa ). E o mais triste é a incapacidade de controlar o foco, e é por isso que capturar a imagem que precisamos para reconhecimento se torna uma tarefa difícil para o usuário. É verdade que o
problema agora foi
resolvido com foco, mas tivemos que continuar a pesquisa. Em geral, o Google acabou sendo bom, mas não para a nossa tarefa. E também devido às especificidades do OpenGL no OSX, não conseguimos que a demo funcionasse no emulador e fizemos tudo em um telefone ao vivo.
Lemos a documentação, assistimos aos
vídeos , parece impressionante. Existem muitos recursos, por exemplo,
Destinos de imagem . Decidimos tentar: registrado, baixado, coletado, lançado. O aplicativo demo foi iniciado, mas não funcionou no emulador ou no android-e ao vivo. A tentativa de testar qualquer recurso travou o aplicativo inteiro. Foi decidido não perder tempo pesquisando o problema e corrigindo-o, passando para o próximo SDK.
Baixamos o SDK, passamos pelo
tutorial , lançamos a demo. Existem muitas possibilidades, a demo é imediatamente impressionante, vários exemplos de mini-play, nós tocamos o suficiente (
por exemplo, há reconhecimento facial ) e, e eis que a demo já tem reconhecimento QR. Mas o problema é que obtemos o que está criptografado no código, mas não sabemos onde ele está localizado. Eles começaram a entender como o scanner QR é organizado. Aconteceu que ele foi criado como um complemento sobre o
ZBar na forma de um plug-in positivo para SDK. No começo, tive a ideia maluca de descobrir o gcc e finalizar o plug-in para que ele também desse as coordenadas, mas paramos a tempo.
E eles lutaram 3 dias e 3 noites
Percebendo que boa parte do tempo alocado para o dia está atrasado, e ainda estamos procurando nosso SDK (havia
amostras de outras soluções, não apenas descritas acima, mas também um fiasco lá ), decidimos não procurar mais a “bala de prata”, mas levar tudo para suas mãos. Um novo plano amadureceu: como marcador de tarefa, adotamos um código QR, simples e comum; para seu reconhecimento, usamos o
ZXing , que pode reconhecer vários códigos ao mesmo tempo e, além do valor, a biblioteca também fornece as coordenadas de 3 pontos de "pesquisa" do código QR. E então, em cima do leitor de código, implementaremos nosso AR. Arregace as mangas e vá, temos 3 pontos, o que significa que, com a ajuda de transformações afins, podemos obter tudo o que precisamos.
Eles não começaram a procurar uma biblioteca de matemática, pois nossa tarefa não é difícil. A primeira coisa que fizemos foi criar nossa própria classe para as coordenadas que precisamos recalcular. O algoritmo final para trabalhar com o código QR acabou sendo bastante primitivo:
- A imagem da câmera é transferida para o ZXing, obtemos uma matriz com as coordenadas dos pontos e os valores do código QR.
- A partir das 3 coordenadas, calculamos o quarto canto do quadrado, aumentamos o quadrado uma vez e meia para sobrepor o código QR original e obtemos a base para o cartão.
- Solicitamos na API do Wrike para coletar dados sobre a tarefa.
- Desenhamos um cartão, graças a transformações afins, salvamos todas as distorções ( ângulo de visão, rotação, escala ).
Reduzimos o algoritmo, ele funciona, testamos, lidamos com vazamentos de memória, adicionamos efeitos visuais, gostamos do hackathon.
E eu estava lá, bebi cerveja de mel
No hackathons, além do próprio produto, a maneira como você o apresenta é muito importante. Todo mundo entende que você tem prazos muito apertados e não espera uma solução tecnicamente bonita, então você precisa mostrar a beleza de sua ideia. Eu sempre gosto da abordagem de contar histórias, onde o público entende para quem o produto é produzido, em que condições é aplicado e que problema resolve.
Portanto, em nossa apresentação, além de demonstrar a funcionalidade obtida, apelamos ao poder da imaginação e descrevemos situações em que essa realidade aumentada (
os óculos RA logo se tornarão comuns ) pode melhorar a vida daqueles que trabalham fora do computador, mas cujo trabalho está relacionado ao wrike. Por exemplo, para a interação entre o designer-arquiteto que está envolvido no reparo da casa e a equipe que implementa diretamente o projeto na própria casa.
Acho que demonstramos com honra nosso MVP e capturamos nossos raios de amor. O verão acabou e a temporada de piqueniques e férias está chegando ao fim, e estamos considerando dedicar as noites de outono ao desenvolvimento do nosso Wrike AR.
Obrigado pela ilustração,
Sai Kin !