Skip to content

CocoaHeadsBrasil/CocoaHeadsApp

Repository files navigation

CocoaHeads Brasil 🇧🇷

waffle board Build Status

Quem Somos

CocoaHeads é um grupo formado por desenvolvedores (profissionais e iniciantes), que se organizam para reunir pessoas com a mesma paixão: Programação para os iDevices da Apple (OSX e iOS). Nossos encontros são informais e servem para juntar pessoas que gostam do mesmo assunto que você [programação! :) ]. Promovemos Talks e Palestras dadas por membros do grupo local ou de convidados especiais. Estamos também presentes no Slack, http://iosdevbr.herokuapp.com, onde temos diversas iniciativas como a criação do aplicativo da comunidade, área de #code-help, uma sessão para divulgação de empregos no canal #jobs, falamos também sobre #design e #ux de aplicações além de ter o podcast da comunidade!

Setup inicial

Instalação das Dependências

./setup.sh

Guidelines de desenvolvimento

UI

Usamos um storyboard Main.storyboard para definir o fluxo do app, porém o desenvolvimento da tela não é feito diretamente no storyboard. Para desenvolver uma tela você deve:

  1. Criar um viewController para esta tela
  2. Criar uma view que extenda de NibDesignable
  3. Criar um Xib com o mesmo nome da View.
  4. Definir a classe do File's Owner para a classe da view que você criou
  5. Adicionar uma nova scene no storyboard.
  6. Definir a classe do ViewController para o controller criado no passo 1
  7. Arrastar uma nova View para dentro dele, e definir a classe dessa view para a view criada no passo 2

Com isso, a view será renderizada corretamente no storyboard, mas sua edição será no arquivo Xib criado.

Interação com a View

Devemos seguir alguns conceitos e princípios para separar a lógica de nossa funcionalidade:

  1. O ViewController deve apenas interagir com a view quando esta tiver que mudar de tamanho, ou apresentar outros ViewControllers
  2. Crie uma classe que extenda de ViewModel.
  3. Adicione uma propriedade viewModel para a classe View.
  4. A classe ViewModel deve conter informações sobre o estado da view, e lógicas que alterem esses estados.
  5. A classe View deve monitorar estes estados para alterar visualmente sua aparência.

Quem pode contribuir

Todos desenvolvedores iOS estão aptos a colaborar com essa iniciativa, basta seguir o workflow de contribuição.

Guideline de contribuição

Neste projeto, estamos usando o Github Flow integrado com o Forking Wokflow.

Preparação

  • Faça o fork do projeto.
  • Clone o seu projeto
$ git clone [email protected]:<github_user>/CocoaHeadsApp.git
  • Sincronize o branch master
$ git pull origin master
  • Adicione o projeto original como upstream remote
$ git remote add upstream [email protected]:CocoaHeadsBrasil/CocoaHeadsApp.git
  • Atualize a tabela do seu repositório
$ git fetch --all
  • Sincronize o branch master do projeto original
$ git checkout -b cocoaheads/master upstream/master

Desenvolvimento

  • Mude para o master do seu fork e crie um novo branch com a sua feature
$ git checkout master; git checkout -b feature_name
  • Faça todas as alterações necessárias

Publicação

  • Quando a feature estiver pronta para publicação, atualize a tabela do seu repositório
$ git fetch --all
  • Atualize o branch master do projeto original
$ git checkout cocoaheads/master; git pull upstream master
  • Rebase seu branch master
$ git checkout master; git rebase cocoaheads/master
  • Push seu branch master para seu fork
$ git push origin master

*Caso necessário (uma vez que o histório do git é remodelo no `rebase`), você pode forçar a atualização*
``` $ git push -f origin master ``` - `Rebase` o branch da sua feature
``` $ git checkout feature_name; git rebase master ``` - `Push` o branch da sua feature para seu fork
``` $ git push origin feature_name ```
*Caso necessário (uma vez que o histório do git é remodelo no `rebase`), você pode forçar a atualização*
``` $ git push -f origin feature_name ``` - Crie um novo [`Pull Request`](https://github.com/CocoaHeadsBrasil/CocoaHeadsApp/pull/new/master)

Features do projeto

Todo o desenvolvimento do app está concentrado no github. Portanto, para gerenciá-lo, usamos issues, labels e milestones.

Issues

Workflow

  1. Quando uma nova issue é criada, ela entra in review. Assim, os participantes do projeto podem conversar a respeito e colaborar com a proposta.
  2. Uma prosposta pode ser negada (Declined) ou transformada em item do backlog do projeto (Onboard).
  3. As issues em onboard podem começar a serem desenvolvidas (In progress).
  4. Quando o desenvolvimento da feature é completado, o desenvolvedor por criar um pull request e associar à issue (Waiting PR review).
  5. Os demais participantes do projeto podem revisar os pull requests (In PR review).
  6. Quando for feito o merge, aquela issue é encerrada (Delivered).

Labels

Progresso

  • In review: Propostas que estão abertas para discussão se será implementado ou não
  • Declined: Dado as conversas na issue, a funcionalidade/refatoração foi negada (e a issue é fechada).
  • Onboard: Proposta que foi "aceita" e pode entrar em uma das milestones do projeto. Nesse ponto, a conversação na issue é bloqueada
  • In progess: Issue que está em desenvolvimento por 1 ou mais pessoas (que devem ser associadas à issue)
  • Waiting PR review: Uma indicação de que o issue foi finalizada e precisa passar por review de PR.
  • In PR review: O PR está sendo avaliado por 1 ou mais pessoas
  • Delivered: PR foi aceito (e a issue é fechada)

Informativo

  • Code base enhancement: Propostas que visam uma melhor implementação ou estrutura de código
  • Product enhancement: Propostas de novas funcionalidades para o produto
  • bug: Informar bugs no código
  • ci: Propostas de novas funções ou melhorias no sistema de C.I.
  • docs: Adição ou melhoria na documentação
  • question: Questões sobre o projeo
  • easy: Proposta considerada de fácil implementação
  • medium: Proposta com dificuldade média
  • hard: Proposta de implementação complexa

Milestone

O projeto, hoje, possui os seguintes milestones:

  • Integrar API: Integrar a API rails
  • Versão de teste: Uma primeira versão do aplicativo, algo que pode ser disponibilizado para beta testers (não precisa ter 100% das funcionalidades)
  • 1.0: Coisas que queremos que sejam válidas para uma versão 1.0
  • Distribuição: Issues relacionadas à distribuição do app (caso seje relevante)

Motivação da criação do App

O crescimento do número de chapters em inúmeras cidades se fez a necessidade de ter um local onde pudessemos ver e organizar tantos eventos. Assim surgiu a ideia de fazermos o aplicativo do CocoaHeads Brasil com a presença de todos os eventos. A visualização destes além das informações mais detalhadas, além de apresentar a lista de participantes por evento, sorteios e muito mais.

Licença

The MIT License

About

O app oficial do CocoaHeads Brasil (em desenvolvimento)

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published