No final de março, em Novosibirsk, o décimo aniversário do
CodeFest morreu . Como, provavelmente, em qualquer conferência, o CodeFestX deixou muitas impressões diferentes para os participantes, de “minhas pernas não estarão mais aqui” a “como comprar uma assinatura vitalícia?”. Não vou descrever como foi,
já existem críticas e, acho, ainda aparecerão. Quero compartilhar a história de como lançamos
uma versão alternativa para a programação do Codefest (
assista melhor a partir de um telefone celular ): da ideia ao resultado.
Idéia
Eu frequento o Codefest desde 2010, e este ano foi minha 9ª conferência. Para mim, o Codefest é uma tradição, e desta vez eu queria fazer algo útil. Antes do evento, lendo o bate-papo da conferência, percebi que a programação é algo que definitivamente pode ser melhorado. O Codefest é um evento agitado que todos gostariam de aproveitar ao máximo, então decidi ajudar a criar uma programação personalizada alternativa.
Os objetivos foram os seguintes:
- Para visitantes - dê a oportunidade de obter informações mais relevantes sobre os eventos atuais e formar seu próprio feed de interesses. Além disso, todos os visitantes da conferência tiveram a oportunidade de vir ao nosso estande e registrar qualquer recurso que faltava ou corrigir um bug;
- Para o Codefest , esse é um canal adicional para a distribuição de um programa "popular";
- Para nós, como empresa , é claro que isso é uma vantagem adicional na marca Employer.
O conceito de um cronograma “bombeado” chegou aos organizadores do Codefest. Compartilhei a ideia no Wrike e rapidamente encontrei pessoas com a mesma opinião e dispostas a se conectar. Começamos com a pesquisa, analisamos os locais das conferências e os aplicativos móveis. Em geral, lançamos o
processo de mercearia usual na Wrike.
Como resultado da elaboração do backlog, determinamos que a funcionalidade necessária é necessária assim:
- A programação principal da conferência com a capacidade de filtrar relatórios e pesquisar;
- Favoritos e notificações sobre a abordagem de eventos selecionados;
- Um programa popular com a mesma funcionalidade do principal, bem como a oportunidade para parceiros e ativistas de adicionar eventos a este programa.
Havia tarefas de prioridade mais baixa:
- Discussões sobre o relatório para que usuários autorizados possam trocar opiniões e discutir;
- Gostos e relatórios de classificação populares;
- Mapa, como O CodeFest é excelente e a navegação é muito importante.
Ainda havia tarefas com a terceira prioridade, onde ainda temos um monte de naves espaciais enterradas, mas acredito que chegará a hora deles.
Implementação
Decidimos usar o que usamos no desenvolvimento de nosso produto como uma pilha para o projeto, para dar uma oportunidade de ver como o frontend é construído no Wrike. Escrevemos no
Dart (
e já dissemos o porquê: aqui e aqui ) e, por enquanto, para grandes projetos da web como o nosso, existe apenas o Angular (
aqui estão 5 minutos de inspiração do bunopus ). O repositório do nosso projeto pode ser encontrado aqui
github.com/wrike/codefestx .
Em nosso aplicativo Angular, adicionamos
Redux . Existem várias implementações para o Dart: usamos
Redux.dart e
Redux Epics para obter efeitos. Em nosso projeto, o código relacionado ao Redux está localizado aqui
github.com/wrike/codefestx/tree/master/lib/src/redux .
Para trabalhar com o
estado imutável, pegamos os
pacotes built_value e
built_collection , que simplificam o trabalho. Por exemplo, criamos uma classe para o estado de nosso aplicativo -
CodefestState , e os pacotes geram um
construtor .
Um truque simples é usado para comunicar Angular e Redux (
no componente principal - github.com/wrike/codefestx/blob/master/lib/app_component.dart ):
E nós os unimos por meio de um
Stream gart padrão:
_dispatcher.onAction.listen((action) => _store.dispatch(action)),
_store.onChange.listen((_) => _zone.run(_cdr.markForCheck)),
Ou seja, quando você cria uma ação no gerenciador (
todas estão aqui ), ela entra no repositório Redux. Ele está sendo processado e o estado está mudando, o que causa um ciclo de detecção angular de alterações.
Criamos 2 mecanismos para o envio de notificações: para notificações da ocorrência de eventos, porque isso é importante, integrado ao
PushWoosh e recebeu um push do sistema (
infelizmente sem suporte para navegadores no iOS ). Para eventos menos críticos, por exemplo, o lançamento de uma nova versão, um soquete foi gerado e o
socket_io_client foi usado no cliente.
Em geral, a estrutura do aplicativo é simples e, na minha opinião, compreensível. Se você tiver dúvidas, podemos discutir soluções específicas nos comentários ou no github.
A infraestrutura
No mundo moderno, para fazer upload de um arquivo JS para uso geral, o
k8s é indispensável. Mas,
falando sério, uma das características do nosso serviço é a revisão na própria conferência (
que vários dartizanos aproveitaram entre os visitantes e não, eles não são do Wrike :) ).
Portanto, decidimos fazer um IC honesto. Examinamos as oportunidades de integração que o
GitHub tem e encontramos o
Google Cloud Build lá : como usamos os produtos do Google, não devemos deixar essa trilha. A integração funciona assim: qualquer confirmação no repositório chama o assembly
cloudbuild.yaml . Seguimos o caminho em que estamos montando um contêiner do Docker com um aplicativo pronto (
existe um modelo de hub para o dart - hub.docker.com/r/google/dart ) e, em seguida, o lançamos no k8s para que possamos reverter liberações, dimensionar e fornecer outras hipotéticas situação. Do que não foi suficiente, foi a capacidade de fazer um comportamento diferente, dependendo do ramo em que estamos comprometendo, ou seja, para o mestre construir e implantar na batalha, e para os demais ramos, etapas mínimas devem ser executadas sem os k8s. Há uma discussão ativa sobre esse tópico
aqui , e aproveitamos a solução dessa discussão. O CI funcionou perfeitamente e nunca falhou.
Voar na pomada
Além dos nossos sucessos, é claro, há algo que poderia ser feito de maneira diferente. Por exemplo, não force as pessoas a fazer login ao votar em relatórios - algumas não gostam disso (
especialmente em serviços de curto prazo ). Como resultado, não recebemos muitas curtidas nos relatórios, mas, no entanto, parabenizamos os campeões do orador.
Também com a coragem do desenvolvimento da web esquecemos as limitações estritas do iOS e que não
há como pressionar pela web . Aconteceu que quase metade dos usuários do nosso serviço estava com o iPhone. Infelizmente, não foi possível enviar um aviso a eles.
E o que mais perturbou a equipe, como eu já mencionei, - não conseguimos fazer todos os nossos planos. Algumas das funcionalidades foram lançadas na conferência e outras ainda estão em atraso.
Resultados
Graças aos organizadores, o link para a programação foi adicionado ao memorando do participante da conferência. Durante a conferência, mais de 1100 usuários usaram o serviço. Ao programa principal de ~ 120 eventos, adicionamos mais ~ 50 "folclore". Aproximadamente 75% das sessões foram em dispositivos móveis, enviamos mais de 500 notificações por push, emitimos três releases durante a própria conferência e recebemos muito prazer com o processo e o resultado.
Foi uma ótima experiência e continuaremos desenvolvendo o projeto, pelo menos para eventos internos e conferências Wrike. Se você esteve no Codefest e usou nossa programação, agradecemos seus comentários nos comentários.