Skip to content
Snippets Groups Projects
Commit 31a242a9 authored by Eduardo E. R. Junior's avatar Eduardo E. R. Junior
Browse files

Distribuí informações do plano.md nos demais arquivos do projeto 

- Migra o mini-roteiro de códigos para o CONTRIBUTING.md
- Migra a lista de obras para o README.md
- Atualiza o painel de realização com espaço para todas as semanas
- Realiza correções ortográficas
parent 8fc1bc72
No related branches found
No related tags found
No related merge requests found
Show whitespace changes
Inline Side-by-side
CONTRIBUTING.md
+ 164
− 42
View file @ 31a242a9
% Guia de Contribuição
% PET Estatística UFPR - <pet.estatistica.ufpr@gmail.com>
# Guia de Contribuição #
**PET Estatística UFPR** - <pet.estatistica.ufpr@gmail.com>
> "O segredo de progredir é começar. O segredo se começar é dividir as
> tarefas árduas e complicadas em tarefas pequenas e fáceis de executar
......@@ -9,10 +10,10 @@
## Para que serve um Guia de Contribuição? ##
O Guia de Contribuição Serve para orientar a forma de trabalhar, tanto
O Guia de Contribuição serve para orientar a forma de trabalhar, tanto
individual quanto em equipe, para que seja eficiente, padronizada,
coordenada e segura. Ele estabelece as regras e etapas principais do
deselvolvimento de um projeto. O Guia de Contribuição incluí orientações
desenvolvimento de um projeto. O Guia de Contribuição incluí orientações
de como escrever o código, mensagens de commit, etc TODO
Interessados em participar do projeto devem se orientar pelo Guia de
......@@ -25,7 +26,9 @@ resultados do projeto.
O fluxo de trabalho é a sequência de etapas que devem ser cumpridas para
atingir um resultado.
## Qual é o fluxo de trabalho do *labestData*?
## Qual é o fluxo de trabalho do *labestData*? ##
**Descrição do roteiro semanal**
1. Criar um *issue* para o Projeto no GitLab. Ao criar o *issue*,
dedique-se para escrever uma detalhada descrição do trabalho a ser
......@@ -63,12 +66,12 @@ atingir um resultado.
6. Quando cumprir com o trabalho previsto no seu *issue*, dê o push
final e faça uma requisição de mescla - um *merge request* (MR). Ao
criar o MR, assim como foi para o *issue*, existe um espaço para a
descrição de tudo o que o *branch*. Basicamente isso é um resumo de
todos os *commits* feitos. Embora a descrição do *issue* informe o
que estava previsto fazer, isso não significa que tudo foi
feito. Você pode ter feito trabalho a mais, ou visto que algo não
foi necessário. Então relate na descrição do MR exatamente o
que será adicionado ao ramo alvo. Os MR devem ser para o ramo
descrição de tudo o que foi realizado no *branch*. Basicamente isso
é um resumo de todos os *commits* feitos. Embora a descrição do
*issue* informe o que estava previsto fazer, isso não significa que
tudo foi feito. Você pode ter feito trabalho a mais, ou visto que
algo não foi necessário. Então relate na descrição do MR exatamente
o que será adicionado ao ramo alvo. Os MR devem ser para o ramo
`devel` e devem ser atribuídos à outra pessoa.
7. Aguarde a avaliação do MR. Nessa etapa quem trabalha é o *merger* -
colaborador responsável por avaliar o seu *branch* e aplicar o
......@@ -76,13 +79,139 @@ atingir um resultado.
contrário, você será notificado.
8. Se o MR não foi aceito, o *merger* vai informar o que fazer com
mensagem abaixo da descrição do merge. Faça as adequações
solicitadas. Retome da etapa 4.
solicitadas. Refaça a etapa 4.
9. Quando o MR for aprovado, feche o *issue* correspondente. Indique
na mensagem de fechamento do *issue* qual foi o número do MR
dele. Os ramos de demanda - com prefixo *issue* - são removidos
dele. Os ramos de demanda - com prefixo *coloborador* - são removidos
após o *merge* mas os *issues* e os MR - que junto com os *commits*
contam a trajetória do projeto - permanem no GitLab.
**Guia de códigos R e GIT para as atividades semanais**
A cada semana nós devemos criar novos ramos para realização das
atividades propostas. Porém devemos nos atentar ao criá-los. Estes ramos
devem necessariamente sair do ramo `devel` e não é necessário a
incorporação do ramo de trabalho anterior (solicitado por MR) para que
este seja criado. Abaixo temos os comandos GIT para criar o ramo a
partir do `devel`.
```bash
## Atualiza todos os ramos com a versão do servidor
git pull
## Retorna para o ramo devel
git checkout devel
## Cria um ramo para atividades propostas no issue00
git branch fulano00
## Vai para o ramo criado
git checkout fulano00
```
Com isso já estamos em um ramo, `fulano00` criado especificamente para o
desenvolvimento das atividades propostas no `issue#00`, assim podemos
prosseguir com o trabalho propriamente dito, a adição de conjunto de
dados.
```r
##======================================================================
## Passo 1 - Ler e inserir os dados na pasta ./data-raw/
## Usando o R ----------------------------------------------------------
## Transcreva os dados das tabelas
ex <- expand.grid(X1 = 1:6, X2 = LETTERS[1:4])
x3 <- scan()
CiclanoTb0.0 <- data.frame(X1 = ex$X1, X2 = ex$X2, X3 = x3)
## Salve a tabela em formato txt no diretório ./data-raw/
write.table(CiclanoTb0.0,
file = "./data-raw/CiclanoTb0.0.txt",
sep = "\t",
row.names = FALSE)
## Você pode usar a função write2txt() definida em:
## https://gitlab.c3sl.ufpr.br/snippets/34.
write2txt(CiclanoTb0.0)
## Usando outro software -----------------------------------------------
## Transcreva os dados da tabela no software e salve-os no formato txt
## na pasta ./data-raw/
## Leia os dados na sessão R, para utilizá-los posteriormente
CiclanoTb0.0 <- read.table("./data-raw/CiclanoTb0.0.txt",
header = TRUE, sep = "\t")
##======================================================================
## Passo 2 - Inserir os dados no diretório ./data/
library(devtools)
use_data(CiclanoTb0.0)
## Você pode usar a função write2rda() definida em:
## https://gitlab.c3sl.ufpr.br/snippets/34.
write2rda(CiclanoTb0.0)
##======================================================================
## Passo 3 - Escreva a documentação utilizando as tags roxygen2
## Dica: rode os códigos da sessão exemplo aqui, para verificar se os
## gráficos/tabelas são realizadas corretamente.
table(CiclanoTb0.0)
plot(X1 ~ X2, data = CiclanoTb0.0)
## Você pode usar a função write2Rdoc() definida em:
## https://gitlab.c3sl.ufpr.br/snippets/34. Essa função cria o arquivo
## com nome do objeto e algumas já escreve algumas informações,
## retiradas do próprio objeto. Depois de usar, abra o arquivo e
## preencha o restante.
write2Rdoc(CiclanoTb0.0)
##======================================================================
## Passo 4 - Gere e check a documentação (insere um arquivo no diretório
## ./man/). Obs.: O aviso sobre o NAMESPACE pode ser ignorado, pois o
## document() tenta criar um NAMESPACE onde já há um existente, mas isso
## não é problema pois ambos são arquivos sem conteúdo relevante.
document()
check_man()
##======================================================================
## Passo 5 - Verifique a constituição e organização do pacote (caso haja
## ERROS, WARNINGS ou mais de um NOTE. Corrija o problema e continue do
## passo 4)
check()
```
Após todos os passos concluídos devemos ter os arquivos `.txt`, `.rda`,
`.R` e `.Rd` devidamente criados. Podemos voltar ao terminal e *comitar*
nossas contribuições.
```bash
## Adiciona os 4 arquivos criados e commita as alterações
git add data-raw/. data/. R/. man/CiclanoTb0.0
git commit -m "Adiciona tabela 0.0 do livro do Ciclano"
## Desconsidera as alterações realizadas nos arquivos que são gerados
## automaticamente
git checkout .
## Enviando as alterações para o servidor
git push origin fulano00
```
Agora com tudo *commitado* podemos seguir para o próximo conjunto de
dados e refazer todos os passos descritos.
Vale ressaltar que este guia de códigos compreende a rotina básica para
inclusão de um conjunto de dados, se for necessária a inclusão de um
biblioteca para elaboração de gráficos ou análises ou ainda forem
criadas funções para o pacote os arquivos NAMESPACE e DESCRIPTION
deverão ser alterados e essas alterações *commitadas*.
## O que é um Guia de Estilo de Código? ##
Um Guia de Estilo de Código é um conjunto de recomendações (ou regras)
......@@ -100,7 +229,7 @@ padrão particular para escrita de código.
## Qual o guia de estilo de código? ##
No pacote *labestData* deve ser considerado o *idiom* padrão do R,
No pacote *labestData* deve ser considerado o *"idioma"* padrão do R,
descrito no [STYLEGUIDE.md].
## Como dar nome aos datasets? ##
......@@ -129,6 +258,8 @@ tabela na obra. Considera os exemplos
* PimentelPg142: Dados em Pimentel-Gomes (2009) que estão em tabelas
distribuidas em duas páginas mas não tem legenda, assim usa-se o
número da primeira página.
* CharnetApD.1: Primeiro conjunto de dados apresentado no apêndice D
do livro Charnet (2008).
A prioridade na hora de atribuir a identificação é a seguinte: Tabela =
Quadro > Exemplo = Exercício > Página. Ou seja, se a tabela 5 faz parte
......@@ -205,7 +336,7 @@ campos sejam praticamente autoexplicativos, segue breve explicação.
#'
#' }
#'
#' @keywords DBC arroz
#' @keywords DBC
#'
#' @source Ramalho, M. A. P., Ferreira, D. F., & Oliveira,
#' A. C. de. (2005). Experimentação em genética e melhoramento de
......@@ -238,21 +369,6 @@ preencha as informações. Use o resultado gerado para vitar a obra.
<http://r-pkgs.had.co.nz/man.html#man-data>
-->
<!------------------------------------------- -->
## Como criar um *branch*? ##
Um *branch* é criado de duas formas, conforme abaixo.
```
# Com duas instruções.
git branch novo # cria
git checkout novo # move
# Com uma instruções 2 em 1
git checkout -b novo
```
## Como criar um *issue*? ##
De uma maneira simples, um *issue* é uma tarefa. Quando você cria um
......@@ -274,6 +390,13 @@ Na página de criar um *issue*, você deve preencher os seguintes campos:
* Labels: com as palavras chaves apropriadas para o *issue*, se
alguma.
No projeto **labesData** são adotadas como _Milestones_, as obras
elencadas para transcrição dos dados ao pacote e os _Labels_ são as
disciplinas Estatísticas que a obra coompreende. Por exemplo, ao criar
um _issue_ que propõe a adição de três conjuntos de dados do capítulo 3
do livro Estatística Multivariada de Ferreira (2011) deve-se selecionar
a _milestone_ `Ferreira` e o _label_ `Análise Multivariada`.
Feito isso, clique em *Submit issue*.
## Quanto de trabalho representa um *issue*? ##
......@@ -288,7 +411,7 @@ grande função, que demora por volta de 5 horas de trabalho. Uma
dedicação de 2 horas pode não ter uma função pronta que passe nas
verificações de *build*. No primeiro caso, por outro lado, se o trabalho
é texto, por exemplo, mesmo que este esteja incompleto a verificação de
*build* ser verde.
*build* será verde.
## Como fechar ou editar um issue ##
......@@ -300,8 +423,9 @@ mesmo. Deve-se dedicar na hora de atribuir título e descriação para que
sejam apropriados e sem necessidade de mudar.
Na página de um *issue* é possível fazer uma discussão sobre ele, bem
como atribuir a outro colaborador. Quandor o issue for concluído,
deve-se fechá-lo.
como atribuir a outro colaborador. Quandor o issue for concluído, ou
seja quando o ramo dedicado as tarefas descritas neste _issue_ for
mesclado ao `devel`, deve-se fechá-lo.
## Como fazer mensagens de *commit*? ##
......@@ -329,11 +453,10 @@ Inclui dataset da página 103
- Adiciona ./data/dataset103.rda.
- Adiciona ./R/dataset103.R.
- Adiciona ./man/dataset103.Rd.
- Atualiza no NAMESPACE.
```
As mensagens de *commit* devem ter verbos conjugados no presente do
indicativo (ele faz, completa, adiciona, remove, edita, conserta,
indicativo (faz, completa, adiciona, remove, edita, conserta,
produz, gera, corrige, documenta, escreve, move, transforma, modifica).
## Como criar um *merge request*? ##
......@@ -352,8 +475,7 @@ satisfeitas:
1. O trabalho deve estar concluído. Isso significa de o que previsto
precisa ser cumprido. Em caso de não conclusão, uma justificativa
deve ser dada e aceita. Se o trabalho foi mal dimensionado, abra um
*issue* no futuro para concluí-lo.
deve ser dada e aceita.
2. O *branch* tem que ter *build sucess*. A vantagem, dentre muitas,
da integração contínua, é sabermos se um ramo tem problemas de
código. Se um *branch* não passa nas verificações do *build*,
......@@ -375,13 +497,13 @@ diretório raíz é o `/labestData`.
diretório `./data-raw`. Usar TAB com separador de campo e ponto
como separador decimal.
2. Criar o `dados.rda`. Carregar o `dados.txt` e criar a imagem do
objeto (`*.rda` ou `*.RData`) no diretório `./data`. A forma mais
simples é usar a função `devtools::use_data(dados)`.
objeto (`*.rda`) no diretório `./data`. A forma mais simples é usar
a função `devtools::use_data(dados)`.
3. Fazer a documentação dos dados. Criar o arquivo `dados.R` no
diretório `./R/`.
4. Gerar o arquivo `dados.Rd`. Com o comando `devtools::document()`
gerar os arquivos de documentação que ficam no diretório
`./man`. Use `devtools::check_doc()` para verificar a documentação.
`./man`. Use `devtools::check_man()` para verificar a documentação.
5. Por fim, execute `devtools::check()` e `devtools::build()`. Observe
se ocorrem notificações de `ERROR`, `WARNING` ou `NOTE`. Faça
correções para removê-las.
......@@ -406,7 +528,7 @@ labestData/
1. As atividades do *issue* foram concluídas.
2. O código está de acordo com o Guia de Estilo de Código.
3. O `devtools::check()` e `devtools::build()` executam notificações
negativas.
3. O `devtools::check()` e `devtools::build()` não executam
notificações negativas.
4. O *branch* passa na integração contínua com *build status*
positivo.
README.md
+ 78
− 2
View file @ 31a242a9
% labestData
% PET Estatística UFPR - <pet.estatistica.ufpr@gmail.com>
# labestData #
**PET Estatística UFPR** - <pet.estatistica.ufpr@gmail.com>
> “Without data, you're just another person with an opinion.”
>
......@@ -28,6 +29,80 @@ O projeto tem dois objetivos principais:
conjuntos de dados na forma de um pacote R de tal forma que possam
ser usados para o ensino de Estatística.
Nesta primeira fase do projeto foram definidas algumas obras nacionais
para transcrição e documentação de suas tabelas de dados ao pacote. As
obras escolhidas estão descritas abaixo e compreendem as disciplinas de
Planejamento de Experimentos, Análise de Regressão Linear e Análise
Estatística Multivariada.
<!-- Inserir links das milestones que representam os livros -->
1. Banzatto, D. A., Kronka, S. D. (2013). **Experimentação Agrícola**
(4th ed.). Jaboticabal, SP: Funep.
[_Milestone_ Banzatto](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/1)
<!-- [*Walmes Zeviani*](https://gitlab.c3sl.ufpr.br/walmes) -->
2. Mingoti, S.A. (2005). **Análise de dados através de métodos de
estatística multivariada - uma abordagem aplicada**. Belo
Horizonte, MG: Editora UFMG.
[_Milestone_ Mingoti](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/2)
<!-- [*Paula Alessandra*](https://gitlab.c3sl.ufpr.br/pazd11) e -->
<!-- [*Ângela Legey*](https://gitlab.c3sl.ufpr.br/alcl12) -->
3. Ramalho, M. A. P., Ferreira, D. F., Oliveira,
A. C. (2005). **Experimentação em Genética e Melhoramento de
Plantas** (2th ed.). Lavras, MG: Editora UFLA.
[_Milestone_ Ramalho](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/3)
<!-- [*Jhenifer Veloso*](https://gitlab.c3sl.ufpr.br/jcv12) -->
4. Barros, W. S., Dias, L. A. S. (2009). **Biometria
Experimental**. Viçosa, MG: Editora UFV.
[_Milestone_ Barros](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/4)
<!-- [*Altamiro Basiewics*](https://gitlab.c3sl.ufpr.br/aab15) -->
6. Zimmermann, F.J. (2004), **Estatística aplicada à pesquisa agrícola**
(1st ed.). Santo Antônio de Goiás, GO: Embrapa Arroz e Feijão.
[_Milestone_ Zimmermann](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/6)
<!-- [*Bruna Wundervald*](https://gitlab.c3sl.ufpr.br/bdw13) -->
7. Pimentel-Gomes, F. (2009). **Curso de Estatística Experimental**
(15th ed.). Piracicaba, SP: FEALQ.
[_Milestone_ Pimentel-Gomes](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/7)
<!-- [*Bruno Geronymo*](https://gitlab.c3sl.ufpr.br/bg15) -->
8. Ferreira, D. F. (2011). **Estatística Multivariada** (2nd
ed.). Lavras, MG: Editora UFLA.
[_Milestone_ Mingoti](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/8)
<!-- [*Eduardo Junior*](https://gitlab.c3sl.ufpr.br/eerj12) -->
9. Manly, B. J. F. (2005). **Métodos Estatísticos Multivariados- uma
introdução**. Porto Alegre, RS: Bookman
[_Milestone_ Manly](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/9)
<!-- [*Gabriel Klostermann*](https://gitlab.c3sl.ufpr.br/gsk12) -->
10. Storck, L., Garcia, B. C., Lopes, S. J., Estefanel,
V. (2011). **Experimentação Vegetal** (3th ed.). Santa Maria, RS:
Editora UFSM.
[_Milestone_ Manly](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/10)
<!-- [*Mônica Ludmilla*](https://gitlab.c3sl.ufpr.br/mlho15) -->
11. Charnet, R., de Luna Freire, C.A., Charnet, E.M.R., Bonvino,
H. (2008). **Análise de modelos de regressão linear com aplicações**
(2nd ed.). Campinas, SP: Editora Unicamp
[_Milestone_ Pimentel-Gomes](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/11)
<!-- [*Daniel Ikenaga*](https://gitlab.c3sl.ufpr.br/di12) -->
12. Demétrio, C. G. B., & Zocchi, S. S. (2011). **Modelos de
Regressão**. Piracicaba: ESALQ.
[_Milestone_ Demetrio](https://gitlab.c3sl.ufpr.br/pet-estatistica/labestData/milestones/12)
<!-- [*Alcides Neto*](https://gitlab.c3sl.ufpr.br/acn13) -->
Ao término desta primeira fase pretende-se ter todos os conjuntos de
dados relevantes destas obras disponíveis para usuários do pacote. Ainda
*vignettes* (vinhetas), exemplificando a análise de dados (em códigos R)
referentes a cada disciplina compreendida, serão elaboradas para
servirem de inspiração ou roteiro para análise dos demais dados do
pacote.
## Quem são os desenvolvedores do *labestData*?
Os colaboradores do *labestData* são os bolsistas do PET, voluntários e
......@@ -173,6 +248,7 @@ dados que deseja usar.
ls("package:labestData") # Lista os objetos do pacote.
data(dados) # Traz para área de trabalho um dataset.
str(dados) # Mostra a estrutura do dataset.
help(dados) # Mostra as informações de ajuda do dataset
## Como reportar sugestões ou erros ao projeto *labestData*?
......
plano.md
+ 26
− 219
View file @ 31a242a9
# Painel de atividades do labestData #
- [Conteúdo previsto](#conteudo-previsto)
**PET Estatística UFPR** - <pet.estatistica.ufpr@gmail.com>
- [Painel de realização](#painel-de-realizacao)
- [Planejamento semanal](#planejamento-semanal)
- [Mini roteiro GIT e adição de *dataset*](#mini-roteiro-do-projeto)
Este painel tem por objetivo documentar as atividades semanalmente
planejadas para cada integrante bem como suas realizações conforme fluxo
de trabalho adotado para o projeto **labestData**.
## Conteúdo previsto ##
Nesta primeira fase do projeto foram definidas algumas obras nacionais
para transcrição e documentação de suas tabelas de dados ao pacote. As
obras escolhidas estão descritas abaixo e compreendem as disciplinas de
Planejamento de Experimentos, Análise de Regressão Linear e Análise
Estatística Multivariada.
<!-- Inserir links das milestones que representam os livros -->
1. Borges, C. G., Demétrio, & Zocchi, S. S. (2011). **Modelo de
Regressão. Piracicaba**, SP: USP.
Sob responsabilidade de
[*Alcides Neto*](https://gitlab.c3sl.ufpr.br/acn13)
2. MINGOTI, S.A. (2005). **Análise de dados através de métodos de
estatística mulq-tivariada - uma abordagem aplicada**. Belo
Horizonte, MG: Editora UFMG.
Sob responsabilidade de
[*Paula Alessandra*](https://gitlab.c3sl.ufpr.br/pazd11) e
[*Ângela Legey*](https://gitlab.c3sl.ufpr.br/alcl12)
3. Barros, W. S. & Dias, L. A. S. (2009). **Biometria Experimental**,
UFV Viçosa, MG.
Sob responsabilidade de
[*Altamiro Basiewics*](https://gitlab.c3sl.ufpr.br/aab15)
4. Zimmermann, F.J.(2004), **Estatística aplicada à pesquisa agrícola**
(1st ed.). Santo Antônio de Goiás, GO: Embrapa Arroz e Feijão.
Sob responsabilidade de
[*Bruna Wundervald*](https://gitlab.c3sl.ufpr.br/bdw13)
5. Pimentel-Gomes, F. (2009). **Curso de Estatística Experimental**
(15th ed.). Piracicaba: FEALQ.
Sob responsabilidade de
[*Bruno Geronymo*](https://gitlab.c3sl.ufpr.br/bg15)
6. Charnet, R., de Luna Freire, C.A., Charnet, E.M.R. & Bonvino,
H. (2008). **Análise de modelos de regressão linear com aplicações**
(2nd ed., p. 356). Editora Unicamp
Sob responsabilidade de
[*Daniel Ikenaga*](https://gitlab.c3sl.ufpr.br/di12)
7. Ferreira, D. F. (2011). **Estatística Multivariada** (2nd
ed.). Lavras, editora UFLA.
Sob responsabilidade de
[*Eduardo Junior*](https://gitlab.c3sl.ufpr.br/eerj12)
8. Manly, B. J. F. (2005). **Métodos Estatísticos Multivariados- uma
introdução**. Porto Alegre, RS: ARTMED
Sob responsabilidade de
[*Gabriel Klostermann*](https://gitlab.c3sl.ufpr.br/gsk12)
9. Ramalho, M. A. P., Ferreira, D. F. & Oliveira,
A. C. (2005). **Experimentação em Genética e Melhoramento de
Plantas** (2th ed.). Lavras: UFLA.
Sob responsabilidade de
[*Jhenifer Veloso*](https://gitlab.c3sl.ufpr.br/jcv12)
10. Banzatto, D. A., & Kronka, S. D. (2013). **Experimentação Agrícola**
(4th ed.). Jaboticabal, SP: Funep.
Sob responsabilidade de
[*Walmes Zeviani*](https://gitlab.c3sl.ufpr.br/walmes)
Ao término desta primeira fase pretende-se ter todos os conjuntos de
dados relevantes destas obras disponíveis para usuários do pacote. Ainda
*vignettes* (vinhetas), exemplificando a análise de dados (em códigos R)
referentes a cada disciplina compreendida, serão elaboradas para
servirem de inspiração ou roteiro para análise dos demais dados do
pacote.
[Retornar à tabela de conteúdo](#painel-de-atividades-do-labestdata)
## Painel de realização ##
**REFERENTE A 1º SEMANA (01/03 à 08/03)**
| Integrante | Realizou as atividades propostas ? | Solicitou MR ? |
|----------------------------------+----------------------+---------|
| Alcides Conte Neto | S :white_check_mark: | S :white_check_mark: |
| Altamiro Antonio Basiewics | S :white_check_mark: | S :white_check_mark: |
| Angela Luiza Cunha Legey | S :white_check_mark: | S :white_check_mark: |
| Bruna Davies Wundervald | S :white_check_mark: | S :white_check_mark: |
| Bruno Geronymo | S :white_check_mark: | S :white_check_mark: |
| Daniel Ikenaga | S :white_check_mark: | S :white_check_mark: |
| Eduardo Elias Ribeiro Junior | S :white_check_mark: | S :white_check_mark: |
| Gabriel Sartori Klostermann | S :white_check_mark: | S :white_check_mark: |
| Jhenifer Caetano Veloso | S :white_check_mark: | S :white_check_mark: |
| Monica Ludmila Hintz De Oliveira | N :x: | N :x: |
| Paula Alessandra Zeizer Dimas | S :white_check_mark: | S :white_check_mark: |
| Walmes Marques Zeviani | S :white_check_mark: | S :white_check_mark: |
| Cesar Augusto Taconeli | S :white_check_mark: | S :white_check_mark: |
Na tabela abaixo são apresentados os _status_ de realização das
atividades propostas para cada semana e integrante. Cada coluna da
tabela, com exceto a que apresenta os integrantes, mostra dois _status_
separados por um pipe (`|`). O estado à esquerda indica se as
atividades da semana foram realizadas e à direita é apresentado se o MR
foi aceito, ou seja, se as contribuições da respectiva semana foram
incorporados ao ramo `devel`. Para facitar a visualização o _emoji_
:white_check_mark:, representa o SIM e :x: o NÃO.
| Integrante | 1º S | 2º S | 3º S | 4º S | 5º S | 6º S | 7º S | 8º S | 9º S | 10º S |
|------------------------------------|:-----------------------------------------:|:-----:|:-----:|:-----:|:-----:|:-----:|:-----:|:-----:|:-----:|:-----:|
| Alcides Conte Neto | :white_check_mark: | :white_check_mark: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Altamiro Antonio Basiewics | :white_check_mark: | :white_check_mark: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Angela Luiza Cunha Legey | :white_check_mark: | :white_check_mark: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Bruna Davies Wundervald | :white_check_mark: | :x: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Bruno Geronymo | :white_check_mark: | :white_check_mark: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Daniel Ikenaga | :white_check_mark: | :white_check_mark: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Eduardo Elias Ribeiro Junior | :white_check_mark: | :white_check_mark: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Gabriel Sartori Klostermann | :white_check_mark: | :x: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Jhenifer Caetano Veloso | :white_check_mark: | :x: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Monica Ludmila Hintz De Oliveira | :x: | :x: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Paula Alessandra Zeizer Dimas | :white_check_mark: | :white_check_mark: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Walmes Marques Zeviani | :white_check_mark: | :white_check_mark: | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Cesar Augusto Taconeli | - | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
[Retornar à tabela de conteúdo](#painel-de-atividades-do-labestdata)
......@@ -179,131 +114,3 @@ ramos específicos, e solicitado MR ao respectivo responsável pelo
status das atividades propostas.
[Retornar à tabela de conteúdo](#painel-de-atividades-do-labestdata)
## Mini roteiro do projeto ##
A cada semana nós devemos criar novos ramos para realização das
atividades propostas. Porém devemos nos atentar ao criá-los. Estes ramos
devem necessariamente sair do ramo `devel` e não é necessário a
incorporação do ramo de trabalho anterior (solicitado por MR) para que
este seja criado. Abaixo temos os comandos GIT para criar o ramo a
partir do `devel`.
```bash
## Atualiza todos os ramos com a versão do servidor
git pull
## Retorna para o ramo devel
git checkout devel
## Cria um ramo para atividades propostas no issue00
git branch fulano00
## Vai para o ramo criado
git checkout fulano00
```
Com isso já estamos em um ramo criado especificamente para o
desenvolvimento das atividades propostas no `issue#00`, assim podemos
prosseguir com o trabalho propriamente dito, a adição de conjunto de
dados.
```r
##======================================================================
## Passo 1 - Ler e inserir os dados na pasta ./data-raw/
## Usando o R ----------------------------------------------------------
## Transcreva os dados das tabelas
ex <- expand.grid(X1 = 1:6, X2 = LETTERS[1:4])
x3 <- scan()
CiclanoTb0.0 <- data.frame(X1 = ex$X1, X2 = ex$X2, X3 = x3)
## Salve a tabela em formato txt no diretório ./data-raw/
write.table(CiclanoTb0.0,
file = "./data-raw/CiclanoTb0.0.txt",
sep = "\t",
row.names = FALSE)
## Você pode usar a função write2txt() definida em:
## https://gitlab.c3sl.ufpr.br/snippets/34.
write2txt(CiclanoTb0.0)
## Usando outro software -----------------------------------------------
## Transcreva os dados da tabela no software e salve-os no formato txt
## na pasta ./data-raw/
## Leia os dados na sessão R, para utilizá-los posteriormente
CiclanoTb0.0 <- read.table("./data-raw/CiclanoTb0.0.txt",
header = TRUE, sep = "\t")
##======================================================================
## Passo 2 - Inserir os dados no diretório ./data/
library(devtools)
use_data(CiclanoTb0.0)
## Você pode usar a função write2rda() definida em:
## https://gitlab.c3sl.ufpr.br/snippets/34.
write2rda(CiclanoTb0.0)
##======================================================================
## Passo 3 - Escreva a documentação utilizando as tags roxygen2
## Dica: rode os códigos da sessão exemplo aqui, para verificar se os
## gráficos/tabelas são realizadas corretamente.
table(CiclanoTb0.0)
plot(X1 ~ X2, data = CiclanoTb0.0)
## Você pode usar a função write2Rdoc() definida em:
## https://gitlab.c3sl.ufpr.br/snippets/34. Essa função cria o arquivo
## com nome do objeto e algumas já escreve algumas informações,
## retiradas do próprio objeto. Depois de usar, abra o arquivo e
## preencha o restante.
write2Rdoc(CiclanoTb0.0)
##======================================================================
## Passo 4 - Gere e check a documentação (insere um arquivo no diretório
## ./man/). Obs.: O aviso sobre o NAMESPACE pode ser ignorado, pois o
## document() tenta criar um NAMESPACE onde já há um existente, mas isso
## não é problema pois ambos são arquivos sem conteúdo relevante.
document()
check_man()
##======================================================================
## Passo 5 - Verifique a constituição e organização do pacote (caso haja
## ERROS, WARNINGS ou mais de um NOTE. Corrija o problema e continue do
## passo 4)
check()
```
Após todos os passos concluídos devemos ter os arquivos `.txt`, `.rda`,
`.R` e `.Rd` devidamente criados. Podemos voltar ao terminal e *comitar*
nossas contribuições.
```bash
## Adiciona os 4 arquivos criados e commita as alterações
git add data-raw/. data/. R/. man/CiclanoTb0.0
git commit -m "Adiciona tabela 0.0 do livro do Ciclano"
## Desconsidera as alterações realizadas nos arquivos que são gerados
## automaticamente
git checkout .
## Enviando as alterações para o servidor
git push origin fulano00
```
Agora com tudo *commitado* podemos seguir para o próximo conjunto de
dados e refazer todos os passos descritos na sessão R.
Vale ressaltar que este mini roteiro compreende a rotina básica para
inclusão de um conjunto de dados, se for necessária a inclusão de um
biblioteca para elaboração de gráficos ou análises ou ainda forem
criadas funções para o pacote os arquivos NAMESPACE e DESCRIPTION
deverão ser alterados e essas alterações *commitadas*.
[Retornar à tabela de conteúdo](#painel-de-atividades-do-labestdata)
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment