CocoaHeadsBrasil/CocoaHeadsApp


O app oficial do CocoaHeads Brasil (em desenvolvimento)

http://www.cocoaheads.com.br

License: MIT

Language: Swift


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 git@github.com:<github_user>/CocoaHeadsApp.git
  • Sincronize o branch master
$ git pull origin master
  • Adicione o projeto original como upstream remote
$ git remote add upstream git@github.com: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

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

Project Statistics

Sourcerank 7
Repository Size 9.94 MB
Stars 69
Forks 33
Watchers 27
Open issues 24
Dependencies 64
Contributors 15
Tags 0
Created
Last updated
Last pushed

Top Contributors See all

Gustavo Barbosa Igor Casta√Īeda Ferreira Vinicius Carvalho Marques Bruno Mazzo Igor Ferreira Bruno Bilescky Gabriel Oliva _ant_one Raphael Silva cs-lucas-cardinali Bruno Koga Miguel Ara√ļjo Bas Broek Bruno Guidolim Tales Pinheiro

Interesting Forks See all

nthegedus/CocoaHeadsApp
O app oficial do CocoaHeads Brasil (em desenvolvimento)
Swift - Updated - 1 stars
brunogb/CocoaHeadsApp
O app oficial do CocoaHeads Brasil!
Swift - Last pushed - 1 stars
felipelmota/CocoaHeadsApp
O app oficial do CocoaHeads Brasil!
Swift - Updated - 1 stars

Something wrong with this page? Make a suggestion

Last synced: 2016-12-13 12:27:24 UTC

Login to resync this repository