Descrição

Utilizar semana para treinar mais recursos do Python e conhecer outras bibliotecas úteis, como o Pandas.

Tarefas

• Alcançar nível 6 no Checkio.
• Realizar commit de um arquivo de treinamento .py na branch de treinamentos (python-pandas).
• Pesquisar meios de conversão de arquivo de texto para pdf. Sugestão da prof. @RochaCarla: https://github.com/luanguimaraesla/pandocker.

Critérios de Aceitação

• Nível de perfil Checkio igual ou superior a 6.
• Enviar arquivo de treinamento.

Descrição

Como Scrum Master, elaborar pesquisa sistemática sobre tópicos concernentes ao método ágil Scrum que demonstrem ser fundamentais para o bom desenvolvimento e aperfeiçoamento do projeto e da equipe.

Tarefas

• O que é o Scrum;
• Papéis dos membros da equipe;
• Funcionalidades e métodos;

Critérios de aceitação

Postar um resumo ou link nesta mesma issue.

Pacote pip

Desenvolver pacote pip para o módulo gera_documentos que está na devel. Já subir, permitir que seja instalado pelo terminal com pip install, e executar o init.py a partir da linha de comando, passando o nome do módulo e os parâmetros de entrada.

Critérios de aceitação

• pacote pip publicado e permitindo instalação com pip install
• poder ser executado via linha de comando ,uma vez instalado pelo pip
• executar o main do initi.py com a passagem de parâmetros no terminal

Descrição

Traduzir todos os arquivos do diretório cmd da branch commands

Critérios de aprovação

• about.txt
• architecture.txt
• help.txt
• list.txt

Descrição

Utilizar semana para estudar arquitetura de software, documentação de projeto e organização do repositório (branches, issues, commits, etc).

Tarefas

• Estudar o básico de arquitetura de software.
• Estudar sobre documentação de projeto.
• Pesquisar sobre organização do repositório.

Critérios de Aceitação

Enviar pequeno resumo até o final da sprint atual (22/11).

Por favor, entrem no link abaixo para que possamos compartilhar o mesmo board do zenbhub.
https://app.zenhub.com/workspaces/mds-team-63738b7798675e7b74c6469c/board?invite=CBKVCxCvrRmCouLDVT1XPY8w

Descrição

Ao gerar os documentos, aparecem apenas uns logs dentro do terminal, essa Issue busca desenvolver uma barra de loading mais apropriada para a geração de documentos

Critérios de avaliação

• Barra de loading no CLI
• Funcionamento normal de todo o fluxo da geração de documentos
• branch e pull request

Descrição

Criação do Story Map e do product backlog

Critérios de aceitação

• ProductBacklog no README.md
• Descrição das histórias de usuário
• branch e pull request

Descrição

Por enquanto a função filter_data(), em /src/modules/data_cleaning.py, aceita somente datasets em csv.
Implementá-la para que também possa aceitar mais formatos de input e retornar o mesmo formato de output especificado na arquitetura.

Tarefas

• Aprimorar a filter_data() para que possa receber outras extensões de dataset (xlsx, html, xml, json, etc);
• Empregar meios de a função lidar com erros (FileNotFoundError, extensão inválida, etc);

Critérios de aceitação

• Função funcionando

Descrição

Update na GitPage, adicionando mais conteúdo a ela.

Critérios de avaliação

• Example of Use novo
• Mudar as cores das caixas de código
• Pull Request e Merge

Reuniões semanais

Comentem abaixo, por favor, quais são seus melhores dias e horários para realizarmos uma reunião semanal (provavelmente online).

Calculo que, devido ao tamanho do projeto, os encontros durarão não mais que 20 minutos.

Descrição

• Ajustar nomes de variáveis em funções (tudo em inglês)
• Comentários de código (caso necessário, comunicar com o resto equipe)

Critérios de aceitação

• código comentado, revisado e com ajustes nas variáveis
• branch e pull request

Descrição

O pacote pip precisa ser disponibilizado, a fim de permitir download via CLI em qualquer ambiente Python.

Nome final : mkdocs-s7

Critérios de aceitação

• Possibilidade de instalar o pacote via CLI
• Testes em ambiente linux, windows, conda, env...
• Execução do comando via CLI
• Execução correta de todos as possibilidades
• Uso das flags --help e --about

Descrição

Como recomendação da professora, é necessário adaptar o README do projeto, de acordo com a documentação apresentada por ela:

O que precisa :

Descrição

Resumo do que foi feito na primeira release

Funcionalidades

• Lista das funcionalidades entregues (com a issue relacionada)
• Lista de artefatos realizados (docs feitos)

Bugs Mapeados

• O que vcs encontraram de problemas e precisam resolver na r2

link da mensagem

Critérios de Aceitação

• README atualizado e seguindo padrão de projeto de software
• Branch e pull request

Tarefas:

• criar arquivo codeowners
• linckar PR's com os respectivos owners

Descrição

Tarefas

• Dominar o básico da linguagem Python: números, strings, listas, dicionários, sets, funções, laços de repetição, estruturas condicionais, etc.
• Alcançar nível igual ou superior a 5 no (Checkio) para python, postando, na sequência, o link do perfil do Checkio nesta mesma issue.

Critérios de aceitação

• Nível do perfil Checkio igual ou superior a 5.

Descrição

Continuar desenvolvimento da pipeline iniciada nas sprints anteriores.

Prioridades:

• Aprimorar código yml do python publish referente ao github actions;
• Ajustar bug do incremento de versões (bumpversion);
• Se os dois itens acima falharem, pesquisar formas alternativas de esquematizar um CICD usando bibliotecas externas (ex.: Poetry);

Secundários

• Estágio de testes unitários (cobertura mínima de 70%)
• Verificação de codestyle

Critérios de Aceitação

• Workflow funcionando adequadamente, sempre quando houver um push na main e/ou lançamento de uma nova release.

Descrição

Utilizar semana para pesquisar sobre os pacotes do Python (pip): o que são, como funcionam, como criá-los e atualizá-los. Realizar testes.

Tarefas

• Pesquisar sobre pacotes pip do Python.
• Realizar testes, se possível.

Critérios de Aceitação

Enviar resumos e link úteis nesta issue.

Descrição

Issue destinada a definição de padrões de código, workflow. A fim de garantir integridade e padronização durante todo o percorrer do projeto

Tarefas

Os seguintes padrões devem ser definidos:

• Nome de arquivos, variáveis, classes e métodos
• Codestyle
• Branches no git
• Commits no git
• Ambientes virtuais

Critérios de aceitação

• Documento de especificação de nomes de arquivos, variáveis, classes e métodos anexado ao comentário na Issue
• Criação das branches no git e anexo do diagrama no comentário da issue
• Anexo de documento de padronização de commits no comentário da Issue
• Anexo de documento explicitando o padrão de ambiente virtual
• Chamada de alinhamento geral, a fim de passar todos os padrões definidos para os outros integrantes da equipe

O que é arquitetura?

A palavra “arquitetura” evoca visões de poder e mistério. Isso nos faz pensar em decisões pesadas e
proeza técnica profunda. A arquitetura de software está no auge da realização técnica.

A arquitetura de um sistema de software é a forma dada a esse sistema por aqueles que a constroem. A forma
dessa estrutura está na divisão desse sistema em componentes, o arranjo desses componentes, e as maneiras
pelas quais esses componentes comunicar uns com os outros.

O objetivo dessa forma é facilitar o desenvolvimento, implantação, operação, e manutenção do sistema
de software nele contido.

A estratégia por trás dessa facilitação é deixar tantas opções em aberto quanto possível, pois tanto tempo quanto possível.

O objetivo principal da arquitetura é dar suporte ao ciclo de vida do sistema. Uma boa arquitetura torna
o sistema fácil de entender, fácil de desenvolver, fácil de manter, e fácil de implantar. O objetivo final é
minimizar o custo de vida útil do sistema e para maximizar a produtividade do programador.

Desenvolvimento

Um sistema de software difícil de desenvolver provavelmente não terá uma vida útil longa e saudável. Portanto, a arquitetura de um sistema deve torná-lo fácil de se desenvolver, pela a(s) equipe(s) que o desenvolvem.

Diferentes estruturas de equipe implicam em diferentes decisões arquitetônicas. Por um lado, uma pequena equipe de cinco desenvolvedores pode trabalhar efetivamente em conjunto para desenvolver um sistema monolítico sem componentes ou interfaces bem definidos. Na verdade, tal equipe provavelmente acharia as restrições de uma arquitetura algo como um impedimento durante os primeiros dias de desenvolvimento. Esta é provavelmente a razão pela qual tantos sistemas carecem de boa arquitetura: Começaram sem nenhuma, porque a equipe era pequena e não queria o impedimento de uma superestrutura.

Por outro lado, um sistema sendo desenvolvido por cinco equipes diferentes, cada uma incluindo sete desenvolvedores, não pode progredir a menos que o sistema seja dividido em componentes bem definidos com interfaces confiáveis ​​e estáveis. Se nenhum outro fator for considerado, a arquitetura desse sistema provavelmente evoluirá para cinco componentes—
um para cada equipe.

Essa arquitetura de componente por equipe provavelmente não é a melhor arquitetura para implantação, operação e manutenção do sistema. Não obstante, é o arquitetura em que um grupo de equipes irá gravitar se forem movidos apenas por cronograma de desenvolvimento.

Implementação

Para ser eficaz, um sistema de software deve ser implantável. Quanto maior o custo de implantação, menos útil é o sistema. Um objetivo de uma arquitetura de software, então, deve ser criar um sistema que possa ser facilmente implementado com uma única ação.

Infelizmente, a estratégia de implantação raramente é considerada durante o desenvolvimento inicial. Isso leva à arquiteturas que podem tornar o sistema fácil de se desenvolver, mas deixá-lo muito difícil de implementar.

Operação

O impacto da arquitetura na operação do sistema tende a ser menos dramático do que o impacto da arquitetura no desenvolvimento, implementação e manutenção. Quase qualquer dificuldade operacional pode ser resolvida jogando mais hardware no sistema sem afetar drasticamente a arquitetura do software.

De fato, vemos isso acontecer repetidamente. Sistemas de software que possuem arquiteturas ineficientes muitas vezes podem ser feitas para funcionar de forma eficaz simplesmente adicionando mais armazenamento e mais servidores. O fato de que o hardware é barato e as pessoas estão caras significa que as arquiteturas que impedem a operação não são tão caras quanto arquiteturas que impedem o desenvolvimento, implantação e manutenção.

Manutenção

De todos os aspectos de um sistema de software, a manutenção é o mais caro. O não termino de novos recursos e o inevitável rastro de defeitos e correções consomem grandes quantidades de recursos humanos.

O custo primário de manutenção está em espeleologia e risco. Espeleologia é o custo de vasculhando no software existente, tentando determinar o melhor lugar e a melhor estratégia para adicionar um novo recurso ou reparar um defeito. Ao fazer tais mudanças, o a probabilidade de criar defeitos inadvertidos está sempre presente, aumentando o custo do risco.

Uma arquitetura cuidadosamente pensada reduz amplamente esses custos. Ao separar o sistema em componentes e isolando esses componentes por meio de interfaces, é possível iluminar os caminhos para futuras funcionalidades e, em muito, reduzir o risco de quebra inadvertida.

Resumo de tradução livre: primeira parte do capítulo 15 Clean Architecture

Requisitos funcionais e não funcionais do sistema

Comentem abaixo quais requisitos vocês acham que são fundamentais para o nosso projeto, focando na Release 1(R1).

Atenção: A R1 está programada para acontecer no dia 13/12/22 (MENOS DE 1 MÊS!!!!).

Descrição

Testes

• Biblioteca Pytest - pytest: helps you write better programs — pytest documentation

• Testes unitários

• 80% de cobertura

• Pesquisa sobre a biblioteca Pytests

• Realização dos testes

Descrição

Verificar e testar em quais versões do Python o pacote funiona, fazer o teste desde o Python 2.0.1 até a versão mais nova Python 3.11.1, sendo pelo menos 10 casos testes.

Critérios de avaliação

• 10 casos testes, 1 por versão
• Funcionamento normal de todo, relaçao dos erros encontrados
• Atualização do README
• branch e pull request

Descrição

Debug do código fonte.

Prioridades:

• Encontrar bugs nos módulos (data_cleaning, doc_generator, usable, etc) e na main através de variados casos de teste utilizando o pytest ou qualquer outra biblioteca que acharem útil ou necessária;
• Propor soluções para eliminação dos bugs encontrados;
• Reportar à equipe caso seja preciso realizar uma grande mudança de código;

Critérios de Aceitação

• Commits e pull request com descrição das atividades desenvolvidas.

Descrição
Editar vídeo apresentando o que foi realizado no projeto para a R1 e apresentá-lo para professora

Critérios de avaliação

• Gravar vídeo
• Editar vídeo com menos de 10 minutos
• Colocar vídeo no drive

Módulo gera Documentos

O módulo gera documentos é responsável por receber um conjunto de dados, e um template, e fazer as substituições das chaves. Gerando no fim os arquivos preenchidos:

Critérios de aceitação

• Módulo encapsulado com assinatura: path_template, dicionário_chave_valor, nome do arquivo de saída, flag pdf ou não
• Geração de documentos a partir de template md
• Conversão para pdf caso flag == 1
• Padronização do nome do arquivo, a fim de criar arquivo com nome aceito pelo sistema operacional
• pull request do módulo

Assinatura dicionário chave_valor:

{
"NOME": "Rafael",
"DISCIPLINA": "Sistema de bancos de dados 1",
"DATA": "23 de Novembro de 2022",
"CPF": "074.157.341-50",
"MATRICULA": "200026788"
}

Descrição

Elencar bibliotecas para envio de e-mails em python

Critérios de Aceitação

• Descrever nos comentários link de bibliotecas
• Responder à questão : Usaremos um email próprio ou solicitaremos o do usuário?
• Realizar testes, criando uma função que recebe um nome, email e documento e faz o envio.

Descrição

Implementar features de abrir e processar os arquivos de dataset e template nos Módulos de Tratamento de Dados e Geração de Certificados, respectivamente.

Tarefas

• Criar issue para feature de tratamento de dados na atual sprint;
• Criar issue para feature de geração de certificados na atual sprint.

Critérios de Aceitação

Todas as tarefas cumpridas.

Descrição

• Ajustar nomes de variáveis em funções (tudo em inglês)
• Comentários de código (caso necessário, comunicar com o resto equipe)

Critérios de aceitação

• código comentado, revisado e com ajustes nas variáveis
• branch e pull request

Descrição

Issue destinada ao lançamento da versão 1.0.0 do pacote ez-docs dentro do sistema de distribuição python PyPI

Critérios de Aceitação

• Pacote atualizado dentro do PyPI
• Testes executados em ambientes linux e windows, com instalação e utilização do pacote
• Verificação de todos os documentos (README, LICENCE . . . )
• Branch e pull request

Github Pages

Definição, construção e deploy da landing page do projeto.

Critérios de avaliação

• página landing page com apresentação do projeto e informações importantes
• link no corpo do github, hospedada no github pages

Descrição

Desenvolver documentação README.md, atualizando todos os comandos necessários, escopo do projeto, equipe etc...

Adequar o projeto aos padrões de software livre (padrões da comunidade)
Padrões Software Livre

Critérios de aceitação

• Todos os padrões de software livre marcados
• Readme atualizado e legível
• Branch e pull request (devel)

A partir de 23/11, por decisão em conjunto do squad, as sprints passarão de ciclo semanais de terças em terças para quartas e quartas.

Módulo gera Documentos

O módulo gera documentos é responsável por receber um conjunto de dados, e um template, e fazer as substituições das chaves. Gerando no fim os arquivos preenchidos:

Critérios de aceitação

• Módulo encapsulado com assinatura: path_template, dicionário_chave_valor, nome do arquivo de saída, flag pdf ou não
• Geração de documentos a partir de template md
• Conversão para pdf caso flag == 1
• Padronização do nome do arquivo, a fim de criar arquivo com nome aceito pelo sistema operacional
• pull request do módulo

Assinatura dicionário chave_valor:

{
"NOME": "Rafael",
"DISCIPLINA": "Sistema de bancos de dados 1",
"DATA": "23 de Novembro de 2022",
"CPF": "074.157.341-50",
"MATRICULA": "200026788"
}

Descrição

Pesquisar métodos para setar o CI e CD no girthub
Somente será feito CI/CD com a branch main:

Prioridades:

• Lançar versão nova do pacote python no PyPi

Secundários

• Estágio de testes unitários (cobertura mínima de 70%)
• Verificação de codestyle

Critérios de Aceitação

• Comentários com link de artigos e exemplos de como realizar os objetivos
• Spikes de testes

Ideias de projeto

O grupo apresentou as seguintes sugestões:

Tema 1: RU+

1. Consulta e depósito de saldo;
2. Consulta do cardápio semana;
3. Ranking de refeições mais votadas;

Tema 2: Dados abertos (sugestão da professora)

1. Analisar dados criticamente e matematicamente utilizando conceitos como média, mediana, moda, desvio-padrão, variância;
2. Aplicar conceitos de inferência estatística para fazer suposições sobre como a disposição dos dados se refletem nas dinâmicas da sociedade;
3. Empregar conceitos e novidades de Data Sciente e Data Visualization;

Tema 3: Geração automatizada de certificados (sugestão da professora)

1. Gerar certificados pdf automaticamente através de uma lista (planilha) de dados um template definido pela usuário;
2. Enviar o pdf gerado por email;
3. Definir regras lógicas: por exemplo, gerar certificado de todos os alunos que tiveram presença igual ou superior a 75% e nota maior ou igual a 5,0.

Descrição

Ajustar o uso do ícone do projeto dentro da github pages do projeto, além de mudar os nomes das páginas para o novo nome do pip install.

Critérios de aceitação

• ícone no favicon da página
• Ícone aparecendo em todos os displays da página
• Mudar o nome de mkdocs para ez-docs
• Branch e pull request

Descrição

A ideia é estender a lista de comandos possíveis na chamada do main.py.
A princípio, os dois comandos adicionais serão:
--help: printa na janela de comando um pequeno tutorial de como utilizar o nosso framework.
--about: printa na janela de comando uma série de informações sobre o projeto: membros, disciplina, professora, arquitetura, etc.

Critérios de Avaliação

• Chamada do --help via CLI
• Chamada do --about via CLI
• Branch e pull requests