- 1. Preâmbulo
- 2. Resumo do projeto
- 3. Objetivos de aprendizagem
- 4. Considerações gerais
- 5. Critérios de aceitação mínimos do projeto
- 6. Hacker edition
- 7. Considerações técnicas
- 8. Pistas, tips e leituras complementares
- 9. Checklist
O jogo Memory Match, também conhecido como Concentration, Match Match, Match Up, Memory, entre outros, é um jogo de cartas em que todas as cartas são postas viradas pra baixo sobre a superficie, virando duas cartas em cada turno. O objetivo do jogo é encontrar pares de cartas iguais.
Exemplos:
Neste projeto será construído uma versão web do jogo Memory Match, em que uma jogadora possa jogar sozinha no navegador.
O objetivo principal deste projeto é aprender a desenhar e construir uma interface web baseada em data e interação com a usuária.
Reflita e depois enumere os objetivos que quer alcançar e aplique no seu projeto. Pense nisso para decidir sua estratégia de trabalho.
-
Uso de HTML semântico
-
Uso de seletores de CSS
-
Modelo de caixa (box model): borda, margem, preenchimento
-
Uso de flexbox em CSS
-
Uso de seletores de DOM
-
Manipulação de eventos de DOM (listeners, propagação, delegação)
-
Manipulação dinâmica de DOM
-
Variáveis (declaração, atribuição, escopo)
-
Uso de condicionais (if-else, switch, operador ternário, lógica booleana)
-
Uso de laços (while, for, for..of)
-
Funções (params, args, return)
-
Uso de linter (ESLINT)
-
Uso de identificadores descritivos (Nomenclatura e Semântica)
-
Diferença entre expressões (expressions) e declarações (statements)
-
Diferenciar entre tipos de dados primitivos e não primitivos
-
Arrays (arranjos)
-
Objetos (key, value)
-
Testes unitários (unit tests)
-
Módulos de ECMAScript (ES modules)
-
Git: Instalação e configuração
-
Git: Controle de versão com git (init, clone, add, commit, status, push, pull, remote)
-
Git: Integração de mudanças entre ramos (branch, checkout, fetch, merge, reset, rebase, tag)
-
GitHub: Criação de contas e repositórios, configuração de chave SSH
-
GitHub: Implantação com GitHub Pages
- GitHub: Colaboração pelo Github (branches | forks | pull requests | code review | tags)
- Desenhar e desenvolver um produto ou serviço colocando as usuárias no centro
-
Criar protótipos para obter feedback e iterar
-
Aplicar os princípios de desenho visual (contraste, alinhamento, hierarquia)
- Planejar e executar testes de usabilidade
- Este projeto deverá ser feito em duplas.
- O intervalo de tempo estimado para concluir o projeto é de 3 a 4 Sprints.
- O projeto será entregue subindo seu código no GitHub (commit/push) e a interface será publicada usando GitHub Pages.
Os critérios para considerar que completou este projeto são:
Documenta brevemente seu trabalho no arquivo README.md do seu repositório,
contando como foi seu processo de desenho e como acredita que o produto resolve
o problema (ou problemas) que seu usuário tem.
Uma vez que entenda as necessidades de seus usuários, escreva as Histórias de Usuário que represente tudo que o usuário necessite fazer/ver. As Histórias de Usuário devem ser o resultado do seu processo de investigação ou research de seus usuários.
Certifique-se de incluir a definição de pronto (definition of done) e os Critérios de Aceitação para cada uma.
Na medida do possível, termine uma história de usuário antes de passar para a próxima (Cumpra com a Definição de pronto + Critérios de Aceitação).
Durante seu trabalho deve fazer e iterar esboços (sketches) de sua
solução usando papel e lápis. Te recomendamos tomar fotos de todas as
iterações que fizer, coloque em seu repositório e as menciones em seu
README.md.
O próximo passo é desenhar a sua Interface de Usuário (UI que vem do inglês - User Interface). Para isso aprenda a utilizar algm ferramenta de desenho visual. Nós te recomendamos o Figma, que é uma ferramenta que funciona no navegador com um conta gratuita. Porém, a escolha é livre e você pode utilizar outros editores gráficos como Illustrator, Photoshop, PowerPoint, Keynote, etc.
O desenho deve representar a sua solução ideal. Digamos que é o que desejaria implementar se tivesse tempo ilimitado para trabalhar. Além disso, seu desenho deve seguir os fundamentos de visual design.
Durante o desafio deverá fazer tests de usabilidade com distintos usuários, e com base nos resultados, deverá iterar seus desenhos. Conte quais problemas de usabilidade foram encontradas através dos tests e como elas foram melhoradas na sua proposta final.
Assim que desenhar sua interface de usuário, deve trabalhar em sua implantação. Não é necessário que construa a interface exatamente como foi desenhado. O tempo de hacking é escasso, assim deverá priorizar
Como mínimo, sua implantação deve:
- Dado um set de cartas, embaralhar as cartas e mostrá-las na interface.
- Permitir al usuário virar as cartas de 2 em 2.
- Os pares encontrados devem permanecer viradas para cima.
- Indicar ao usuário que ganhou quando conseguir virar todas as cartas.
- Ser responsiva, ou seja, deve ser visualizada sem problemas a partir de diversos tamanhos de tela: celulares, tablets e desktops.
- Que a interface siga os fundamentos de visual design.
O boilerplate deste projeto inclui testes unitários (unit tests) de um componente como exemplo. A medida que vai agregando componentes, terá que ir agregando os testes para manter uma boa cobertura.
Seus testes unitários devem ter uma cobertura de 70% de statements (sentencias), functions (funciones), lines (líneas), e branches (ramas) de seus componentes.
As seções chamadas Hacker Edition são opcionais. Se já tiver terminado todos os requisitos anteriores e tiver tempo, pode tentar completá-las. Dessa forma, você pode aprofundar e/ou exercitar mais os objetivos de aprendizagem deste projeto.
Features/características extra sugeridas:
- Ao invés de consumir os dados estáticos fornecidos neste repositório, pode
consumir os dados de forma dinâmica, carregando um arquivo JSON por meio de
fetch. A pastasrc/datacontém uma versão.jse uma.jsonde de cada conjunto de dados. - Adicionar novos conjuntos de cartas.
- Calcular a pontuação baseado na quantidade de turnos.
- Adicionar timer e ter conta em pontuação.
- 100% Coverage
A lógica do projeto deve ser implementada completamente em JavaScript, HTML e CSS. Neste projeto NÃO é permitido usar bibliotecas ou frameworks, apenas vanilla JavaScript.
Para iniciar um novo jogo, sempre teremos que embaralhar as cartas antes de printá-las na tela. Para isso, te convidamos a explorar algoritmos existentes para este tipo de operação (chamada shuffle em inglês), como por exemplo o algoritmo de Fisher-Yates (aka Knuth).
Neste projeto não se espera que invente ou implemente seu próprio algoritmo
para embaralhar as cartas. Considere as opções existentes,
escolha uma e a adapte para seu projeto (agregando uma função shuffle
que possa ser usada em sua aplicação).
O boilerplate contém uma estrutura de arquivos como ponto de partida, assim como toda a configuração de dependências:
.
├── .babelrc
├── .editorconfig
├── .eslintrc
├── .gitignore
├── package.json
├── README.md
└── src
├── components
│ ├── App.js
│ └── App.spec.js
├── data
│ ├── pokemon
│ │ ├── pokemon.js
│ │ └── pokemon.json
│ ├── README.md
│ └── webdev
│ ├── webdev.js
│ └── webdev.json
├── index.html
├── main.js
└── style.css
Como no projeto anterior, existe um arquivo index.html. Como já sabe, aqui
entra a página que vai ser exibida ao usuário. Também serve para indicar quais
scripts serão utilizados e juntar tudo o que foi feito.
Recomendamos usar src/main.js como ponto de entrada da sua aplicação. O
boilerplate inclui este arquivo para conectar ou montar o componente
App no DOM. Desta forma poderemos fazer testes unitários de nossos
componentes sen necessidade de que estejam conectados a um DOM global.
Esta não é a única forma de dividir seu código. Pode usar mais arquivos e pastas, contanto que a estrutura esteja clara para suas companheiras.
Este arquivo contém um componente de exemplo que mostra como podemos
representar um componente como uma função que retorna um HTMLElement. Na
hora de construir interfaces, é útil pensar nos termos de componentes ou
vistas que podemos ir aninhando umas dentro das outras. Te convidamos a
pensar quais componentes ou caixinhas são necessárias para construir sua aplicação
e que vá adicionando componentes no directorio components para implementar
cada um deles. Embora, novamente, no final, a forma de organizar seu arquivos depende
de você e da sua equipe. Há muitas formas de faze-lo, e o boilerplate
é apenas uma sugestão 🙊.
Este arquivo mostra como podemos criar arquivos com especificações (expressadas como testes unitários) de nossos componentes.
Nesta pasta há dados com conjuntos de cartas como exemplo que pode usar na sua
aplicação, assim como informação sobre como adicionar seus próprios conjuntos.
Encontrará uma pasta por cada set, e dentro de cada pasta dois arquivos: um
com la extensão .js e outro .json. Ambos arquivos contém o mesmos dados;
a diferença é que o .js usaremos através de um import, enquanto que
o .json está aqui para opcionalmente carregar os dados de forma assíncrona com
fetch().
Participe do canal do Slack #project-memory-match para conversar e pedir ajuda no projeto.
Antes de começar a escrever código, deve definir o que seu produto faz com base no conhecimento que conseguir obter de seu usuário. Estas perguntas podem te ajudar:
- Quem são os principais usuários do produto?
- Quais são os objetivos destes usuários em relação com o produto?
- Quais são os principais componentes da interface e por que?
- Quando utilizam ou utilizariam o produto?
- Toda seu investigação prévia deve ter como resultado todas as Histórias de Usuário de seu projeto.
- Não faça os protótipos de alta fidelidade de todas suas Histórias. Comece apenas pelos que necessitem para sua Sprint 1 (semana 1 de trabalho). Há mais dicas na guia de organização desse projeto.
Quando estiver pronta para codar, te sugerimos começar desta maneira:
- Uma das integrantes da equipe deve realizar um
fork do repositório de sua
turma (a equipe de formação fornecerá o link). A outra integrante da dupla
deve fazer um fork a partir do repositório de sua companheira e
configurar um
remotea partir dele. - Clona seu fork a seu computadora (copia local).
- Instale as dependências do projeto com o comando
npm install, assumindo que já tenha instalado o Node.js (que inclui npm). - Se tudo correr bem, deve ser capaz de executar os 🚥 testes
unitários (unit tests) com o comando
npm test. - Para ver a interface de seu programa no navegador, utilize o comando
npm startpara subir o servidor web no endereçohttp://localhost:5000. - Comece a codar! 🚀
- Investigação com usuários / entrevistas
- Princípios de design/UI
- Unidade de testes do curso de JavaScript do LMS.
- Unidade de arrays do curso de JavaScript do LMS.
- Unidade de objetos do curso de JavaScript do LMS.
- Unidade de funções do curso de JavaScript do LMS.
- Unidade de DOM do curso de JavaScript do LMS.
- Array no MDN
- Array.map no MDN
- Array.sort no MDN
- Array.filter no MDN
- Array.reduce no MDN
- Array.forEach no MDN
- Object.keys no MDN
- Object.entries no MDN
- Fetch API no MDN
- json.org
- expressions-vs-statements
- Módulos: Export
- Módulos: Import
- Usar VanillaJS.
- Passa pelo linter (
npm run pretest) - Passa pelos testes (
npm test) - Testes unitários cobrem um mínimo de 70% de statements, functions, lines e branches.
- Inclui uma definição de produto clara e informativa no
README.md. - Inclui histórias de usuário no
README.md. - Inclui rascunho da solução (protótipo de baixa fidelidade) no
README.md. - Inclui Desenho da Interface de Usuário (protótipo de alta fidelidade)
no
README.md. - Inclui uma lista de problemas detectados nos testes de usabilidade no
README.md. - UI: Mostra cartas embaralhadas corretamente.
- UI: Permite o usuário virar as cartas de 2 em 2.
- UI: Deixa os pares que foram formados virados.
- UI: Informar o usuário que ganhou quando for relevante.
- UI: É responsivo.
- UI: A interface segue os fundamentos de visual design.