Design Patterns

— BEHAVIORAL —

Chain Of Responsibility

• Usado pra processar vários requests.
  

Command

• Usado para expressar um comando.
  

Interpreter

• Usado pra avaliar sentenças em uma linguagem.
  

Iterator

• Provém uma interface standard para percorrer uma coleção de itens.
  

Mediador

• Usado para reduzir o acoplamento de classes que comunicam umas com as outras. Envia mensagens via um objeto mediador.
  

Memento

• Usado para capturar o estado atual de um objeto e guardá-lo de maneira que possa ser restaurado sem quebrar as regras de encapsulamento.
  

Observer

• Usado para habilitar mudanças no estado de um objeto. Outros objetos ficam “assinados” para serem notificados imediatamente de qualquer mudança ocorrida.
  

State

• Usado para alterar o comportamento de um objeto e seus estados internos.
  

Strategy

• Usado para realizar a “troca” de um algoritmo durante o runtime.
  

Template

• Usado para implementar dois ou mais algoritmos. O template é definido e construído em algumas variações.
  

Visitor

• Usado pra separar estruturas complexas de informações, da funcionalidade que pode ser usada na informação que ela possui.
  

— CREATIONAL —

Abstract Factory

• Usado para prover ao cliente um grupo de objetos relacionados ou dependentes. Esse grupo é criado pela factory durante o tempo de execução.
  

Builder

• Usado para criar objetos complexos que devem ser criados usando uma ordem ou algoritmo específico.
  

Factory Method

• Usado para substituir construtores das classes, abstraindo o processo de geração de objetos, dessa forma, o tipo do objeto pode ser determinado em tempo de execução.
  

Prototype

• Usado para instanciar um novo objeto através da cópia das propriedades de um objeto já existente, um clone independente.
  

Singleton

• Usado para garantir que apenas um objeto de uma classe em particular seja criado. Todas as outras referências vão referenciar a mesma instância.
  

— STRUCTURAL —

###Adapter

• Usado para prover um link entre dois tipos incompatíveis.
  

Bridge

• Usado pora separar os elementos abstratos dos detalhes da implementação, provendo um meio de substituir os detalhes de implementação sem modificar a abstração.
  

Composite

• Usado pra criar árvores hierárquicas de objetos relacionados, onde qualquer elemento da estrutura pode ser acessado e utilizado de uma maneira “padrão”.
  

Decorator

• Usado para estender ou alterar a funcionalidade de um objeto em tempo de execução. Isso dá a oportunidade de alterar comportamento utilizando herança.
  

Façade

• Usado para definir uma interface simplificada de um subsistema mais complexo.
  

Flyweight

• Usado para minimizar o uso de memória ou recursos computacionais compartilhando o possível com outros objetos similares.
  

Protection Proxy

• Usado para prover uma camada de segurança, onde esse objeto referencia um outro objeto mais “abaixo”, dessa forma restringindo o acesso.
  

Virtual Proxy

• Usado da mesma forma que o Protection Proxy, mas para carregar objetos sob demanda.
  

Source - https://github.com/ochococo/Design-Patterns-In-Swift
Design Patterns in Swift - https://github.com/VamshiIITBHU14/DesignPatternsInSwift

Official Guides from Github Team

Video Tutorials from Ray Wender Lich - Beginning Git

• 1 - Introduction
• 2 - Cloning a Repo
• 3 - Creating a Repo
• 4 - Creating a Remote
• 5 - Commiting Changes
• 6 - The Staging Area
• 7 - Ignoring Files
• 8 - Viewing History
• 9 - Branching
• 10 - Merging
• 11 - Syncing with a Remote
• 12 - Pull Requests
• 13 - Conclusion

Video Tutorials from Ray Wender Lich - Mastering Git

• 1 - Implementation of Git
• 2 - Merge Conflicts
• 3 - Stashes
• 4 - Aliases
• 5 - Rebase: A Mega Alternative
• 6 - Rebase: Rewriting History
• 7 - Gitignore After the Fact
• 8 - Cherry Picking
• 9 - Filter Branch
• 10 - Many Faces of Undo
• 11 - GUIs: GITK
• 12 - GUIs: Sourcetree
• 13 - GUIs: GitUp
• 14 - Conclusion

Atlassian Tutorial - Gitflow Workflow

The overall flow of Gitflow is:

1. A develop branch is created from master.
2. A release branch is created from develop.
3. Feature branches are created from develop.
4. When a feature is complete it is merged into the develop branch.
5. When the release branch is done it is merged into develop and master.
6. If an issue in master is detected a hotfix branch is created from master.
7. Once the hotfix is complete it is merged to both develop and master.

Documentation

• - Premium realmente oferece melhor qualidade no áudio? Downloads Ilimitados? Badges?
• - Tamanho? 26 mb pra Android e 175 pra iOS?
• - Como funcionam os testes automatizados?

Design System

• - Temos o hexadecimal de todas as cores lá registrados, mas onde usamos elas?
• - Aba de search?
• - Faltando Videos na página do My Music?

Swift

• - O uso do “init” é obrigatório para todas as classes?
• - Quando usar private/fileprivate/internal/public?

GitHub

• - Os comandos básicos do git são utilizados? Ou é tudo controlado pela página online.
• - Snapshots são tiradas automaticamente ou é preciso fazer manualmente?
• - Quando um problema é encontrado num Pull Request, a mudança feita desqualifica o Pull Request?
• - Integração com o Slack?
• - Como é feito o merge de múltiplas branches?
• - Quem é o responsável ou responsáveis por avaliar os Pull Requests?
• - Por quê realizar merge da Release Branch de volta para a Develop?

Semantic Versioning

• - Integração com o Gitflow?
• - A quanto tempo utilizam? Já seguem à risca?

Firebase

• - Quais funcionalidades utilizam?

Arquiteruas

• - Diferença funcional entre MVC e MVP?

We are testing commit and merge