Lições aprendidas: UA Hackathon

Alguns fins de semana atrás, participei do incrível Crimson Hacks Hackathon hospedado no campus da Universidade do Alabama. Este foi o primeiro evento de Hackathon que eu já participei e não tinha idéia do que esperar, e os membros da minha equipe estavam no mesmo barco. Este foi um evento patrocinado pela MLH 24 horas, onde você tinha muitos recursos à sua disposição para construir o que queria. Nossa equipe acabou em terceiro lugar, além de ganhar um concurso patrocinado em separado pelo “hack mais perturbador”. Um link para o nosso post de desenvolvedor pode ser encontrado aqui. Muitas coisas inesperadas ocorreram dentro de um período de 24 horas e achei que seria bom refletir sobre a experiência e tentar examinar quais lições poderiam ser aprendidas.

O que fizemos certo

MVP e funções estabelecidos

Na noite anterior à competição, estabelecemos exatamente o que queríamos fazer para o nosso projeto. Garantimos que todos estivessem na mesma página do que seria construído e estabelecemos quais tecnologias seriam usadas. Nosso projeto era construir um site em realidade virtual e gerar o HTML real do lado do cliente, o que você pode imaginar deixa espaço para muitos recursos de estilo e layout. Se nos propusemos a criar todos esses recursos desde o início para criar estilos, não teríamos terminado dentro do período de 24 horas. Em vez disso, focamos no produto mínimo viável . O que um site precisa ser um site? O estilo é agradável, mas com certeza não é necessário para fornecer conteúdo. Decidimos permitir que um usuário pudesse colocar imagens, texto e botões em um layout de coluna ou linha como nosso produto viável mínimo, deixando espaço em nossa representação JSON do site para estilizar se chegássemos a essa parte da competição ( alerta de spoiler : não o fizemos). Uma vez definido o MVP, e exatamente como o usuário interagia com os objetos na cena, poderíamos definir corretamente os papéis para todos com exatamente no que eles trabalhariam. Assim que a competição começou, sabíamos exatamente quem estava fazendo o que e todos podiam correr a toda velocidade.

Protocolo Cliente-Servidor Bem Definido

Se o produto que você está construindo tiver 2 ou mais entidades conversando entre si (como nosso aplicativo de VR e nosso servidor), é extremamente crucial definir formalmente exatamente quando eles enviarão mensagens uns aos outros e como essa mensagem estará ser estruturado . Acabamos criando um documento do google e escrevemos como seria o json, comentando cada campo dentro do objeto com quais dados ele conteria. Poderíamos então criar um site de exemplo representado no JSON que definimos anteriormente para executar testes com o código que estávamos desenvolvendo. Com o exemplo de site desenvolvido, uma pessoa poderia trabalhar para gravá-lo e converter um conversor de JSON para HTML, e uma pessoa diferente poderia escrever o código a ser convertido, em VR para JSON. Isso impedia que os desenvolvedores pisassem nos pés um do outro o tempo todo.

Encontrei um bom tutorial sobre VR

Foi a primeira vez que desenvolvi para o Vive, portanto, encontrar bons tutoriais sobre a tecnologia era essencial para ter sucesso e terminar nossa ideia. O tipo de controle que estávamos planejando desenvolver onde não é complicado, seja simplesmente pegar objetos e jogá-los / colocá-los em diferentes partes da cena. Um link para o tutorial que usamos aqui. As duas coisas que tornaram este tutorial bom:

  1. Está em texto e não no youtube. Você pode lê-lo o mais rápido que desejar, em vez de tentar procurar por algum vídeo
  2. Muitos trechos de código à medida que avançam nas suas habilidades de copiar e colar ninja.

Ambos os pontos têm algo em comum, economizando seu tempo!

Lugares onde jogamos a bola

Não Pesquisando O Suficiente Para Soluções Lá Fora

Quando se trata da implementação de sua ideia, você precisa fazer o máximo de pesquisa possível para garantir que o que você está prestes a construir ainda não tenha sido realizado por outra pessoa. A comunidade de código aberto de hoje é incrível e facilita encontrar o que você precisa. Um de nossos colegas de equipe passou parte do tempo escrevendo seus próprios objetos C # no JSON porque precisávamos ter mais controle sobre a aparência do JSON do que sobre a solução serializável geral encontrada. Depois que a competição terminou, encontramos uma solução que o poupou algum tempo.

Não definir uma demonstração para trabalhar em direção

No final das 24 horas, nos sentimos incríveis. Nós construímos um projeto de trabalho. Realizamos o que nos propusemos a fazer e funcionou relativamente bem. Nosso primeiro juiz veio até nós para fazermos uma demonstração e nos atrapalhámos. Não sabíamos o que mostrar primeiro ou como íamos fazer. Como resultado disso, acabamos não entendendo o que nosso produto poderia fazer da maneira mais eficiente possível. Isso teria sido resolvido se tivéssemos criado algumas histórias de usuário antes para criar uma demonstração adequada.

Roupas / materiais de dormir inadequados

Nem todos tínhamos roupas quentes. Alguns de nós nem trouxeram cobertores para dormir. O lugar estava gelado. Durante 48 horas sofremos. Não faça o que fizemos.

Meu conselho

Este é o meu conselho pessoal dirigido a indivíduos cujo objetivo principal é vencer o próximo hackathon em que participarem. O Crimson Hacks realizou um evento incrível com muitas coisas para os alunos fazerem para aliviar o estresse. Os patrocinadores realizaram palestras no evento em que qualquer um poderia participar para aprender sobre diferentes tecnologias ou linguagens de programação. Se o seu foco principal é aprender o máximo possível, algumas dessas dicas podem impedir você.

1. Tempo para o aprendizado * assistido *

Um hackathon típico permitirá que os desenvolvedores formem equipes entre si. Os hackers carmesins fizeram isso muito bem e dedicaram um canal inteiro apenas para ajudar as pessoas a conhecer outras pessoas e formar equipes. Trabalhar com outras pessoas é uma oportunidade importante que permite que os desenvolvedores compartilhem seus conhecimentos uns com os outros e adquiram experiência em tecnologias que talvez não usem normalmente. Dito tudo isso, não exagere e peça a sua equipe inteira experimentar uma nova tecnologia com a qual nem você trabalhou. Eu assisti uma equipe de 11 horas na competição ter que desfazer uma grande parte do projeto, porque eles investiram tempo em alguma tecnologia da web que ninguém sabia nada. Certifique-se de escolher as tecnologias com as quais você trabalhará, pelo menos alguém da sua equipe possui algum nível de experiência para ajudá-lo, caso você seja pego de surpresa.

2. Sério. Apenas durma

Entendemos. Você é um estudante universitário, o que significa que você está familiarizado demais com a criatura que é a tarefa “tudo mais agradável”. Mas hackathons são uma raça diferente. Este não é um ensaio em que você possa continuar a hackear até atingir a contagem de páginas desejada. Hackathons são um produto que você está tentando desenvolver, que será colocado na frente de outros para serem dissecados e com furos. Ter mais nem sempre significa melhor, especialmente quando você continua adicionando recursos que mal funcionam enquanto dorme. Se você se encontrar sem saber o que fazer a seguir, durma. Se você se deparar com um bug por 30 minutos com 0 progresso (e ninguém mais pode ajudar), vá dormir. Diga a seus colegas de equipe que o acordem em uma hora ou quando precisarem que você faça alguma coisa. É incrível o que fazer com um único ciclo REM pode fazer por você.

3. Traga um segundo monitor

Todo mundo precisa de um segundo monitor quando se desenvolve. Se você acha que não precisa de um segundo monitor, está errado. Além disso, eles tornam a demonstração do seu produto muito mais suave.

4. Firebase It

Não posso enfatizar isso o suficiente. Isso é provavelmente tudo o que você precisa em um back-end. Se você nunca ouviu falar, por favor, confira. É grátis e você pode compartilhar seu projeto com outros desenvolvedores facilmente. Ele vem com seu próprio banco de dados e facilita a criação e a conta de usuário. Se você precisar de mais funcionalidades, crie um serviço heroku que se conecte ao seu projeto do firebase para que tudo fique gratuito e na nuvem. O banco de dados em tempo real do Firebase permitiu que uma conexão em soquete fosse vinculada entre nosso aplicativo VR e nosso servidor do outro lado, sem ter que se preocupar com uma única linha de código de soquete.

5. Tarefas documentadas, bem definidas e separadas

Esta é uma boa prática para começar, mas acho que ainda deve ser declarada aqui, porque determinará quão bem você pode utilizar o fato de estar trabalhando em equipe. Se você pode definir tarefas que não são apenas separadas, mas também podem ser concluídas na ordem que você escolher, você terá o melhor cenário. Seu projeto se torna escalável para o número de membros da equipe em tarefas separadas. Garantir que todos tenham algo a fazer na equipe é extremamente importante para a utilização do tempo limitado concedido ao desenvolvimento. Definir as mensagens enviadas entre cliente e servidor pode ajudar a separar tarefas, permitindo que os desenvolvedores escrevam testes que simulam essas mensagens que chegam.

6. Espere que algo dê errado

Depois de todo o planejamento que fizemos para o nosso projeto e definir tudo o que precisa ser feito com os problemas criados dentro do github, ainda não planejamos tudo. Duas horas depois da competição, um de nossos colegas de equipe teve alguns problemas em casa e teve que sair. Eventos inesperados como esse apenas enfatizam a importância de gastar tempo na definição de um MVP que não seja arrogante e permita que recursos extras sejam adicionados posteriormente.