Agenda do Curso
-
-
2ª avaliação
-
Fórum de Discussões sobre a REC
-
Projeto de 2ª Avaliação (prazo: 28/fev) Tarefa
Projeto de 2ª avaliação: Contribuição
(prazo: 28/fev/2020)Neste projeto você deve realizar uma contribuição de qualidade para um projeto de código aberto hospedado no GitHub ou no GitLab.
O objetivo principal é produzir e submeter uma modificação ou extensão não trivial para um projeto de código aberto de modo a maximizar as chances do código ser aceito pelos mantenedores do projeto. Se você demonstrar que o código foi incorporado ao código do projeto até a data de entrega desta avaliação, você receberá um bônus de 10% na média final.
Seleção do Projeto
Você deve selecionar um projeto de código aberto e implementar uma ou mais correções de problemas (um bug reportado na seção de issues do projeto) ou implementar uma extensão (uma nova funcionalidade) para o projeto. Você tem liberdade para escolher qualquer projeto, independentemente da linguagem de programação em que ele foi escrito, desde que o projeto satisfaça os seguintes critérios:
- o projeto deve estar ativo e ter muitas contribuições. Um projeto inativo ou com pouco suporte terá uma comunidade de desenvolvedores que não poderá te ajudar a implementar a contribuição. Você não pode escolher um projeto seu ou de um outro aluno da USP, mas pode escolher um projeto que você eventualmente já tenha contribuído antes;
- você deve escolher a(s) tarefa(s) a ser(em) implementada(s) (correção de problemas ou extensão). A tarefa deve constar em um relato de erro (bug report), um pedido de nova funcionalidade (feature request) listados em um banco de dados ou fórum de discussão públicos, seguindo qualquer que seja o protocolo que o projeto utilize para comunicar e relatar defeitos no código (GitHub Issues, por exemplo). Você não pode estar envolvido com a criação do bug report (ou seja, você não pode trabalhar em um bug que você mesmo tenha relatado). Escolha uma necessidade do projeto que já seja conhecida e que tenha sido documentada por alguém da comunidade do projeto;
- a tarefa deve envolver a modificação do código-fonte do projeto. Tarefas restritas à documentação ou discussões sobre algum aspecto do projeto não são válidas para este projeto;
- você pode escolher uma tarefa complicada ou várias pequenas tarefas.
Uma vez escolhido o projeto e a(s) tarefa(s) candidata(s), pesquise o projeto com calma. Leia a documentação, tente compilar e executar o código do projeto e tente ler o código e entendê-lo. Você deve entender o código do projeto a ponto de entender como sua contribuição irá impactar o projeto como um todo.Implementação da Tarefa
Implemente a tarefa escolhida. Você deve escrever o código e garantir a qualidade da contribuição (aka. escrever testes e demonstrar que o conjunto de testes é adequado para o projeto em questão). Além disso, você provavelmente terá que:- realizar ações para entender melhor o código do projeto selecionado. Você pode achar útil analisar o código com o uso de diagramas (especialmente se gerados automaticamente, como vimos que a gema railroady faz para projetos Rails)
- submeter contribuição para o projeto. Crie toda a documentação necessária para permitir que o seu código seja aceito pelos mantenedores do projeto. Novos contribuidores raramente têm permissão de commit para o repositório master de um projeto, então a contribuição talvez envolva a criação de um pull request, envio de e-mails para os líderes do projeto, ou posts em fóruns de discussão.
Você é obrigado a submeter sua contribuição para o projeto usando sua identidade real (para que eu possa verificar que a contribuição é mesmo sua). Sua contribuição não precisa ser aceita pelo projeto, mas você ganhará um bônus na nota caso ele seja aceito.Relatório Final
Até o prazo máximo de entrega desta 2ª avaliação, você deverá entregar também um relatório sobre a sua contribuição. Este relatório deverá conter:- informações sobre o projeto selecionado: uma breve descrição do projeto de código aberto com o qual você contribuiu (1 ou 2 parágrafos)
- contexto do projeto: uma análise do contexto do projeto e seu "business model". Isso pode incluir uma breve história do projeto, outros projetos abertos e fechados relacionados a esse projeto, ou uma discussão sobre as motivações dos desenvolvedores para o desenvolvimento do projeto
- governança do projeto: descreva o processo e ferramentas que o projeto usa para se comunicar e coordenar os contribuidores. Esses processos são formais ou informais? Forneça uma descrição (talvez com um diagrama) do processo de aceitação que o projeto utiliza para contribuições como a que você realizou
- descrição da tarefa (uma para cada tarefa): uma descrição da tarefa que você implementou e uma descrição de alto nível da sua implementação
- artefatos submetidos ao projeto: evidência de código, documentação, casos de testes e/ou outros artefatos que você produziu para a tarefa e alguma evidência de que a contribuição foi realmente enviada para o projeto. Você deve obrigatoriamente incluir links públicos que confirmem o envio da contribuição para o projeto (links para o repositório, lista de e-mails, pull requests, etc.). Cada link deve vir acompanhado de uma breve descrição sobre ele
- estratégia e evidência de QA: você deve elencar e justificar quais ações tomou para garantir a qualidade do código que você contribuiu. Além disso, você deve apresentar evidências das ações que tomou para garantir a qualidade do código. Exemplos dessas evidências incluem código de teste, resultado dos testes, comentários dos revisores do código, relatórios de ferramentas de avaliação de qualidade de código e de cobertura de testes, links ou screenshots para uma plataforma de integração contínua, etc.
- resumo da experiência: relate a sua experiência como contribuidor de um projeto de código aberto. Diga o que você aprendeu ao interagir com outros desenvolvedores, ao tentar entender o código do projeto e ao desenvolver novo código para um projeto existente. Diga se a comunidade do projeto foi receptiva a sua contribuição ou se a cultura deles atrapalhou o envio. Relate suas interações com os demais membros do projeto. Destaque os comentários mais úteis (e talvez inúteis) que você recebeu dos demais membros. Descreva em detalhes também quais cuidados de engenharia de software o projeto aplica para garantir a qualidade do código do projeto. Descreva em detalhes quais cuidados você tomou para que o código da sua contribuição fosse de qualidade e não quebrasse a base de código existente. Critique o código do projeto com o qual você contribuiu: ele foi fácil de entender e evoluir? Ele possui um conjunto suficiente de testes? Quais as maiores dificuldades encontradas?
O resumo da experiência é a parte mais importante do relatório! Quanto mais detalhado ele for, melhor.Sites como up-for-grabs.net e codetriage.com listam repositórios do GitHub com projetos adequados para contribuições de iniciantes. Podem ser um bom ponto de partida para a escolha do projeto.Este projeto é aplicado em cursos de engenharia de software em várias universidades do mundo. O site do curso de Eng. de Software da U. de Michigan (o mais detalhado que encontrei e que está cheio de ótimas dicas de como fazer esse projeto) elenca alguns dos projetos com os quais seus alunos contribuíram nos últimos oferecimentos: Adobe Brackets. algorithms. Arrow. Atom. Cataclysm: Dark Days Ahead. Chronos Timetracker. City Scrapers. Coala. Docusaurus. Elasticsearch. Firefox. GitHub Desktop. Guppy. Jarvis-On-Messenger. Karrot. LMMS. Mission Pinball Framework. MusicBot. Mypy. neovim. Notepad++. NumPY. Open Broadcaster Software. Open Food Network. OpenRCT2. Oppia. pandas. Pantry-for-Good. plots2. Pytest. Pytorch. Red-DiscordBot. Runelite. scikit-learn. Strongbox. Sympy. Tenor Core. VSCode. wemake-python-styleguide. Wikimedia Commons Android App. Yoda. youtube-dl. Zulip.O site também mostra algumas das issues que seus alunos trabalharam. Vale a pena dar uma olhada. -
Fórum geral para fazer perguntas, compartilhar notícias e tudo o mais que acharem que está relacionado com Engenharia de Software e com a nossa profissão.
-
A partir dessa iteração espera-se que haja grande ênfase na criação de testes automatizados para o seu código. Use e abuse das técnicas vistas quando tratamos de BDD e TDD (Capítulos 7 e 8 do livro texto).
-
Usaremos o Pivotal Tracker para acompanhar de perto o que está sendo implementado. Por isso, a partir de agora, em cada iteração o grupo:
- deve manter as histórias do projeto no Pivotal Tracker; só será considerado o projeto no Pivotal que tiver sido criado por mim;
- deve colocar um ponteiro para o projeto do Pivotal na descrição de seu projeto no Github;
- cada
história no Pivotal Tracker deve ter uma indicação clara sobre as
iterações em que essa história foi trabalhada. Coloque um label para indicar se ela foi trabalhada na “iteração1”, “iteração2”, etc.
- indique quem é o dono (owner)
de cada história; note que nós (eu e o grupo) vamos coletar métricas do
Pivotal Tracker sobre quando a história foi reivindicada por um
desenvolvedor, terminada, entregue, etc. Não faça isso só no final, antes da entrega da iteração! A ideia é usar o Tracker como forma de gerenciar o projeto do jeito que ele deveria ser usado na prática. O dono (owner) deve, minimamente, verificar se a funcionalidade descrita na história está funcionando corretamente no Heroku antes de aceitar a história como pronta.
A partir desta iteração, espera-se que todas as histórias de usuário sejam cadastradas no Pivotal Tracker, que a descrição das histórias siga o formato Connextra, que as histórias sejam SMART e que toda história possua cenários de testes de aceitação/integração automatizados implementados com Cucumber + Capybara.
-
O projeto acontecerá em iterações de 2 semanas. No final da iteração, cada membro deve entregar uma avaliação das contribuições de cada um dos membros da equipe. As respostas serão confidenciais e usadas apenas na atribuição de notas individuais dos membros da equipe. Por isso, seja honesto e justo!
A entrega, individual, deve conter:
- link para o projeto no GitHub;
- uma frase que resuma o que você fez nessa iteração;
- para cada outro membro do grupo, a resposta da pergunta: "De modo geral, o membro excedeu as expectativas,
atendeu as expectativas, fez só o mínimo necessário (só para dizer que fez alguma coisa) ou ficou aquém das
expectativas do grupo durante a última iteração?" Justifique (brevemente) cada avaliação.
Considere todos os fatores que podem contribuir para o desenvolvimento do projeto: essa pessoa se comunicou com o resto da equipe de forma eficiente? Ela tentou fazer a sua parte no trabalho? Ela estava tecnicamente preparada para realizar o trabalho (ela tinha conhecimento do que foi visto em aula e das ferramentas necessárias)?
-
-
Os processos Planeje-e-Documente e Métodos Ágeis
-
Ver
-
-
Tutorial sobre Rails e início do projeto
-
Videoaula: Tutorial de Rails URL
-
Texto do chat da aula de segunda URL
-
Videoaula: Tutorial de Rails URL
-
-
Software como Serviço e Arquitetura Orientada a Objetos
-
Ver
-