Artigos técnicos on Luciano Brum

Memory leaks em Java

Sat, 21 Sep 2024 12:15:00 -0300

O que são memory leaks
Como memory leaks ocorrem
Exemplos de memory leak
Sinais de memory leak
Como prevenir memory leak
Como encontrar a causa do memory leak

O que são memory leaks

Se você já atua como programador, especialmente em linguagens como Java, C++ ou JavaScript, já deve ter ouvido falar de memory leaks (vazamentos de memória). Esses vazamentos podem se tornar um verdadeiro pesadelo para o desempenho de aplicações e sistemas de grande escala. O que são memory leaks, como eles ocorrem e como podemos preveni-los?

Como memory leaks ocorrem?

Um memory leak ocorre quando um programa aloca memória para armazenar dados, mas nunca libera essa memória após o uso. Isso significa que o espaço ocupado na memória permanece inativo, não podendo ser utilizado por outras partes do programa ou pelo sistema. Ao longo do tempo, esses vazamentos podem resultar no esgotamento da memória disponível, causando lentidão, falhas e até mesmo o travamento completo de um sistema.

Mesmo em linguagens com garbage collector, como Java ou C#, os memory leaks podem ocorrer se o programador não gerenciar adequadamente a vida útil dos objetos. Aqui estão algumas causas comuns:

Referências inúteis mantidas em coleções: Um dos erros mais comuns é armazenar objetos em coleções (como listas, mapas ou conjuntos) e nunca removê-los, mesmo após eles não serem mais necessários.

Eventos não cancelados: Se você cria listeners ou callbacks que ficam observando eventos, mas esquece de removê-los quando eles não são mais necessários, pode deixar referências persistentes, causando um vazamento de memória.

Uso incorreto de recursos externos: Em linguagens como C ou C++, o programador deve manualmente alocar e desalocar memória. Não liberar corretamente essa memória resulta em vazamento.

Singletons e objetos globais: Objetos globais ou singletons mantêm referências ao longo de toda a execução do programa. Se esses objetos armazenarem referências a outros, esses dados podem nunca ser liberados.

Exemplos de memory leak

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


public class MemoryLeakExample {
 public static void main(String[] args) {
 JButton button = new JButton("Clique Aqui");
 JFrame frame = new JFrame();
 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 frame.add(button);
 frame.setSize(300, 200);
 frame.setVisible(true);

 // Adicionando um ActionListener ao botão
 button.addActionListener(e -> {
 System.out.println("Botão clicado!");
 // Este listener nunca é removido, criando um possível vazamento
 });
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


import com.google.common.cache.Cache;
import com.google.common.cache.CacheBuilder;

public class CacheMemoryLeakExample {
 public static void main(String[] args) {
 Cache<String, Object> cache = CacheBuilder.newBuilder().build();

 for (int i = 0; i < 1000000; i++) {
 // Adicionando elementos ao cache sem política de expiração
 cache.put("key" + i, new Object());
 }

 // Mesmo que não precisemos mais desses objetos, eles ainda estão no cache
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


import java.util.HashMap;

public class StaticMemoryLeakExample {
 private static final HashMap<Integer, String> map = new HashMap<>();

 public static void main(String[] args) {
 for (int i = 0; i < 1000000; i++) {
 map.put(i, "value" + i);
 }

 // O map é estático, então seus dados nunca serão removidos,
 // causando um vazamento de memória conforme o tempo passa
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ThreadLeakExample {
 public static void main(String[] args) {
 ExecutorService executor = Executors.newFixedThreadPool(10);

 for (int i = 0; i < 1000; i++) {
 executor.submit(() -> {
 try {
 Thread.sleep(1000);
 } catch (InterruptedException e) {
 Thread.currentThread().interrupt();
 }
 });
 }

 // O executor nunca é fechado, o que mantém as threads em execução
 // Para fechar o executor: executor.shutdown();
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class JdbcMemoryLeakExample {

 private static final String DB_URL = "jdbc:mysql://localhost:3306/mydatabase";
 private static final String USER = "root";
 private static final String PASSWORD = "password";

 public static void main(String[] args) {
 for (int i = 0; i < 1000; i++) {
 memoryLeak();
 }
 }

 public static void memoryLeak() {
 Connection conn = null;
 Statement stmt = null;
 ResultSet rs = null;
 
 try {
 // Criando conexão com o banco de dados
 conn = DriverManager.getConnection(DB_URL, USER, PASSWORD);

 // Criando uma declaração
 stmt = conn.createStatement();

 // Executando uma consulta
 rs = stmt.executeQuery("SELECT * FROM my_table");

 // Iterando sobre o resultado
 while (rs.next()) {
 System.out.println(rs.getString("column1"));
 }

 } catch (Exception e) {
 e.printStackTrace();
 } finally {
 // Aqui temos um vazamento de memória porque as conexões não são fechadas corretamente
 // conn.close(); -> Conexão não está sendo fechada, o que pode causar um vazamento
 // stmt.close(); -> O Statement também deveria ser fechado
 // rs.close(); -> O ResultSet também deveria ser fechado
 }
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;

public class HttpMemoryLeakExample {

 public static void main(String[] args) {
 for (int i = 0; i < 1000; i++) {
 makeHttpCall();
 }
 }

 public static void makeHttpCall() {
 HttpURLConnection connection = null;
 BufferedReader reader = null;

 try {
 URL url = new URL("https://jsonplaceholder.typicode.com/todos/1");
 connection = (HttpURLConnection) url.openConnection();
 connection.setRequestMethod("GET");

 // Abrindo stream de resposta, mas não fechando (causa o vazamento)
 reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));

 String line;
 while ((line = reader.readLine()) != null) {
 System.out.println(line);
 }

 } catch (Exception e) {
 e.printStackTrace();
 } finally {
 // O InputStream e o HttpURLConnection não são fechados corretamente, causando vazamento de recursos
 // reader.close(); // Deveria fechar o BufferedReader
 // connection.disconnect(); // Deveria desconectar a conexão
 }
 }
}

Sinais de memory leak

Como identificar que sua aplicação está sofrendo com vazamentos de memória? Alguns sinais comuns incluem:

Uso Contínuo e Crescente de Memória: O uso de memória do sistema aumenta gradualmente, mesmo sem aumentar a carga de trabalho.

Desempenho Lentamente Degradado: Sua aplicação pode começar a apresentar lentidão conforme continua a executar.

Falhas Ocorrem Após Longo Tempo de Execução: O aplicativo funciona corretamente por horas ou dias, mas eventualmente trava ou falha devido à falta de memória.

Como prevenir memory leak

Gerenciar Bem as Referências: Sempre que um objeto não for mais necessário, certifique-se de que ele seja liberado. Em linguagens com gerenciamento automático de memória, como Java, remover referências ajuda o garbage collector a identificar quais objetos podem ser desalocados.

Remover Listeners Inúteis: Se sua aplicação usa listeners ou observers, lembre-se de removê-los quando eles não forem mais necessários.

Fechar Recursos Externos: Ao trabalhar com arquivos, conexões de rede ou outros recursos externos, sempre feche-os após o uso. Em Java, por exemplo, você pode usar estruturas como try-with-resources para garantir que os recursos sejam liberados.

Ferramentas de Monitoramento de Memória: Use ferramentas de profiling e depuração para monitorar o uso de memória da aplicação. Em Java, o VisualVM e o JProfiler são ótimos exemplos de ferramentas que ajudam a identificar vazamentos.

Teste de Estresse e Carga: Execute testes de carga em sua aplicação para identificar possíveis vazamentos que só se manifestam após longos períodos de execução.

Como encontrar a causa do memory leak

Mostrarei, no próximo artigo, com alguns exemplos, de como detectar memory leaks no VisualVM.

Dica bônus: não é simples identificar um memory leak. Já me aconteceu do problema estar não no código da aplicação em si, mas em uma das dependências da aplicação. Por isso é sempre importante buscar entender em qual funcionalidade acontece, se é quando utiliza uma dependência específica, ou em horários do sistema que muitos usuários utilizam, ou quando grandes conjuntos de dados são processados em lote, e assim por diante. Com sorte, podemos encontrar em poucas buscas no Google/Stack Overflow/ChatGpt o problema, fazendo uma pesquisa com algo como ‘jackson-core version 2.xx lib memory leak’.

Conclusão

Memory leaks são um problema silencioso, mas potencialmente devastador para qualquer aplicação. Eles podem surgir de forma sutil e afetar negativamente o desempenho, confiabilidade e escalabilidade do seu software. Ao adotar boas práticas de gerenciamento de memória e monitorar cuidadosamente a aplicação, é possível evitar que esses vazamentos prejudiquem a experiência dos usuários e a integridade do sistema.

Uma boa gestão de memória não só melhora o desempenho da aplicação como também contribui para uma experiência de usuário mais fluida e agradável.

Sobre memory leaks em Java era isso o que eu tinha para compartilhar.

Valeu pessoal e até o próximo post !

Programação procedural em java

Sun, 15 Sep 2024 12:15:00 -0300

O que é programação procedural
Programação em java
Problemas da abordagem procedural

O que é programação procedural

Na programação procedural, o código é organizado em funções e procedimentos. Comumente ensinada nas universidades, a linguagem C exemplifica bem o uso desse paradigma.

Abaixo, um exemplo de código em Java considerado procedural.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


// Dados separados de comportamento
class Employee {
 String name;
 double salary;
}

public class ProceduralExample {

 public static void increaseSalary(Employee employee, double increaseAmount) {
 employee.salary += increaseAmount;
 }

 public static void displayEmployee(Employee employee) {
 System.out.println("Name: " + employee.name);
 System.out.println("Salary: " + employee.salary);
 }

 public static void main(String[] args) {
 Employee emp = new Employee();
 emp.name = "Alice";
 emp.salary = 5000;

 displayEmployee(emp);
 increaseSalary(emp, 500);
 displayEmployee(emp);
 }
}

Em aplicações reais, é comum encontrar métodos static com mais de 100 linhas de código, assim como as notórias ‘God Classes’.

Programação em java

Abaixo um exemplo de como seria um código em Java no paradigma de orientação à objetos.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


class Employee {
 private String name;
 private double salary;

 public Employee(String name, double salary) {
 this.name = name;
 this.salary = salary;
 }

 public void increaseSalary(double increaseAmount) {
 if (increaseAmount > 0) {
 this.salary += increaseAmount;
 } else {
 System.out.println("Invalid increase amount!");
 }
 }

 public void displayInfo() {
 System.out.println("Name: " + name);
 System.out.println("Salary: " + salary);
 }
}

public class ObjectOrientedExample {
 public static void main(String[] args) {
 Employee emp = new Employee("Alice", 5000);

 emp.displayInfo();
 emp.increaseSalary(500);
 emp.displayInfo();
 }
}

Vantagens da Programação Orientada a Objetos:

Encapsulamento: Com os atributos sendo privados, só podem ser acessados ou modificados pelos métodos da classe.

Regras de negócio centralizadas: A lógica de aumento de salário está encapsulada no método increaseSalary. Se regras de negócio mudarem (por exemplo, aplicar um limite para o aumento), só será necessário alterar esse método.

Facilidade de manutenção e extensão: Se for necessário adicionar novos métodos ou funcionalidades à classe, isso pode ser feito sem impactar outras partes do código.

Problemas da abordagem procedural

Modularidade e Organização

No exemplo procedural, os dados (name e salary) estão separados da lógica que os manipula, tornando o código menos modular. Na orientação a objetos, o comportamento está junto com os dados, o que facilita a manutenção.

Encapsulamento

No exemplo orientado a objetos, o encapsulamento protege os dados de serem acessados ou modificados diretamente, forçando o uso de métodos apropriados. Isso melhora a segurança do código e facilita o controle sobre as operações realizadas.

Reutilização e Extensibilidade

A orientação a objetos facilita a reutilização de código. Por exemplo, a classe Employee pode ser facilmente estendida para criar tipos de funcionários especializados (usando herança ou composição), sem precisar modificar o código existente.

Tais problemas não são tão perceptíveis quando estamos iniciando no desenvolvimento de software. Basta olharmos um código procedural em Java escrito 5 anos atrás por outra pessoa, ou até escrito por nós mesmos, que ficará evidente o problema de fazer manutenção de códigos procedurais em linguagens orientadas à objeto.

Como assim, ficará evidente? classes com dez mil linhas, métodos que fazem dezenas de coisas de formas diferentes, duplicação indevida de regras de negócio, dificuldade de entender o racional por trás das decisões (principalmente se for mal documentado), métodos que trabalham com interface, regras de negócio e banco ao mesmo tempo, métodos que alteram objetos de entrada e assim por diante. Vamos nos deparar, inclusive, com o modelo de domínio anêmico (anemic domain model) e os scripts de transação (transaction scripts), citados pelo Martin Fowler neste link (de 2003!).

Vejam, para mim, não é problema utilizar código procedural em linguagem orientada à objetos. O problema é utilizar onde não deve ser utilizado. Se você precisa realizar algum tipo de operação em estrutura de dados, talvez seja interessante ter um método estático ou uma classe ‘Utils’ para isso. Deve ser exceção, e não a regra.

Realizar correções e evolução de código procedural se tornam um desafio, um custo à empresa, um dano na experiência de desenvolvimento, uma demora na entrega ao cliente, coisas tais que poderiam ser evitadas.

Sei que, no mundo real, existem desafios que vão além da parte da criação do software em si, como gerência, prazos, contexto, comunicação, escopo, autonomia de decisões, e assim por diante. Nosso papel como desenvolvedores ou engenheiros não é meramente digitar código. É, mais do que outra coisa, resolver problemas. A forma como resolvemos um problema também pode se tornar um problema. Então não é apenas resolver um problema, mas tentar resolvê-lo da forma adequada em um tempo apropriado.

Código procedural em linguagens orientadas à objeto é um problema que afeta dezenas de milhares de soluções Java, convertendo-se em custos desnecessários prejudicando todo o ecossistema dessas linguagens.

Meus conselhos finais são: estude o paradigma de orientação à objetos e leia os artigos do Martin Fowler.

Sobre o paradigma procedural em Java era isso o que eu tinha para compartilhar.

Valeu pessoal e até o próximo post !

Git no meu dia a dia

Sat, 07 Sep 2024 12:15:00 -0300

Comandos Git
Minhas estatísticas de uso do git
Cenários de uso
Considerações Finais

Comandos Git

A ideia deste post é mostrar os comandos que eu mais utilizo no dia a dia com desenvolvimento java nos últimos cinco anos. Assumo aqui que o leitor tenha um conhecimento básico de Git e de versionamento de código.

Minhas estatísticas de uso do git

Segue abaixo as minhas estatísticas de uso do comando git:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


history | grep ' git ' | awk '{CMD[$2" "$3]++} END {for (a in CMD) print CMD[a], a}' | sort -nr

443 git status
355 git add
318 git push
302 git commit
77 git pull
44 git branch
43 git checkout
40 git clone
16 git stash
13 git restore
12 git config

Cenários de uso

git status

Mostra o estado do repositório, o que está modificado, adicionado, ou ainda precisa ser comitado.

Geralmente eu utilizo esse comando para relembrar os arquivos que alterei. Acontece quando faz muito tempo que estou trabalhando na mudança ou quando estou com muitas abas de arquivos abertas na IDE ou quando fechei algumas sem lembrar quais.

git add

Adiciona arquivos modificados ou novos à área de preparação (stage) para o próximo commit.

Geralmente eu utilizo o comando conforme abaixo:

git add .

Ele adiciona todos os arquivos na área stage com o símbolo ponto. Porém, com frequência, trabalhei em projetos que não tem o arquivo .gitignore no repositório. Por outro lado, preciso dele no ambiente local para não comitar determinados arquivos.

Daí, eu utilizo o comando assim:

git add arquivo_alterado.java

Quando são muitos arquivos, podemos usar regex:

git add *.java

O comando acima coloca na área stage todos arquivos modificados que terminam em ‘.java’.

git push

Envia os commits locais para um repositório remoto.

Geralmente, eu uso o comando assim mesmo. Existem outras formas, mas essa é simples e direta.

git commit

Cria um commit com as mudanças na área de stage, com uma mensagem descritiva. Segue exemplo abaixo:

1

git commit -m "FIX correção de bug NPE em classe"

A mensagem acima ‘FIX correção de bug NPE em classe’ é a que vai aparecer na sua ferramenta de controle de versão (VCS) quando você listar os commits daquele projeto naquela branch. É um espaço que temos que deve ser usado para deixar claro para outros membros da equipe o que feito. Pode ser que 5 ou 10 anos no futuro alguém deseje entender o racional daquela decisão, não o código em si.

git pull

Atualiza o repositório local com as últimas mudanças do repositório remoto.

Este comando uso com frequência para não acabar executando um código do projeto que está deprecated/desatualizado. Sempre antes de iniciar uma nova branch, uso esse comando para ter no meu repositório local as branches principais atualizadas com o repositório remoto. Isso ajuda a evitar problemas futuros com conflitos nos momentos de merge ou códigos que estavam em produção e magicamente sumiram.

git branch

Lista, cria ou exclui branches.

Uso mais este comando para saber quais branches estão no meu repositório local e quais não estão (quando comparo ao remoto).

git checkout

Alterna entre branches ou restaura arquivos.

Eu utilizo quase sempre este comando para mudar para uma nova branch. Lembrando que, se ela existe no repositório remoto, podem existir alterações remotas para serem atualizadas, daí a importância do ‘git pull’ mencionado anteriormente.

Em algumas situações bem específicas, eu precisei comparar o estado do projeto em um commit específico. Isso também é possível com o comando checkout conforme exemplo abaixo:

1

git checkout abc1234

Isso muda o estado do repositório para o commit abc1234. Se você fizer mudanças aqui, elas ficarão isoladas desse commit, a menos que você crie uma nova branch para mantê-las.

git clone

Clona um repositório remoto para a máquina local.

1

git clone https://github.com/user/repo.git

Uso ele mais para projetos pessoais e para baixar projetos open-source para minha máquina.

git stash

Armazena mudanças temporariamente sem fazer um commit.

É muito útil em cenários em que você precisa salvar temporariamente suas alterações não comitadas para poder trabalhar em outro branch e depois restaurá-las.

Você está desenvolvendo uma nova funcionalidade, fez várias modificações nos arquivos, mas não quer comitar ainda. De repente, surge um bug urgente que você precisa corrigir em outra branch. Nesse caso, você pode “guardar” suas mudanças temporariamente.

1

git stash push -m "Mudanças para funcionalidade X"

Isso salva todas as suas alterações não comitadas no stash com a mensagem “Mudanças para funcionalidade X”, permitindo que você troque de branch sem perder essas modificações.

Para ver mudanças temporárias guardadas no stash:

1
2
3
4


git stash list

stash@{0}: On main: Mudanças para funcionalidade X
stash@{1}: WIP on main: Mudanças para correção de bug Y

Para restaurar as mudanças na sua branch atual, o comando é o abaixo:

1

git stash pop

Isso aplica o stash mais recente ao seu diretório de trabalho, restaurando suas modificações, e remove o stash da pilha.

Para aplicar um stash específico, utiliza-se a sintaxe abaixo:

1

git stash pop stash@{1}

Isso aplica o stash da posição 1, conforme o exemplo anterior apresentado.

git restore

Restaura o conteúdo de arquivos para o último estado do commit.

Uso com frequência o comando acima quando utilizo o ‘git add .’ mas não quero que o ‘.gitignore’, por exemplo, ou arquivos de IDE, sejam comitados junto ao repositório. O comando ‘git restore’ pode remover da área stage e desfaz as mudanças desses arquivos.

Por exemplo, para remover o .gitignore da área stage:

1

git restore --staged .gitignore

Isso remove o arquivo da área stage, mas não desfaz as mudanças. Para desfazer quaisquer mudanças e retornar ao último estado do commit.

1

git restore .gitignore

Observação: não funciona com arquivos novos criados localmente que não existe no repositório remoto.

Para remover arquivos novos e que não existem no repositório remoto, existe o comando clean:

1

git clean

É uma boa prática usar o comando clean com o ‘-n’, pois ele vai mostrar os arquivos novos que vão ser removidos, antes de realmente remover.

1

git clean -n

Para remover não só arquivos, mas também pastas, usa-se o clean com -fd.

1

git clean -fd

git config

1

git config --global user.name "Seu Nome"

Configura variáveis de ambiente do Git, como nome de usuário e email.

Utilizei esse comando quando iniciei desenvolvimento em máquinas novas após formatação ou quando precisei fazer alguma modificação específica em um cenário de uma máquina com várias contas do git.

O –global indica que é a configuração git que será utilizada por padrão em todos repositórios. Por outro lado, é possível configurar essas variáveis para cada repositório, localmente. Nesse caso, a configuração que valerá é a local, não a global.

Para ver as configurações globais do git na máquina (caso tenham sido anteriormente definidas):

git config –global –list

Para ver as configurações locais definidas em um repositório:

git config –list

Considerações Finais

Sobre os comandos git que eu mais utilizo era isso que eu tinha para compartilhar.

Se você deseja apoiar o meu trabalho de escrita sobre os mais diversos assuntos de tecnologia, compartilhe meus artigos em suas redes sociais.

O objetivo é o de contribuir com o compartilhamento de experiências práticas em desenvolvimento de software e sobre tecnologia com a comunidade.

Valeu pessoal e até o próximo post !

Git Hooks

Sun, 04 Aug 2024 17:15:00 -0300

Resumo
O que são os Hooks
Exemplo de hook
Considerações Finais

Resumo

A ideia deste post é mostrar o que são os Hooks do Git e algumas das suas utilidades no dia a dia da produção de software. Assumo aqui que o leitor tenha um conhecimento básico de Git e de versionamento de código.

O que são os Hooks

Os hooks são scripts personalizados que são executados automaticamente em momentos específicos do ciclo de vida de um repositório Git. Eles são úteis para automatizar tarefas, impor políticas, e garantir a consistência do código. Neste post, veremos como criar um hook simples para validar mensagens de commit.

Hooks do Git são scripts localizados no diretório .git/hooks de um repositório. Eles são ativados por diferentes ações, como commits, pushs, e merges. Existem dois tipos principais de hooks:

Hooks do lado do cliente: São executados em operações locais, como commits e merges.

Hooks do lado do servidor: São executados em operações de rede, como pushs e recepções de dados de repositórios remotos.

Exemplo de hook

Vamos criar um exemplo simples de hook que valida mensagens de commit. Suponha que queremos que todas as mensagens de commit sigam um formato específico, por exemplo, que comecem com um prefixo como FIX, FEAT, ou DOC.

Passo 1: Navegue até o diretório de hooks

Primeiro, navegue até o diretório .git/hooks do seu repositório:

1

cd /caminho/do/seu/repositorio/.git/hooks

Passo 2: Crie o script do hook commit-msg

Crie um novo arquivo chamado commit-msg e abra-o em seu editor de texto favorito:

1
2


touch commit-msg
nano commit-msg

Passo 3: Escreva o script do hook

Adicione o seguinte código ao arquivo commit-msg:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


#!/bin/sh

# Leia a mensagem de commit
commit_message=$(cat $1)

# Verifique se a mensagem de commit começa com um dos prefixos permitidos
if ! echo "$commit_message" | grep -qE "^(FIX|FEAT|DOC):"; then
 echo "Erro: A mensagem de commit deve começar com um dos seguintes prefixos: FIX, FEAT, DOC."
 exit 1
fi

Passo 4: Torne o script executável

Para garantir que o script possa ser executado, você precisa alterar suas permissões:

1

chmod +x commit-msg

Como funciona o script?

O script lê a mensagem de commit do arquivo temporário passado como argumento ($1).

Ele verifica se a mensagem de commit começa com um dos prefixos permitidos (FIX, FEAT, DOC) usando uma expressão regular.

Se a mensagem não corresponder ao formato esperado, o script exibirá uma mensagem de erro e retornará um código de saída diferente de zero (exit 1), o que impede o commit de prosseguir.

Testando o Hook

Vamos fazer um commit com uma mensagem que não siga o formato especificado:

1

git commit -m "Atualizando documentação"

Você deverá ver uma mensagem de erro e o commit será bloqueado.

Tente novamente com uma mensagem válida:

1

git commit -m "DOC: Atualizando documentação"

Este commit deve ser bem-sucedido.

Um exemplo bem interessante de hook nas mensagens de commit é o de você adicionar na mensagem de commit a hashtag e o número da issue que você está trabalhando.

Isso ajuda na rastreabilidade das tarefas e modificações, melhora a comunicação em equipe e transparência, facilita a revisão de código e melhora a documentação do que é feito. Mesmo em um cenário com poucos desenvolvedores, todos ficam cientes da relação das issues com cada commit, sobre qual problema cada commit resolveu (ou criou rsrs).

Em ferramentas como o Gitlab, você tem um destaque com um link para a issue quando você tem o uso do #, por exemplo, nas mensagens de commit, facilitando a experiência do desenvolvedor que busca entender o contexto daquele commit.

Outras possibilidades:

pre-commit - Hook para Verificação de Estilo de Código;
pre-push - Hook para Rodar Testes Automatizados;
post-merge - Hook para Atualização de Dependências;
pre-rebase - Hook para Verificar Branch Protegida;

Considerações Finais

Sobre os hooks era isso. Se você deseja apoiar o meu trabalho de escrita sobre os mais diversos assuntos de tecnologia, compartilhe meus artigos em suas redes sociais. O objetivo é o de contribuir com o compartilhamento de experiências práticas em desenvolvimento de software e sobre tecnologia com a comunidade.

Valeu pessoal e até o próximo post !

Comunicação de um aplicativo com um serviço em execução no Docker e Nginx

Sun, 19 Feb 2023 19:15:00 -0300

Resumo
Descrição do problema
Solução

Resumo

A ideia deste post é mostrar como habilitar a comunicação de um aplicativo feito com React Native (executando localmente com a ajuda do expo) com um serviço backend containerizado com Docker. O serviço é uma aplicação feita com Spring Boot em Java, mas a dica é válida para um serviço em qualquer linguagem.

Este setup é apenas para ambientes de desenvolvimento. Não use esse tutorial como exemplo para implantação em ambientes de produção.

Descrição do problema

Antes de containerizar a aplicação Spring Boot no Docker, o aplicativo acessava as APIs normalmente através do IP da máquina (pode ser obtido com o comando ifconfig ou nas configurações de rede do SO) e a porta da aplicação Spring (por exemplo - 192.168.0.9:8000). Isso só funcionava porque ambos serviços estavam na mesma rede.

O problema surgiu quando o serviço do Spring Boot foi containerizado. Não fazia mais sentido utilizar o IP da máquina + porta da aplicação, pois agora essa comunicação dependeria de como o Docker e sua rede foram configurados e se há proxy reverso no caminho (como Nginx, HAProxy, etc). Vamos ver na sequência ambos os cenários.

Solução

Vamos supor que nossa aplicação Spring (chamada neste exemplo de ‘my_image/my_app’) executa na porta 8002 e que temos o seguinte arquivo docker-compose.yml para subir o serviço:

1
2
3
4
5
6
7
8


version: '3.8'

services:
 app:
 image: 'my_image/my_app:latest'
 container_name: app
 ports:
 - "8001:8002"

O parâmetro ports no docker compose é um mapeamento entre uma porta no host e uma porta no container. A porta 8002 (da aplicação Spring containerizada) está mapeada na porta 8001 do host. Então para acessar esse serviço localmente, basta digitar no browser:

1

http://localhost:8001

Para acessar esse serviço a partir de um app executando na rede local, basta modificar o ’localhost’ pelo endereço IP da máquina que está hospedando o Docker.

No Ubuntu, você pode usar os comandos ip a ou ifconfig para descobrir o IP privado (podem aparecer vários, basta tentar cada um deles), ou também ir em Settings -> Wi-fi -> Settings (da rede local) -> Details -> IPV4 Address, e obter o IP. No meu caso, é 192.168.100.17. Então, para acessar a API através do aplicativo, seria assim:

1

http://192.168.100.17:8001

Outro cenário possível é o de existir um proxy reverso (Nginx) em um container no host. Segue abaixo um arquivo de configuração de exemplo do Nginx (geralmente salvo em /etc/nginx/conf.d):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


upstream my_app {
 server app:8002;
 keepalive 16;
}

server {
 listen 80;

 server_name localhost;
 location / {
 proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
 proxy_cache_background_update on;
 proxy_cache_lock on;

 proxy_pass http://my_app/;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Host $host;
 proxy_set_header Connection "";
 proxy_http_version 1.1;
 proxy_read_timeout 600;

 add_header X-Cache-Status $upstream_cache_status;
 }
}

E o respectivo docker-compose.yml, que agora inclui o Nginx:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


version: '3.8'

services:
 nginx:
 image: nginx:1.23.3-alpine-slim@sha256:60a7532e3b954c902cb651aa29a2c757c495e11c264368fdf77b139985b923c6
 restart: always
 ports:
 - "80:80"
 - "443:443"
 hostname: nginx
 volumes:
 - /etc/nginx/conf.d:/etc/nginx/conf.d
 depends_on:
 - app

 app:
 image: 'my_image/my_app:latest'
 restart: always
 hostname: app
 ports:
 - "8001:8002"

Para acessar o serviço app, será necessário passar pelo Nginx. Para acessar o Nginx, basta usar localhost:80 (ou IP_DO_HOST:80).

As configurações do Nginx apresentadas anteriormente farão um redirecionamento de chamadas do localhost:80 (ou do IP_DO_HOST:80) para o Nginx, que na sequência direciona a chamada para o app:8002. 8002 é a porta do serviço Spring Boot e o app é o hostname do container, que se traduz no IP do mesmo. Não é a porta 8001, pois essa é a porta que está mapeada no Host para acessar o serviço Spring Boot.

Então, de acordo com o exemplo acima, para acessar o serviço backend através do aplicativo rodando no emulador do Android, basta usar o IP da máquina + porta 80 nas chamadas de API no código do app.

Podemos ir além e testar as chamadas de API com o Nginx e com HTTPS (e redirecionar chamadas HTTP para HTTPS). Uma forma de fazer esse teste é com o openssl.

Os comandos abaixo geram o certificado necessário e copiam para o diretório que vamos usar como volume no container do Nginx. Uma boa referência sobre o assunto é essa resposta do Stackoverflow.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


>openssl.cnf cat <<-EOF
[ req ]
default_bits = 2048
default_keyfile = localhost.key
default_md = sha256
default_days = 825
encrypt_key = no
distinguished_name = subject
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = utf8only
prompt = no

[ subject ]
countryName = BR
stateOrProvinceName = SC
localityName = Florianopolis
organizationName = LucianoBrum
OU = Engineering

commonName = localhost
emailAddress = lucianobrum18@gmail.com

[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer

basicConstraints = critical, CA:TRUE
keyUsage = critical, digitalSignature, keyEncipherment, cRLSign, keyCertSign
subjectAltName = DNS:localhost,IP:10.0.2.2
extendedKeyUsage = serverAuth
extendedKeyUsage = TLS Web Server Authentication

[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = DNS:localhost,IP:10.0.2.2
nsComment = "OpenSSL Generated Certificate"
EOF

openssl req -config openssl.cnf -new -x509 -days 825 -out localhost.crt -verbose
sudo cp localhost.key /etc/ssl/private/localhost.key
sudo cp localhost.crt /etc/ssl/certs/localhost.crt

Observe os parâmetros essenciais para este exemplo:

default_keyfile = localhost.key

commonName = localhost

subjectAltName = DNS:localhost,IP:10.0.2.2

Utilizamos aqui, além do localhost, o IP 10.0.2.2 porque é o IP que o emulador do Android utiliza para se comunicar com o localhost da máquina HOST.

Para testar o serviço no Browser, vamos precisar importar o certificado de autoridade. Cada browser tem um fluxo diferente para fazer isso.

Os passos no Google Chrome são os seguintes.

1- menu de opções do Chrome (três pontinhos no canto superior direito)

2- Settings (Configurações)

3- Privacy and Security (Privacidade e Segurança - menu esquerdo)

4- Security (Segurança - no grupo Privacy and Security)

5- Manage certificates (Gerenciar certificados)

6- Authorities (Autoridades - selecionar a aba)

7- Import (Importar)

8- Buscar o certificado gerado anteriormente, o localhost.crt, e dar ok

Adicionamos os volumes /etc/ssl/certs:/etc/ssl/certs e /etc/ssl/private:/etc/ssl/private no docker-compose.yml para que o container do Nginx possa acessar os certificados gerados.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


version: '3.8'

services:
 nginx:
 image: nginx:1.23.3-alpine-slim@sha256:60a7532e3b954c902cb651aa29a2c757c495e11c264368fdf77b139985b923c6
 restart: always
 ports:
 - "80:80"
 - "443:443"
 hostname: nginx
 volumes:
 - /etc/nginx/conf.d:/etc/nginx/conf.d
 - /etc/ssl/certs:/etc/ssl/certs
 - /etc/ssl/private:/etc/ssl/private
 depends_on:
 - app

 app:
 image: 'my_image/my_app:latest'
 restart: always
 hostname: app
 ports:
 - "8001:8002"

Por fim, vamos modificar o arquivo de configurações do Nginx conforme abaixo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


upstream my_app {
 server app:8002;
 keepalive 16;
}

server {
 listen 80 default_server;
 server_name _;
 return 307 https://$host$request_uri;
}

server {
 listen 443 ssl;
 server_name localhost;
 ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
 ssl_ciphers HIGH:!aNULL:!MD5;

 ssl_certificate /etc/ssl/certs/localhost.crt;
 ssl_certificate_key /etc/ssl/private/localhost.key;

 location / {
 proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
 proxy_cache_background_update on;
 proxy_cache_lock on;

 proxy_pass http://my_app/;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Host $host;
 proxy_set_header Connection "";
 proxy_http_version 1.1;
 proxy_read_timeout 600;

 add_header X-Cache-Status $upstream_cache_status;
 }
}

Foi adicionado o path dos certificados que geramos anteriormente para o ’localhost’ para habilitar o acesso local por HTTPS. Ainda habilitamos um redirecionamento de chamadas HTTP para HTTPS no localhost. O ip:porta para acessar o serviço Spring é app:8002 em vez de app:8001, pois estamos acessando o container a partir da porta do serviço (8002) e não da porta mapeada no Host (8001).

Agora é só testar no browser: https://localhost. Deverá aparecer ao lado da URL a imagem do cadeado fechado mostrando que o site possui um certificado e tem uma conexão confiável.

Para testar no emulador do Android, vamos precisar fazer quatro ações.

1- adicionar o certificado localhost.crt no projeto do aplicativo em teste.

Para isso, abrir o projeto (Android) e adicionar o seguinte conteúdo em ./app/src/main/res/xml/network-security-config.xml

1
2
3
4
5
6
7
8


<network-security-config xmlns:tools="http://schemas.android.com/tools"
	xmlns:android="http://schemas.android.com/apk/res/android">
	<base-config>
		<trust-anchors>
			<certificates src="@raw/localhost" />
		</trust-anchors>
	</base-config>
</network-security-config>

2- adicionar o arquivo localhost.crt no diretório ./app/src/main/res/raw.

Se não existir esse diretório, criar o mesmo.

3- verificar se o arquivo em ./app/src/main/AndroidManifest.xml possui o trecho abaixo. Se não tiver, adicione-o. Ele habilita as configurações de segurança de rede através do arquivo network_security_config.xml.

1
2
3


...
<application android:networkSecurityConfig="@xml/network_security_config">
...

4- ajustar as urls das APIs no aplicativo de forma que elas usem agora o IP:porta https://10.0.2.2:80.

Ao executar o aplicativo no emulador, deverá ser possível acessar recursos com urls em HTTPS com um serviço executando localmente em um container.

Esse teste também pode ser feito com um Nginx executando no Host em vez de em um container. Poucas mudanças seriam necessárias…

Considerações Finais

Não entrei no mérito de boas práticas (com Docker, Nginx, openssl, etc) ou explicar o que cada coisa faz. Acredito que já existam bons tutoriais sobre isso. A ideia deste artigo foi a de apresentar dicas relacionadas a ambientes que envolvam várias coisas diferentes, que exigem um certo nível de conhecimento das ferramentas e dos conceitos por trás de tudo isso.

Se você deseja apoiar o meu trabalho de escrita sobre os mais diversos assuntos de tecnologia, compartilhe meus artigos em suas redes sociais. O objetivo é o de contribuir com o compartilhamento de experiências práticas em desenvolvimento de software e sobre tecnologia com a comunidade.

Valeu pessoal e até o próximo post !!

Referências

Comunicação entre o frontend no Netlify (HTTPS) e backend na AWS EC2 (HTTP)

Mon, 13 Feb 2023 00:10:00 -0300

Resumo
Descrição do problema
Solução

Resumo

A ideia deste post é compartilhar com vocês sobre como eu habilitei a comunicação de um serviço no Netlify hospedado em um domínio com HTTPS, por meio de uma API (com axios, mas poderia ser outra forma), com um serviço (backend) na AWS EC2 em um domínio com HTTP.

Descrição do problema

O Netlify começou a utilizar por padrão o HTTPS nos seus sites desde 2018. Isso implica que os serviços implantados no Netlify só podem também acessar domínios HTTPS. O problema surge quando você precisa acessar algum recurso que não tem HTTPS, por exemplo, uma API em um serviço implantando no EC2 da Amazon que não tem um domínio pessoal cadastrado.

Uma saída que pensei foi a de usar o Cerbot (que por baixo usa o letsencrypt) para gerar um certificado HTTPS para o domínio público disponibilizado pela Amazon ao criar a instância do EC2 (free tier). Não funcionou, pois o letsencrypt não gera certificados para domínios temporários como os disponibilizados pela Amazon na criação do EC2. O domínio pode mudar e passar a ser utilizado por outra pessoa. Só funcionaria se o domínio fosse de fato, meu, e não da Amazon.

A outra alternativa que encontrei foi essa. A ideia é a de utilizar um recurso do Netlify de proxy de chamadas à serviços externos que vai permitir a chamada de serviços em HTTP. O lado negativo é que perdemos a segurança do HTTPS, portanto, não é recomendado utilizar essa solução em produção, principalmente se envolver dados sensíveis. No nosso caso, como só desejamos colocar uma demonstração de um projeto de portfólio em ambiente de produção, não vejo muito perigo nessa abordagem.

Isso tudo poderia ser evitado se tivéssemos um domínio registrado. Bastaria ter esse registro cadastrado no Route53 da Amazon e gerar o certificado HTTPS com o letsencrypt. Recomendo essa alternativa como primeira opção por ser mais simples e segura (porém acarreta no custo de criar um domínio, custo esse que nem sempre uma pessoa criando um portfólio terá disponível).

Solução

Vamos supor que há uma instância EC2 com o seguinte endereço DNS público:

1

*ec2-99-999-999-999.sa-east-1.compute.amazonaws.com*

Nesta instância tem um serviço backend em execução. Nas configurações dos grupos de segurança (security groups) o acesso de entrada (input rules) é liberado na porta 80.

O serviço frontend, que está hospedado no Netlify, tem a seguinte chamada de API:

1
2
3


export function fetchProducts() {
 return axios(`http://ec2-99-999-999-999.sa-east-1.compute.amazonaws.com/products`)
}

A chamada não vai funcionar pelas razões mencionadas anteriormente. O frontend hospedado no Netlify é HTTPS por padrão, só pode consultar recursos também em HTTPS. Para viabilizar acessar um recurso HTTP, vamos utilizar o recurso de proxy do Netlify chamado _redirects.

Então, modificaremos as chamadas de API à recursos HTTP conforme abaixo:

1
2
3


export function fetchProducts() {
 return axios(`/products`)
}

No publish directory (diretório de publicação dos artefatos no Netlify - pode ser modificado nas configurações do Netlify em Site Settings -> Build & Deploy -> Continuous Deployment -> Build Settings -> Publish Directory), criamos o arquivo _redirects e colocamos o seguinte conteúdo:

1

/products http://ec2-99-999-999-999.sa-east-1.compute.amazonaws.com/products 200!

O que vai acontecer é o seguinte: quando ocorrer a chamada a API /products, a chamada será redirecionada de acordo com o mapeamento no arquivo _redirects, a partir dos servidores CDN do Netlify. Não é como se estivessemos chamando diretamente a API.

Um exemplo real onde essa estratégia foi aplicada é neste projeto. Ao abrir este link, haverá uma chamada a uma API /products, que é um backend hospedado em um ambiente com HTTP. Esse backend retorna os dados para o Netlify, e o mesmo retorna para o browser. Esse processo de redirecionamento não é transparente (ao abrir a aba network após um inspect no Google Chrome, não aparecerá a URL do serviço backend, e sim a chamada da API /products com o endereço do próprio site hospedado no Netlify).

Existe ainda uma outra forma de fazer esse processo que é utilizando um arquivo de configuração do Netlify (netlify.toml), onde é possível especificar como o Netlify deve fazer o build e deploy do site. Para saber tudo que é possível fazer com o netlify.toml, acesse este link da documentação oficial.

Detalhe importante: para esse mecanismo de redirect funcionar em ambiente local é necessário executar o projeto com o comando netlify dev, e não com o convencional react-scripts start. Essa lógica de proxy é específica do Netlify, o netlify cli permite reproduzir funcionalidades do ambiente de produção do Netlify em ambiente local.

Considerações Finais

Espero que este tutorial tenha auxiliado de alguma forma no entendimento da comunicação entre serviços no Netlify e na AWS.

Valeu pessoal e até o próximo post !!

Resolução do problema do mapa híbrido do Google Maps no Richfaces 3.x

Sun, 07 Aug 2022 12:19:00 -0300

Resumo
Descrição do problema
Solução

Resumo

E aí pessoal, beleza?

A ideia deste post é compartilhar com vocês sobre como eu resolvi (temporariamente) um problema de compatibilidade entre o Google Maps e a biblioteca Richfaces.

O Richfaces é uma biblioteca antiga para projetos web que utilizava JSF (JavaServer Faces) com suporte para AJAX (Asynchronous JavaScript And XML).

Em junho 2016 ela deixou de ser mantida. Isso significa que os responsáveis por projetos que utilizavam Richfaces deveriam ver alguma forma de substituir essa tecnologia.

Nesse meio tempo poderiam surgir bugs pontuais que poderiam serem resolvidos sem substituir a biblioteca inteira, pois o tempo para fazer essa troca, dependendo do tamanho do projeto, poderia significar não atender demandas mais urgentes acarretando na perda de um ou vários clientes.

Um desses problemas que surgiram foi o uso Google Maps no modo híbrido integrado com a biblioteca do Richfaces na versão 3.3.3.Final.

Descrição do problema

O problema quando você usa o Google Maps (nas versões 3.46+) e o richfaces-impl versão 3.3.3.Final (e possivelmente outras versões anteriores) é que existe uma incompatibilidade entre o modo híbrido/satélite do mapa e uma das dependências da biblioteca richfaces-impl. Esse problema faz com que o mapa no modo Híbrido/Satélite não funcione como deveria.

Abaixo duas imagens, a primeira ilustrando o problema e a segunda mostrando como deveria ser:

Fonte da imagem: https://i.stack.imgur.com/4a0x3.png

Fonte da imagem: próprio autor.

Solução

O ponto de partida para buscar a solução foi a mensagem de erro que aparecia no console do navegador ao tentar carregar o mapa no modo Híbrido.

1

This site overrides Array.from() with an implementation that doesn't support iterables, which could cause Google Maps JavaScript API v3 to not work correctly.

Existia uma dependência no projeto que alterava o funcionamento do método Array.from() no Javascript de modo que acarretava no mal funcionamento da versão em uso do Google Maps.

A primeira solução que funcionou por um tempo foi a de voltar algumas versões do Google Maps (até a versão 3.45.8 o mapa híbrido funcionava). Porém, a versão 3.45.8 recentemente foi removida pelo Google. A alternativa foi encontrar a dependência que tinha esse problema para realizar a correção (ou atualização de versão).

Este link do stackoverflow deu a pista sobre a biblioteca prototype.js estar causando o problema da sobrescrita do método Array.from().

O próximo passo foi descobrir qual biblioteca poderia estar utilizando o prototype.js. Ao focar nas bibliotecas relacionadas ao frontend, foi possível verificar que a lib richfaces-impl versão 3.3.3.Final tinha essa dependência.

Ao abrir o jar, temos os seguintes arquivos (neste link é possível obter o código fonte do richfaces-impl):

org/ajax4jsf/framework.pack.js
org/ajax4jsf/javascript/scripts/prototype.js

No arquivo prototype.js, foi feita a seguinte substituição na linha 837:

1

Array.from = $A;

para:

1

Array.from = Array.from || $A;

Isso basicamente não altera mais o comportamento do Array.from nos navegadores modernos (que é o problema original) e mantém a compatibilidade com os navegadores antigos onde essa atribuição era necessária. Essa solução foi mencionada neste link, onde também é dito que isso não resolve problemas de compatibilidade com navegadores antigos e o Google Maps.

A mesma alteração do prototype.js foi feita no arquivo framework.pack.js, só que na linha 343. Esse arquivo é, aparentemente, a versão obfuscada e minificada dos scripts do richfaces-impl.

Ao realizar essas duas modificações pontuais, gerar uma nova versão do artefato do richfaces-impl e atualizar as dependências do projeto original (apontando para essa versão corrigida do richfaces-impl), os modos híbrido e satélite do Google Maps voltaram a funcionar normalmente.

Considerações Finais

Espero que este tutorial tenha auxiliado de alguma forma no aprendizado deste problema entre Google Maps e Richfaces. Como essa lib (Richfaces) é bem antiga, possivelmente a maioria dos projetos já migrou para outras tecnologias.

Valeu pessoal e até o próximo post !!

Um tutorial completo sobre o Maven e o gerenciamento de dependências

Mon, 02 Aug 2021 01:22:00 -0300

Resumo
O que é gerenciamento de dependências
Gerenciadores de dependências
Apache Maven
Utilizando o Maven com o Eclipse
Criação do projeto de exemplo
Arquivo pom.xml
Ciclo de vida do build com Maven
Versionamento de dependências
Tipos de dependências
Escopos de dependências
Executando o Maven via linha de comando
Executando o Maven via Eclipse

Resumo

E aí pessoal, beleza?

A ideia deste post é compartilhar com vocês sobre como o Maven funciona e qual os conceitos por trás do gerenciamento de dependências.

Os pré-requisitos para acompanhar este tutorial são:

o conhecimento básico de inglês para leitura;
ter uma versão do Java instalado;
ter uma IDE para programação em Java com o Maven embutido (como o Eclipse, que já vem com uma versão do Maven) ou com o Maven instalado separadamente.

O que é gerenciamento de dependências

Ao programar em Java (e em outras linguagens de backend), é muito comum precisarmos de funcionalidades especiais para testes automatizados, frameworks para web, funcionalidades para tratamento de tipos específicos de dados (XML, JSON, csv, etc), ou ainda, algoritmos específicos para um determinado problema.

Se você é um programador com mais experiência, você mesmo pode criar essas funcionalidades. É um excelente exercício para o aprendizado, porém, na vida real, trabalhamos com prazos (deadlines) que muitas vezes inviabilizam essa prática, por ter um alto custo (de tempo para implementação, testes, validação, etc). Então, se não temos tempo suficiente para resolver estes problemas, o que fazer?

Em vez de reinventar a roda, é possível utilizar o que já existe para economizarmos tempo (e por consequência, dinheiro). Muitos dos problemas que fazem parte do dia a dia de programadores, hoje, possuem soluções em código aberto (open source) disponibilizadas no Github para toda a comunidade. Essas soluções podem ser integradas e utilizadas em nossos projetos, e nesse caso, acabam se tornando uma dependência do projeto. A partir deste momento, as novas funcionalidades podem ser utilizadas no nosso projeto de modo que não seja necessário implementar toda a lógica necessária para resolver o problema.

* É importante analisar as licenças destes projetos de código aberto e verificar o que é ou não permitido com relação ao uso comercial e não-comercial do software/dependência.

Por exemplo, em Java, se precisarmos manipular dados no formato JSON, em vez de escrevermos toda a lógica para manipular esses dados e mapea-los para variáveis e objetos, podemos utilizar a biblioteca (lib ou library) jackson, que vai tornar a tarefa muito mais simples com muito menos esforço, utilizando um código testado por outros desenvolvedores em muitos projetos reais.

* Isso não quer dizer que todas as soluções de código aberto sejam amplamente utilizadas e testadas. Na verdade, uma parte ínfima delas que é amplamente usada, por isso, pesquise antes de sair utilizando dependências de forma irresponsável.

Ainda, surgirão situações em que uma solução comum é necessária para vários projetos de uma organização, mas são problemas muito específicos e estratégicos que não podem estar disponibilizados em plataformas de código aberto, como o Github.

Nesses casos, é possível que a própria organização crie a solução e a salve em um repositório interno e fechado para que os próprios colaboradores possam utilizar essas soluções como dependências nos projetos internos da empresa. São dependências que não são de código aberto.

A ideia por trás do gerenciamento de dependências é a de termos o controle sobre as dependências em nossos projetos, sejam essas dependências internas (da própria organização) ou externas (feitas por terceiros ou pela comunidade, em código aberto), para que o desenvolvedor possa focar mais na solução dos problemas específicos do negócio e menos nas dependências em si.

Gerenciadores de dependências

Com o objetivo de simplificar e automatizar tarefas de gerenciamento de dependências, ao longo dos anos surgiram diversas ferramentas para resolver específicamente este problema. Abaixo, é descrita uma lista de ferramentas para gerenciamento de dependências para diversas linguagens de desenvolvimento:

NPM: aplicações web e JavaScript;
Yarn: aplicações web e JavaScript;
Composer: aplicações PHP;
Maven: aplicações Java e Kotlin;
Gradle: aplicações Java, Groovy, Kotlin, Android, Scala e JavaScript;
NuGet: aplicações .NET;
Pip: aplicações Python;
Rubygem: aplicações Ruby;
Mix: aplicações Elixir;
Hex: aplicações Erlang;
Cargo: aplicações Rust;

Neste post, vou escrever em detalhes sobre como funciona o gerenciamento de dependências com o Maven.

* No futuro pretendo fazer com mesmo com o Gradle ;).

Apache Maven

O Maven é o gerenciador de dependências para desenvolvimento com Java (e também para Kotlin). A primeira versão estável foi liberada em julho de 2004. No momento de escrita deste artigo, o Maven está na versão 3.8.1, com o total de 1,435,611 pacotes publicados em 2020.

No site do Maven, é possível ler a documentação completa sobre o Maven e seus respectivos plugins, muito utilizados para auxiliar no processo de automação do processo de build dos projetos.

No repositório central do Maven podem ser encontradas as dependências que podem ser importadas nos nossos projetos. Eu utilizo muito esse site quando estou atualizando dependências antigas de projetos legados.

Utilizando o Maven com o Eclipse

Para mostrar como utilizar o Maven, será utilizada a IDE Eclipse para a criação de um projeto de exemplo.

O objetivo é mostrar como funciona o gerenciamento de dependências com o Maven. Para quem utiliza outra IDE (como o IntelliJ ou o VS Code), não tem problema nenhum, pois o mais importante é a parte sobre como utilizar o Maven, que independe da IDE. Para os que desejarem acompanhar o tutorial com o Eclipse, recomendo uma breve leitura na documentação caso existam dúvidas.

Criação do projeto de exemplo

Vamos seguir o passo a passo para criar um projeto de exemplo com o Maven como gerenciador de dependências.

1- Clicar em File -> new -> Other…

Other' aberto.">

2- Selecionar Maven -> Maven Project e clicar em Next.

3- Desmarcar a opção “Create a simple project” e marque a opção “Use default workspace location” se desejar usar o diretório padrão do eclipse como base do projeto. Caso contrário, logo abaixo, você pode escolher manualmente o diretório do projeto. Após isso, clicar em Next.

4- No campo Filter, digite org.apache.maven.archetypes e selecione o Artifact Id maven-archetype-quickstart. Esse ‘archetype’ é o esqueleto de uma aplicação de exemplo com o Maven. Clique em Next.

5- Preencher os seguintes campos:

a) Group Id: é o identificador do projeto. O padrão de nomenclatura utilizado é com.EMPRESA.PROJETO OU br.com.EMPRESA.PROJETO, que geralmente é a hierarquia de diretórios do projeto. Aqui vou colocar com.luciano.app.

b) Artifact Id: é o identificador do projeto em si. Nomes compostos são geralmente separados por traços. Vou colocar example-app.

c) Version: é a versão inicial do projeto. Eu não gosto de usar o versionamento com palavras misturadas com números, mas a título de exemplo vamos usar o padrão oferecido pela IDE, a versão 0.0.1-SNAPSHOT. Feito isso, clicar em Finish para criar o projeto.

Ao abrir o arquivo pom.xml, teremos a visualização abaixo.

O código fonte e de testes que desenvolvemos em nossos projetos ficam na pasta src;
As bibliotecas da versão do Java que estamos utilizando ficam em JRE System Library[JavaSE-1.7] (no meu caso, o Java 7);
As dependências do nosso projeto ficam em Maven Dependencies e os arquivos resultantes do build do projeto ficam em target;
Em src, ainda temos os subdiretórios main/java (onde fica o código fonte do projeto) e test/java (onde fica o código de testes automatizados).

Arquivo pom.xml

Gerenciamos as dependências e o processo de build do Maven pelo comando executado e pelo pom.xml. Vejamos abaixo cada uma das tags no projeto de exemplo.

xml: versão do xml utilizado e a codificação utilizada para o documento. Não é obrigatória, mas é recomendado o seu uso para que o parser saiba o encoding correto do documento.

1

<?xml version="1.0" encoding="UTF-8"?>

project: Todas tags que representam nosso projeto vão no interior da tag project. As propriedades são opcionais.

1
2


<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

modelVersion: indica que o descritor do projeto é compatível com as versões 2 e 3 do Maven. É uma tag obrigatória.

1

<modelVersion>4.0.0</modelVersion>

* Para verificar a versão do Maven embutida no Eclipse: Window -> Preferences -> Maven -> Installations. Na imagem abaixo, temos a versão 3.6.3.

* Para verificar a versão do Maven instalada por outros meios, abra o prompt de comando e digite mvn -version. No meu caso, tenho a versão 3.8.1 instalada.

groupId, artifactId e version: São as tags que definimos anteriormente ao criarmos o projeto. GroupId é a hierarquia de diretórios, artifactId é o ID do projeto em si e version é a versão do artefato.

1
2
3


<groupId>com.luciano.app</groupId>
<artifactId>example-app</artifactId>
<version>0.0.1-SNAPSHOT</version>

name: é a tag que representa o nome oficial do projeto e url é a url para acessar o site do projeto, caso exista. Como não temos um site, vou remover a tag url.

1
2
3


<name>example-app</name>
<!-- FIXME change it to the project's website -->
<url>http://www.example.com</url>

properties: são propriedades que serão utilizadas pelo próprio arquivo de dependências em um dos processos do ciclo de vida do Maven. Mais adiante vou explicar o que é este ciclo de vida.

1
2
3
4
5


<properties>
 <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 <maven.compiler.source>1.7</maven.compiler.source>
 <maven.compiler.target>1.7</maven.compiler.target>
</properties>

O projeto de exemplo veio com três propriedades:

project.build.sourceEncoding: define que o padrão de codificação dos arquivos do projeto é o UTF-8. Para mais detalhes sobre codificação, acesse aqui.

1

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

maven.compiler.source e maven.compiler.target: são argumentos para o compilador do Java, para o código fonte (source) e para o código gerado após o build (target). Podemos, a partir da versão 3.6 do maven-compiler-plugin e da versão 9 do JDK (Java), usar a tag maven.compiler.release com o mesmo efeito.

1
2
3
4
5
6


<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>

<!-- ou -->

<maven.compiler.release>1.7</maven.compiler.release>

* Dica: até a versão 8 do java, colocamos o prefixo ‘1.’ antes da versão. Assim: 1.7 (versão 7), 1.8 (versão 8). A partir da versão 9, o número da versão não tem esse prefixo.

No meu caso, vou substituir pela versão do Java que eu utilizo com mais frequência, a versão 11.

* Para fazer isso você precisa dessa versão do JDK (Java Development Kit) instalada no computador.

Para concretizar a mudança na IDE, clique em cima da pasta raíz do projeto -> Maven -> Update Project. Apenas clique em Ok. Para verificar se deu certo, verifique se o nome do diretório JRE System Library[JavaSE-1.7] mudou para JRE System Library[JavaSE-11].

dependencies: todos os artefatos que usamos como dependências em nosso projeto devem ser colocados dentro dessa tag.

1
2
3
4
5
6
7
8


<dependencies>
 <dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>4.11</version>
 <scope>test</scope>
 </dependency>
</dependencies>

Para cada dependência, teremos uma tag dependency e dentro dela, informamos obrigatoriamente os seguintes identificadores da dependência: groupId, artifactId e version. O significado já foi apresentado aqui.

scope: serve para limitar a transitividade da dependência e determinar o momento de incluir a mesma no classpath.

No exemplo acima, junit é uma conhecida biblioteca no mundo Java para a criação de testes automatizados, como testes unitários. Ela só é utilizada durante os testes, não sendo necessária em outros momentos do ciclo de vida do projeto. Ao definir o scope como test, dizemos que a dependência só é requerida na fase de testes (fases test-compile e test) do Maven.

* Veremos os outros possíveis valores dessa tag na sequência deste tutorial.

Caso queiramos adicionar outras dependências, basta adicioná-las seguindo o mesmo formato, conforme abaixo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


<dependencies>
 <dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>4.11</version>
 <scope>test</scope>
 </dependency>

 <dependency>
 <groupId>org.apache.logging.log4j</groupId>
 <artifactId>log4j-api</artifactId>
 <version>2.14.1</version>
 </dependency>

 <dependency>
 <groupId>org.apache.logging.log4j</groupId>
 <artifactId>log4j-core</artifactId>
 <version>2.14.1</version>
 </dependency>
</dependencies>

No caso, adicionamos o log4j, uma biblioteca que permite criarmos logs para nossa aplicação de forma simples e prática.

Uma pecualiaridade desse caso é que precisamos de duas dependências para usar essas funcionalidades.

Nesses casos, há uma outra forma mais segura de se fazer essa declaração: utilizando BOMs (Bill Of Materials).

Basicamente, o BOM garante que as versões de dependências diretas e transitivas de artefatos sejam as mesmas. Ainda, isso permite que não seja necessário declarar a tag version dos artefatos envolvidos nas dependencies.

* Exemplo de dependência transitiva: a dependência A depende de B e B depende de C, portanto A depende de ambas B e C. C é uma dependência transitiva para A, pois A não requer C diretamente, mas B sim, e B é requerida por A.

Abaixo um exemplo de como usar o BOM com o log4j:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


<dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>org.apache.logging.log4j</groupId>
 <artifactId>log4j-bom</artifactId>
 <version>2.14.1</version>
 <scope>import</scope>
 <type>pom</type>
 </dependency>
 </dependencies>
</dependencyManagement>

<dependencies>
 <dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>4.11</version>
 <scope>test</scope>
 </dependency>

 <dependency>
 <groupId>org.apache.logging.log4j</groupId>
 <artifactId>log4j-api</artifactId>
 </dependency>

 <dependency>
 <groupId>org.apache.logging.log4j</groupId>
 <artifactId>log4j-core</artifactId>
 </dependency>
</dependencies>

Declaramos a BOM do log4j na tag dependencyManagement. Agora os artefatos log4j-api e log4j-core não precisam mais definir a versão em version, pois já foram definidos no BOM (como versão 2.14.1).

Caso seja necessário atualizar no futuro a versão dessa dependência, basta atualizar o campo version do BOM em vez de atualizar cada version individualmente.

* Cabe ressaltar que cada projeto é responsável pelo fornecimento do BOM, portanto nem todos os projetos tem essa funcionalidade/facilidade.

build: inclui os plugins que utilizamos no build do projeto. Segue o exemplo abaixo, gerado pela IDE.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50


<build>
 <pluginManagement>
 <plugins>
 <plugin>
 <artifactId>maven-clean-plugin</artifactId>
 <version>3.1.0</version>
 </plugin>

 <plugin>
 <artifactId>maven-resources-plugin</artifactId>
 <version>3.0.2</version>
 </plugin>

 <plugin>
 <artifactId>maven-compiler-plugin</artifactId>
 <version>3.8.0</version>
 </plugin>

 <plugin>
 <artifactId>maven-surefire-plugin</artifactId>
 <version>2.22.1</version>
 </plugin>

 <plugin>
 <artifactId>maven-jar-plugin</artifactId>
 <version>3.0.2</version>
 </plugin>

 <plugin>
 <artifactId>maven-install-plugin</artifactId>
 <version>2.5.2</version>
 </plugin>

 <plugin>
 <artifactId>maven-deploy-plugin</artifactId>
 <version>2.8.2</version>
 </plugin>

 <plugin>
 <artifactId>maven-site-plugin</artifactId>
 <version>3.7.1</version>
 </plugin>

 <plugin>
 <artifactId>maven-project-info-reports-plugin</artifactId>
 <version>3.0.0</version>
 </plugin>
 </plugins>
 </pluginManagement>
</build>

No xml acima temos os principais plugins, geralmente utilizados em projetos Java da vida real com o Maven (não tive ainda a oportunidade de ver na prática o maven-site-plugin e o maven-project-info-reports-plugin, mas basicamente servem para gerar uma documentação do projeto em formato de site).

Antes de falar sobre os plugins, precisamos entender como funciona o ciclo de vida (Lifecycle) do build com o Maven.

Ciclo de vida do build com Maven

Temos três Lifecycles no Maven:

clean
default
site

Vou abordar aqui o default que é o que envolve mais fases do build.

Os Lifecycles são compostos por fases executadas em uma determinada ordem. O default é composto pelas seguintes fases (nessa ordem):

validate: verifica se o projeto está correto e possui as informações mínimas necessárias;
initialize: inicializa o estado do build (seta propriedades ou cria diretórios);
generate-sources: gera código fonte para inclusão na compilação;
process-sources: processa o código fonte (por exemplo, para filtrar valores);
generate-resources: gera recursos para inclusão no pacote;
process-resources: copia e processa os recursos para o diretório destino para o empacotamento (packaging);
compile: compila o código fonte do projeto;
process-classes: pós processamento dos arquivos gerados pela compilação (por exemplo, melhoria do bytecode das classes Java);
generate-test-sources: gera código fonte de teste para inclusão na compilação dos testes;
process-test-sources: processa o código fonte dos testes (por exemplo, para filtrar valores);
generate-test-resources: cria recursos para os testes;
process-test-resources: copia e processa os recursos para o diretório destino dos testes;
test-compile: compila o código fonte dos testes para o diretório destino dos testes;
process-test-classes: pós processamento dos arquivos de teste gerados pela compilação (por exemplo, melhoria do bytecode das classes Java);
test: execução de testes com um framework de testes unitários. Tais testes não requerem que o código seja empacotado packaged ou implantado (deployed);
prepare-package: executa operações necessárias para preparação do pacote. Resulta em uma versão não empacotada e processada do pacote;
package: empacotamento do código fonte compilado em um formato distribuível, como o JAR;
pre-integration-test: executa ações requeridas antes da execução dos testes de integração (como montar um ambiente por exemplo);
integration-test: processa e implanta o pacote em um ambiente onde os testes de integração podem ser executados (se necessário);
post-integration-test: executa ações requeridas após a execução dos testes de integração (como limpar o ambiente onde foram executados os testes, por exemplo);
verify: execução de verificações se o pacote é válido e atinge os critérios de qualidade;
install: instalação do pacote no repositório local para ser utilizado por outras dependências locais;
deploy: feito em um ambiente de integração (integration) ou liberação (release), realiza a cópia do pacote final para o repositório remoto para compartilhamento com outros desenvolvedores e projetos.

A execução dessas fases depende também do modo de empacotamento packaging definido no pom.xml. Exemplos práticos, com mais detalhes, serão dados mais adiante.

Para o gerenciamento de cada fase do lyfecycle, os plugins do Maven nos auxiliam nesse processo.

O clean plugin é utilizado para limpar o ambiente de um build executado anteriormente. Podemos customizar o processo, como quais diretórios excluir ou não.

1

<artifactId>maven-clean-plugin</artifactId>

O resources plugin é utilizado para mover recursos do código fonte e de testes para diretórios específicos, entre outras tarefas relativas aos recursos do projeto.

1

<artifactId>maven-resources-plugin</artifactId>

O compiler plugin é utilizado no processo de compilação do código fonte e de testes. Podemos customizar os parâmetros da compilação, usar uma versão específica da JDK, entre outros.

1

<artifactId>maven-compiler-plugin</artifactId>

O surefire plugin é utilizado para a execução dos testes unitários do projeto. Podemos customizar os parâmetros da execução dos testes, como por exemplo, definir o framework de testes a ser utilizado.

1

<artifactId>maven-surefire-plugin</artifactId>

O jar plugin é utilizado no processo de geração de jars nos processos de empacotamento do código. Podemos customizar os arquivos que serão empacotados, entre outras funcionalidades.

1

<artifactId>maven-jar-plugin</artifactId>

O install plugin é utilizado na fase install para instalar o projeto no repositório local do usuário, para que o projeto possa ser utilizado como dependência em outros projetos localmente. O repositório local costuma ser em (~/.m2/repository) mas a localização pode ser alterada no arquivo (~/.m2/settings.xml), modificando o conteúdo na tag localRepository.

1

<artifactId>maven-install-plugin</artifactId>

O deploy plugin é utilizado na fase deploy para instalar o projeto no repositório remoto onde o projeto ficará disponível para outros projetos e desenvolvedores.

1

<artifactId>maven-deploy-plugin</artifactId>

Versionamento de dependências

Uma prática comum adotada é a de declarar as versões das dependências do projeto na tag properties. No projeto de exemplo, ficaria assim.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82


<properties>

 <!-- plugins versioning -->
 <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 <maven.compiler.release>11</maven.compiler.release>
 <maven.clean.plugin.version>3.1.0</maven.clean.plugin.version>
 <maven.resources.plugin.version>3.0.2</maven.resources.plugin.version>
 <maven.compiler.plugin.version>3.8.0</maven.compiler.plugin.version>
 <maven.surefire.plugin.version>2.22.1</maven.surefire.plugin.version>
 <maven.jar.plugin.version>3.0.2</maven.jar.plugin.version>
 <maven.install.plugin.version>2.5.2</maven.install.plugin.version>
 <maven.deploy.plugin.version>2.8.2</maven.deploy.plugin.version>

 <!-- dependencies versioning -->
 <log4j.bom.version>2.14.1</log4j.bom.version>
 <junit.version>4.11</junit.version>

</properties>

<dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>org.apache.logging.log4j</groupId>
 <artifactId>log4j-bom</artifactId>
 <version>${log4j.bom.version}</version>
 <scope>import</scope>
 <type>pom</type>
 </dependency>
 </dependencies>
</dependencyManagement>

<dependencies>
 <dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>${junit.version}</version>
 <scope>test</scope>
 </dependency>
 <dependency>
 <groupId>org.apache.logging.log4j</groupId>
 <artifactId>log4j-api</artifactId>
 </dependency>
 <dependency>
 <groupId>org.apache.logging.log4j</groupId>
 <artifactId>log4j-core</artifactId>
 </dependency>
</dependencies>

<build>
 <pluginManagement>
 <plugins>
 <plugin>
 <artifactId>maven-clean-plugin</artifactId>
 <version>${maven.clean.plugin.version}</version>
 </plugin>
 <plugin>
 <artifactId>maven-resources-plugin</artifactId>
 <version>${maven.resources.plugin.version}</version>
 </plugin>
 <plugin>
 <artifactId>maven-compiler-plugin</artifactId>
 <version>${maven.compiler.plugin.version}</version>
 </plugin>
 <plugin>
 <artifactId>maven-surefire-plugin</artifactId>
 <version>${maven.surefire.plugin.version}</version>
 </plugin>
 <plugin>
 <artifactId>maven-jar-plugin</artifactId>
 <version>${maven.jar.plugin.version}</version>
 </plugin>
 <plugin>
 <artifactId>maven-install-plugin</artifactId>
 <version>${maven.install.plugin.version}</version>
 </plugin>
 <plugin>
 <artifactId>maven-deploy-plugin</artifactId>
 <version>${maven.deploy.plugin.version}</version>
 </plugin>
 </plugins>
 </pluginManagement>
</build>

Para o junit, por exemplo, criamos a tag junit.version com valor 4.11. Ao definirmos a versão nas dependências, colocamos ${junit.version}.

Ao executar o build do projeto, ${junit.version} será substituído pelo valor 4.11.

Acredito que essa forma é mais adequada, pois as versões de todas dependências ficam centralizadas em um só lugar, não sendo necessário mais lidar com a lista de dependências, com menos riscos de erros ao atualizar versões.

Tipos de dependências

As mais comuns são pom e jar (default). Elas são definidas na tag type em dependências presentes em dependencyManagement. O tipo jar é o padrão, que nos informa que a dependência do projeto é um jar (geralmente representa a extensão da dependência mas nem sempre é o caso).

O caso pom é especial e será tratado na parte dos escopos de dependências. Ainda temos os tipos war e ear, comuns em sistemas legados com JBoss e versões antigas do Java.

Escopos de dependências

O scope das dependências pode ser:

Direto: quando são definidas no arquivo pom.xml em dependencies;
Transitivo: quando dependem de nossas dependências diretas (Exemplo: A depende de B que depende de C. B está declarada no projeto A e C está declarada no projeto B. Portanto, C é uma dependência transitiva para A);

Temos seis escopos no Maven:

Compile: Este é o escopo padrão, usado se nenhum for especificado. As dependências ficam disponíveis em todos os classpaths de um projeto. Além disso, essas dependências são propagadas para projetos dependentes.

* classpath: caminho completo das classes que são dependências diretas do projeto. Fonte: em parte, traduzido do site oficial do Maven

Provided: Indica que o JDK ou um contêiner forneça a dependência no tempo de execução (runtime). Por exemplo, ao construir um aplicativo web para o Java Enterprise Edition (JEE), as dependências da API Servlet e APIs Java EE seriam setadas com o escopo provided porque o contêiner web fornece essas classes. Uma dependência com este escopo é adicionada ao classpath usado para compilação e testes, mas não ao classpath do tempo de execução. Não é transitivo.
Runtime: indica que a dependência não é necessária para compilação, mas sim para execução. O Maven inclui uma dependência com esse escopo no tempo de execução e nos caminhos de classe de teste, mas não no caminho de classe de compilação.
Test: indica que a dependência está disponível apenas para as fases de compilação e testes. Este escopo não é transitivo. Normalmente, é usado para bibliotecas de teste, como JUnit e Mockito. Também é usado para bibliotecas como Apache Commons IO, se essas bibliotecas forem usadas em testes de unidade (src/test/java) mas não no código principal (src/main/java).
System: semelhante ao provided, exceto que é preciso fornecer o JAR que o contém explicitamente, especificado na declaração da dependência (através da tag systemPath). O artefato está sempre disponível e não é consultado em um repositório. Não é recomendado seu uso por questões de portabilidade (exemplo: você garante que o caminho da dependência será o mesmo nos servidores ou nas máquinas/containers de todos os devs?).
Import: é compatível apenas com dependências do tipo (type) pom na tag dependencyManagement. Indica que a dependência deve ser substituída pela lista efetiva de dependências no dependencyManagement do POM especificado. Uma vez que foram substituídas, as dependências com o escopo import não participarão na limitação da transitividade de uma dependência.

O caso do import é mais complicado, portanto vou exemplificar com o exemplo do site oficial do Maven.

Vamos supor que temos os seguintes projetos.

Projeto X:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>maven</groupId>
 <artifactId>X</artifactId>
 <packaging>pom</packaging>
 <name>X</name>
 <version>1.0</version>
 
 <dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>test</groupId>
 <artifactId>a</artifactId>
 <version>1.1</version>
 </dependency>
 <dependency>
 <groupId>test</groupId>
 <artifactId>b</artifactId>
 <version>1.0</version>
 <scope>compile</scope>
 </dependency>
 </dependencies>
 </dependencyManagement>
</project>

Projeto Y:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>maven</groupId>
 <artifactId>Y</artifactId>
 <packaging>pom</packaging>
 <name>Y</name>
 <version>1.0</version>
 
 <dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>test</groupId>
 <artifactId>a</artifactId>
 <version>1.2</version>
 </dependency>
 <dependency>
 <groupId>test</groupId>
 <artifactId>c</artifactId>
 <version>1.0</version>
 <scope>compile</scope>
 </dependency>
 </dependencies>
 </dependencyManagement>
</project>

Projeto Z:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>maven</groupId>
 <artifactId>Z</artifactId>
 <packaging>pom</packaging>
 <name>Z</name>
 <version>1.0</version>
 
 <dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>maven</groupId>
 <artifactId>X</artifactId>
 <version>1.0</version>
 <type>pom</type>
 <scope>import</scope>
 </dependency>
 <dependency>
 <groupId>maven</groupId>
 <artifactId>Y</artifactId>
 <version>1.0</version>
 <type>pom</type>
 <scope>import</scope>
 </dependency>
 </dependencies>
 </dependencyManagement>
</project>

O projeto Z importa as dependências de X e Y, porém ambas tem o artefato a com versões diferentes.

Será importado o artefato mais próximo na hierarquia do projeto pai.

Porém, neste caso, ambos estão no mesmo nível, então será importado o de X com a versão 1.1, pois foi declarado no pom de Z antes do artefato Y.

Ainda, Z não possui uma dependência direta do artefato a, pois se tivesse, essa que seria utilizada.

Outro exemplo:

Projeto A:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>maven</groupId>
 <artifactId>A</artifactId>
 <packaging>pom</packaging>
 <name>A</name>
 <version>1.0</version>
 <dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>test</groupId>
 <artifactId>a</artifactId>
 <version>1.2</version>
 </dependency>
 <dependency>
 <groupId>test</groupId>
 <artifactId>b</artifactId>
 <version>1.0</version>
 <scope>compile</scope>
 </dependency>
 <dependency>
 <groupId>test</groupId>
 <artifactId>c</artifactId>
 <version>1.0</version>
 <scope>compile</scope>
 </dependency>
 <dependency>
 <groupId>test</groupId>
 <artifactId>d</artifactId>
 <version>1.2</version>
 </dependency>
 </dependencies>
 </dependencyManagement>
</project>

Projeto B:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>maven</groupId>
 <artifactId>B</artifactId>
 <packaging>pom</packaging>
 <name>B</name>
 <version>1.0</version>
 
 <dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>maven</groupId>
 <artifactId>A</artifactId>
 <version>1.0</version>
 <type>pom</type>
 <scope>import</scope>
 </dependency>
 <dependency>
 <groupId>test</groupId>
 <artifactId>d</artifactId>
 <version>1.0</version>
 </dependency>
 </dependencies>
 </dependencyManagement>
 
 <dependencies>
 <dependency>
 <groupId>test</groupId>
 <artifactId>a</artifactId>
 <version>1.0</version>
 <scope>runtime</scope>
 </dependency>
 <dependency>
 <groupId>test</groupId>
 <artifactId>c</artifactId>
 <scope>runtime</scope>
 </dependency>
 </dependencies>
</project>

Neste exemplo, o projeto B possui o projeto A e suas dependências como dependência, exceto os artefatos d e a de A, pois os mesmos estão sendo declarados no projeto B. Todos artefatos (a, b, c, d) são da versão 1.0.

Utilizando o Maven

Para demonstrar o uso do Maven, vamos fazer isso de duas formas: utilizando a linha de comando no terminal (CLI - Command Line Interface) e a própria IDE Eclipse.

Executando o Maven via linha de comando

Para executar o Maven através da linha de comando, é possível utilizar o terminal do Ubuntu (Ctrl + T) ou a aba Terminal do próprio Eclipse.

Para abrir o terminal no Eclipse: clicar em Window -> Show View -> Other, e selecionar Terminal, conforme as imagens abaixo.

Show View -> Other...' aberto.">

Logo após, clicar no ícone destacado no círculo amarelo, selecionar ‘Local Terminal’ e clicar em Ok.

Agora, é preciso ir ao terminal e digitar o path (local) do projeto. Para isso, basta utilizar o comando cd e logo após, o path completo de onde está localizado o projeto.

Exemplo:

1

cd /home/usuario_x/projetos/example_project

* Caso tenha dúvidas sobre comandos básicos de bash/shell no Linux, recomendo a leitura deste artigo da Hostinger, em português.

Agora vamos executar algumas fases do ciclo de vida do Maven. Digite o comando abaixo no terminal:

1

mvn clean

O comando acima executa a fase ‘clean’ do ciclo de vida do Maven. Abaixo, a saída exibida no terminal.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


[INFO] Scanning for projects...
[INFO] 
[INFO] ------------------< com.luciano.app:example-project >-------------------
[INFO] Building example-project 0.0.1-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ example-project ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.312 s
[INFO] Finished at: 2021-07-11T23:01:02-03:00
[INFO] ------------------------------------------------------------------------

A mensagem acima informa que o clean funcionou conforme o esperado, ou seja, excluiu todo o conteúdo do diretório target, na raíz do projeto. O conteúdo desse diretório é o resultado do processamento de builds executados anteriormente.

Agora, o comando ‘compile’:

1

mvn compile

Resultado:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


[INFO] Scanning for projects...
[INFO] 
[INFO] ------------------< com.luciano.app:example-project >-------------------
[INFO] Building example-project 0.0.1-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ example-project ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/lu/Lubrum/example-project/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ example-project ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to /home/lu/Lubrum/example-project/target/classes
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.252 s
[INFO] Finished at: 2021-07-11T23:08:05-03:00
[INFO] ------------------------------------------------------------------------

O resultado acima informa que o compile executou com sucesso, ou seja, o código fonte foi compilado com sucesso. Neste processo, o Maven executou as fases process-resources e compile. Como não existem recursos em nosso projeto de exemplo, o Maven exibiu as mensagens abaixo:

1
2
3


[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ example-project ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/lu/Lubrum/example-project/src/main/resources

Por padrão, as fases executadas em um projeto dependem do modo de empacotamento (packaging) definido no pom.xml. Se nenhum modo for definido, é utilizado o modo jar.

Para o jar, temos por padrão as seguintes fases, nessa ordem:

process-resources, compile, process-test-resources, test-compile, test, package, install e deploy;

Foi definido como objetivo a fase compile, portanto as fases anteriores e a escolhida (process-resources e compile) foram executadas.

Agora vamos executar o comando para limpar o diretório target e empacotar nosso código.

1

mvn clean package

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


[INFO] Scanning for projects...
[INFO] 
[INFO] ------------------< com.luciano.app:example-project >-------------------
[INFO] Building example-project 0.0.1-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ example-project ---
[INFO] Deleting /home/lu/Lubrum/example-project/target
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ example-project ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/lu/Lubrum/example-project/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ example-project ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to /home/lu/Lubrum/example-project/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:testResources (default-testResources) @ example-project ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/lu/Lubrum/example-project/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @ example-project ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to /home/lu/Lubrum/example-project/target/test-classes
[INFO] 
[INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ example-project ---
[INFO] 
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.luciano.app.example_project.AppTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 s - in com.luciano.app.example_project.AppTest
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) @ example-project ---
[INFO] Building jar: /home/lu/Lubrum/example-project/target/example-project-0.0.1-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.800 s
[INFO] Finished at: 2021-07-11T23:57:20-03:00
[INFO] ------------------------------------------------------------------------

As seguintes fases foram executadas: clean, process-resources, compile, process-test-resources, test-compile, test e package.

Perceba que a fase clean não faz parte do processo de build default para o modo jar, mas como incluímos no comando, ele foi primeiramente executado, e logo após, a fase package. Podemos executar uma sequência de várias fases do lifecycle especificando argumentos e definindo objetivos (goals), se assim desejarmos.

Na fase compile foram compilados os códigos fontes em /src/main/java e na fase testCompile foram compilados os códigos de testes em /src/test/java. Ainda, após a compilação do código de testes, foram executados os testes em si, na fase test.

Não vou entrar no mérito da lógica e funcionamento dos testes unitários com o JUnit, por si só é um assunto para um livro inteiro. Quem sabe um dia eu escreva algo por aqui? :-)

Por fim, foi feito o empacotamento do código resultante do processo de build no formato .jar na pasta target. Lá deve conter um arquivo com o nome example-project-0.0.1-SNAPSHOT.jar.

Se abrirmos o conteúdo do jar, veremos que ele possui dois diretórios:

com: possui todo o código compilado pelo Maven, seguindo a estrutura original de diretórios do projeto;
META-INF: possui o arquivo MANIFEST.MF com informações do build/projeto e o diretório Maven com os arquivos pom.xml (o mesmo que criamos) e pom.properties (com detalhes do projeto empacotado).

Ok, agora vamos proceder para a instalação do projeto no nosso repositório local:

1

mvn install

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


.
.
. 
(mesmas mensagens apresentadas anteriormente até a fase package)
.
.
.
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ example-project ---
[INFO] Installing /home/lu/Lubrum/example-project/target/example-project-0.0.1-SNAPSHOT.jar to /home/lu/.m2/repository/com/luciano/app/example-project/0.0.1-SNAPSHOT/example-project-0.0.1-SNAPSHOT.jar
[INFO] Installing /home/lu/Lubrum/example-project/pom.xml to /home/lu/.m2/repository/com/luciano/app/example-project/0.0.1-SNAPSHOT/example-project-0.0.1-SNAPSHOT.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.008 s
[INFO] Finished at: 2021-07-12T00:15:51-03:00
[INFO] ------------------------------------------------------------------------

Após a mensagem de sucesso, podemos verificar no diretório apresentado acima o conteúdo dessa instalação do Maven (em /home/lu/.m2…).

* Conforme mencionado anteriormente no tutorial, o diretório (~/.m2/repository) geralmente é o padrão de instalação de dependências no ambiente local.

Temos quatro arquivos: o .jar gerado na fase package, o arquivo .pom (uma cópia do pom.xml), o maven-metadata-local (arquivo com metadados do projeto, gerenciado pelo Maven) e um _remote.repositories (arquivo também gerenciado pelo Maven, que serve para se saber de onde foram geradas as dependências).

Ok, nosso projeto está instalado no ambiente local. O que isso significa?

Significa que podemos importar este projeto como dependência em outros projetos locais que forem desenvolvidos. Para isso, basta declararmos no novo projeto o seguinte (no pom.xml, na tag dependencies):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


<dependencies>
 .
 .
 .
 outras dependências
 .
 .
 .
 <dependency>
 <groupId>com.luciano.app</groupId>
 <artifactId>example-app</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 </dependency>
</dependencies>

Com isso, importamos as funcionalidades do example-app neste hipetético novo projeto !

Para exemplificar o deploy do projeto, vou utilizar como gerenciador de repositórios local o Archiva. Na prática, é possível instalar o Archiva em um servidor e instruir o Maven para fazer o deploy neste servidor (que pode ser em ambiente local, ou remoto na nuvem com serviços providos pela AWS, Google Cloud, Azure, etc).

Para instalar o archiva:

baixe o arquivo tar.gz do site do archiva;
extraia o conteúdo do pacote em um diretório de sua preferência;
na pasta bin, execute o comando ./archiva start;
verifique no navegador o archiva em http://localhost:8080;
crie um usuário e senha para o acesso ao archiva;

Podemos utilizar o próprio repositório que o archiva já oferece para instalar nossos artefatos. Nesse caso, o repositório internal (você pode verificar quais repositórios existem no archiva no menu à esquerda, em repositories).

Feito tudo isso, agora precisamos modificar nosso arquivo pom.xml do projeto e o settings.xml do Maven, geralmente localizado em /home/usuario/.m2.

Vamos adicionar o seguinte no pom.xml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


	<repositories>
		<repository>
			<id>archiva.internal</id>
			<name>repositorio interno local</name>
			<url>http://localhost:8080/repository/internal/</url>
		</repository>
	</repositories>

	<distributionManagement>
		<repository>
			<id>archiva.internal</id>
			<name>repositorio interno local</name>
			<url>http://localhost:8080/repository/internal/</url>
		</repository>
	</distributionManagement>

A tag repositories indica ao Maven o local de onde os artefatos devem ser importados para satisfazer as dependências do projeto. Por padrão, o Maven tenta resolver as dependências através do repositório central do Maven.

A tag distributionManagement indica ao maven os repositórios para onde devem ser enviados os artefatos construídos na fase de deploy do Maven.

Neste exemplo, adicionei o mesmo repositório em ambos, o archiva.internal, para que o nosso projeto possa baixar dependências que não estão no repositório central do Maven. E também para que na fase deploy o nosso projeto seja enviado para o nosso repositório privado do archiva.

Agora vamos adicionar o seguinte trecho no arquivo settings.xml no diretório .m2:

1
2
3
4
5
6
7
8
9


<settings>
 <servers>
 <server>
 <id>archiva.internal</id>
 <username>MEU_USUARIO_DO_ARCHIVA</username>
 <password>MINHA_SENHA_DO_ARCHIVA</password>
 </server>
 </servers>
</settings>

Com essas tags, estamos informando ao Maven que o repositório archiva.internal possui o nome de usuário e senha definidos neste arquivo. Em outras palavras, para enviar arquivos ao archiva é necessária essa autenticação.

Por fim, para testar se o deploy vai funcionar, basta executarmos abaixo o comando:

1

mvn deploy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


[INFO] Scanning for projects...
[INFO] 
[INFO] ------------------< com.luciano.app:example-project >-------------------
[INFO] Building example-project 0.0.1-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ example-project ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/lu/Lubrum/example-project/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ example-project ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:testResources (default-testResources) @ example-project ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/lu/Lubrum/example-project/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @ example-project ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ example-project ---
[INFO] 
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.luciano.app.example_project.AppTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.078 s - in com.luciano.app.example_project.AppTest
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) @ example-project ---
[INFO] 
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ example-project ---
[INFO] Installing /home/lu/Lubrum/example-project/target/example-project-0.0.1-SNAPSHOT.jar to /home/lu/.m2/repository/com/luciano/app/example-project/0.0.1-SNAPSHOT/example-project-0.0.1-SNAPSHOT.jar
[INFO] Installing /home/lu/Lubrum/example-project/pom.xml to /home/lu/.m2/repository/com/luciano/app/example-project/0.0.1-SNAPSHOT/example-project-0.0.1-SNAPSHOT.pom
[INFO] 
[INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ example-project ---
[INFO] Downloading from archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/0.0.1-SNAPSHOT/maven-metadata.xml
[INFO] Downloaded from archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/0.0.1-SNAPSHOT/maven-metadata.xml (367 B at 1.1 kB/s)
[INFO] Uploading to archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/0.0.1-SNAPSHOT/example-project-0.0.1-20210725.224704-2.jar
[INFO] Uploaded to archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/0.0.1-SNAPSHOT/example-project-0.0.1-20210725.224704-2.jar (3.0 kB at 16 kB/s)
[INFO] Uploading to archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/0.0.1-SNAPSHOT/example-project-0.0.1-20210725.224704-2.pom
[INFO] Uploaded to archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/0.0.1-SNAPSHOT/example-project-0.0.1-20210725.224704-2.pom (3.4 kB at 76 kB/s)
[INFO] Downloading from archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/maven-metadata.xml
[INFO] Downloaded from archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/maven-metadata.xml (327 B at 20 kB/s)
[INFO] Uploading to archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/0.0.1-SNAPSHOT/maven-metadata.xml
[INFO] Uploaded to archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/0.0.1-SNAPSHOT/maven-metadata.xml (780 B at 78 kB/s)
[INFO] Uploading to archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/maven-metadata.xml
[INFO] Uploaded to archiva.local: http://localhost:8080/repository/internal/com/luciano/app/example-project/maven-metadata.xml (326 B at 20 kB/s)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.047 s
[INFO] Finished at: 2021-07-25T19:47:05-03:00
[INFO] ------------------------------------------------------------------------

Podemos verificar nas mensagens que o Maven executou as fases anteriores ao deploy, e logo após, executou a fase deploy.

Para verificar se o arquivo foi para o repositório archiva, abrir este link.

Ao navegar em /com/luciano/app, vemos que temos a pasta relativa à versão do projeto (0.0.1-SNAPSHOT).

Ao entrar nessa pasta, temos o arquivo .jar com o nosso projeto em si com os códigos compilados, o pom.xml que informa as dependências do projeto e o arquivo maven-metadata.xml com metadados úteis para este processo de gerenciamento dos artefatos pelo Maven.

Executando o Maven via Eclipse

Em vez de utilizar comandos no terminal, é possível utilizar a própria IDE para executar os comandos do Maven. No caso do Eclipse, os passos são os seguintes:

clicar no menu superior em Run -> Run Configurations:

selecionar a opção Maven Build, clicar com o botão direito e escolher a opção New Configuration:

na aba Main, preencher o nome da configuração no campo name, definir o caminho do diretório do projeto em Base Directory (clicando em Workspace é possível buscar esse diretório) e no campo Goals definir a instrução do Maven desejada. No exemplo abaixo, foi definido o comando clean, relativo à fase clean do ciclo de vida do Maven.

adicionalmente, podemos também definir com qual versão do Java queremos executar o processo de compilação pelo Maven, na aba JRE conforme abaixo. Neste exemplo, foi definido que o Java 11 deve ser utilizado, em vez do Java 8.

Ao concluir as configurações, basta clicar no botão run para executar a tarefa do Maven.

Outra alternativa para executar o comando do Maven que foi construído é clicar no botão Run, conforme abaixo:

Considerações Finais

Espero que este tutorial tenha auxiliado de alguma forma no aprendizado do Maven e do gerenciamento de dependências.

Valeu pessoal e até o próximo post !!

Bem vindo ao Tek Broon!

Tue, 20 Apr 2021 23:00:00 -0300

Olá pessoal. Meu nome é Luciano Brum, e o objetivo do site Tek Broon é compartilhar informações e projetos sobre desenvolvimento de software e ciência de dados com a comunidade.

Serão também apresentados projetos aplicados, com foco em java para desenvolvimento e R para análise de dados.

Serão abordados os processos que englobam coleta, processamento, visualização e modelagem de dados assim como os processos de construção de modelos preditivos de aprendizado de máquina.

Para cada assunto, será criada uma página neste site, com o objetivo de compartilhar informações e resultados obtidos nas análises. Os códigos utilizados serão publicados em meu Github pessoal. Também serão produzidos e publicados vídeos reproduzindo as análises desenvolvidas em meu canal pessoal no Youtube.

Desde já, agradeço pelo interesse em meu site e se alguém tiver alguma dúvida é só entrar em contato comigo :-).

O que eu aprendi como desenvolvedor em 18 meses

Sun, 18 Apr 2021 20:40:00 -0300

Resumo

E aí pessoal, beleza?

A ideia deste post é compartilhar um pouco da minha história e do que aprendi nos últimos 18 meses como desenvolvedor Java.

Esse post é particularmente especial, pois é o primeiro que escrevo com um foco menor na parte técnica e maior na parte pessoal e de carreira. Então vamos lá !

Jornada até o primeiro emprego

Bom, tudo começou na minha infância. Com os meus aproximadamente 12 anos, ganhei um computador de presente do meu pai, que na verdade era usado por quase toda a família na época (meu pai, irmã e eu). O computador foi o primeiro contato que eu tive com algo de ’tecnologia’, por assim dizer.

Assim como muitos da minha geração, eu costumava comprar jogos (na época em CDs) para me divertir nas horas vagas na minha infância/adolescência. Cito alguns dos jogos que jogava: Diablo II, Age of Empires I e II, Hulk, Age of Mithology, Ghost Recon, Tactical Ops, Soldier of Fortune, e outros…

Por tabela, acabei desenvolvendo muita curiosidade sobre como o computador funcionava. Além de lidar com a máquina, fiz alguns cursos básicos de informática sobre Windows, Word, Excel, Internet, Power Point, Page Maker e alguns outros softwares que nem existem mais. Aos 16 anos, também fiz um curso de montagem e configuração de computadores. Naquela época estavam bombando os famosos ’notebooks’. Em paralelo, meu pai me ajudou financeiramente para fazer um curso de inglês durante dois anos.

Terminei o ensino médio e não sabia o que fazer da vida. Normal para a maioria, infelizmente. Eu sabia que gostava de números e não gostava de nada relacionado com área de saúde ou humanas. Então pensei em arquitetura. Mas minha nota no ENEM (Exame Nacional de Ensino Médio) não era suficiente para a universidade mais próxima de minha cidade (Dom Pedrito - DP) e eu não queria estudar mais um ano para o ENEM, então escolhi o curso de Engenharia de Computação, curso que existia em uma universidade bem próxima de DP, em Bagé. Escolhi esse curso por fazer mais sentido com o que eu já tinha interesse desde o começo: computadores, números, etc.

Bom, pulando a história sobre a formação em si, entrei em 2011 e me formei em 2015. Em 2016, tive a oportunidade de ser professor substituto do curso de Engenharia de Computação na Unipampa (universidade que estudei). Logo após, em 2017, iniciei o mestrado em Computação Aplicada na Unipampa em parceria com a Embrapa e por um ano e meio fiz as duas atividades simultaneamente. Em maio de 2018, terminou o contrato de professor substituto e pude focar minhas atividades para terminar o mestrado (que foi concluído em fevereiro de 2019).

Engenheiro de computação e mestre em Computação Aplicada. Gostei muito de dar aulas e de fazer pesquisas. O caminho natural era prosseguir com o doutorado e buscar uma carreira no ensino superior. Eu cheguei a desenvolver uma proposta de doutorado com três páginas sobre HMC (Hierarquical Multilabel Classification). Entrei em contato com um professor na UFSCAR, mas não pude seguir adiante. Descobri que ia ser pai. No momento em que a ciência estava seriamente ameaçada de cortes de bolsas e por questões financeiras, decidi mudar o rumo da minha vida.

Em maio de 2019 comecei a procurar emprego na área que eu achava que mais gostava: Ciência de Dados. Não obtive sucesso, a maioria das vagas eram para pessoas com experiência na área e quando não era, a concorrência acaba sendo com pessoas mais qualificadas (doutorado, estágio no exterior, etc). Então comecei a restringir menos as minhas opções de carreira, criei meu github e comecei a compartilhar meus trabalhos no Instagram, LinkedIn e Facebook, criei este site e comecei a buscar vagas na área de desenvolvimento e, logo neste começo, comecei a receber propostas de trabalho. Percebi rapidamente que a demanda por profissionais em desenvolvimento era muito maior se comparada com a demanda por analistas e cientistas de dados.

Uma estatística interessante (eu acho): enviei currículo para 95 empresas no Sul e Sudeste do Brasil. Obtive retorno positivo de 4 empresas e negativo de aproximadamente 20 (o restante não respondeu, comprovando o que muitos dizem sobre a falta de retorno nos processos seletivos). Dessas 4, avancei para as entrevistas em 2 e uma delas recebi uma proposta. Cabe ressaltar que a maioria das vagas que busquei foram para júnior e expondo que eu tinha graduação e mestrado, porém que não tinha experiência de mercado (só a de professor substituto em instituição pública). Foi então em outubro de 2019, após aceitar a proposta que tinha recebido, que começou minha jornada como desenvolvedor backend.

De forma objetiva, o que eu aprendi tecnicamente até agora?

A maior parte da minha carreira, antes de ser desenvolvedor, tinha trabalhado com as linguagens C e R. C no ambiente acadêmico e R com análise e visualização de dados e desenvolvimento de algoritmos de Machine Learning. Isso me ajudou muito na transição para a linguagem Java. Java é mais fácil do que C, porém tem a carga adicional de se compreender o paradigma de orientação à objetos e o ecossistema em volta do mesmo.

Posso dizer que aprendi muito sobre o ecossistema Java, principalmente o Java 8 e 11.

Junto com o Java, aprendi do zero sobre diversas ferramentas/tecnologias:

gerenciamento de dependências e boas práticas com Ant, Maven e Gradle;
injeção de dependências com CDI e Dagger;
os padrões de Clean Code que ajudam a criar códigos mais legíveis e mantíveis;
os padrões de Engenharia de Software que eram muito abstratos para mim, agora pude ver como aplicar alguns deles;
como desenvolver uma aplicação web com frontend, backend e banco de dados, com suas particularidades;
sobre o Postgres, SQL, noSQL e como otimizar consultas com índices;
trabalhar com o Ubuntu passou a fazer parte da minha rotina de trabalho e pessoal. Não uso mais Windows, praticamente (exceto para alguns jogos);
aprendi muito sobre bash, processos, serviços e sistema de arquivos no Ubuntu;
deploy de aplicações Java na nuvem;
monitoramento de aplicações na nuvem;
versionamento de código com git usando comandos além dos básicos push, pull, commit, etc;
plataformas que fazem parte do dia a dia de um desenvolvedor como Gitlab, Jira, Confluence, Miro, Figma, Slack;
desenvolvimento de melhorias para apps Android (com Java e Kotlin) e iOS (com Swift);
frameworks para frontend, no caso, o VueJS;
Swagger (OpenApi) para documentação de APIs;
criação e consumo de APIs seguindo as boas práticas;
Javalin, framework web para Java e Kotlin;
testes automatizados com JUnit (de unidade e de integração);
migração de banco de dados com Flyway;

Posso dizer que essa era a minha maior dúvida antes de entrar no mercado: com quais ferramentas vou trabalhar? que tecnologias vou precisar aprender? como é o fluxo de trabalho de um desenvolvedor em uma empresa, em uma equipe?

Os pontos citados acima ajudam um pouco a responder essa dúvida.

Backstage…

Esse é um compilado bem legal, são vários aprendizados para um ano e meio de trabalho.

Porém, cabe mencionar que eu estudava algumas horas além do meu horário de serviço para preencher eventuais gaps de conhecimento que surgiam no caminho. Um deles que me recordo claramente foi o de testes automatizados: qual a melhor forma de fazer? quais as boas práticas? como fazer quando temos DAOs e acesso ao banco?

Acredito que ter essas dúvidas no início da carreira seja normal, nem mesmo profissionais mais experientes tem as respostas para tudo. Com a experiência que tenho hoje, ainda preciso tirar algumas dúvidas no Google ou no Stackoverflow sobre algum aspecto específico de uma tecnologia/ferramenta. É normal. Acho que superei esse sentimento de que temos que saber tudo decorado.

Mais importante que isso, é saber o fundamento das decisões: devo fazer testes para este controller? é o momento certo de fazer testes? TDD? Nesse ponto, pode ser que a internet atrapalhe pela ampla variedade de respostas que são geralmente subjetivas e controversas. Este é um dos pontos em que os profissionais mais experientes, líderes, ou referências técnicas do time podem ajudar. Com alguns minutos de conversa, você pode ser poupado de semanas de estudo e pesquisas por pessoas que vivem no mesmo contexto que você e já passaram por essas situações.

Soft skills (ou human skills, como alguns preferem)

Vou mencionar aqui algumas habilidades que vejo como importantes e essenciais para ter sucesso no trabalho em equipe:

boa e correta comunicação;
comunicação assertiva;
educação;
empatia;
paciência;
autonomia (levemente direcionada por alguém mais experiente, se possível);
foco no cliente;
colaboração;
aprendizado constante de novas tecnologias ou teorias;
flexibilidade;
controle emocional e trabalho sob pressão;
boa gestão do tempo;
liderança;

Nem todas que citei acima são essenciais para todos. Depende do contexto de onde o profissional está inserido. Se você é líder de um time, liderança se torna essencial. Se você é o liderado, um determinado nível de autonomia se torna essencial, pois ninguém gostaria de ser interrompido a cada 15 minutos com dúvidas simples (ou com perguntas mal formuladas).

Posso ter esquecido alguma habilidade que me ajudou, com o tempo vou adicionando aqui.

Referências que me ajudaram

Além dos meus colegas de trabalho e equipe (Moysés, Luana, Fábio, Rogério, Rodrigo, Kathleen e Flávia), que me ajudaram muito na minha evolução profissional e pessoal, tenho algumas referências que me ajudaram nesse início de jornada como desenvolvedor. Abaixo cito essas referências:

Livro Effective Java (Joshua Bloch);
Várias postagens sobre testes e engenharia de software do Martin Fowler. 1, 2 e 3;
Canais do youtube como o do Lucas Montano, Filipe Deschamps, Fábio Akita e Programador Br (Igor Oliveira);
Curso na Udemy de Java do Nélio Alves;
Curso gratuito de Jekyll do Willian Justen (me ajudou a criar esse site :D) - não está mais disponível na Udemy;

Dicas rápidas

Inglês é fundamental;
Soft skills são tão importantes quanto as hard skills. O tempo mostrará isso;
Aprenda a vender o seu peixe. Faça o seu marketing pessoal;
Tenha um portfólio público e acessível, com soluções criadas e/ou customizadas por você no Github;
Se você não é autodidata, faça um curso técnico e/ou uma graduação em um curso de computação;
Caso faça graduação, complemente a formação com cursos online na carreira que almeja seguir;
Agarre as oportunidades que surgirem. Se tiver mais de uma, escolha a que for mais adequada para você;
No início de tudo, experiência vale mais do que salário (isso caso você tenha condições de viver por um tempo com um salário abaixo do que pretende ter);
Tenha uma boa gestão do seu tempo;
Tenha o perfil sempre atualizado e adequado à vaga que você busca no LinkedIn;
Tenha um bom Networking;
Pesquise a média dos salários do cargo que busca, ou na empresa que você quer, no Glassdoor, por exemplo;
Treine antes das entrevistas técnicas e com o Recursos Humanos (RH);
Evite aprender sobre frameworks antes de aprender a base (exemplos: não comece com ReactJS sem antes entender o básico de HTML, CSS e Javascript);
Matemática e estruturas de dados são importantes;
Não espere oportunidades aparecerem, corra atrás delas ou as crie;

Cada uma dessas dicas pode ser aprofundada em um assunto futuro neste blog, fique ligado ;)

Posso ter esquecido alguma dica que me ajudou, com o tempo vou adicionando aqui.

Considerações Finais

Espero que este relato tenha auxiliado você de alguma forma na sua jornada e carreira como iniciante na área de desenvolvimento. E, ainda, que possa ter esclarecido para você algum caminho para que possa chegar no primeiro emprego.

Valeu !! Até o próximo post !!

Tutorial de instalação do Ubuntu 20.04.1 LTS do Zero

Mon, 28 Sep 2020 22:11:00 -0300

Resumo

E aí pessoal, beleza?

Vamos supor que você chegou no primeiro dia de trabalho na sua empresa e seu líder/chefe solicitou uma máquina configurada com o Linux. A máquina já possui o Windows instalado em uma partição em um disco SSD e possui um disco HD.

O nosso objetivo é configurar a máquina com um dual boot (ou seja, possibilitando a escolha do Sistema Operacional na inicialização do sistema), sendo que o Ubuntu deve ser instalado no disco HD.

Utilizaremos neste tutorial a versão 20.04.1 LTS do Ubuntu, a mais atualizada versão LTS (Long Term Support) disponível.

Passo a passo

Download do Ubuntu;
Criação de um pen-drive bootável;
Instalação do Ubuntu;

Download do Ubuntu

O download do Ubuntu pode ser feito neste link. Basta clicar em Download na versão Ubuntu 20.04.1 LTS. Cabe destacar que as versões LTS (Long-Term Support) do Ubuntu possuem um tempo extendido de suporte se comparada com outras versões (a versão 18.04.3 LTS tem suporte até Abril de 2023, a 19.10 até Julho de 2020 e a 20.04.1 até Abril de 2025). Salve o arquivo no formato .iso no diretório de sua preferência.

Criação de um pen-drive bootável

Agora será necessário o download do Rufus. Rufus é um software open-source que permite criar dispositivos bootaveis. Ou seja, permite que você inicialize um Sistema Operacional através de algum dispositivo. É necessário um pen-drive com no mínimo 4 Gigabytes de espaço de armazenamento.

Com o download realizado, execute-o.

Em Dispositivo, selecione o pen-drive inserido no computador.

Em Seleção de Boot, selecione o arquivo no formato .iso que contém a imagem do Ubuntu (é o arquivo do download anterior).

Em Esquema de partição mantenha a opção MBR e Sistema de destino mantenha a opção BIOS ou UEFI.

Em Nome do volume você pode dar um nome ao mesmo.

Em Sistema de arquivos mantenha a opção FAT32. Tamanho do cluster mantenha em 4096 bytes.

Após estes passos, basta clicar em iniciar. E pronto ! Agora é possível inicializar a máquina a partir do pen-drive, que agora é bootável com o Ubuntu.

Instalação do Ubuntu

Antes de começar, recomendo que seja feito um backup. Ou seja, salvar todos os dados e programas importantes em um HD externo ou na nuvem (Google Drive, Dropbox, Amazon, etc). Felizmente nunca aconteceu comigo, mas já vi pessoas escolherem a partição errada no processo de formatação e acabaram apagando o próprio Sistema Operacional existente (muitas vezes, Windows), perdendo o acesso aos antigos dados e programas.

Temos duas alternativas:

Criar as partições necessárias no próprio Windows;
Criar as partições necessárias no processo de instalação do Ubuntu;

Este tutorial seguirá com a segunda alternativa, mas se alguém tiver interesse na primeira, indico os seguintes tutoriais:

Conecte o pendrive no computador e reinicie a máquina. Antes da máquina inicializar, é necessário garantir que o computador encontre o pen-drive bootável para iniciar a instalação do Ubuntu. Para isso, acesse o menu do boot.

Para acessar o menu de boot ou o setup da BIOS, pressione a tecla que aparecer na primeira tela de boot. Essa tecla muda de fabricante para fabricante, pode ser f2, f8, f10, f12, etc. No caso da minha máquina, Dell, a tecla é f2.

A tela acima é exibida no meu caso. O próximo passo é encontrar o menu com as opções de sequência de boot. No meu caso, é a opção destacada em vermelho.

Temos a sequência de boot na parte superior e as opções de adicionar ou remover opções de boot na parte destacada inferior. No meu caso, a ordem do boot estava Ubuntu -> Windows -> UEFI … (Pen-drive). No caso de vocês, se vocês não possuem instalação prévia do Ubuntu, irão aparecer apenas as opções Windows e UEFI (pen-drive).

Se a opção UEFI não aparecer, verifique se ela está presente no menu Boot List Option, em view. Se a opção de UEFI não aparecer, é possível que tenha ocorrido algum problema na geração do pen-drive bootável, então recomendo refazer o passo Criação de um pen-drive “bootável”.

O que é preciso fazer? alterar a ordem do boot de forma que o UEFI seja a primeira opção. Basta utilizar as setas para mudar a ordem. Feito isso, basta pressionar Exit e salvar as modificações. O computador vai reiniciar, só que em vez de iniciar no Windows, vai inicializar no Pen-drive.

Idioma de instalação: Português.

Layout do teclado: Português.

Se você desejar realizar atualizações durante a instalação, conecte-se na sua rede. Caso contrário, apenas não se conectar nesse momento.

Instalação normal, incluindo softwares básicos.

Eu prefiro instalar software de terceiros, pra evitar algum problema com falta de drivers, mas caso desejar, você pode desabilitar essa opção.

Selecionar opção avançada.

Pelo amor de Deus, não marque Apagar disco...

Inicialmente será criada a partição principal (root). Selecione o “espaço livre” e clique no “+”. Nas configurações da partição, selecione as opções abaixo e clique em aplicar:

Tamanho = pelo menos 20000 MB

Tipo da nova partição = Primary

Localização para a nova partição = Início deste espaço

Usar como = Sistema de arquivos EXT4

Ponto de Montagem = /

Agora será criada a partição de swap. Essa partição é utilizada quando o computador vai para a hibernação ou quando a memória RAM fica cheia (em resumo). Selecione o “espaço livre” restante e clique no “+”. Nas configurações da partição, selecione as opções abaixo e clique em aplicar. Uma regra empírica para o tamanho do swap é a de utilizar um valor entre a RAM da sua máquina e o dobro da RAM.

Tamanho = 16000 MB

Tipo da nova partição = Primary

Localização para a nova partição = Início deste espaço

Usar como = Sistema de arquivos EXT4

Ponto de Montagem = /home

Agora será criada a partição home. Selecione o “espaço livre” restante e clique no “+”. Nas configurações da partição, selecione as opções abaixo e clique em aplicar:

Tamanho = Todo tamanho restante

Tipo da nova partição = Primary

Localização para a nova partição = Início deste espaço

Usar como = Sistema de arquivos EXT4

Ponto de Montagem = /home

Clique no botão “Instalar Agora” para aplicar as mudanças nos discos e iniciar a instalação. Ao aparecer uma mensagem de alerta, clique em “Continuar”.

Selecione o fuso horário e clique em “Continuar”.

Defina um nome para o usuário, para a máquina, e login e senha (se desejar). Após clicar em “Continuar”, a instalação vai executar automaticamente.

Ao reiniciar a máquina, deverá aparecer o menu do Grub por dez segundos, onde você poderá escolher o Windows ou Ubuntu para inicializar. Por padrão, o Ubuntu é selecionado após os dez segundos.

Utilize as credenciais que você inseriu no processo de instalação para logar no Ubuntu e pronto ! Agora você possui uma máquina com dois Sistemas Operacionais, um em cada disco.

Considerações Finais

Espero que este tutorial tenha auxiliado você na instalação do Ubuntu 20.04.1 LTS na sua máquina.

Valeu !! Até o próximo post !!

Referências Bibliográficas

Análise Exploratória de Dados (EDA) e Técnicas Estatísticas com o R

Sun, 17 May 2020 02:00:00 -0300

Resumo

Saudações pessoal.

A ideia deste post é compartilhar com vocês um exemplo completo de Análise Exploratória de Dados (em inglês é EDA - Exploratory Data Analysis). Também são aplicadas técnicas estatísticas como testes de normalidade, análise de variância, kruskal wallis e outros.

Este trabalho foi desenvolvido no Sistema Operacional Ubuntu versão 18.10 LTS 64 bits, com o auxílio da linguagem R v.3.6.3 (2020-02-29) e do RStudio v. 1.2.5033.

Tópicos

Parte I - Fonte dos dados;
Parte II - Análise Exploratória de Dados do dataset;
Parte III - Estatísticas do dataset;
Considerações finais;

Parte I - Fonte dos dados

Os dados utilizados como base para este trabalho são os de estudantes de disciplinas de Desenho Técnico de uma IES (Instituição de Ensino Superior), e podem ser obtidos pelo meu Github.

Dois datasets foram fornecidos:

1 - Dados de estudantes separados por curso de graduação, de todos professores que ministraram a disciplina (sem informação credencial de estudantes e sem identificação de professores).

2 - Dados de estudantes da turma de um professor específico da disciplina.

Vamos fazer a EDA e análises estatísticas do primeiro dataset neste post.

Parte II - Análise Exploratória de Dados do Dataset

Temos 16 variáveis (ou colunas) por aluno:

Nome do aluno;
Identidade estudantil (matrícula);
Código do curso;
Ano;
Semestre;
Código de disciplina;
Nome da disciplina;
Número de créditos (1 crédito = 15 horas);
Nota final;
Situação do aluno;
Carga horária total em horas;
Tipo de Admissão na Universidade;
Ano de admissão;
Tipo de evasão (incluindo alunos matriculados);
Ano de evasão (se aplicável);
Sexo;

Todas as informações sensíveis dos conjuntos de dados foram removidas antes de iniciar essa análise, como os nomes dos alunos. A identificação dos alunos foi criptografada para preservar os dados sensíveis da universidade.

Inicialmente, vamos importar os pacotes necessários para a execução de nossas análises.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


if (!require(dplyr)) install.packages("dplyr")
library(dplyr)

if (!require(ggplot2)) install.packages("ggplot2")
library(ggplot2)

if (!require(ggpubr)) install.packages("ggpubr")
library(ggpubr)

if (!require(jpeg)) install.packages("jpeg")
library(jpeg)

if (!require(ggimage)) install.packages("ggimage")
library(ggimage)

if (!require(magick)) install.packages("magick")
library(magick)

if (!require(showtext)) install.packages("showtext")
library(showtext)

if (!require(extrafont)) install.packages("extrafont")
library(extrafont)

if (!require(ggchicklet)) install.packages("ggchicklet", repos = "https://cinc.rud.is")
library(ggchicklet)

if (!require(car)) install.packages("car")
library(car)

if (!require(lattice)) install.packages("lattice")
library(lattice)

if (!require(rcompanion)) install.packages("rcompanion")
library(rcompanion)

if (!require(FSA))install.packages("FSA")
library(FSA)

Inicialmente, vamos importar os dados de cada uma das planilhas com dados.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# importação dos dados
BAEA_path <- "../csv/Technical_Drawing_I_II - BAEA.csv"
BAEE_path <- "../csv/Technical_Drawing_I_II - BAEE.csv"
BAEC_path <- "../csv/Technical_Drawing_I_II - BAEC.csv"
BAEP_path <- "../csv/Technical_Drawing_I_II - BAEP.csv"
BAEQ_path <- "../csv/Technical_Drawing_I_II - BAEQ.csv"
BALF_path <- "../csv/Technical_Drawing_I_II - BALF.csv"

BAEA <- read.csv(BAEA_path, sep = ";", stringsAsFactors = FALSE, encoding = "latin1")
BAEE <- read.csv(BAEE_path, sep = ";", stringsAsFactors = FALSE, encoding = "latin1")
BAEC <- read.csv(BAEC_path, sep = ";", stringsAsFactors = FALSE, encoding = "latin1")
BAEP <- read.csv(BAEP_path, sep = ";", stringsAsFactors = FALSE, encoding = "latin1")
BAEQ <- read.csv(BAEQ_path, sep = ";", stringsAsFactors = FALSE, encoding = "latin1")
BALF <- read.csv(BALF_path, sep = ";", stringsAsFactors = FALSE, encoding = "latin1")

O que significa cada Sigla?

BAEE: Bacharelado em Engenharia de Energias Renováveis e Ambiente;
BAEA: Bacharelado em Engenharia de Alimentos;
BAEC: Bacharelado em Engenharia de Computação;
BAEP: Bacharelado em Engenharia de Produção;
BAEQ: Bacharelado em Engenharia Química;
BALF: Licenciatura em Física;

Com os dados importados e organizados em dataframes, podemos observar que o dataframe BAEA possui uma coluna de informações a mais. É possível verificar com uma rápida visualização no RStudio, no Global Environment. Como a informação não possui contexto que agregue em nossas análises, vamos removê-la.

1

BAEA <- BAEA[,-10]

Vamos checar o nome das colunas de cada dataframe, para confirmar se são as mesmas informações.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


> colnames(BAEA) == colnames(BAEE)
 [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
> colnames(BAEA) == colnames(BAEC)
 [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE
> colnames(BAEA) == colnames(BAEP)
 [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
> colnames(BAEA) == colnames(BAEQ)
 [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
> colnames(BAEA) == colnames(BALF)
 [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE

BAEC possui um nome diferente na coluna de carga horária, então vamos deixar o nome igual ao dos outros dataframes.

1

colnames(BAEC)[10] <- colnames(BAEA)[10]

Agora podemos concatenar todos os dados com o comando rbind. Todos os dados estão agora no dataframe all_data. A concanetação com rbind é feita pelas linhas.

1
2
3
4
5


all_data <- rbind(BAEA, BAEE)
all_data <- rbind(all_data, BAEC)
all_data <- rbind(all_data, BAEP)
all_data <- rbind(all_data, BAEQ)
all_data <- rbind(all_data, BALF)

Também vamos reduzir o nome de algumas colunas para facilitar o desenvolvimento na sequência.

1
2
3
4


colnames(all_data)[10] <- "CARGA_HORARIA"
colnames(all_data)[9] <- "SITUACAO"
colnames(all_data)[5] <- "COD_DISCIPLINA"
colnames(all_data)[6] <- "DISCIPLINA"

Feita a junção dos dados, vamos analisar individualmente o conteúdo único das colunas que contém categorias (Strings). Também vamos verificar em cada coluna se existem NaNs (Not a Number - Não-Números) ou campos vazios.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


> all_data$MATR_ALUNO[is.na(all_data$MATR_ALUNO)]
character(0)
> all_data$MATR_ALUNO[all_data$MATR_ALUNO == ""]
character(0)
> 
> all_data$COD_CURSO[is.na(all_data$COD_CURSO)]
character(0)
> all_data$COD_CURSO[all_data$COD_CURSO == ""]
character(0)
> unique(all_data$COD_CURSO)
[1] "BAEA" "BAEE" "BAEC" "BAEP" "BAEQ" "BALF"
> 
> all_data$ANO[is.na(all_data$ANO)]
integer(0)
> unique(all_data$ANO)
 [1] 2007 2009 2008 2011 2010 2012 2013 2015 2014 2017 2016 2019 2018
> 
> all_data$PERIODO[is.na(all_data$PERIODO)]
character(0)
> all_data$PERIODO[all_data$PERIODO == ""]
character(0)
> unique(all_data$PERIODO)
[1] "1. Semestre" "2. Semestre"
> 
> all_data$COD_DISCIPLINA[is.na(all_data$COD_DISCIPLINA)]
character(0)
> all_data$COD_DISCIPLINA[all_data$COD_DISCIPLINA == ""]
character(0)
> unique(all_data$COD_DISCIPLINA)
[1] "10801" "BA010801" "10803" "BA010803" "BA017528" "10802" 
> 
> all_data$DISCIPLINA[is.na(all_data$DISCIPLINA)]
character(0)
> all_data$DISCIPLINA[all_data$DISCIPLINA == ""]
character(0)
> unique(all_data$DISCIPLINA)
[1] "DESENHO TECNICO I" "DESENHO TECNICO II"
> 
> all_data$CREDITOS[is.na(all_data$CREDITOS)]
integer(0)
> unique(all_data$CREDITOS)
[1] 4 2
> all_data$MEDIA_FINAL[is.na(all_data$MEDIA_FINAL)]
numeric(0)
> all_data$MEDIA_FINAL[all_data$MEDIA_FINAL > 10 | all_data$MEDIA_FINAL < 0] 
 [1] 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06
 [18] 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06 1e+06
 ...

Olhem só, existe uma porção dos dados em que a nota na média final está com um valor incorreto e constante de 100000. Vamos transformar em 0 e remover os registros posteriormente.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


> all_data$MEDIA_FINAL[all_data$MEDIA_FINAL > 10 | all_data$MEDIA_FINAL < 0] <- 0
> 
> all_data$SITUACAO[all_data$SITUACAO == ""]
character(0)
> all_data$SITUACAO[is.na(all_data$SITUACAO)]
character(0)
> unique(all_data$SITUACAO)
[1] "Aprovado com nota" "Aproveitamento" "Reprovado por Frequência"
[4] "Reprovado com nota" "Trancamento parcial" "Dispensado sem nota" 
[7] "Matrícula" "Dispensado com nota" "Disciplina Não Concluída"
> 
> all_data[is.na(all_data$CARGA_HORARIA),]
 [1] MATR_ALUNO COD_CURSO ANO PERIODO COD_DISCIPLINA 
 [6] DISCIPLINA CREDITOS MEDIA_FINAL SITUACAO CARGA_HORARIA
[11] FORMA_INGRESSO ANO_INGRESSO FORMA_EVASAO ANO_EVASAO SEXO 
<0 rows> (or 0-length row.names)
> unique(all_data$CARGA_HORARIA)
[1] 68 60 34
> 
> all_data$FORMA_INGRESSO[all_data$FORMA_INGRESSO == ""]
character(0)
> all_data$FORMA_INGRESSO[is.na(all_data$FORMA_INGRESSO)]
character(0)
> unique(all_data$FORMA_INGRESSO)
 [1] "Processo Seletivo - Vestibular" 
 [2] "Transf. Interna Por Reopção de Curso" 
 [3] "Portador de Diploma" 
 [4] "Transferência" 
 [5] "ENEM - Exame Nacional do Ensino Médio" 
 [6] "Reingresso" 
 [7] "Transferência Voluntária ou Externa (oriundo de outra instituição)" 
 [8] "Reopção - Mobilidade Interna (para curso/habilitação área relacionada)"
 [9] "Chamada Regular Sisu" 
[10] "Lista de Espera Sisu" 
[11] "Chamada por Nota do Enem" 
[12] "Chamada Oral por Nota do Enem" 
[13] "Transferência Interna" 
[14] "Programa de Estudantes-Convênio de Graduação" 
[15] "Chamada por Nota do Enem II" 
[16] "Chamada por Nota no Ensino Médio" 
[17] "Transferência Edital de Vagas" 
[18] "Transferência EX-OFFICIO (amparada em lei)" 
[19] "Chamada Oral por Nota do Ensino Medio II" 
> 
> all_data$ANO_INGRESSO[is.na(all_data$ANO_INGRESSO)]
integer(0)
> unique(all_data$ANO_INGRESSO)
 [1] 2006 2009 2007 2008 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019
> 
> all_data$FORMA_EVASAO[all_data$FORMA_EVASAO == ""]
character(0)
> all_data$FORMA_EVASAO[is.na(all_data$FORMA_EVASAO)]
character(0)
> unique(all_data$FORMA_EVASAO)
 [1] "Transf. Interna Por Reopção de Curso" "Transferência" 
 [3] "Abandono" "Formado" 
 [5] "Transferido" "Transferência Interna" 
 [7] "Desligamento" "Cancelamento" 
 [9] "Aluno Regular" "Falecimento" 
> 
> all_data$ANO_EVASAO[is.na(all_data$ANO_EVASAO)]
 [1] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA ...
 [ reached getOption("max.print") -- omitted X entries ]

Mais dados inconsistentes. O ano de evasão registrado como NA (Not Available - Não disponível) em muitos registros, provavelmente indicando casos de alunos que não evadiram da universidade. Vamos transformar em zeros.

1
2
3


> all_data$ANO_EVASAO[is.na(all_data$ANO_EVASAO)] <- 0
> unique(all_data$ANO_EVASAO)
 [1] 2009 2016 2008 2011 2007 2015 2014 2013 2012 2010 2018 2017 2019 0

Agora vamos descartar casos de alunos nas seguintes situações:

Dispensados sem nota (todos neste caso ficaram com média zero);
Trancamento Parcial (todos neste caso ficaram com média zero);
Matrícula (alunos atualmente matrículados não têm informação sobre a média final);
Disciplina Não Concluída (todos neste caso ficaram com média zero);
Aproveitamento em casos que a média foi 0;

Como vamos posteriormente utilizar tratamentos estatísticos, temos que ter o cuidado de não deixar a amostra viesada por causa de registros sem significância para a análise. Os casos acima citados são excepcionais e não vão agregar resultados para este trabalho de análise das médias finais dos alunos. Isso não significa, porém, que tais dados não tenham utilidade. Tais dados podem ser usados para descobrir, por exemplo, o número médio de reprovações de alunos de Desenho Técnico que desistem dos cursos, ou que se formam. Isso pode ser feito através da matrícula de cada aluno. Porém, não é o nosso escopo agora. :-)

Os alunos aprovados e reprovados por nota ou frequência possuem a informação valiosa para as nossas análises.

Vamos também aproveitar para dar um nome mais conciso para algumas formas de evasão.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


> all_data <- all_data[all_data$SITUACAO != "Dispensado sem nota",]
> all_data <- all_data[!(all_data$SITUACAO == "Aproveitamento" & all_data$MEDIA_FINAL == 0),]
> all_data <- all_data[(all_data$SITUACAO != "Trancamento parcial"),]
> all_data <- all_data[(all_data$SITUACAO != "Matrícula"),]
> all_data <- all_data[(all_data$SITUACAO != "Disciplina Não Concluída"),]
> 
> unique(all_data$FORMA_EVASAO)
[1] "Transf. Interna Por Reopção de Curso" "Transferência" 
[3] "Abandono" "Formado" 
[5] "Transferido" "Transferência Interna" 
[7] "Desligamento" "Cancelamento" 
[9] "Aluno Regular" 
> all_data$FORMA_EVASAO[(all_data$FORMA_EVASAO == "Transf. Interna Por Reopção de Curso")] <- "Reopção"
> all_data$FORMA_EVASAO[(all_data$FORMA_EVASAO == "Transferência Interna")] <- "Transf. Interna"

Agora que temos nosso conjunto de dados tratado e integrado em um único dataframe, vamos iniciar as análises gerando diversas estatísticas sobre esses dados. Para isso, vamos reutilizar a função abaixo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


 statistics <- function(dataframe, response, ...) {
 group_var <- enquos(...)
 result <- as.data.frame(
 dataframe %>% 
 group_by(!!!group_var) %>% 
 summarise(mean = mean(!!sym(response)), 
 median = median(!!sym(response)), 
 sd = sd(!!sym(response)), 
 min = min(!!sym(response)), 
 max = max(!!sym(response)),
 n = NROW(!!sym(response)),
 quartil_1st = summary(!!sym(response))[2],
 quartil_3rd = summary(!!sym(response))[5],
 IQR = summary(!!sym(response))[5] - summary(!!sym(response))[2]
 )
 )
 return(result)
}

Na sequência, vamos observar os resultados para cada agregação possível dos nossos dados.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


DT1 <- all_data[all_data$DISCIPLINA == "DESENHO TECNICO I",]
> by_course_drawing_I <- statistics(all_data[all_data$ == "DESENHO TECNICO I",], "MEDIA_FINAL", COD_CURSO)

> by_year_drawing_I <- statistics(DT1, "MEDIA_FINAL", ANO)

> by_year_course_drawing_I <- statistics(DT1, "MEDIA_FINAL", ANO, COD_CURSO)

> by_year_semester_course_drawing_I <- statistics(DT1, "MEDIA_FINAL", ANO, COD_CURSO, PERIODO)

> by_course_drawing_II <- statistics(DT2, "MEDIA_FINAL", COD_CURSO)

> by_year_drawing_II <- statistics(DT2, "MEDIA_FINAL", ANO)

> by_year_course_drawing_II <- statistics(DT2, "MEDIA_FINAL", ANO, COD_CURSO)

> by_year_semester_course_drawing_II <- statistics(DT2, "MEDIA_FINAL", ANO, COD_CURSO, PERIODO)

# Dados sem alunos reprovados por frequência (ou seja, que desistiram da disciplina sem cumprir a carga horária mínima)
> all_data_without_failed_by_attendance <- all_data[!(all_data$DESCR_SITUACAO == "Reprovado por frequencia"),]

> by_course_drawing_I_2 <- statistics(all_data_without_failed_by_attendance[all_data_without_failed_by_attendance$DISCIPLINA == "DESENHO TECNICO I",], "MEDIA_FINAL", COD_CURSO)

> by_year_drawing_I_2 <- statistics(all_data_without_failed_by_attendance[all_data_without_failed_by_attendance$DISCIPLINA == "DESENHO TECNICO I",], "MEDIA_FINAL", ANO)

> by_year_course_drawing_I_2 <- statistics(all_data_without_failed_by_attendance[all_data_without_failed_by_attendance$DISCIPLINA == "DESENHO TECNICO I",], "MEDIA_FINAL", ANO, COD_CURSO)

> by_year_semester_course_drawing_I_2 <- statistics(all_data_without_failed_by_attendance[all_data_without_failed_by_attendance$DISCIPLINA == "DESENHO TECNICO I",], "MEDIA_FINAL", ANO, COD_CURSO, PERIODO)

> by_course_drawing_II_2 <- statistics(all_data_without_failed_by_attendance[all_data_without_failed_by_attendance$DISCIPLINA == "DESENHO TECNICO II",], "MEDIA_FINAL", COD_CURSO)

> by_year_drawing_II_2 <- statistics(all_data_without_failed_by_attendance[all_data_without_failed_by_attendance$DISCIPLINA == "DESENHO TECNICO II",], "MEDIA_FINAL", ANO)

> by_year_course_drawing_II_2 <- statistics(all_data_without_failed_by_attendance[all_data_without_failed_by_attendance$DISCIPLINA == "DESENHO TECNICO II",], "MEDIA_FINAL", ANO, COD_CURSO)

> by_year_semester_course_drawing_II_2 <- statistics(all_data_without_failed_by_attendance[all_data_without_failed_by_attendance$DISCIPLINA == "DESENHO TECNICO II",], "MEDIA_FINAL", ANO, COD_CURSO, PERIODO)

> by_course_drawing_I
 COD_CURSO mean median sd min max n quartil_1st quartil_3rd IQR
1 BAEA 4.078723 4.98 3.093508 0 10.0 462 0.675 6.7375 6.0625
2 BAEC 4.228364 6.00 3.382119 0 10.0 269 0.000 7.0000 7.0000
3 BAEE 4.637683 6.00 3.058525 0 9.7 246 1.225 6.9375 5.7125
4 BAEP 4.341087 6.00 3.324497 0 10.0 727 0.000 7.0100 7.0100
5 BAEQ 4.819648 6.00 3.011449 0 10.0 597 2.000 7.1000 5.1000
6 BALF 3.647069 3.80 3.209636 0 9.8 58 0.000 6.4500 6.4500

Observando o primeiro caso (média, mediana, desvio padrão, mínimo, máximo, n° de amostras, 1° e 3° quartis e IQR (Interquartil Range - Distância Interquartil) dos dados agrupados por curso de graduação), percebemos que a melhor média e menor desvio padrão é do BAEQ, enquanto que a pior média e alto valor de desvio é do BALF. Por outro lado, BALF tem 1/10 das amostras de BAEQ, evidenciando que o resultado discrepante em BALF pode ser devido ao número de amostras. Cabe ressaltar que neste conjunto estão incluídos alunos aprovados, reprovados por nota e frequência (que a nota sempre fica em zero). Os outros cursos aparentemente possuem as médias mais próximas uns dos outros.

Tudo bem. Analisamos um caso. Porém temos outros numerosos casos. Podemos salvar esses dados das tabelas em planilhas para uso e analises posteriores.

Vamos tirar proveito do poder dos gráficos do R para verificarmos visualmente esses resultados.

Podemos confirmar o que foi dito anteriormente através deste gráfico. Se você não sabe como interpretar um boxplot, eu sugiro este link, que explica em detalhes cada um dos componentes do boxplot.

Vamos verificar outros casos.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350


#dark theme
normal_theme <- theme(
 axis.text = element_text(family = font_family, size = 22, color = "#cccccc"),
 axis.title = element_text(family = font_family, size = 35, color = "#cccccc"),
 axis.ticks = element_line(colour = "#cccccc"),
 axis.ticks.length = unit(0.5, "cm"),
 plot.caption = element_text(family = font_family, size = 16, color = "#cccccc"),
 plot.title = element_text(family = font_family, size = 45, 
 hjust = 0.5, color = "#ffffff"),
 plot.background = element_rect(fill = "black"),
 panel.grid.minor.y = element_line(size =.1, color = "grey"),
 panel.grid.minor.x = element_blank(),
 panel.grid.major.y = element_line(size =.1, color = "grey"),
 panel.grid.major.x = element_blank(),
 panel.background = element_rect(fill = 'black'),
 legend.background = element_rect(fill = "black", color = NA),
 legend.key = element_rect(fill = "black"),
 legend.text = element_text(family = font_family,size = 20,color = "#cccccc"),
 text = element_text(family = font_family, color = "#cccccc", size = 22)
)

# Manually open a graphics device if you run this code in RStudio
x11(width = 13, height = 11.25)

# Desenho I - violin plot + boxplot - por curso de graduação 
fig <- ggplot(DT1, 
 aes(x = COD_CURSO, 
 y = MEDIA_FINAL, 
 fill = COD_CURSO)) +
 geom_violin(trim = TRUE) + 
 geom_boxplot(color = "black",
 width = 0.1, 
 outlier.shape = 21, 
 outlier.size = 2, 
 outlier.fill = "white", 
 show.legend = FALSE) + 
 geom_segment(aes(x = 0, 
 y = 6, 
 xend = 7, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 xlab("\nCurso\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Curso") +
 ggtitle("\nDesenho Tecnico I\n") + 
 normal_theme

ggbackground(fig, img)
savePlot(filename = "../images/figure1.png", type = "png", device = dev.cur())

# Desenho I - violin plot + boxplot - por ano
fig <- ggplot(DT1, 
 aes(x = ANO, 
 y = MEDIA_FINAL, 
 fill = as.factor(ANO))) +
 geom_violin(trim = TRUE)+ 
 geom_boxplot(color = "black",
 width = 0.1,
 outlier.shape = 21, 
 outlier.size = 2, 
 outlier.fill = "white", 
 show.legend = FALSE) + 
 geom_segment(aes(x = 2007, 
 y = 6, 
 xend = 2019, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 scale_x_continuous(breaks = seq(min(all_data$ANO), 
 max(all_data$ANO), 
 by = 1)) +
 xlab("\nAno\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Ano") + 
 ggtitle("\nDesenho Tecnico I\n") +
 normal_theme

ggbackground(fig, img)
savePlot(filename = "../images/figure2.png", type = "png", device = dev.cur())

# Desenho I - violin plot - por semestre e ano
fig <- ggplot(DT1, 
 aes(x = as.factor(ANO), 
 y = MEDIA_FINAL, 
 fill = as.factor(PERIODO))) +
 geom_violin(trim = TRUE) +
 geom_segment(aes(x = 0, 
 y = 6, 
 xend = 13, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 xlab("\nAno\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Periodo") + 
 ggtitle("\nDesenho Tecnico I\n") +
 normal_theme +
 theme(legend.position = "bottom") 

ggbackground(fig, img)
savePlot(filename = "../images/figure3.png", type = "png", device = dev.cur())

# Desenho II - violin plot + boxplot - por curso de graduação
fig <- ggplot(DT2, 
 aes(x = COD_CURSO, 
 y = MEDIA_FINAL, 
 fill = COD_CURSO)) +
 geom_violin(trim = TRUE) + 
 geom_boxplot(color = "black", 
 width = 0.1, 
 outlier.shape = 21, 
 outlier.size = 2, 
 outlier.fill = "white", 
 show.legend = FALSE) + 
 geom_segment(aes(x = 0, 
 y = 6, 
 xend = 7, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 xlab("\nCurso\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Curso") + 
 ggtitle("\nDesenho Tecnico II\n") +
 normal_theme

ggbackground(fig, img)
savePlot(filename = "../images/figure4.png", type = "png", device = dev.cur())

# Desenho II - violin plot + boxplot - por ano
fig <- ggplot(DT2, 
 aes(x = ANO, 
 y = MEDIA_FINAL, 
 fill = as.factor(ANO), 
 group = ANO)) +
 geom_violin(trim = TRUE)+ 
 geom_boxplot(color = "black", 
 width = 0.1, 
 outlier.shape = 21, 
 outlier.size = 2, 
 outlier.fill = "white", 
 show.legend = FALSE) + 
 geom_segment(aes(x = 2007, 
 y = 6, 
 xend = 2019, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 scale_x_continuous(breaks = seq(2007, 2019, by = 1)) +
 xlab("\nAno\n") +
 ylab("\nMedia Final\n") + 
 labs(fill = "Ano") + 
 ggtitle("\nDesenho Tecnico II\n") +
 normal_theme

ggbackground(fig, img)
savePlot(filename = "../images/figure5.png", type = "png", device = dev.cur())

# Desenho II - violin plot - por semestre e ano
fig <- ggplot(DT2, 
 aes(x = as.factor(ANO), 
 y = MEDIA_FINAL, 
 fill = as.factor(PERIODO))) +
 geom_violin(trim = TRUE) +
 geom_segment(aes(x = 0, 
 y = 6, 
 xend = 13, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 theme(legend.position = "bottom") +
 xlab("\nAno\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Periodo") + 
 ggtitle("\nDesenho Tecnico II\n") +
 normal_theme

ggbackground(fig, img)
savePlot(filename = "../images/figure6.png", type = "png", device = dev.cur())

# Desenho I - violin plot + boxplot - por curso de graduação - sem reprovados por frequência
fig <- ggplot(partial_data[partial_data$DISCIPLINA == "DESENHO TECNICO I",], 
 aes(x = COD_CURSO, 
 y = MEDIA_FINAL, 
 fill = COD_CURSO)) +
 geom_violin(trim = TRUE) + 
 geom_boxplot(color = "black", 
 width = 0.1, 
 outlier.shape = 21, 
 outlier.size = 2, 
 outlier.fill = "white", 
 show.legend = FALSE) + 
 geom_segment(aes(x = 0, 
 y = 6, 
 xend = 7, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) + 
 xlab("\nCurso\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Curso") + 
 ggtitle("\nMedias em Desenho Tecnico I", subtitle = "Sem reprovados por frequencia\n") +
 normal_theme

ggbackground(fig, img)
savePlot(filename = "../images/figure7.png", type = "png", device = dev.cur())

# Desenho I - violin plot + boxplot - por ano - sem reprovados por frequência
fig <- ggplot(partial_data[partial_data$DISCIPLINA == "DESENHO TECNICO I",], 
 aes(x = ANO, 
 y = MEDIA_FINAL, 
 fill = as.factor(ANO), 
 group = ANO)) +
 geom_violin(trim = TRUE)+ 
 geom_boxplot(color = "black", 
 width = 0.1, 
 outlier.shape = 21, 
 outlier.size = 2, 
 outlier.fill = "white", 
 show.legend = FALSE) + 
 geom_segment(aes(x = 2007, 
 y = 6, 
 xend = 2019, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 scale_x_continuous(breaks = seq(2007, 2019, by = 1)) +
 xlab("\nAno\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Ano") + 
 ggtitle("\nMedias em Desenho Tecnico I", subtitle = "Sem reprovados por frequencia\n") +
 normal_theme

ggbackground(fig, img)
savePlot(filename = "../images/figure8.png", type = "png", device = dev.cur())

# Desenho I - violin plot - por ano e semestre - sem reprovados por frequência
fig <- ggplot(partial_data[partial_data$DISCIPLINA == "DESENHO TECNICO I",], 
 aes(x = as.factor(ANO), 
 y = MEDIA_FINAL, 
 fill = as.factor(PERIODO))) +
 geom_violin(trim = TRUE) + 
 geom_segment(aes(x = 0, 
 y = 6, 
 xend = 13,
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 theme(legend.position = "bottom") +
 xlab("\nAno\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Periodo") + 
 ggtitle("\nMedias em Desenho Tecnico I", subtitle = "Sem reprovados por frequencia\n") +
 normal_theme +
 theme(plot.title = element_text(hjust = 0))

ggbackground(fig, img)
savePlot(filename = "../images/figure9.png", type = "png", device = dev.cur())

# Desenho II - violin plot + boxplot - por curso de graduação - sem reprovados por frequência
fig <- ggplot(partial_data[partial_data$DISCIPLINA == "DESENHO TECNICO II",], 
 aes(x = COD_CURSO, 
 y = MEDIA_FINAL, 
 fill = COD_CURSO)) +
 geom_violin(trim = TRUE)+ 
 geom_boxplot(color = "black",
 width = 0.1, 
 outlier.shape = 21, 
 outlier.size = 2, 
 outlier.fill = "white", 
 show.legend = FALSE) + 
 geom_segment(aes(x = 0, 
 y = 6, 
 xend = 7, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 xlab("\nCurso\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Curso") + 
 ggtitle("\nMedias em Desenho Tecnico II", subtitle = "Sem reprovados por frequencia\n") +
 normal_theme

ggbackground(fig, img)
savePlot(filename = "../images/figure10.png", type = "png", device = dev.cur())

# Desenho II - violin plot + boxplot - por ano - sem reprovados por frequência
fig <- ggplot(partial_data[partial_data$DISCIPLINA == "DESENHO TECNICO II",], 
 aes(x = ANO, 
 y = MEDIA_FINAL, 
 fill = as.factor(ANO), 
 group = ANO)) +
 geom_violin(trim = TRUE)+ 
 geom_boxplot(color = "black",
 width = 0.1, 
 outlier.shape = 21, 
 outlier.size = 2, 
 outlier.fill = "white", 
 show.legend = FALSE) + 
 geom_segment(aes(x = 2007,
 y = 6, 
 xend = 2019, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 scale_x_continuous(breaks = seq(2007, 2019, by = 1)) +
 xlab("\nAno\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Ano") + 
 ggtitle("\nMedias em Desenho Tecnico II", subtitle = "Sem reprovados por frequencia\n") +
 normal_theme

ggbackground(fig, img)
savePlot(filename = "../images/figure11.png", type = "png", device = dev.cur())

# Desenho II - violin plot - por ano e semestre - sem reprovados por frequência
fig <- ggplot(partial_data[partial_data$DISCIPLINA == "DESENHO TECNICO II",], 
 aes(x = as.factor(ANO), 
 y = MEDIA_FINAL, 
 fill = as.factor(PERIODO))) +
 geom_violin(trim = TRUE) +
 geom_segment(aes(x = 0, 
 y = 6, 
 xend = 13, 
 yend = 6), 
 linetype = "dotted", 
 colour = "red") +
 scale_y_continuous(breaks = seq(0, 10, by = 1)) +
 theme(legend.position = "bottom") +
 xlab("\nAno\n") + 
 ylab("\nMedia Final\n") + 
 labs(fill = "Periodo") + 
 ggtitle("\nMedias em Desenho Tecnico II", subtitle = "Sem reprovados por frequencia\n") +
 normal_theme +
 theme(plot.title = element_text(hjust = 0))

ggbackground(fig, img)
savePlot(filename = "../images/figure12.png", type = "png", device = dev.cur())

Resumindo um pouco dos gráficos acima:

Os alunos de Desenho I em 2008 tiveram um desempenho superior nas notas em relação aos outros anos;
De 2009 até 2014 o desempenho caiu até começar a melhorar de 2015 até 2018;
Em Desenho II, o curso de BAEC aparece com desempenho superior nas notas, BALF é o curso com desempenho inferior, e os cursos restantes possuem estatísticas semelhantes. Obs: Desenho II é desenvolvida com o uso de softwares de CAD - (Desenho Auxiliado por Computador);
O desempenho dos alunos entre 2009 e 2013 foi superior em Desenho II com relação aos anos posteriores;
Sem reprovados por frequência, o desempenho por curso em Desenho I ficou mais homogêneo. O curso de BAEC apresenta notas melhores que BAEQ (provavelmente BAEQ possui mais alunos e poucos reprovados por frequência, o que pode justificar a mudança). O comportamento por ano se manteve, como no caso com todos os dados;
O comportamento das medianas no caso de Desenho II sem reprovados manteve o mesmo padrão, diferenças mínimas por curso, ano e período.

Agora vamos observar outros aspectos do nosso dataset…

Interessante observação que as estudantes do sexo feminino reprovam menos em quantidade e percentual se comparadas aos estudantes do sexo masculino. O percentual apresentado nos gráficos é relativo ao universo de estudantes do sexo em questão, e não do total de alunos. Exemplo: se de uma turma de 100, 50 foram reprovados e 10 destes são estudantes do sexo feminino, então 20% dos estudantes do sexo feminimo reprovaram, e não 10%. O percentual é relacionado com o universo de reprovados, e não do total de alunos.

O mesmo acontece se observamos as reprovações por ano e por disciplina. Existem raríssimas exceções onde estudantes do sexo feminino reprovaram mais em quantidade/percentual do que do sexo masculino (2008 em Desenho I e 2014 em Desenho II).

Outro caso interessante são as reprovações por disciplina, semestre e ano. Na maioria dos anos, as reprovações em percentual e absolutas são maiores no 1° semestre para Desenho I e no 2° semestre para Desenho II.

Faz sentido, já que Desenho I é pré-requisito para cursar Desenho II, que geralmente é no semestre subsequente.

A maior parte dos reprovados por frequência em Desenho I acaba abandonando o curso de origem. Esta é uma realidade preocupante evidenciada pelo gráfico acima. O cenário é menos intenso em Desenho II, porém ainda preocupante. Vejam que uma parcela muito pequena dos estudantes que reprovaram nos Desenhos I e II se formaram ou são alunos regulares.

A diferença das reprovações por frequência e aprovações entre os Desenhos é evidenciada acima. Estudantes de Desenho I e II aparentemente tem mantido constante o seu desempenho nos últimos anos, de uma forma geral, apesar do cenário não ser satisfatório. Houveram variações significativas na quantidade de estudantes neste período analisado.

A distribuição das médias por ano e semestre, tanto em Desenho I como II, se concentram na nota 6, que é a nota mínima para aprovação. Em Desenho II, o desempenho dos estudantes tem sido muito superior ao de Desenho I.

Aqui novamente observamos a maior concentração das médias entre as notas 6 e 7, em Desenho I e II. O cenário é mais positivo em Desenho II, apesar de aparentemente ter piorado nos últimos anos (pois ocorreu maior concentração das médias em torno do 6 e 7, e menor concentração em notas mais altas, como aconteceu em anos entre 2007 e 2014).

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400


# Bar plot - reprovados por frequência por sexo (n e %)
by_sex <- statistics(all_data, "MEDIA_FINAL", SEXO)
by_sex_failed_by_attendance <- statistics(all_data[(all_data$SITUACAO == "Reprovado por Frequência"),], "MEDIA_FINAL", SEXO)

by_sex$per[by_sex$SEXO == "M"] <- round((by_sex_failed_by_attendance$n[by_sex_failed_by_attendance$SEXO == "M"] / by_sex$n[by_sex$SEXO == "M"]) * 100, 2)
by_sex$per[by_sex$SEXO =="F"] <- round((by_sex_failed_by_attendance$n[by_sex_failed_by_attendance$SEXO == "F"] / by_sex$n[by_sex$SEXO == "F"]) * 100, 2) 

by_sex$ndrop[by_sex$SEXO == "M"] <- round((by_sex_failed_by_attendance$n[by_sex_failed_by_attendance$SEXO == "M"]), 2)
by_sex$ndrop[by_sex$SEXO == "F"] <- round((by_sex_failed_by_attendance$n[by_sex_failed_by_attendance$SEXO == "F"]), 2) 

# Bar plot - reprovados por frequência por sexo (n e %)
a <- ggplot(by_sex, aes(x = SEXO, y = ndrop, fill = SEXO)) + 
 geom_chicklet(radius = grid::unit(10, 'mm')) +
 scale_fill_manual(name = "Sexo", values = c("#bc7b87","#7b87bc")) + 
 geom_text(data = by_sex, aes(label = ndrop), fontface = "bold", hjust = 0.5, 
 vjust = 1.5, color = "white", size = 5) +
 xlab("\nSexo\n") + 
 ylab("\nNumero de Reprovados\n") + 
 ggtitle("\nReprovados por Frequencia", subtitle = "Desenho Tecnico I e II\n") +
 normal_theme + 
 theme(plot.title = element_text(size = 25)) 

b <- ggplot(data = by_sex, aes(x = SEXO, y = per, fill = SEXO)) + 
 geom_chicklet(radius = grid::unit(10, 'mm')) +
 scale_fill_manual(name = "Sexo", values = c("#bc7b87","#7b87bc")) +
 geom_text(data = by_sex, aes(label = paste(per, '%')), fontface = "bold", hjust = 0.5, 
 vjust = 1.5, color = "white", size = 5) +
 xlab("\nSexo\n") + 
 ylab("\nPercentual de Reprovados\n") +
 ggtitle("\nReprovados por Frequencia", subtitle = "Desenho Tecnico I e II\n") +
 normal_theme + 
 theme(plot.title = element_text(size = 25))
 
c <- ggarrange(a, b, ncol = 2)

ggbackground(c, img)
savePlot(filename = "../images/figure13.png", type = "png", device = dev.cur())

# Bar plot - reprovados por frequência por sexo e disciplina (n e %)
frequency_failed_by_attendance_data <- all_data[(all_data$SITUACAO == "Reprovado por Frequência"),]

# por sexo e disciplina
a <- statistics(all_data, "MEDIA_FINAL", SEXO, DISCIPLINA)

# reprovados por freq. - por sexo e disciplina
b <- statistics(all_data[(all_data$SITUACAO == "Reprovado por Frequência"),], "MEDIA_FINAL", SEXO, DISCIPLINA)

b$per <- round((b$n[b$SEXO == a$SEXO && b$DISCIPLINA == a$DISCIPLINA] / 
 a$n[a$SEXO == b$SEXO && a$DISCIPLINA == b$DISCIPLINA]) * 100, 2) 

# Bar plot - reprovados por frequência - por sexo e disciplina (n e %)
fig <- ggplot(b, aes(DISCIPLINA, 
 n, 
 group = SEXO, 
 color = SEXO)) + 
 geom_bar(stat = "identity", 
 fill = "#101010", 
 position = position_dodge2()) +
 geom_text(data = b, aes(label = paste(n,"(",per,"% )")), 
 hjust = 0.5, 
 vjust = 1.5, 
 color = "white", 
 size = 5, 
 position = position_dodge2(width = 0.9)) +
 scale_fill_hue(c = 40) +
 scale_y_continuous(breaks = seq(0, 400, by = 50)) +
 xlab("\nDisciplina\n") + 
 ylab("\nNumero de reprovados\n") + 
 labs(fill = "Sexo") + 
 ggtitle("\nReprovados por frequencia\n\n") +
 normal_theme 

ggbackground(fig, img)
savePlot(filename = "../images/figure14.png", type = "png", device = dev.cur())

# Bar plot - reprovados por frequência por sexo, disciplina e ano (n e %)

# por sexo, disciplina e ano
a <- statistics(all_data, "MEDIA_FINAL", SEXO, DISCIPLINA, ANO)

# reprovados por frequência - por sexo, disciplina e ano
b <- statistics(all_data[(all_data$SITUACAO == "Reprovado por Frequência"),], "MEDIA_FINAL", SEXO, DISCIPLINA, ANO)

b$per <- round((b$n[b$SEXO == a$SEXO && b$DISCIPLINA == a$DISCIPLINA && b$ANO == a$ANO] / 
 a$n[a$SEXO == b$SEXO && a$DISCIPLINA == b$DISCIPLINA && b$ANO == a$ANO]) * 100, 2) 

# Bar plot - reprovados por frequência por sexo, disciplina e ano (n e %)
fig1 <- ggplot(b, aes(ANO, n, color = SEXO)) + 
 geom_bar(stat = "identity", fill = "#101010", position = position_dodge2()) +
 scale_y_continuous(breaks = seq(0, 50, by = 5)) +
 scale_x_continuous(breaks = round(seq(min(b$ANO), max(b$ANO), by = 1), 1)) +
 scale_fill_hue(c = 40) +
 ylab("\nNum. de alunos\n") + xlab("\nAno\n") + labs(fill = "Sexo") + 
 ggtitle("\nReprovados por frequencia\n") +
 normal_theme +
 theme(plot.title = element_text(size = 25), axis.title = element_text(size = 18),
 axis.text = element_text(size = 12), strip.background = element_rect(fill = "#111111"), 
 strip.text = element_text(colour = 'white')) +
 facet_wrap(~DISCIPLINA) 

fig2 <- ggplot(b, aes(ANO, per, color = SEXO)) + 
 geom_bar(stat = "identity", fill = "#101010", position = position_dodge2()) +
 scale_y_continuous(breaks = seq(0, 50, by = 5)) +
 scale_x_continuous(breaks = round(seq(min(b$ANO), max(b$ANO), by = 1), 1)) +
 scale_fill_hue(c = 40) +
 ylab("\nPercentual (%)\n") + xlab("\nAno\n") + labs(fill = "Sexo") +
 normal_theme +
 theme(plot.title = element_text(size = 25), axis.title = element_text(size = 18),
 axis.text = element_text(size = 12), strip.background = element_rect(fill = "#111111"), 
 strip.text = element_text(colour = 'white')) +
 facet_wrap(~DISCIPLINA) 

c <- ggarrange(fig1, fig2, nrow = 2)
x11(width = 15, height = 11.25)
ggbackground(c, img)
savePlot(filename = "../images/figure15.png", type = "png", device = dev.cur())

# Bar plot - reprovados por frequência - por semestre, disciplina e ano (n)

# by semestre + ano + disciplina
a <- statistics(all_data, "MEDIA_FINAL", PERIODO, DISCIPLINA, ANO)

# reprovados por frequência - por semestre, disciplina e ano
b <- statistics(all_data[(all_data$SITUACAO == "Reprovado por Frequência"),], "MEDIA_FINAL", PERIODO, DISCIPLINA, ANO)

b$per <- round((b$n[b$PERIODO == a$PERIODO && b$DISCIPLINA == a$DISCIPLINA && b$ANO == a$ANO] / 
 a$n[a$PERIODO == b$PERIODO && a$DISCIPLINA == b$DISCIPLINA && b$ANO == a$ANO]) * 100, 2) 

b$DISCIPLINA[b$DISCIPLINA == "DESENHO TECNICO I"] <- "DESENHO I"
b$DISCIPLINA[b$DISCIPLINA == "DESENHO TECNICO II"] <- "DESENHO II"

# Bar plot - reprovados por frequência - por semestre, disciplina e ano (n)
fig1 <- ggplot(b, aes(DISCIPLINA, 
 n, 
 fill = as.factor(PERIODO),
 color = as.factor(PERIODO))) + 
 geom_bar(stat = "identity", 
 position = position_dodge(),
 alpha = 0.2) +
 scale_fill_hue(c = 50) +
 ylab("\nNum. de alunos\n") + 
 xlab("Disciplina\n") + 
 labs(fill = "", 
 color = "") + 
 ggtitle("\nReprovados por frequencia\n") +
 normal_theme + 
 theme(plot.title = element_text(size = 35), 
 axis.text = element_text(size = 12),
 legend.position = "top",
 strip.background = element_rect(fill = "#111111"), 
 strip.text = element_text(colour = 'white')) +
 facet_wrap(~ANO) 

ggbackground(fig1, img)
savePlot(filename = "../images/figure16.png", type = "png", device = dev.cur())

# Bar plot - reprovados por frequência - por semestre, disciplina e ano (%)
fig1 <- ggplot(b, aes(DISCIPLINA, 
 per, 
 fill = as.factor(PERIODO), 
 color = as.factor(PERIODO))) + 
 geom_bar(stat = "identity", 
 position = position_dodge(),
 alpha = 0.2) +
 scale_fill_hue(c = 50) +
 ylab("\nPercentual\n") + 
 xlab("Disciplina") + 
 labs(fill = "", color = "") + 
 ggtitle("\nReprovados por frequencia\n") +
 normal_theme + 
 theme(plot.title = element_text(size = 35), 
 axis.text = element_text(size = 12),
 legend.position = "top",
 strip.background = element_rect(fill = "#111111"), 
 strip.text = element_text(colour = 'white')) +
 facet_wrap(~ANO) 

ggbackground(fig1, img)
savePlot(filename = "../images/figure17.png", type = "png", device = dev.cur())

# Bar plot - reprovados por frequência - por disciplina e modo de evasão (n)

# reprovados por frequência - por disciplina e modo de evasão
b <- statistics(all_data[(all_data$SITUACAO == "Reprovado por Frequência"),], "MEDIA_FINAL", DISCIPLINA, FORMA_EVASAO)

b$FORMA_EVASAO[b$FORMA_EVASAO == "Reopção"] <- "Reopcao"
b$FORMA_EVASAO[b$FORMA_EVASAO == "Transferência"] <- "Transferencia"

# Bar plot - reprovados por frequência - por disciplina e modo de evasão (n)
fig1 <- ggplot(b, aes(DISCIPLINA, 
 n, 
 color = as.factor(FORMA_EVASAO),
 fill = as.factor(FORMA_EVASAO))) + 
 geom_bar(stat = "identity", 
 width = 0.5, 
 alpha = 0.2,
 position = position_dodge()) +
 scale_fill_hue(c = 50) + 
 ylab("\nNum. de alunos\n") + 
 labs(color = "Situacao atual",
 fill = "Situacao atual") + 
 xlab("\nDisciplina\n") + 
 ggtitle("\nReprovados por frequencia por situacao\n") +
 normal_theme +
 theme(plot.title = element_text(size = 35)) 
 
ggbackground(fig1, img)
savePlot(filename = "../images/figure18.png", type = "png", device = dev.cur())

# Bar plot - todos alunos - por disciplina, situação atual e ano (n)

# por disciplina, situação atual e ano
b <- statistics(all_data, "MEDIA_FINAL", DISCIPLINA, SITUACAO, ANO)

b$DISCIPLINA[b$DISCIPLINA == "DESENHO TECNICO I"] <- "DESENHO I"
b$DISCIPLINA[b$DISCIPLINA == "DESENHO TECNICO II"] <- "DESENHO II"
b$SITUACAO[b$SITUACAO == "Reprovado por Frequência"] <- "Reprovado por Frequencia"

# Bar plot - todos alunos - por disciplina, situação atual e ano (n)
fig1 <- ggplot(b, aes(DISCIPLINA, 
 n, 
 fill = as.factor(SITUACAO),
 color = as.factor(SITUACAO))) + 
 geom_bar(stat = "identity", 
 width = 0.5, 
 alpha = 0.2,
 position = position_dodge()) +
 scale_fill_hue(c = 50) + 
 ylab("\nNum. de alunos\n") + 
 labs(color = "Situacao", 
 fill = "Situacao") + 
 xlab("\nDisciplina") + 
 ggtitle("\nAlunos por Ano, Disciplina e Situacao\n") +
 guides(fill = guide_legend(nrow = 3)) +
 normal_theme + 
 theme(plot.title = element_text(size = 30), 
 axis.text = element_text(size = 10), 
 legend.position = "top",
 strip.background = element_rect(fill = "#111111"), 
 strip.text = element_text(colour = 'white')) +
 facet_wrap(~ANO, nrow = 3) 

ggbackground(fig1, img)
savePlot(filename = "../images/figure19.png", type = "png", device = dev.cur())

# Line plot - todos alunos - por disciplina, situação atual e ano (n)
fig1 <- ggplot(b, aes(ANO, 
 n, 
 group = SITUACAO, 
 color = SITUACAO)) + 
 geom_line(size = 1.5) +
 geom_point(size = 3, 
 shape = 21, 
 fill = "white") +
 scale_x_continuous(breaks = round(seq(min(b$ANO),
 max(b$ANO), 
 by = 1), 1)) +
 scale_y_continuous(breaks = round(seq(0, 
 max(b$n), 
 by = 10), 1)) +
 ylab("\nNum. de Alunos\n") + 
 xlab("\nAno") +
 labs(color = "Situacao do Aluno") + 
 ggtitle("\nAlunos por Ano, Disciplina e Situacao\n") +
 guides(color = guide_legend(nrow = 3)) +
 normal_theme + 
 theme(plot.title = element_text(size = 25), 
 axis.text = element_text(size = 12), 
 legend.position = "bottom",
 strip.background = element_rect(fill = "#111111"), 
 strip.text = element_text(colour = 'white')) +
 facet_wrap(~DISCIPLINA, nrow = 2) 

ggbackground(fig1, img)
savePlot(filename = "../images/figure20.png", type = "png", device = dev.cur())

# Line plot - todos alunos - por disciplina, situação atual e ano (%)

b <- as.data.frame(b %>% 
 group_by(ANO, DISCIPLINA) %>% 
 mutate(percent = 100*(n/sum(n))))

# Line plot - todos alunos - por disciplina, situação atual e ano (%)
fig1 <- ggplot(b, aes(ANO, 
 percent, 
 group = SITUACAO, 
 color = SITUACAO)) + 
 geom_line(size = 1.5) +
 geom_point(size = 3, 
 shape = 21, 
 fill = "white") +
 scale_x_continuous(breaks = round(seq(min(b$ANO), 
 max(b$ANO), 
 by = 1),1)) +
 scale_y_continuous(breaks = round(seq(0, 100, by = 10),1)) +
 ylab("\nPercentual de Alunos (%)\n") + 
 xlab("\nAno") +
 labs(color = "Situacao do Aluno") + 
 ggtitle("\n% de Alunos por Situacao em cada Disciplina e Ano") +
 guides(color = guide_legend(nrow = 3)) +
 normal_theme + 
 theme(plot.title = element_text(size = 25), 
 axis.text = element_text(size = 12), 
 legend.position = "bottom", 
 legend.text = element_text(size = 14),
 strip.background = element_rect(fill = "#111111"), 
 strip.text = element_text(colour = 'white')) +
 facet_wrap(~DISCIPLINA, nrow = 2) 

ggbackground(fig1, img)
savePlot(filename = "../images/figure21.png", type = "png", device = dev.cur())

# Density curve plot - sem reprovados por frequência - nota final por semestre e ano em Desenho I
fig1 <- ggplot(partial_data[partial_data$DISCIPLINA == "DESENHO TECNICO I",], 
 aes(x = MEDIA_FINAL , 
 fill = as.factor(ANO), 
 colour = PERIODO)) +
 geom_density(alpha = 0.9, 
 size = 1) + 
 scale_x_continuous(breaks = round(seq(min(partial_data$MEDIA_FINAL), 
 max(partial_data$MEDIA_FINAL), 
 by = 5), 10)) +
 xlab("\nMedia Final") + 
 ylab("\nDensidade\n") + 
 labs(fill = "Ano", 
 colour = "Semestre") +
 ggtitle("\nDistribuicao das Medias em Desenho I (Sem rep. por frequencia)\n") +
 normal_theme + 
 theme(strip.background = element_blank(), 
 strip.text = element_blank(), 
 axis.title = element_text(size = 18), 
 plot.title = element_text(size = 18), 
 axis.text = element_text(size = 15), 
 legend.position = "bottom", 
 legend.text = element_text(size = 15)) +
 facet_wrap(ANO ~ PERIODO, nrow = 5)

ggbackground(fig1, img)
savePlot(filename = "../images/figure22.png", type = "png", device = dev.cur())

# Density curve plot - sem reprovados por frequência - nota final por semestre e ano em Desenho II
fig1 <- ggplot(partial_data[partial_data$DISCIPLINA == "DESENHO TECNICO II",], 
 aes(x = MEDIA_FINAL , 
 fill = as.factor(ANO), 
 colour = PERIODO)) +
 geom_density(alpha = 0.9, 
 size = 1) +
 scale_x_continuous(breaks = round(seq(min(partial_data$MEDIA_FINAL), 
 max(partial_data$MEDIA_FINAL), 
 by = 5), 10)) +
 xlab("\nMedia Final") + 
 ylab("\nDensidade") + 
 labs(fill = "Ano", 
 colour = "Semestre") +
 ggtitle("\nDistribuicao das Medias em Desenho II (Sem rep. por frequencia)\n") +
 normal_theme + 
 theme(strip.background = element_blank(), 
 strip.text = element_blank(), 
 axis.title = element_text(size = 18), 
 plot.title = element_text(size = 18), 
 axis.text = element_text(size = 15), 
 legend.position = "bottom", 
 legend.text = element_text(size = 15)) +
 facet_wrap(ANO ~ PERIODO, nrow = 5)

ggbackground(fig1, img)
savePlot(filename = "../images/figure23.png", type = "png", device = dev.cur())

# Density plot - sem reprovados por frequência - nota final por ano e disciplina
fig1 <- ggplot(partial_data,
 aes(x = ANO, y = MEDIA_FINAL)) +
 ggtitle("\nDensidade das Medias por Ano (Sem reprovados por frequencia)\n") +
 ylab("\nMedia Final\n") + xlab("\nAno") + 
 labs(fill = "Densidade") + 
 stat_density2d(aes(fill = ..density..), 
 contour = F, 
 geom = 'tile') +
 scale_fill_gradient(low = "black", high = "white") +
 geom_segment(aes(x = 2007, y = 6, xend = 2019, yend = 6), 
 linetype = "dotted", colour = "black") +
 geom_segment(aes(x = 2007, y = 7, xend = 2019, yend = 7), 
 linetype = "dotted", colour = "black") +
 geom_segment(aes(x = 2016, y = 0, xend = 2016, yend = 10), 
 linetype = "dotted", colour = "black") +
 geom_segment(aes(x = 2018, y = 0, xend = 2018, yend = 10), 
 linetype = "dotted", colour = "black") +
 scale_x_continuous(expand = c(0, 0), breaks = seq(2007, 2019, by = 1)) +
 scale_y_continuous(expand = c(0, 0), breaks = seq(0, 10, by = 1)) +
 normal_theme + 
 theme(axis.title = element_text(size = 18), 
 axis.text = element_text(size = 15), 
 panel.spacing = unit(2, "lines"), 
 plot.title = element_text(hjust = 0.5, size = 18), 
 axis.text.x = element_text(face = "bold", size = 8), 
 legend.key.width = unit(2, "cm"), 
 legend.position = "bottom", legend.text = element_text(size = 11)) +
 facet_wrap(~DISCIPLINA)

ggbackground(fig1, img)
savePlot(filename = "../images/figure24.png", type = "png", device = dev.cur())

Apesar dos resultados das análises serem visíveis, temos que corroborar com o uso de métodos estatísticos.

Parte III - Estatísticas do Dataset

Vamos testar hipóteses sobre as variáveis independentes e a nota final dos alunos. Primeiro, separamos as análises, uma incluindo dados de Desenho Técnico I e a outra com dados de Desenho Técnico II, já que são disciplinas distintas. Começaremos com Desenho I.

Primeiro, transformamos os dados da coluna do período para números, representando o primeiro e o segundo semestres. Na sequência, o período e o ano são transformados em fatores, para trabalharmos na sequência com este formato.

1
2
3
4
5


all_data$PERIODO[all_data$PERIODO == "1. Semestre"] <- 1
all_data$PERIODO[all_data$PERIODO == "2. Semestre"] <- 2
all_data$PERIODO <- as.factor(all_data$PERIODO)
all_data$ANO <- as.factor(all_data$ANO)
DT1 <- all_data[all_data$DISCIPLINA == "DESENHO TECNICO I",]

Caso I: Performance dos Estudantes por Semestre e Ano em Desenho Técnico I

Primeiro vamos checar as três pressuposições da análise de variância:

(1) Amostras independentes – uma observação não pode ser influenciada pela anterior ou pela próxima. Esse pressuposto garante que os dados sejam coletados aleatoriamente dentro do espaço amostral.

(2) Resíduos seguem uma distribuição normal – assume-se que a média geral dos resíduos é igual a zero, ou seja, distribuem-se normalmente.

(3) Homogeneidade das variâncias entre os grupos – as variâncias dentro de cada grupo é aproximadamente igual àquela dentro de todos os grupos. Desta forma, cada tratamento contribui de forma igual para a soma dos quadrados.

No caso de (1): podemos assumir que cada estudante é responsável por seu respectivo esforço e, por consequência, suas notas. A influência entre alunos é desprezível neste caso. Portanto, o primeiro pressuposto está ok (isso vale para todas as análises na sequência).

No caso de (2): realizar o teste de shapiro-walk, para checar se os resíduos/erros possuem uma distribuição normal. Para isso, vamos antes executar uma análise de variância com o aov no R

1
2
3
4
5
6
7
8


# | var. indep. | var. depend. | conjunto de dados
aov_result <- aov(MEDIA_FINAL ~ ANO * PERIODO, data = DT1)
shapiro.test(residuals(aov_result))

Shapiro-Wilk normality test

data: residuals(aov_result)
W = 0.93032, p-value < 2.2e-16

p-value < 0.05 : H0 (Hipótese Nula) rejeitada, a evidência de que a distribuição de resíduos não segue uma distribuição normal é estatisticamente significante.

Resultado: os resíduos não têm uma distribuição normal.

No caso de (3): teste de homogeneidade da variância entre grupos. Primeiro manualmente e depois com o teste de Levene.

1
2
3


max(aggregate(MEDIA_FINAL ~ ANO + PERIODO, DT1, var)$MEDIA_FINAL)/min(aggregate(MEDIA_FINAL ~ ANO + PERIODO, DT1, var)$MEDIA_FINAL)

[1] 1.620751

Regra empírica: Variações que não excedem a taxa de 1.5:1 entre a variância máxima e mínima não violam o pressuposto.

Resultado: 1.62. A variação entre os grupos possui discrepâncias. Vamos confirmar com testes de Levene.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


leveneTest(MEDIA_FINAL ~ ANO, DT1, center = median)

Levenes Test for Homogeneity of Variance (center = median)
 Df F value Pr(>F) 
group 12 4.6556 1.579e-07 ***
 2346 
---
Signif. codes: 0 "***" 0.001 "**" 0.01 "*" 0.05 "." 0.1 " " 1

leveneTest(MEDIA_FINAL ~ PERIODO, DT1, center = median)

Levenes Test for Homogeneity of Variance (center = median)
 Df F value Pr(>F) 
 group 1 6.2454 0.01252 *
 2357 
 ---
 Signif. codes: 0 "***" 0.001 "**" 0.01 "*" 0.05 "." 0.1 " " 1

leveneTest(MEDIA_FINAL ~ ANO * PERIODO, DT1, center = median)

Levenes Test for Homogeneity of Variance (center = median)
 Df F value Pr(>F) 
 group 24 2.2232 0.0005779 ***
 2334 
 ---
 Signif. codes: 0 "***" 0.001 "**" 0.01 "*" 0.05 "." 0.1 " " 1

p-value < 0,05: H0 rejeitado em todos os testes de Levene, a evidência de que as variações entre os grupos (anos, semestres e ambos) são diferentes é estatisticamente significante.

Oh good ! E agora?

Calma, podemos recorrer aos testes não-paramétricos…

Uma das técnicas que é possível utilizar com violações das pressuposições da anova é o teste de Kruskal-Wallis. É testado se a função de distribuição das médias entre os grupos é igual (H0).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


kruskal.test(MEDIA_FINAL ~ ANO, DT1)

Kruskal-Wallis rank sum test
data: MEDIA_FINAL by ANO
Kruskal-Wallis chi-squared = 134.28, df = 12, p-value < 2.2e-16

kruskal.test(MEDIA_FINAL ~ PERIODO, DT1)

Kruskal-Wallis rank sum test
data: MEDIA_FINAL by PERIODO
Kruskal-Wallis chi-squared = 4.8196, df = 1, p-value = 0.02814

kruskal.test(MEDIA_FINAL ~ interaction(ANO, PERIODO), DT1)

Kruskal-Wallis rank sum test
data: MEDIA_FINAL by interaction(ANO, PERIODO)
Kruskal-Wallis chi-squared = 172.89, df = 24, p-value < 2.2e-16

p-value < 0,05: H0 rejeitado em todos os testes de Kruskal-Wallis. Portanto, a diferença de distribuição das médias em pelo menos um dos grupos de anos e semestres é estatisticamente significante.

Vamos observar graficamente estes dados.

É possível observar que no caso dos semestres, as distribuições possuem alguma semelhança. Por isso o p-value dos semestres como tratamento resultou em um valor mais próximo de 0.05. Ao verificarmos ano e ambos ano e semestre, as diferenças entre os grupos se mostraram mais significativas.

Agora a questão que fica é: quais grupos possuem diferença significativa?

Antes vamos aplicar o teste de size effect com a função multiVDA. O teste indica a probabilidade da amostra de um grupo ser maior que a de outro grupo.

Resultados: o VDA varia de 0 a 1, com 0.5 indicando igualdade estocástica e 1 indicando que o primeiro grupo domina o segundo. O CD varia de -1 a 1, com 0 indicando igualdade estocástica e 1 indicando que o primeiro grupo domina o segundo. r varia de aproximadamente -0,86 a 0,86, dependendo do tamanho da amostra, com 0 indicando nenhum efeito e um resultado positivo indicando que os valores no primeiro grupo são maiores que no segundo.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


multiVDA(MEDIA_FINAL ~ ANO, data = DT1)
# Par de grupos mais distinto: 78.5% de probabilidade de valores de 2008 serem superiores aos de 2014.

multiVDA(MEDIA_FINAL ~ PERIODO, data = DT1)
# Par de grupos mais distinto: 47.4% de probabilidade de valores do primeiro semestre serem superiores aos do segundo.

multiVDA(MEDIA_FINAL ~ SEX, data = DT1)
# Par de grupos mais distinto: 51.4% de probabilidade de valores do sexo F serem superiores aos do sexo M.

multiVDA(MEDIA_FINAL ~ COD_CURSO, data = DT1)
# Par de grupos mais distinto: 60.1% de probabilidade de valores do curso BAEQ serem superiores aos do curso BALF.

Agora para finalizar vamos aplicar o teste de dunncan (dunnTest) para checar quais grupos de atributos pertencem a mesma classe de médias. Em outras palavras, quais grupos não possuem diferença estatística significante comparado com outros.

1
2
3
4
5
6
7
8


PT = dunnTest(MEDIA_FINAL ~ ANO,
 data = DT1,
 method = "bh") 

O <- cldList(P.adj ~ Comparison,
 data = PT$res,
 threshold = 0.05,
 remove.zero = FALSE)

As médias dos alunos em anos que pertencem a mesma label não possuem diferença estatística significativa. Este é o resultado que o teste nos trouxe.

Infelizmente não é possível utilizar mais de uma variável dependente neste teste, mas a solução do problema é uma simples manipulação do dataframe, conforme apresento abaixo.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


merged_data <- transform(DT1, ANO_PERIODO = paste(ANO, '.', PERIODO))

PT = dunnTest(MEDIA_FINAL ~ ANO_PERIODO,
 data = merged_data,
 method = "bh") 

O <- cldList(P.adj ~ Comparison,
 data = PT$res,
 threshold = 0.05,
 remove.zero = FALSE)

Agora vamos proceder as mesmas análises, porém com os alunos de Desenho Técnico II.

Caso (1): podemos assumir que cada estudante é responsável por seu respectivo esforço e, por consequência, suas notas. A influência entre alunos é desprezível neste caso. Portanto, o primeiro pressuposto está ok.

Caso (2): Os resíduos seguem uma distribuição normal?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


> DT2 <- all_data[all_data$DISCIPLINA == "DESENHO TECNICO II",]
> aov_result <- aov(MEDIA_FINAL ~ ANO * PERIODO, data = DT2)
> 
> # Normality of errors test
> shapiro.test(residuals(aov_result))

	Shapiro-Wilk normality test

data: residuals(aov_result)
W = 0.88, p-value <0.0000000000000002

p-value < 0.05 : H0 (Hipótese Nula) rejeitada, a evidência de que a distribuição de resíduos não segue uma distribuição normal é estatisticamente significante.

Resultado: os resíduos não têm uma distribuição normal.

Caso (3): teste de homogeneidade da variância entre grupos.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


> max(aggregate(MEDIA_FINAL ~ ANO + PERIODO, DT2, var)$MEDIA_FINAL)/min(aggregate(MEDIA_FINAL ~ ANO + PERIODO, DT2, var)$MEDIA_FINAL)
[1] 5.044
> 
> leveneTest(MEDIA_FINAL ~ ANO, DT2, center = median)
Levenes Test for Homogeneity of Variance (center = median)
 Df F value Pr(>F) 
group 12 3.66 0.00002 ***
 1260 
---
Signif. codes: 0 "***" 0.001 "**" 0.01 "*" 0.05 "." 0.1 " " 1
> leveneTest(MEDIA_FINAL ~ PERIODO, DT2, center = median)
Levenes Test for Homogeneity of Variance (center = median)
 Df F value Pr(>F)
group 1 1.3 0.25
 1271 
---
Signif. codes: 0 "***" 0.001 "**" 0.01 "*" 0.05 "." 0.1 " " 1 
> leveneTest(MEDIA_FINAL ~ ANO * PERIODO, DT2, center = median)
Levenes Test for Homogeneity of Variance (center = median)
 Df F value Pr(>F) 
group 23 2.67 0.000033 ***
 1249 
---
Signif. codes: 0 "***" 0.001 "**" 0.01 "*" 0.05 "." 0.1 " " 1

Onde p-value < 0,05: H0 rejeitado, a evidência de que as variações das médias entre os grupos (anos, e ambos semestres e anos) são diferentes é estatisticamente significante.

Onde p-value >= 0,05: H0 é aceita, a evidência de que as variações das médias entre os grupos de semestres são diferentes não é estatisticamente significante.

Como houveram violações dos pressupostos, vamos recorrer novamente aos métodos não-paramétricos.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


> kruskal.test(MEDIA_FINAL ~ ANO, DT2)

	Kruskal-Wallis rank sum test

data: MEDIA_FINAL by ANO
Kruskal-Wallis chi-squared = 127, df = 12, p-value <0.0000000000000002

> kruskal.test(MEDIA_FINAL ~ PERIODO, DT2)

	Kruskal-Wallis rank sum test

data: MEDIA_FINAL by PERIODO
Kruskal-Wallis chi-squared = 9.3, df = 1, p-value = 0.002

> kruskal.test(MEDIA_FINAL ~ interaction(ANO, PERIODO), DT2)

	Kruskal-Wallis rank sum test

data: MEDIA_FINAL by interaction(ANO, PERIODO)
Kruskal-Wallis chi-squared = 142, df = 23, p-value <0.0000000000000002

No caso dos semestres, as distribuições das médias possuem alguma semelhança. Ao verificarmos ano e ambos ano e semestre, as diferenças entre os grupos se mostraram mais significativas. Um resultado semelhante ao de Desenho Técnico I.

Agora vamos verificar quais grupos possuem semelhanças significativas.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


merged_data <- transform(DT2, ANO_PERIODO = paste(ANO, '.', PERIODO))

PT = dunnTest(MEDIA_FINAL ~ ANO_PERIODO,
 data = merged_data,
 method = "bh") 

O <- cldList(P.adj ~ Comparison,
 data = PT$res,
 threshold = 0.05,
 remove.zero = FALSE)

Os resultados até o momento são compatíveis com o que visualizamos na etapa dos gráficos, não é mesmo? Essa é uma das numerosas importâncias da estatística em nossas vidas: extrair valiosas informações de amostras de um universo de infinitas possibilidades, e esboçar possíveis considerações sobre elas.

O que foi possível extrair destas análises?

O curso de BAEQ tem médias superiores nos Desenhos comparada com outros cursos, enquanto que BALF possui desempenho inferior (e menor número de amostras);
Removidos os dados de reprovados por frequência, BAEC supera BAEQ em Desenho II nas estatísticas descritivas (porém, BAEC possui bem menos amostras que outros cursos);
Os grupos possuem um número muito diferente de amostras e isto não foi apresentado nos boxplots/violin plots;
A diferença entre as médias é significativa entre anos e semestres, anos, e em alguns casos, em semestres distintos, tanto em Desenho I como Desenho II.
Há uma tendência de redução geral do desempenho em Desenho II;
Estudantes do sexo feminino tem reprovado em menor quantidade e percentual do que estudantes do sexo masculino;
Uma quantidade significativa dos estudantes que reprovam por frequência em Desenho I e II acabam desistindo do curso, e uma parcela muito pequena acaba se formando ou permanecendo nos cursos;
A quantidade de reprovações são maiores no 1° semestre para Desenho I e no 2° para Desenho II. Faz sentido por Desenho I ser pré-requisito de Desenho II;
O desempenho médio em Desenho II é superior que em Desenho I em geral, e a quantidade de reprovados por frequência e por nota em Desenho II é menor do que em Desenho I;
Não há um padrão evidente na variação do desempenho se considerarmos apenas o ano/tempo como variável;

O que seria possível agregar para enriquecermos estes resultados?

Informações do docente que ministrou a disciplina, assim como suas características (mestrado/doutorado/substituto/graduação/…);
Demais informações dos estudantes, como forma de ingresso, notas no enem por área de estudo, se o estudante trabalha, etc;
Inclusão da forma de avaliação e formato de atividades adotado nas disciplinas;

Considerações Finais

Bom pessoal, a ideia foi apresentar um passo a passo detalhado sobre o processo de análise exploratória de dados utilizando o R. Além disso, incluímos análises estatísticas para verificar diferenças entre grupos de médias, como diferenças entre cursos, anos, semestres e outras variáveis.

Espero que vocês tenham gostado do post e que ele tenha auxiliado vocês de alguma forma.

Agradeço especialmente ao professor Dr. Alexandro Schafer por ter compartilhado este dataset comigo, possibilitando a realização destas análises.

Quaisquer dúvidas, podem deixar comentários logo abaixo :-)

Valeu !! Até o próximo post !! :-) (refêrencias logo abaixo).

Referências

Conjunto de dados de alunos de Desenho Técnico. Acesso em: 15 de maio de 2020.
Effect of variance ratio on ANOVA robustness: Might 1.5 be the limit?. Acesso em: 16 de maio de 2020.
MultiVDA - Pairwise Vargha And Delaney’s A And Cliff’s Delta. Acesso em: 16 de maio de 2020.
Undestanding boxplots. Acesso em: 16 de maio de 2020.

Investigando Programas de Pós-Graduação em Computação no Brasil (PT 2)

Fri, 17 Apr 2020 23:55:00 -0300

Resumo

Saudações pessoal.

A ideia deste post é compartilhar com vocês um tutorial de como hospedar uma aplicação desenvolvida com o R no shinyapps.io. Por conveniência, vou ilustrar o tutorial com base no Sistema Operacional Ubuntu versão 18.10 LTS.

Os dados que utilizei como base para este app são os dos Programas de Pós-Graduação em Computação do Brasil, já trabalhados anteriormente neste post.

O que eu preciso para reproduzir este experimento?

Linguagem R versão 3.6.3;
RStudio versão 1.2.5033 (IDE opcional);
Conjunto de planilhas com os dados dos Programas de Pós-Graduação em Computação do Brasil;
Uma conta no shinyapps.io;
Conhecimentos básicos de lógica e programação, estruturas de dados e R.

Tópicos

Quais informações vamos trazer aos usuários?
Coleta e organização dos dados;
Elaboração da Interface do Usuário (User Interface - UI);
Elaboração da lógica do servidor (Server);
Execução do app na própria máquina (localmente);
Publicando o app no shinyapps.io;

Quais informações vamos trazer aos usuários?

Não adianta avançarmos para os tópicos técnicos do desenvolvimento sem antes termos clareza do propósito deste app. A idéia é fornecer um meio de consulta aos locais do Brasil onde existem Programas de Pós-Graduação em Computação com filtros para parâmetros específicos como tema de pesquisa, localização, conceito da CAPES, nível do programa, entre outros. Também pretende-se gerar informações sobre as linhas de pesquisa destes Programas, como surgimento com o passar dos anos e número total no país.

Portanto, foram elencadas as seguintes propostas de informações:

Localização (GPS) dos Programas de Pós-Graduação em Computação do Brasil, com filtros por Unidade da Federação (estados), universidade, linha de pesquisa e conceito da CAPES (gráfico de mapa);
Quantitativo de Programas por estado (gráfico de barras);
Total de Programas por temas de pesquisa (gráfico de barras);
Número de Programas com determinado tema de pesquisa com o passar dos anos (com possibilidade de comparação com outro tema) (gráfico de linhas);

Coleta e Organização dos Dados

Na Parte 1, eu coletei os dados dos Programas e salvei em arquivos no formato csv. Estes dados foram obtidos de dois locais, entre 10/2019 e 01/2020:

Sucupira;
Página Oficial de cada um dos Programas de Pós-Graduação em Computação do Brasil;

Eu coletei estes dados manualmente, organizei e salvei em arquivos csv no formato normalizado (com id e fk). Para maiores detalhes deste processo, acesse a parte 1 deste projeto.

Antes de começar, você tem duas alternativas: Clonar o meu projeto do github, utilizar o setwd para o diretório raiz do projeto e acompanhar este tutorial ou fazer o download do diretório csv e shapefile para o diretório do seu projeto e seguir este tutorial.

Abaixo são apresentados os pacotes utilizados na primeira parte do tutorial. O código fonte completo está disponível no Github.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# loading / installing packages
#sudo apt install default-jdk -> rjava package dependency
if (!require(xlsx)) install.packages("xlsx")
library(xlsx)

#sudo apt install libgdal-dev -> https://stackoverflow.com/questions/12141422/error-gdal-config-not-found
if (!require(rgdal)) install.packages("rgdal")
library(rgdal)

if (!require(rgeos)) install.packages("rgeos")
library(rgeos)

if (!require(ggplot2)) install.packages("ggplot2")
library(ggplot2)

if(!require(maptools)) install.packages("maptools")
library(maptools)

if (!require(dplyr)) install.packages("dplyr")
library(dplyr)

if (!require(forcats)) install.packages("forcats")
library(forcats)

Inicialmente, vamos importar e organizar esses dados para obter as informações necessárias para a UI.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


# importação dos dados
universities_path <- "../csv/universities_after.xlsx"
cities_path <- "../csv/brazilian_cities.csv"
states_path <- "../csv/brazilian_states.csv"
research_names_path <- "../csv/research_names.xlsx"
university_research_path <- "../csv/university_research.xlsx"
graduation_level_path <- "../csv/graduation_level.xlsx"
course_name_path <- "../csv/course_name.xlsx"
concentration_area_path <- "../csv/concentration_area.xlsx"
university_concentration_area_path <- "../csv/university_concentration_area.xlsx"

universities <- read.xlsx(universities_path, stringsAsFactors = FALSE, sheetIndex = 1, encoding = "UTF-8")
brazilian_cities <- read.csv(cities_path, sep = ",", stringsAsFactors = FALSE, encoding = "UTF-8")
brazilian_states <- read.csv(states_path, sep = ",", stringsAsFactors = FALSE, encoding = "UTF-8")
research_names <- read.xlsx(research_names_path, sheetIndex = 1, encoding = "UTF-8")
university_research <- read.xlsx(university_research_path, sheetIndex = 1, encoding = "UTF-8")
graduation_level <- read.xlsx(graduation_level_path, sheetIndex = 1, encoding = "UTF-8")
course_name <- read.xlsx(course_name_path, sheetIndex = 1, encoding = "UTF-8")
concentration_area <- read.xlsx(concentration_area_path, sheetIndex = 1, encoding = "UTF-8")
university_concentration_area <- read.xlsx(university_concentration_area_path, sheetIndex = 1, encoding = "UTF-8")

# união dos dados em um único dataframe
all_data <- inner_join(universities, brazilian_cities, by = c("city_id" = "ibge_code"))
all_data <- inner_join(all_data, brazilian_states, by = c("state_id" = "state_id"))
all_data <- inner_join(all_data, university_research, by = c("id" = "university_id"))
all_data <- inner_join(all_data, research_names, by = c("research_id" = "id"))
all_data <- inner_join(all_data, graduation_level, by = c("level" = "id"))
all_data <- inner_join(all_data, course_name, by = c("course" = "id"))
all_data <- inner_join(all_data, university_concentration_area, by = c("id" = "university_id"))
all_data <- inner_join(all_data, concentration_area, by = c("concentration_area_id" = "id"))

# colunas de ID descartadas, dados para formato numérico (limpeza e preparação dos dados)
all_data <- all_data[,-9]
all_data <- all_data[,-14]
all_data <- all_data[,-16]
all_data <- all_data[,-19]
all_data$latitude <- as.numeric(as.character(all_data$latitude))
all_data$longitude <- as.numeric(as.character(all_data$longitude))
all_data$grade <- as.numeric(as.character(all_data$grade))

# importação do shapefile 
shape_brazil_path <- "../../shapefile/Brazil.shp"
shape_brazil <- readOGR(shape_brazil_path, "Brazil", encoding = "latin1")

# transformação do shapefile para dataframe
shape_brazil$id <- rownames(as.data.frame(shape_brazil))
coordinates_brazil <- fortify(shape_brazil, region = "id") # apenas coordenadas
shape_brasil_df <- merge(coordinates_brazil, shape_brazil, by = "id", type = 'left') # acréscimo de atributos restantes

Com os dados importados e organizados em dataframes, agora vamos criar dataframes específicos para cada um dos gráficos na UI. Isso fará com que a aplicação consuma mais memória, mas por outro lado tornará a lógica de processamento e acesso aos dados mais simples.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


# dados agrupados por estado e id, ordem decrescente de n° de Programas por estado
barplot_1_data <- as.data.frame(
 all_data %>%
 group_by(state_code) %>%
 summarise(id = n_distinct(id)) %>%
 arrange(-id) %>%
 mutate(state_code = fct_reorder(state_code, -id))
)

# dados agrupados por tópico de pesquisa e id, especificamente os tópicos que aparecem no mínimo 10 vezes, em ordem decrescente de n° de Programas por tópico
barplot_2_data <- as.data.frame(
 all_data %>%
 group_by(research_name) %>%
 summarise(id = n_distinct(id)) %>%
 arrange(-id) %>%
 mutate(research_name = fct_reorder(research_name, -id)) %>%
 filter( id > 10 )
)

# dados agrupados por tópico de pesquisa e ano, ordenados por ano, agregando o n° de Programas por tópico de pesquisa por ano
lineplot_1_data <- as.data.frame(
 all_data %>%
 group_by(research_name, year) %>%
 summarise(id = n_distinct(id)) %>%
 arrange(year) %>%
 mutate( cumsum = cumsum(id))
)

# valores possíveis de notas da CAPES 
mybreaks <- c("3", "4", "5", "6", "7")

O código acima (em lineplot_1_data) tem um problema: é feito o agrupamento do n° de Programas por linha de pesquisa e por ano, porém não são gerados registros para os anos em que não houve variação do n° de Programas. Abaixo um exemplo:

1995 surgiu 1 novo tópico de pesquisa em IA e havia 12 tópicos de pesquisa em IA. Portanto, 1995 passou a ter 13 Programas em IA.

1996 surgiram 2 novos tópicos de pesquisa em IA e havia 13 tópicos de pesquisa em IA. Portanto, 1995 passou a ter 15 Programas em IA.

1997 não surgiu nenhum novo tópico em IA. Nesse caso, não é gerado registro para 1997, causando distorções nos gráficos.

O algoritmo abaixo foi feito para gerar registros nos anos em que o número de tópicos de pesquisa não variou, para todos anos e tópicos de pesquisa.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# gerando registros para os anos sem variação no n° de Programas para cada tópico de pesquisa
for( i in 1:length(unique(lineplot_1_data$research_name)) ) {
 name <- as.character(unique(lineplot_1_data$research_name)[i])
 last_year <- 0
 last_cumsum <- 0
 for (j in min(lineplot_1_data$year):max(lineplot_1_data$year) ) {
 if (j %in% lineplot_1_data$year[lineplot_1_data$research_name == name]){
 last_year <- j
 last_cumsum <- lineplot_1_data$cumsum[lineplot_1_data$research_name == name & lineplot_1_data$year == j]
 } 
 else {
 lineplot_1_data <- rbind.data.frame(lineplot_1_data, c(name, j, 0, last_cumsum), stringsAsFactors = FALSE)
 }
 }
}

lineplot_1_data$year <- as.numeric(lineplot_1_data$year)
lineplot_1_data$id <- as.numeric(lineplot_1_data$id)
lineplot_1_data$cumsum <- as.numeric(lineplot_1_data$cumsum)
lineplot_1_data <- lineplot_1_data[order(lineplot_1_data$year),]

Também foram realizadas customizações para cada gráfico que será gerado na UI. Abaixo é apresentado o código para customizar o tema (dark theme) e layout dos gráficos. O nome das variáveis já indica em qual gráfico que será aplicado o tema. Também são definidos os textos das escalas X e Y de cada gráfico.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


geral_1_theme <- theme(
 axis.text = element_text(size = 12, color = "#cccccc"),
 axis.title = element_text(size = 16, face = "bold", color = "#cccccc"),
 axis.ticks = element_line(colour = "#cccccc"),
 axis.ticks.length = unit(0.5, "cm"),
 plot.caption = element_text(size = 12, face = "bold", color = "#cccccc"),
 plot.title = element_text(size = 22, hjust = 0.5, color = "#ffffff"),
 plot.background = element_rect(fill = "black"),
 panel.grid.major = element_blank(),
 panel.grid.minor = element_blank(),
 panel.background = element_rect(fill = 'black'),
 legend.background = element_rect(fill = "black", color = NA),
 legend.key = element_rect(color = "gray", fill = "black"),
 legend.text = element_text(size = 14),
 text = element_text(color = "#cccccc")
)

map_labs <- labs(
 x = "Longitude", 
 y = "Latitude", 
 caption = "Fonte: Programas de Pós-Graduação em Computação - Plataforma Sucupira."
) 

barplot_1_labs <- labs(
 x = "\nEstados do Brasil", 
 y = "\nNúmero de Programas\n", 
 caption = "\nFonte: Programas de Pós-Graduação em Computação - Plataforma Sucupira."
) 

barplot_2_labs <- labs(
 y = "Número de Programas de Pós-Graduação", 
 caption = "\nFonte: Programas de Pós-Graduação em Computação - Plataforma Sucupira."
) 

lineplot_1_labs <- labs(
 x = "\nAnos", 
 y = "Número de Programas\n", 
 caption = "\nFonte: Programas de Pós-Graduação em Computação - Plataforma Sucupira."
) 

Agora salvamos nosso ambiente (variáveis, dados e pacotes) em um arquivo RData. Depois ele será importado no servidor da aplicação (entenda o servidor/server como o backend, responsável pela lógica do app, processamento de inputs e geração dos gráficos com as informações processadas) e na interface da aplicação (para a geração de alguns menus para inputs do usuário).

1

save.image(file = "R/data/all_data.RData")

Elaboração da Interface do Usuário (User Interface - UI)

Agora devemos preparar a UI com os gráficos para o usuário. Abaixo o código utilizado para gerar a UI.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118


if (!require(shiny)) install.packages("shiny")
library(shiny)

if (!require(shinydashboard)) install.packages("shinydashboard")
library(shinydashboard)

load(file = "data/all_data.RData")

ui <- navbarPage(
 "Tek Broom",
 tabPanel(
 "Mapas",
 fluidPage(id = 'fluidPage', 
 shinyjs::useShinyjs(),
 titlePanel("Programas de Pós-Graduação em Computação - Brasil"),
 sidebarLayout(
 
 sidebarPanel(id = "sidebar",
 selectInput(
 "input_state",
 "Estado",
 choices = c("Todos", sort(unique(all_data$state_name))),
 selected = "Todos"
 ),
 selectInput(
 "input_university",
 "Universidade",
 choices = c("Todas", as.character(sort(unique(all_data$university)))),
 selected = "Todas"
 ),
 selectInput(
 "input_research_topic",
 "Assunto de Pesquisa",
 choices = c("Todos", as.character(sort(unique(all_data$research_name)))),
 selected = "Todos"
 ),
 sliderInput(
 "input_grade_range",
 label = "Notas dos Programas:",
 min = 3,
 max = 7,
 value = c(3, 7)
 )
 ),
 mainPanel(id = 'mainPanel',
 fluidRow(box(
 background = "black",
 plotOutput("map", height = 900), width = 12 )))
 ),
 includeCSS("css/styles.css"))
 ),
 tabPanel(
 "Gráficos",
 dashboardPage(
 dashboardHeader(disable = TRUE),
 dashboardSidebar( disable = TRUE),
 dashboardBody(
 fluidRow(
 box(
 background = "black",
 title = "Programas de Pós-Graduação em Computação por Estado",
 solidHeader = TRUE,
 collapsible = TRUE,
 plotOutput("barplot_1"),
 width = 6
 )
 ,
 box(
 background = "black",
 title = "Programas de Pós-Graduação em Computação por Tópico de Pesquisa",
 solidHeader = TRUE,
 collapsible = TRUE,
 plotOutput("barplot_2"),
 width = 6
 )
 ),
 fluidRow(
 box(
 background = "black",
 title = "Histórico dos Programas de Pós-Graduação em Computação por Tópico de Pesquisa",
 solidHeader = TRUE,
 collapsible = TRUE,
 "Observação: o ano apresentado é o de surgimento do Programa que originou
 o Tópico de Pesquisa. Não é o ano de surgimento do Tópico de Pesquisa em si,
 já que a informação dos tópicos de pesquisa não foi coletada do site da
 CAPES e sim da página de cada Programa de Pós-Graduação em Computação do
 Brasil.",
 br(),br(),br(),
 plotOutput("lineplot_1"),
 width = 12
 ),
 box(
 background = "black",
 box(
 background = "black",
 selectInput(
 "input_research_1",
 "Tópico de Pesquisa 1",
 choices = sort(unique(lineplot_1_data$research_name)),
 selected = lineplot_1_data$research_name[1]
 )
 ),
 box(
 background = "black",
 selectInput(
 "input_research_2",
 "Tópico de Pesquisa 2",
 choices = c("Nenhum", as.character(sort(unique(lineplot_1_data$research_name)))),
 selected = "Nenhum"
 )
 ),
 width = 12
 )
 )
 )
 )
 )
)

Antes de explicar em detalhes cada componente da UI, cabe mostrar o que é cada um destes componentes na tela final do shinyapp. Abaixo são apresentadas duas telas do nosso app final, com destaque para cada componente da UI.

navbarPage - cria uma página com a possibilidade de menus no topo;

tabPanel - cria um menu no painel que é aplicado;

fluidPage - cria páginas com layout adaptável, definidas por largura e altura (width e height);

titlePanel - título do painel onde é aplicado;

sidebarLayout - estilo de layout aplicado na página. O layout sidebar contém um painel lateral e a área principal;

sidebarPanel - cria um painel lateral;

selectInput - input de dados no estilo menu dropdown;

sliderInput - input de dados no estilo slider;

mainPanel - painel com a área principal da página;

plotOutput - local onde é plotado o gráfico “map”.

Na página dos gráficos, apenas para fins didáticos e de autoaprendizado, utilizei o shiny dashboards. Abaixo uma breve explicação de cada componente.

dashboardPage - cria uma página com shiny dashboard;

dashboardHeader - componente header da página, que no nosso caso está desabilitado (disable = TRUE);

dashboardSidebar - componente da barra lateral, que no nosso caso também está oculto (collapsed = TRUE);

dashboardBody - área principal do dashboard, corpo da página;

fluidRow - componente para geração de linhas e colunas baseada no bootstrap;

box - principal componente de um shinydashboard, que pode conter outros elementos shiny, inputs, outputs de dados, gráficos e outros.

Para maiores detalhes dos componentes do shiny, acessem este link.

E para detalhes dos componentes do shinyDashboard, acessem este link.

Cabe destacar três elementos em especial:

load(file = “data/all_data.RData”) aqui importamos os dados que processamos no início deste tutorial, pois vamos precisar do dataframe all_data para fornecer as opções de estados e universidades nos selects para os usuários. Também vamos precisar dos nomes das linhas de pesquisa para um dos gráficos.

shinyjs::useShinyjs() utilizamos o shinyjs para habilitar e desabilitar o input de dados, em certas condições. Ex: se eu quero ver todos os Programas de Pós do Brasil, devo desabilitar a seleção de universidade. O código para isso está no server.R.

includeCSS(“css/styles.css”)) este trecho de código permite customizar o estilo da nossa página. Nesse caso, alteramos a página original para um dark theme.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#fluidPage { 
 background-color: #222222; 
 color: #ffffff; 
} 

body { 
 background-color: #222222; 
 color: #ffffff; 
}

.content-wrapper, .right-side {
 background-color: #000000;
}
 
#sidebar { 
 background-color: #333333; 
 color: #ffffff;
}

#mainPanel { 
 background-color: #222222; 
 color: #ffffff; 
}

.navbar-default {
 background-color: #333333;
 border-color: #ffffff;
}

.bg-black {
 background-color: #222222 !important;
}

Em resumo:

A variável ui armazenará os componentes para a geração da interface gráfica para o usuário. Nossa interface terá duas abas: Mapas e Gráficos, definidas em tabPanel. A aba Mapas permitirá ao usuário fazer consultas com o resultado exibido em mapas e a aba Gráficos permitirá ao usuário visualizar informações gerais dos Programas e linhas de pesquisa em gráficos de barras e linhas.
Aba Mapas: essa tela possuirá um componente sidebar (barra lateral) onde serão inseridos os inputs (entrada de dados) para a geração dos mapas e o restante da tela é onde o mapa será apresentado. titlePanel é o título da barra lateral, sidebarLayout é o layout da página (com barra lateral) e sidebarPanel terá os componentes que desejamos para essa barra lateral (inputs para seleção dos Programas por estado, universidade, linha de pesquisa e conceito da CAPES).
Aba Gráficos: essa tela terá três gráficos. Um gráfico de barras verticais para a exibição do total de Programas por estado, um gráfico com barras horizontais com as linhas de pesquisa no Brasil com no mínimo 10 em número de Programas (com no mínimo 10) e um gráfico de linhas com a evolução do número de Programas para as linhas de pesquisa selecionadas (uma ou duas linhas de pesquisa por vez).

A UI se resume a isso. Agora vamos para o server xD (parte mais complicada, em termos de lógica).

Elaboração da lógica do servidor (Server);

O nosso server será responsável por processar os inputs do usuário para gerar os gráficos adequados em cada situação possível.

Vamos criar um arquivo com o nome server.R e instalar/importar os seguintes pacotes, além de carregar os dados que organizamos no início do tutorial:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


if (!require(dplyr)) install.packages("dplyr")
library(dplyr)

if (!require(ggplot2)) install.packages("ggplot2")
library(ggplot2)

if(!require(RColorBrewer)) install.packages("RColorBrewer")
library(RColorBrewer)

if(!require(viridis)) install.packages("viridis")
library(viridis)

if (!require(shinyjs)) install.packages("shinyjs")
library(shinyjs)

if(!require(ggrepel)) install.packages("ggrepel")
library(ggrepel)

if (!require(shiny)) install.packages("shiny")
library(shiny)

if (!require(directlabels)) install.packages("directlabels")
library(directlabels)

if (!require(mapproj)) install.packages("mapproj")
library(mapproj)

if (!require(stringr)) install.packages("stringr")
library(stringr)

load(file = "data/all_data.RData")

O primeiro trecho de código em observe trata o princípio de modificar o input da página dos mapas nas seguintes situações:

Ao selecionar “Todos os Estados”, o input de Universidade é desabilitado;
Ao selecionar um estado específico, o input de Universidade deve conter apenas opções de universidade para o estado selecionado;
Se uma universidade específica for selecionada, o input de Estado é desabilitado;

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# Server logic ----
server <- function(input, output, session) { 
 observe({
 if (input$input_state != "Todos") {
 shinyjs::enable("input_university")
 states <- c("Todas", as.character(sort(unique(all_data$university[which(all_data$state_name == input$input_state)]))))
 updateSelectInput(session, "input_university", choices = states, selected = input$input_university)
 } else { 
 shinyjs::disable("input_university")
 }
 
 if (input$input_university == "Todas") {
 shinyjs::enable("input_state")
 } else {
 shinyjs::disable("input_state")
 }
 })

Agora precisamos modificar o conjunto de dados que será plotado na tela de acordo com os inputs do usuário.

A variável map_data armazenará o conjunto de dados adequado para exibição no nosso mapa. Vamos utilizar o reactive do shiny para realizar essa tarefa: sempre que algum input for alterado na interface, o código em reactive no server irá executar e atualizar o conjunto de dados.

Essa lógica se resume a uma série de condicionais (if else), considerando todas as possibilidades de input do usuário (estado, universidade, linha de pesquisa e intervalo de notas da CAPES). A lógica pode ser analisada logo abaixo.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


 map_data <- reactive({ 
 if(input$input_state == "Todos") {
 if(input$input_university == "Todas") {
 if(input$input_research_topic == "Todos") { 
 map_data <- all_data[all_data$grade >= input$input_grade_range[1] & all_data$grade <= input$input_grade_range[2],]
 } else {
 map_data <- all_data[all_data$research_name == input$input_research_topic & all_data$grade >= input$input_grade_range[1] & all_data$grade <= input$input_grade_range[2],]
 }
 } else {
 if(input$input_research_topic == "Todos") {
 map_data <- all_data[all_data$university == input$input_university & all_data$grade >= input$input_grade_range[1] & all_data$grade <= input$input_grade_range[2],]
 } else {
 map_data <- all_data[all_data$university == input$input_university & all_data$research_name == input$input_research_topic & all_data$grade >= input$input_grade_range[1] & all_data$grade <= input$input_grade_range[2],]
 }
 }
 } else {
 if(input$input_university == "Todas") {
 if(input$input_research_topic == "Todos") {
 map_data <- all_data[all_data$state_name == input$input_state & all_data$grade >= input$input_grade_range[1] & all_data$grade <= input$input_grade_range[2],]
 } else {
 map_data <- all_data[all_data$state_name == input$input_state & all_data$research_name == input$input_research_topic & all_data$grade >= input$input_grade_range[1] & all_data$grade <= input$input_grade_range[2],]
 }
 } else {
 if(input$input_research_topic == "Todos") {
 map_data <- all_data[all_data$university == input$input_university & all_data$grade >= input$input_grade_range[1] & all_data$grade <= input$input_grade_range[2],]
 5 } else {
 map_data <- all_data[all_data$university == input$input_university & all_data$research_name == input$input_research_topic & all_data$grade >= input$input_grade_range[1] & all_data$grade <= input$input_grade_range[2],]
 } 
 }
 } 
 })

Também vamos customizar o formato do mapa quando um estado específico for selecionado. Para isso, vamos utilizar novamente o reactive do shiny para selecionar apenas o shape do estado selecionado ou o shape de todo o Brasil caso a opção “Todos” seja selecionada. O shape será salvo na variável map_shapes.

1
2
3
4
5
6
7


map_shapes <- reactive({ 
 if(input$input_state != "Todos") {
 map_shapes = shape_brasil_df[which(shape_brasil_df$ESTADOS == input$input_state),]
 } else{
 map_shapes = shape_brasil_df
 }
})

Na outra tela teremos um gráfico da evolução de uma determinada linha de pesquisa (ou duas, se o usuário desejar) com o passar dos anos. Por padrão, apenas uma será exibida. Para isso, haverão dois inputs do estilo select para a seleção das linhas de pesquisa. Portanto, para determinar se o gráfico deve possuir uma ou duas linhas, será utilizado o dado informado no select do usuário. A opção “Nenhum” foi definida como padrão para a segunda linha de pesquisa (ver código da UI) e indica que o gráfico deve exibir apenas uma linha. Qualquer outra opção neste mesmo menu acarreta na exibição de duas linhas (uma para cada linha de pesquisa selecionada).

Um detalhe importante: repare o dataframe está sendo utilizado no ifelse… Não é o all_data, que contém todos os dados. É o lineplot_1_data. Aquele dataframe com os dados já processados para o gráfico com análise de dados anuais das linhas de pesquisa no Brasil.

1
2
3
4


line_data <- reactive({ 
 line_data <- if (input$input_research_2 == "Nenhum") lineplot_1_data[lineplot_1_data$research_name == input$input_research_1,] 
 else lineplot_1_data[lineplot_1_data$research_name == input$input_research_1 | lineplot_1_data$research_name == input$input_research_2,] 
})

Por fim, as variáveis output apresentadas na sequência vão receber o conteúdo de renderPlot, que são os gráficos para cada situação.

1- Mapa dos Programas de Pós-Graduação em Computação do Brasil

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


 output$map <- renderPlot({ 
 validate(
 need(nrow(map_data()) != 0, 'Para esta(s) universidade(s) não há o selecionado tema de pesquisa!'),
 need(map_shapes(), 'Selecione um estado válido.')
 )
 
 ggplot() + 
 geom_polygon(data = map_shapes(), aes(x = long, y = lat, group = group), fill = "#3d3d3d", color = "black", size = 0.15) +
 geom_point(data = map_data()[!duplicated(map_data()$code),], aes(x = longitude, y = latitude, color = as.factor(grade), size = 10, shape = graduation_level)) + 
 scale_color_manual(name = "Conceito", breaks = mybreaks, values=c("red", "orange", "yellow", "darkgreen", "green")) +
 scale_shape_discrete(name = "Nível do Programa") +
 coord_map() + 
 guides(colour = guide_legend(override.aes = list(size = 5)), shape = guide_legend(override.aes = list(size = 5, color = "white")), size = FALSE) +
 ggtitle("Programas de Pós-Graduação em Computação") +
 geom_text_repel(data = map_data()[!duplicated(map_data()$code),], aes(x = longitude, y = latitude, label = code), hjust = 0, nudge_x = 2, direction = "y", color = "#cccccc") +
 map_labs + geral_1_theme + theme( panel.grid.minor.y = element_line(size =.1, color = "grey"),
 panel.grid.minor.x = element_line(size =.1, color = "grey"),
 panel.grid.major.y = element_line(size =.1, color = "grey"),
 panel.grid.major.x = element_line(size =.1, color = "grey"),
 legend.key = element_rect(color = "black", fill = "black"))
 }, bg = "transparent", execOnResize = TRUE)

A função validate serve para validar determinadas variáveis. No nosso caso, verificamos se map_data, o dataframe com os dados processados anteriormente no server, possui registros. Se não possuir, o app vai exibir a mensagem ‘Para esta(s) universidade(s) não há o selecionado tema de pesquisa!’. Também é verificado se map_shapes foi atribuido corretamente, caso contrário a mensagem ‘Selecione um estado válido.’ é exibida.

Por fim, decidi utilizar o ggplot para gerar o mapa. As formas do polígono do mapa (shape) estão em map_shape na função geom_polygon, com latitude na coordenada X, longitude na coordenada Y, variável de agrupamento dos polígonos na coluna group, fundo do mapa na cor cinza (fill) e polígonos de cor preta (color). Para plotar os pontos, foi necessário diferenciar os programas pela cor e pela forma (shape).

Em geom_point foi utilizado o dataframe com os dados dos programas map_data(), utilizando-se um único registro por universidade (!duplicated()), com a posição de cada ponto definida pela latitude e longitude em X e Y, cor do ponto de acordo com a nota da CAPES (de 3 até 7) em color e o formato do ponto (shape)de acordo com o nível do programa (se mestrado profissional, acadêmico, doutorado, ou ambos mestrado e doutorado).

scale_color_manual foi utilizado para definir manualmente as cores utilizadas, que representam a nota da CAPES dos programas. Escolhi por cores bem claras para constrastar com o tema dark.

scale_shape_discrete foi usado para dar o nome da legenda do shape, que vai representar o nível do programa.

coord_map aplica a projeção de mercator no mapa, deixando ele visualmente proporcional.

guides garante que legendas para shape e color serão usadas, e não para size, além de customizações específicas para cada legenda.

ggtitle é o título do mapa.

geom_text_repel serve para plotar textos no gráfico, com uma certa distância do ponto onde seria originalmente desenhado. O texto no nosso caso será a sigla da universidade onde existem programas de pós em computação. Deixo como exercício descobrirem a lógica deste elemento :P

map_labs + geral_1_theme são características do tema dark para os gráficos. Esses temas definimos no início deste tutorial.

E theme foi utilizado para aplicar propriedades específicas deste gráfico.

bg = “transparent”, execOnResize = TRUE são argumentos do renderPlot que permitem gerar novamente o gráfico ao redimensionar a tela e torna o background da figura transparente (se removermos, aparecerá um fundo branco misterioso sempre que redimensionamos o plot).

2- Gráfico de barras com o número de Programas de Pós em Computação por estado.

1
2
3
4
5
6
7


 output$bar_1 <- renderPlot({ 
 ggplot(data = barplot_1_data, aes(x = state_code, y = id)) +
 geom_bar(stat = "identity", fill = "black", color = "#E4F00A" ) + 
 geom_text(data = barplot_1_data, aes(label = id), vjust = 1.6, color = "white", size = 6) +
 scale_y_continuous(breaks = seq(0, max(barplot_1_data$id), 2)) +
 barplot_1_labs + geral_1_theme + theme(axis.text.y = element_blank(), axis.ticks.y = element_blank())
 })

Vale destacar o uso do geom_bar para gerar gráfico de barras e o uso do scale_y_continuous para definir que a escala Y seja sempre uma sequência entre 0 e o estado com o maior número de programas, somado de 2 em 2. geom_text vai exibir na barra o número de programas daquele estado. O restante é semelhante ao gráfico do mapa.

3- Gráfico de barras com o número de Programas de Pós em Computação por linha de pesquisa (apenas tópicos de pesquisa com mais de 10 Programas de Pós).

1
2
3
4
5
6
7
8


 output$bar_2 <- renderPlot({ 
 ggplot(data = barplot_2_data, aes(x = research_name, y = id)) +
 geom_bar(stat = 'identity', fill = "black", color = "#22FF00") +
 geom_text(data = barplot_2_data, aes(label = id), hjust = 1.2, color = "white", size = 5) +
 scale_y_continuous(breaks = seq(0, max(barplot_2_data$id), 5)) +
 coord_flip() +
 barplot_2_labs + geral_1_theme + theme(axis.title.y = element_blank(), axis.text.x = element_blank(), axis.ticks.x = element_blank())
 })

Vale destacar novamente o scale_y_continuous para definir que a escala Y seja sempre uma sequência entre 0 e o estado com o maior número de programas, somado de 5 em 5. coord_flip() inverte as coordenadas X e Y. O restante já foi abordado.

4- Gráfico de linhas com o número de Programas de Pós em Computação por linha de pesquisa por ano.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 output$line_1 <- renderPlot({ 
 ggplot(data = line_data(), aes(x = year, y = cumsum, group = research_name)) +
 geom_line(aes(color = research_name)) +
 scale_color_manual(values = c("#E4F00A", "#22FF00")) +
 guides(colour = FALSE) +
 scale_x_continuous(expand = c(0, 0), limits = c(1965, 2030), breaks = seq(min(line_data()$year), max(line_data()$year), 2)) +
 lineplot_1_labs + geral_1_theme + theme(panel.grid.major = element_line(color = "#666666")) +
 geom_dl(aes(label = str_wrap(research_name, 30), color = research_name), method = list(cex = 1, dl.trans(x = x + .3), "last.qp")) 
 })
}

Foi usado o geom_line para gerar o gráfico de linhas. O scale_x_continuous foi usado para definir que a escala X seja sempre uma sequência entre o menor e o maior ano, somados de 2 em 2, com limites em 1965 e 2030. geom_dl() foi utilizado para plotar o nome da linha de pesquisa no último ponto na coordanada X, no final da linha.

E com isso, concluímos o lado server da nossa aplicação shiny !! :-)

Bora rodar a aplicação então !!

Execução do app na própria máquina (localmente);

Agora vamos estruturar os diretórios e arquivos da nossa aplicação no seguinte formato (se você clonou o projeto do github, a estrutura de diretório deve estar igual):

shinyapp (diretório do nosso app) contendo os seguintes arquivos:

+ server.R (server da aplicação)

+ ui.R (interface da aplicação)

+ data (diretório com o seguinte arquivo):

- all_data.RData (ambiente com dados e pacotes, gerado pelo get_data.R)

+ css (diretório com o seguinte arquivo);

- styles.css (customização de alguns elementos do shiny para o tema dark)

Não vamos incluir o arquivo que gerou os temas e dataframes a partir dos csvs, pois esse processamento só foi necessário uma vez, com o objetivo de gerar o arquivo all_data.RData com os nossos dados e pacotes. all_data.RData sim será incluído, e está no diretório data.

Para rodar o app, basta abrir o RStudio no diretório do app, carregar o pacote shiny e executar o seguinte comando:

1

runApp()

Se foi exibida uma tela com um mapa, semelhante a primeira figura do mapa deste tutorial, parabéns !! Este é o app que vocês desenvolveram comigo em pleno funcionamento !! Façam alguns testes com os inputs para verificar se está tudo ok ou se não há bugs :-).

Bom pessoal, agora o último passo… colocar o nosso app online com o shinyapps.io.

Publicando o app no shinyapps.io

É necessário criar uma conta no shinyapps.io. Vocês podem criar uma conta gratuitamente com um email e senha ou utilizar contas existentes do Google ou do Github.

O shinyapps vai solicitar um nome para a conta, que também será o domínio do app. Algumas restrições para o nome do domínio/conta: deve ter entre 4 e 63 caracteres, podendo ser letras, números e o símbolo - . O nome da conta não pode começar com números ou o símbolo -, e não podem terminar com o símbolo -.

Feito isso, vamos agora instalar o pacote rsconnect install.packages(“rsconnect”).

Agora precisamos fornecer a autorização para o pacote rsconnect fazer o deploy de nossos apps. Para isso:

Na página inicial do shinyapps.io, cliquem no botão superior direito referente à conta e cliquem em tokens.
Cliquem no botão show. A aplicação vai apresentar o comando que vocês precisam executar localmente no RStudio/R para habilitar o deploy dos apps com o rsconnect. Cliquem em Copy to clipboard e colem o comando no RStudio e executem. O comando deve ser semelhante ao código abaixo.

1
2
3


rsconnect::setAccountInfo(name='NOME-DA-MINHA-CONTA',
			 token='MEU-TOKEN-SUPER-HIPER-MEGA-SECRETO',
			 secret='SEGREDO-MAIS-SECRETO-DE-TODOS')

Se aparecer alguma mensagem de erro como:

1
2
3


Error: HTTP 401
GET https://api.shinyapps.io/v1/users/current/
bad signature

É porque o token ou o secret não foram copiados da forma correta.

Copiem manualmente o token e o secret, caso dê alguma mensagem de erro.

Se tudo ocorrer da forma prevista, não será exibido nenhum erro ou mensagem.

Se tudo funcionou, basta fazer o Deploy da aplicação. Tão simples como os comandos abaixo:

1
2


library(rsconnect)
deployApp()

O navegador padrão da sua máquina será aberto exibindo a aplicação online funcionando bonitinho :-). Deve ser semelhante com a imagem abaixo.

Se surgir algum erro estranho, é provável que a pasta não tenha as permissões adequadas. Para isso, use o comando abaixo no terminal do ubuntu

1

chmod -R 700 caminho/completo/do/diretório/com/o/app

O comando acima fornece permissão total para o usuário local no diretório indicado e subdiretórios.

É possível ter um controle do serviço responsável pelo app no shinyapps.io. Algumas das possibilidades:

É possível ter uma visão geral do app, como tempo online, acessos, datas de criação, atualização, tamanho da aplicação e outros.
Também é permitido analisar métricas computacionais da aplicação, como uso de memória, CPU, uso de rede e conexões simultâneas.
Na versão paga, é possível customizar a URL.
É possível ter acesso aos logs do app, sendo simples o processo de checar se ocorreram erros ao fazer o Deploy ou em runtime (tempo de execução).

Para mais detalhes, acessem https://shiny.rstudio.com/articles/shinyapps.html.

Considerações Finais

Bom pessoal, a ideia foi apresentar um passo a passo detalhado sobre o processo de desenvolvimento de um app na linguagem R com o shinyapps.io.

Abordei as fases de coleta dos dados, organização dos dados, persistência dos dados e pacotes em um arquivo, construção das lógicas da interface da aplicação e do servidor, um pouco de CSS para customizar o app e o processo de execução do app com shiny e submissão para o shinyapps.io de forma gratuita.

Espero que vocês tenham gostado do post e que ele tenha auxiliado vocês de alguma forma. Quaisquer dúvidas, podem deixar comentários logo abaixo :-)

Valeu !! Até o próximo post !!

Como posso hospedar meu app no shinyapps.io ?

Tue, 03 Mar 2020 23:55:00 -0300

Resumo

Saudações pessoal.

A ideia deste post é compartilhar com vocês um passo a passo de como hospedar o seu app desenvolvido com o R e o shiny no shinyapps.io. Por conveniência, vou ilustrar o tutorial com base no Sistema Operacional Ubuntu versão 19.10 (versão lançada em 17 Out. 2019).

Vocês precisam minimamente do RStudio e do R instalados antes de começar.

Tópicos

Criando uma conta no shinyapps.io;
RStudio e instalação de pacotes necessários;
Configuração do pacote rsconnect;
Criação e execução de um App de Exemplo;
Checando a aplicação no shinyapps.io;

Criando uma conta no shinyapps.io

A página acima é a inicial do shinyapps.io, onde você pode criar uma conta gratuitamente com um email e senha, ou você pode utilizar sua conta existente do Google ou do Github.

O shinyapps vai solicitar que você dê um nome para a sua conta, que também será o domínio do seu app (ou apps). Algumas restrições para o nome do domínio/conta: deve ter entre 4 e 63 caracteres, podendo ser letras, números e o símbolo - . O nome da conta não pode começar com números ou o símbolo -, e não podem terminar com o símbolo -.

RStudio e instalação de pacotes necessários;

Com a linguagem R e o RStudio instalados e devidamente configurados, vamos agora instalar o pacote rsconnect. A figura abaixo apresenta este processo.

Após o êxito da instalação, utilize o comando library(rsconnect) para carregar a biblioteca para o ambiente do RStudio.

Configurando o pacote rsconnect

Agora precisamos fornecer a autorização para o pacote rsconnect fazer o deploy de nossos apps. Para isso:

Na página inicial do shinyapps.io, clique no botão superior direito referente à conta e clique em tokens.
Clique no botão show. A aplicação vai apresentar o comando que você precisar executar localmente no seu RStudio/R para habilitar o deploy dos apps com o rsconnect. Clique em Copy to clipboard e cole o comando no seu RStudio e execute-o. O comando deve ser semelhante ao código abaixo.

1
2
3


rsconnect::setAccountInfo(name='NOME-DA-MINHA-CONTA',
			 token='MEU-TOKEN-SUPER-HIPER-MEGA-SECRETO',
			 secret='SEGREDO-MAIS-SECRETO-DE-TODOS')

Se aparecer alguma mensagem de erro como:

1
2
3


Error: HTTP 401
GET https://api.shinyapps.io/v1/users/current/
bad signature

É porque você não copiou o token da forma correta.

Se tudo ocorrer da forma prevista, não será exibido nenhum erro ou mensagem.

Criando um App de Exemplo

O código abaixo, um app de exemplo utilizando o shiny, foi retirado do próprio tutorial de instalação e configuração do shinyapps.io.

Crie os arquivos server.R e ui.R em um diretório qualquer e adicionem o seguinte conteúdo nestes arquivos.

server.R

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


library(shiny)
library(ggplot2)

function(input, output) {

 dataset <- reactive({
 diamonds[sample(nrow(diamonds), input$sampleSize),]
 })

 output$plot <- renderPlot({

 p <- ggplot(dataset(), aes_string(x=input$x, y=input$y)) + geom_point()

 if (input$color != 'None')
 p <- p + aes_string(color=input$color)

 facets <- paste(input$facet_row, '~', input$facet_col)
 if (facets != '. ~ .')
 p <- p + facet_grid(facets)

 if (input$jitter)
 p <- p + geom_jitter()
 if (input$smooth)
 p <- p + geom_smooth()

 print(p)

 }, height=700)

}

ui.R

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


library(shiny)
library(ggplot2)

dataset <- diamonds

fluidPage(

 titlePanel("Diamonds Explorer"),

 sidebarPanel(

 sliderInput('sampleSize', 'Sample Size', min=1, max=nrow(dataset),
 value=min(1000, nrow(dataset)), step=500, round=0),

 selectInput('x', 'X', names(dataset)),
 selectInput('y', 'Y', names(dataset), names(dataset)[[2]]),
 selectInput('color', 'Color', c('None', names(dataset))),

 checkboxInput('jitter', 'Jitter'),
 checkboxInput('smooth', 'Smooth'),

 selectInput('facet_row', 'Facet Row', c(None='.', names(dataset))),
 selectInput('facet_col', 'Facet Column', c(None='.', names(dataset)))
 ),

 mainPanel(
 plotOutput('plot')
 )
)

Certifique-se de que o shiny e o ggplot2 estão instalados.Para executar o app localmente e verificar se está tudo ok, use os comandos abaixo no RStudio. Você deve estar no mesmo diretório dos arquivos para o comando runApp() funcionar.

1
2


library(shiny)
runApp()

Se tudo funcionou, basta fazer o Deploy da aplicação. Tão simples como os comandos abaixo:

1
2


library(rsconnect)
deployApp()

O navegador padrão da sua máquina será aberto exibindo a aplicação online funcionando bonitinho :-). Deve ser semelhante com a imagem abaixo.

Em caso de erros...

Se surgir algum erro estranho, é provável que a pasta não tenha as permissões adequadas. Para isso, use o comando abaixo no terminal do ubuntu:

1

chmod 777 caminho/completo/do/diretório/com/o/app

Obviamente, isso não é correto de numerosas formas, já que qualquer usuário poderá ler, modificar e executar o conteúdo da pasta. Para fins de teste e confirmar se a aplicação está funcionando, é uma abordagem válida. Porém, o correto é definir permissões com restrições e para os usuários adequados. Este é assunto já foi amplamente discutido em diversos fóruns, basta pesquisar um pouco sobre chmod e permissões no Ubuntu. Uma alternativa menos perigosa (permissão total para o usuário local apenas, para o diretório indicado e subdiretórios):

1

chmod -R 700 caminho/completo/do/diretório/com/o/app

Checando a aplicação no shinyapps.io

É possível ter um nível de controle do serviço responsável pelo app no shinyapps.io. Algumas possibilidades:

É possível ter uma visão geral do app, no sentido de tempo online, acessos, datas de criação, atualização, tamanho da aplicação e outros.
Também é permitido analisar métricas computacionais da aplicação, como uso de memória, CPU, uso de rede e conexões simultâneas.
Na versão paga, é possível customizar a URL.
É possível ter fácil acesso aos logs da aplicação, sendo simples o processo de checar se ocorreu algum erro inesperado ao fazer o Deploy.

Para mais detalhes, acesse https://shiny.rstudio.com/articles/shinyapps.html.

Considerações Finais

Bom pessoal, a ideia era apresentar um passo a passo bem resumido e sucinto sobre o processo de Deploy de um app em R com o shinyapps.io. Boa parte do tutorial já é disponibilizado no site do shinyapps.io, porém nem todas as pessoas possuem facilidade com o idioma em inglês.

O próximo post será dedicado em apresentar a utilização do RStudio Server Edição Open Source para o seu app, com um exemplo funcional localmente na máquina.

Valeu e até o próximo post !!

Investigando Programas de Pós-Graduação em Computação no Brasil

Sat, 23 Nov 2019 08:00:00 -0300

Resumo

Saudações pessoal.

A ideia deste post é compartilhar com vocês alguns códigos e resultados que gerei ao coletar, processar e analisar os dados dos Programas de Pós-Graduação em Computação do Brasil.

Metodologia

As seguintes ferramentas e linguagens foram utilizadas para a produção das análises e geração dos gráficos:

R (R, 2019): Linguagem de Programação utilizada para Ciência de Dados. Em nosso caso, utilizada específicamente para as etapas de importação, organização, limpeza e visualização de dados;
RStudio (RStudio, 2019): Ambiente de Programação Integrado para Ciência de Dados, de forma geral. Em nosso caso, foi o ambiente utilizado para programar as soluções com a linguagem R;
Excel versão 2013 (Microsoft Excel, 2019): Programa de planilhas eletrônicas para armazenamento, manipulação e visualização de dados;
Github (Github, 2019): Plataforma com comunidades de desenvolvedores para descoberta, compartilhamento e criação de códigos e soluções de software com controle de versão. O Github foi utilizado para compartilhar o código utilizado neste tutorial para garantir a reprodutibilidade dos experimentos e isenção na realização das análises dos dados. Os códigos do projeto podem ser acessados neste link.

Sobre os dados coletados

Inicialmente, os dados dos Programas de Pós-Graduação em Computação foram extraídos de um arquivo em PDF, obtido neste link. Abaixo, é apresentada a forma que os dados estavam armazenados no PDF.

Eu tinha como objetivo gerar um vídeo e apresentar a metodologia de como se extrair dados de arquivos em PDF e gerar análises visuais destes dados, e como estudo de caso, os dados dos Programas de Computação.

Olhem só como ficou o script para realizar a extração do PDF para uma planilha excel… Para entender em detalhes a sequência lógica dos comandos e metodologia adotada, acessem meu Github -> Lubrum).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


if (!require(pdftools)) install.packages("pdftools", repos = "http://cran.us.r-project.org")
require(pdftools)

if (!require(dplyr)) install.packages("dplyr", repos = "http://cran.us.r-project.org")
require(dplyr)

if (!require(readr)) install.packages("readr", repos = "http://cran.us.r-project.org")
require(readr)

if (!require(stringi)) install.packages("stringi", repos = "http://cran.us.r-project.org")
require(stringi)

if (!require(stringr)) install.packages("stringr", repos = "http://cran.us.r-project.org")
require(stringr)

if (!require(xlsx)) install.packages("xlsx", repos = "http://cran.us.r-project.org")
require(xlsx)

file_pdf <- pdf_text("../pdf/Evaluation report - Computer science.pdf") %>% read_lines()
file_pdf <- file_pdf[1098:1190]
file_pdf <- file_pdf[-(grep("Coordenação", file_pdf))]
file_pdf <- file_pdf[-(grep("Diretoria", file_pdf))]
file_pdf <- file_pdf[-(24:28)] #Remove UFBA-UNIFACS-UEFS 
file_pdf <- file_pdf[-(34:35)] #Remove some useless info
file_pdf <- file_pdf[-(75:76)] #Remove some useless info
file_pdf <- file_pdf[-(44:46)] #Remove UFSCAR-Sorocaba
file_pdf <- file_pdf[-(47:49)] #Remove USP-ICMC
file_pdf[56]<-gsub("-CA-MP"," ",file_pdf[56]) 
file_pdf[57]<-gsub("-IN-MP"," ",file_pdf[57]) 
file_pdf <- strsplit(file_pdf, " ")
list_pdf <- 0
a <- 1

for(i in 1:length(file_pdf)){
 info_number <- length(file_pdf[[i]][!stri_isempty(file_pdf[[i]])])
 for(j in 1:info_number){
 list_pdf[a] <- str_trim(file_pdf[[i]][!stri_isempty(file_pdf[[i]])][j])
 a <- a + 1
 }
}

data_pdf <- data.frame(stringsAsFactors = FALSE, "Universidade" = 0, "Curso" = 0, "Nivel" = 0, "Nota" = 0)
a <- 1
for(i in seq(from = 2, to = length(list_pdf), by = 5)){
 data_pdf[a,1] <- list_pdf[i]
 data_pdf[a,2] <- list_pdf[i+1]
 data_pdf[a,3] <- list_pdf[i+2]
 data_pdf[a,4] <- list_pdf[i+3]
 a <- a + 1
}

write.xlsx(data_pdf, file = "../pdf/universities_before.xlsx", col.names = TRUE, row.names = TRUE, append = FALSE)

Porém, descobri posteriormente sobre a existência do site Sucupira. O Sucupira possui os dados de todos os Programas de Pós-Graduação do Brasil. Abaixo, uma foto da página dos Programas de Pós em Computação do Brasil. É possível clicar em cada um dos Programas e obter informações mais específicas de cada um.

Então decidi expandir o horizonte dos meus objetivos. Primeiro realizei a metodologia de extração dos dados do PDF, e na sequência realizei uma validação e integração com os dados da plataforma Sucupira. O processo de integração e validação foi manual, conferindo caso a caso, entre os dados do PDF e os do Sucupira. Dados faltantes foram inseridos na base de dados, que no momento eram planilhas eletrônicas (Excel).

Posteriormente, pensei: já que estou coletando dados dos Programas, por que não coletar informações sobre as linhas de pesquisa, áreas de concentração e temas de pesquisa? Então manualmente acessei o site de cada um dos Programas e gerei uma base de dados com essas informações, também armazenadas em planilhas eletrônicas (Excel).

O resultado deste processo pode ser conferido abaixo.

Também foram geradas outras planilhas com dados de área de concentração, linhas de pesquisa, temas de pesquisa e nível do Programa.

Resultados

Com os dados consolidados, foi necessário apenas importar, integrar e visualizar os mesmos. Segue abaixo parte do código para a integração dos dados (sem a importação das bibliotecas) e geração do primeiro mapa com algumas informações dos Programas :D.

O shapefile dos mapas pode ser obtido aqui e os dados das cidades e estados do Brasil no Github do kelvins.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91


# reading data from csv
universities_path <- "../csv/universities_after.xlsx"
cities_path <- "../csv/brazilian_cities.csv"
states_path <- "../csv/brazilian_states.csv"
research_names_path <- "../csv/research_names.xlsx"
university_research_path <- "../csv/university_research.xlsx"
graduation_level_path <- "../csv/graduation_level.xlsx"
course_name_path <- "../csv/course_name.xlsx"
concentration_area_path <- "../csv/concentration_area.xlsx"
university_concentration_area_path <- "../csv/university_concentration_area.xlsx"

universities <- read.xlsx(universities_path, sheetIndex = 1, encoding = "UTF-8")
cities <- read.csv(cities_path, sep = ",", stringsAsFactors = FALSE, encoding = "UTF-8")
states <- read.csv(states_path, sep = ",", stringsAsFactors = FALSE, encoding = "UTF-8")
research_names <- read.xlsx(research_names_path, sheetIndex = 1, encoding = "UTF-8")
university_research <- read.xlsx(university_research_path, sheetIndex = 1, encoding = "UTF-8")
graduation_level <- read.xlsx(graduation_level_path, sheetIndex = 1, encoding = "UTF-8")
course_name <- read.xlsx(course_name_path, sheetIndex = 1, encoding = "UTF-8")
concentration_area <- read.xlsx(concentration_area_path, sheetIndex = 1, encoding = "UTF-8")
university_concentration_area <- read.xlsx(university_concentration_area_path, sheetIndex = 1, encoding = "UTF-8")

# reading data from shapefile
shape_brazil_path <- "../shapefile/Brazil.shp"
shape_brazil <- readOGR(shape_brazil_path, "Brazil", encoding = "latin1")

# joining data into one dataframe
all_data <- universities %>% left_join(cities, by = c("city_id" = "ibge_code"))
all_data <- all_data %>% left_join(states, by = c("state_id" = "state_id"))
all_data <- all_data %>% left_join(university_research, by = c("id" = "university_id"))
all_data <- all_data %>% left_join(research_names, by = c("research_id" = "id"))
all_data <- all_data %>% left_join(graduation_level, by = c("level" = "id"))
all_data <- all_data %>% left_join(course_name, by = c("course" = "id"))
all_data <- all_data %>% left_join(university_concentration_area, by = c("id" = "university_id"))
all_data <- all_data %>% left_join(concentration_area, by = c("concentration_area_id" = "id"))

# cleaning and preparing data
all_data <- all_data[,-9]
all_data <- all_data[,-14]
all_data <- all_data[,-16]
all_data <- all_data[,-19]
all_data$latitude <- as.numeric(as.character(all_data$latitude))
all_data$longitude <- as.numeric(as.character(all_data$longitude))
all_data$grade <- as.numeric(as.character(all_data$grade))

# possible values for CAPES concept 
mybreaks <- as.numeric(c(3, 4, 5, 6, 7))

# black theme
theme <- theme(axis.text = element_text(size = 16),
 plot.caption = element_text(size = 12, face = "bold", color = "white"),
 axis.title = element_text(size = 18, face = "bold", color = "white"),
 legend.title = element_text(size = 18, color = "white"), 
 legend.text = element_text(size = 14, color = "white"),
 legend.key.width = unit(0.4, "cm"),
 legend.position = c(.95, .25),
 legend.key.size = unit(0.8, "cm"),
 legend.box.background = element_rect(color = "white", size = 0.5),
 legend.justification = c("right", "top"),
 legend.box.just = "right",
 legend.margin = margin(6, 6, 6, 6)
 text = element_text(color = "white"), 
 legend.background = element_rect(fill = "black"),
 panel.background = element_rect(fill = "black"),
 plot.title = element_text(size = 19, hjust = 0.5, color = "white"),
 panel.grid.minor.y = element_line(size =.1, color = "grey"),
 panel.grid.minor.x = element_line(size =.1, color = "grey"),
 panel.grid.major.y = element_line(size =.1, color = "grey"),
 panel.grid.major.x = element_line(size =.1, color = "grey"),
 plot.background = element_rect(fill = "black"),
 axis.text.x = element_text(color = "white"),
 axis.text.y = element_text(color = "white"),
 axis.title.x = element_text(color = "white"),
 axis.title.y = element_text(color = "white"))


labs <- labs(x = "Longitude", y = "Latitude", caption = "Fonte: Programas de Pós-Graduação em Computação - Plataforma Sucupira.") 


all_data_2 <- subset(all_data, all_data$research_name == "Inteligencia Artificial")

ggplot() + 
geom_polygon(data = shape_brazil, aes(x = long, y = lat, group = group), fill = "grey", size = 0.1, color = "black") +
geom_point(data = all_data_2[!duplicated(all_data_2$id),], aes(x = longitude, y = latitude, size = as.factor(grade), color = as.factor(grade), alpha = I(2/grade))) +
scale_colour_manual(name = "Conceito", values = c("red","blue","dark green","green","yellow")) +
scale_size_manual(name = "Conceito", values = mybreaks) +
geom_text_repel(data = all_data_2[all_data_2$longitude > -45 & !duplicated(all_data_2$code),], aes(x = longitude, y = latitude, label = code, size = as.factor(5)), hjust = 0, nudge_x = -34 - subset(all_data_2, all_data_2$longitude > -45 & !duplicated(all_data_2$code))$longitude, direction = "y", show.legend = FALSE, color = "white", segment.color = "white", segment.size = 0.15) +
geom_text_repel(data = all_data_2[all_data_2$longitude <= -45 & !duplicated(all_data_2$code),], aes(x = longitude, y = latitude, label = code, size = as.factor(5)), hjust = 1, nudge_x = -72 - subset(all_data_2, all_data_2$longitude <= -45 & !duplicated(all_data_2$code))$longitude, direction = "y", show.legend = FALSE, color = "white", segment.color = "white", segment.size = 0.15) + 
coord_map() + 
guides() +
ggtitle("Programas de Pós-Graduação com Pesquisa em Inteligência Artificial") +
labs + theme

Também é possível gerar gifs como a apresentada abaixo, mostrando o surgimento dos Programas com o passar dos anos no Brasil.

Próximos passos

No momento é possível fazer os seguintes filtros por Programa de Pós-Graduação em Computação:

Programas por conceito da CAPES;
Programas por região geográfica (cidade ou estado);
Programas por nível de Pós (Mestrado, Doutorado ou Mestrado Profissional);
Programas por área de concentração;
Programas por tema de pesquisa;
Programas por ano ou período de criação;

A ideia para a sequência do projeto, além de compartilhar estes dados e informações, é criar uma maneira de disponibilizar essas informações em uma solução online, com interface amigável com o usuário, para o mesmo selecionar os filtros e dados/informações de seu interesse. Uma ferramenta direcionada para graduados com interesse no ingresso na Pós-Graduação. Também há a possibilidade de agregar mais informações por Programa, como dados dos pesquisadores, alunos e respectivas publicações. Para esta última proposta, precisarei do auxílio da comunidade para esta etapa, pois são MUITOS dados para serem coletados, integrados, e mantidos. O projeto inteiro está em meu Github, e quem tiver interesse em colaborar com o projeto, é só entrar em contato!! :-)

Considerações Finais

Bom pessoal, então era isso.

Quis trazer para vocês um pouco de ideias, códigos e resultados, com base em um problema que enfrentei em um ponto da minha vida, e muitos meses depois vislumbrei essa possibilidade de solução. Compartilhei a ideia com vocês, agora é colocar a mão na massa e dar a sequência.

Para os interessados em contribuir, servirá como experiência prática com o R e tecnologias web, processamento e análise de dados, estatística, visualização de dados, um pouco de Git e talvez outras tecnologias não vislumbradas no momento. Também é possível agregar a participação de vocês neste projeto nos seus próprios portfólios pessoais, para apresentar no currículo ou em entrevistas de emprego. Enfim, muito bônus mas também respectivo ônus.

Obrigado e até o próximo post !!

Referências Bibliográficas

Github. Built for developers. Acesso em: 08 set. 2019.

Microsoft Excel. Excel. Acesso em: 08 set. 2019.

R. The R Project for Statistical Computing. Acesso em: 08 set. 2019.

RStudio. RStudio about. Acesso em: 23 nov. 2019.

O dia que utilizei a linguagem C em um jogo online

Fri, 27 Sep 2019 08:00:00 -0300

Resumo

Saudações pessoal.

Vou compartilhar com vocês algo inusitado que encontrei em meu HD externo enquanto eliminava e organizava meus arquivos dos tempos de faculdade, entre 2011 e 2015.

Durante a graduação, no tempo livre que eu tinha (que era escasso, já que eu tinha que viajar 2 horas e meia por dia para o campus em outra cidade), eu jogava Tibia (“você pode sair do tibia mas o tibia nunca sai de você… rsrs”).

Sobre o Jogo

Tibia é um jogo 2D desenvolvido pela CipSoft no estilo MMORPG (Massively Multiplayer Online Role-Playing Games), em que tem-se muitos jogadores online que interagem entre si ou com o ambiente do jogo em tempo-real. O jogo foi criado em 1997, na Alemanha, na linguagem C++.

O jogo se resume em criar um personagem de uma das quatro vocações (knight, paladin, sorcerer ou druid) e explorar o que o jogo oferece. Entenda explorar como o objetivo indivual de cada jogador para o Tibia, além do tipo de servidor onde o personagem foi criado (que pode ser PVP, non-PVP e Hardcore PVP). Em outras palavras, você pode jogar Tibia para colecionar itens raros, upar níveis, matar jogadores, dominar servidores ou aparecer em algum rank específico do jogo.

Algo que me perturbava...

Eu sempre joguei o Tibia com o objetivo de upar níveis e acessar novos desafios e lugares no jogo. Só que para isso, eu precisava upar níveis, e para fazer isso de forma eficiente, é necessário ter dinheiro no jogo. E para ter dinheiro, você precisa ir em lugares (ou cavs) que os monstros que você derrota carreguem itens valiosos. Eis então que percebi algo que faltava no jogo na época:

Como eu vou saber se, durante a minha caçada (hunt) de uma hora, eu obtive lucro ou prejuízo?

Ao derrotar os monstros, você pode coletar os itens que ele derruba (dropa), porém, não havia mecanismo simples no jogo que permitisse que soubessemos os valores dos itens no próprio jogo. Pior que isso, para saber se a hunt foi lucro ou prejuízo, era necessário sempre somar o preço individual de cada item e fazer uma estimativa do loot obtido. Porém esse processo era oneroso e desgastante.

Então surgiu uma ideia...

A Figura abaixo mostra uma foto do jogo atualmente, porém apenas com as funcionalidades (features) do jogo na época (2014~2015).

No centro da tela temos o personagem e o ambiente do jogo, na tela do lado direito temos funções e botões para configurações e manipulação de itens na mochila do personagem e na tela abaixo temos o chat do jogo.

O chat tem uma aba chamada Server Log que contém registros do que o personagem fez na sessão atual (porém este Log é limitado).

Uma função interessante, porém que nunca havia me despertado a atenção, é que sempre foi possível salvar este Log em um arquivo texto na própria máquina. Mas eu não entendia por que eu precisaria disso.

Até que lembrei das minhas aulas em linguagem C…

A Solução

Então eu criei um código simples em linguagem C para, por exemplo, estimar o heal (cura) médio do meu personagem em uma hunt específica que eu havia feito. Na época era impossível saber essa informação no próprio jogo.

A Figura abaixo mostra o conteúdo de um Server Log da época que eu jogava.

E abaixo, uma solução simples para estimar a cura média do personagem em uma hunt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


#include<stdio.h>
#include<stdlib.h>
#include<string.h>
int main(){
	FILE *file = fopen("serverlog.txt", "r");
	if( file == NULL ){
 		printf("Nao foi possivel abrir o arquivo!");
	}
	int heal_vector[10000];
	int j, heal, count = 0;
	float total_heals = 0.0, average;
	char name[20];
	while( fscanf( file, "%s", name ) != EOF ){
		if( !strcmp( name, "yourself" ) ){
			fscanf( file,"%*s %d", &heal );
			printf("%d \n", heal);
			heal_vector[count] = heal;
			count++;
		}
	}
	for( j = 0; j < count; j++ ){
		total_heals += heal_vector[j];
	}
	average = total_heals / count;
	printf("\n\nMedia de heal: %.2f hitpoints.", average);
	return 0;
}

Claro que este programa calcula algo muito básico, mas seria trivial pensar em uma solução para o cálculo do valor dos itens que caíram dos monstros na hunt.

Bastaria identificar a palavra inicial Loot por linha do Server Log, criar uma base de dados com o valor dos itens da hunt, identificar o nome de cada item dropado e converter para o valor em dinheiro do jogo.

Tempos depois eu descobri que já existiam ferramentas online como o Tibia Stats que, ao você copiar e colar o texto do Server Log, ela lhe trazia todas as informações e estatísticas que o jogo falhava em fornecer. A Figura abaixo apresenta a ferramenta em operação.

Hunting Session Analyzer

Em 2017, o jogo implementou os recursos de análise (analytics) em tempo real no proprio ambiente do jogo, chamado de Hunt Session Analyzer.

Com este recurso, é possível saber agora se a hunt é lucrativa, se você está tomando muitos danos, ou gastando muitos recursos na hunt, entre diversas outras estatísticas. A Figura abaixo mostra o Analyzer durante uma hunt (na 1° e 3° coluna da foto do jogo).

Considerações Finais

Bom pessoal, então era isso.

Queria trazer pra vocês essa solução boba que desenvolvi na época da graduação, mas que na época acabou me despertando muito mais interesse em computação, programação e algoritmos em geral, pois pensei e vi essas tecnologias na prática resolvendo um problema extremamente específico que eu tive.

Eu não teria nem ideia de como resolver se não fossem os conceitos de computação e programação que eu aprendi na universidade.

Obrigado e até o próximo post !!

Referências Bibliográficas

TIBIA. Latest News. Acesso em: 27 set. 2019.

TIBIA STATS. News. Acesso em: 27 set. 2019.

Como extrair dados de documentos em PDF com o R?

Sun, 22 Sep 2019 12:00:00 -0300

Resumo

Saudações pessoal. A ideia deste post é apresentar a metodologia e os resultados obtidos ao extrair e apresentar os dados de um documento em formato PDF, disponibilizado pelo CREFITO (Conselho Regional de Fisioterapia e Terapia Ocupacional). A apresentação dos dados foi realizada por meio de mapas, adquiridos no formato shapefile, produzidos com a linguagem R e bibliotecas auxiliares.

Obtenção dos dados

Os dados obtidos foram de um arquivo no formato PDF que informa, por município, o número de Consultórios, Empresas, Entidades Filantrópicas, Fisioterapeutas, Órgãos Públicos e Terapeutas Ocupacionais (CREFITO, 2019). O shapefile do mapa do Rio Grande do Sul (RS) foi obtido através do site da FEPAM (Fundação Estadual de Proteção Ambiental Henrique Luiz Roessler - RS) (FEPAM, 2019). Ainda, foram integrados os dados da estimativa populacional dos municípios do RS, presentes no Censo Demográfico disponível no portal SIDRA (Sistema de Recuperação Automática) do IBGE (Instituto Brasileiro de Geografia e Estatística) (IBGE, 2019).

Metodologia

As seguintes ferramentas e linguagens foram utilizadas para a extração e organização dos dados, realização das análises e geração dos gráficos:

Excel versão 2013 (MICROSOFT EXCEL, 2019): Programa de planilhas eletrônicas para armazenamento, manipulação e visualização de dados. No presente estudo, foi utilizado para armazenar as informações obtidas da SIDRA sobre a estimativa populacional dos municípios do RS;
Github (GITHUB, 2019): Plataforma com comunidades de desenvolvedores para descoberta, compartilhamento e criação de códigos e soluções de software com controle de versão. O Github foi utilizado para compartilhar o código utilizado em partes deste trabalho para garantir a reprodutibilidade dos experimentos e isenção na realização das análises dos dados. Os códigos deste trabalho, além da explicação técnica e detalhada do processo, podem ser acessados neste link.
R (R, 2019): Linguagem de Programação utilizada para Ciência de Dados. No presente estudo, o R, em conjunto com o ambiente do RStudio, foi utilizado específicamente para as etapas de extração, importação, organização, limpeza e visualização dos dados;
RStudio (RStudio, 2019): Ambiente de Desenvolvimento Integrado que oferece diversas facilidades para a programação na linguagem R.

Descrição e Análise dos Resultados

Os dados presentes no PDF estavam no seguinte formato:

Após a importação no ambiente do RStudio (através das funções pdf_text e read_lines do R), os dados ficaram no seguinte formato:

A dificuldade evidente é a de se extrair dados de um PDF que não possui um padrão no formato da tabela. Cada município pode ter ou não, por exemplo, consultórios de fisioterapia, e na ausência desta informação, nada era apresentado na tabela. Outro problema que ficou evidente ao realizar a integração com os dados do shapefile foi a nomeação diferenciada (e incorreta) de algumas cidades. A última página também possuia um formato distinto do restante do PDF, portanto foi necessário dar um tratamento especial para a última página do PDF. Por fim, mesmo com estratégias definidas para uma leitura algoritmica dos dados, as informações de algumas cidades não eram lidas da forma correta. Foi necessário realizar uma correção manual destes registros, através de comparações visuais com o arquivo PDF original. O formato final dos dados no RStudio é apresentado abaixo.

Após uma série de tratamentos nos dados, envolvendo manipulação de strings, uso de estruturas condicionais e de repetição, manipulação de dataframes, integração de dados com shapefiles e conversão do formatos dos dados, foi possível gerar dois mapas sobre:

1 - Número de fisioterapeutas nos municípios do Rio Grande do Sul.

2 - Taxa população/fisioterapeuta nos municípios do Rio Grande do Sul.

É possível também gerar outras informações envolvendo o número de terapeutas ocupacionais, consultórios, entidades filantrópicas, órgaõs públicos e empresas, além da relação destas variáveis com o número de fisioterapeutas.

Considerações Finais

A ideia do post foi apresentar de forma sucinta um exemplo objetivo do processo de extração de informações de arquivos em formato PDF. Infelizmente, não foi possível realizar todo o processo de forma automática e, ao mesmo tempo, reutilizável para outros casos, porém é um exercício válido pelo processo de aprendizagem e extração de informação.

Se compararmos a forma de apresentação dos dados nas tabelas do PDF e a forma apresentada nos mapas, podemos dizer que conseguimos comprimir um volume razoável de informações em um mapa e apresentá-las de forma mais eficiente. Qualquer pessoa pode comparar o dado de um município específico com a região ou outros municípios de forma praticamente instantânea com um mapa, agora imaginem fazer isso no arquivo PDF? (Ctrl-F pra lá e pra cá…). Para melhores resultados, é possível gerar mapas interativos, de forma que o usuário possa analisar o dado de cada município de forma mais individualizada.

Pessoal, então era isso. Abaixo cito as referências utilizadas para estas análises. Obrigado e até o próximo post !!

Referências Bibliográficas

FEPAM. Biblioteca Digital. Acesso em: 23 set. 2019.

GITHUB. Built for developers. Acesso em: 17 set. 2019.

INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA. Censo Demográfico. Acesso em: 23 set. 2019.

MICROSOFT EXCEL. Excel. Acesso em: 17 set. 2019.

R. The R Project for Statistical Computing. Acesso em: 17 set. 2019.

RStudio. Why RStudio? Acesso em: 23 set. 2019.

Como fazer uma Revisão da Literatura?

Tue, 17 Sep 2019 07:00:00 -0300

Resumo

Saudações pessoal. A ideia deste post é apresentar a metodologia e os resultados obtidos ao explorar dados sobre publicações científicas recentes (2008-2018) sobre a utilização de Business Intelligence (BI) e Data Warehouse (DW) no setor agrário, em nível internacional. Este trabalho foi previamente publicado em um artigo completo na revista Journal of Agricultural Science (BRUM; CAMARGO; LAMPERT, 2019).

Obtenção dos dados

Os dados obtidos foram de artigos que tratam o tema de BI e DW através de bases de dados da área do conhecimento de Ciências Agrárias do portal de periódicos da CAPES (Coordenação de Aperfeiçoamento de Pessoal de Ensino Superior).

Metodologia

As seguintes ferramentas e linguagens foram utilizadas para a coleta dos dados, realização das análises e geração dos gráficos:

R (R, 2019): Linguagem de Programação utilizada para Ciência de Dados. Em nosso caso, utilizada específicamente para as etapas de importação, organização, limpeza e visualização de dados;
Excel versão 2013 (MICROSOFT EXCEL, 2019): Programa de planilhas eletrônicas para armazenamento, manipulação e visualização de dados. No nosso caso, foi utilizado para armazenar as informações obtidas da internet sobre os artigos, autores e revistas mais relevantes sobre o tema, para posterior utilização nas análises;
Github (GITHUB, 2019): Plataforma com comunidades de desenvolvedores para descoberta, compartilhamento e criação de códigos e soluções de software com controle de versão. O Github foi utilizado para compartilhar o código utilizado em partes deste trabalho para garantir a reprodutibilidade dos experimentos e isenção na realização das análises dos dados. Os códigos do projeto podem ser acessados neste link.
Mendeley (ELSEVIER, 2019): Gerenciador bibliográfico e rede social acadêmica que permite organizar as pesquisas realizadas, colaborar com os pares e realizar descoberta de artigos recentes, entre diversas outras funções. O Mendeley online, a versão Desktop e o plugin para browsers foram utilizados para realizar o download dos metadados dos artigos nos repositórios de dados científicos.
WordArt (WORDART, 2019): Ferramenta de geração de nuvens de palavras online, foi utilizada para geração de um dos gráficos necessários.

O método utilizado para desenvolver esta pesquisa foi o seguinte:

(1) Coleta de dados

a. O Mendeley foi utilizado para buscar informações nas seguintes bases de dados: AGRIS, BDPA, EBSCO, Google Scholar, ProQuest, SciELO, ScienceDirect, SCOPUS, SpringerLink, Taylor & Francis Online, Web of Science and Wiley Online Library.

b. As seguintes restrições foram aplicadas para filtragem dos artigos: (i) artigos publicados em revistas e conferências; (ii) artigos publicados em determinado escopo temporal (2008-2018); (iii) poucas palavras-chave utilizadas e uma única busca em cada base de dados; (iv) bases de dados e mecanismos de busca disponíveis no site da CAPES Periódicos com acesso gratuito aos artigos de Ciências Agrárias; (v) alinhamento dos artigos ao tema de acordo com a percepção do próprio autor.

c. Foi utilizada a seguinte combinação de palavras-chave para a busca dos artigos: (“business intelligence” OR “inteligencia de negocio” OR “data warehouse” OR “data warehousing” OR “armazem de dados” OR “almacen de datos”) AND (agricultur* OR livestock OR pecuaria OR ganaderia OR agribusiness OR agronegocio OR agroindustria). A busca foi realizada nos campos título, resumo e palavra-chave, simultaneamente, nos casos em que tal operação fosse permitida.

(2) Armazenamento dos dados: os dados e metadados dos artigos, que fora obtidos com o Mendeley, foram armazenados manualmente em planilhas do Excel para posterior realização de análises. Cabe ressaltar que foram salvas apenas as informações de artigos a partir da quarta filtragem (análise de citações e ano de publicação).

(3) Organização dos dados: foram realizados cinco níveis de filtragem nos artigos obtidos. Para cada nível de filtragem foi criada uma nova aba na planilha com as informações filtradas (as informações específicas dos artigos foram salvas a partir da quarta filtragem).

(4) Análise dos dados: em casos simples, o próprio Excel foi utilizado para geração de gráficos, e em casos onde era necessário gerar gráficos mais sofisticados, foi utilizada a ferramenta RStudio conjuntamente com a linguagem R.

Descrição e Análise dos Resultados

Filtragem de Artigos

Na Figura abaixo é apresentada a quantidade de publicações encontradas por base de dados com as palavras-chave definidas anteriormente sem a aplicação de filtros.

No total, foram encontrados 1435 trabalhos. No Google Scholar, foram encontrados 20200 resultados com as palavras-chave definidas, mas a ferramenta apresenta apenas as primeiras 100 páginas com resultados. Portanto, somente os trabalhos das primeiras 10 páginas foram importados, ordenados por relevância.

1° filtragem:

Na sequência foram eliminados os artigos redundantes utilizando uma funcionalidade do próprio Mendeley. Neste processo foram removidos 166 trabalhos (11.57% do total), restando 1269 publicações. A Figura abaixo apresenta a quantidade de trabalhos resultantes por ano de publicação.

2° filtragem:

A próxima filtragem realizada foi a remoção de trabalhos não relacionados com o tema de pesquisa, evidenciada através da leitura dos títulos e resumos dos trabalhos. Os trabalhos sem resumo disponível foram eliminados das análises. Tal filtragem foi a mais significativa, com 1112 trabalhos eliminados (87.63% dos trabalhos restantes eliminados), restando 157 trabalhos.

3° filtragem:

Trabalhos em idiomas diferentes do inglês, português e espanhol, ou indisponíveis na versão gratuita, ou duplicados (através de detecção manual) foram eliminados das análises. Neste processo foram removidos 51 trabalhos (32.48% dos restantes, restando 106 trabalhos).

4° filtragem:

A próxima filtragem foi a análise das citações e do ano de publicação dos artigos. O Google Scholar foi utilizado para a contagem das citações dos trabalhos. Artigos com pelo menos uma citação avançam para a próxima filtragem. Neste processo foram removidos 25 trabalhos, porém 8 destes foram reinseridos por serem muito recentes (2017 e 2018), não tendo tido ainda muitas oportunidades de serem citados. Portanto, 17 trabalhos foram removidos (16.04% dos restantes, restando 89 trabalhos).

5° filtragem:

O último filtro aplicado foi a leitura completa dos 89 artigos restantes. 60 artigos foram eliminados da análise (67.42% dos restantes). Portanto, 29 artigos serão analisados em detalhes na sequência.

Análise dos Artigos Selecionados

Os seguintes artigos foram selecionados para a análise de citações, autores, referências bibliográficas e análise temporal (em resumo, uma análise bibliométrica, que pode ser conferida na íntegra aqui).

{% include /revisao-literatura/articles_table.html %}

A Figura abaixo, em ordem decrescente, apresenta o número de citações de cada um dos artigos selecionados, assim como o acumulado de citações destes trabalhos.

É importante observar que 13 artigos (45% do total) concentram 89% do total acumulado de citações aos 29 trabalhos selecionados.

No gráfico abaixo é apresentado o número de artigos e o acumulado de citações por ano.

Observa-se que artigos mais recentes possuem menos citações que trabalhos mais antigos. Tal comportamento já era esperado, já que trabalhos mais antigos tiveram mais tempo e oportunidades de serem citados do que os trabalhos mais recentes.

Na figura abaixo, é apresentada a quantidade de trabalhos publicados por autor. Foram considerados apenas autores que publicaram no mínimo dois artigos.

Na Figura abaixo, desenvolvida com a linguagem R, é apresentada a rede de colaboração entre os autores dos 29 artigos mais relevantes selecionados. A cor representa o país de filiação do primeiro autor, os nós representam os autores, as arestas representam uma publicação conjunta dos autores representados pelos nós conectados e o tamanho do nó representa a quantidade de colaborações do autor em questão.

É possível observar o destaque da França e da Índia em publicações sobre BI e DW aplicados no setor agrário de uma forma geral. Também observa-se uma forte rede de colaboração em torno dos autores Bimonte, Miralles, Vernier e Molla, todos de instituições da França. As publicações da Índia e demais paises aparentemente possuem menos colaborações com instituições de outros paises. Claro que uma análise mais aprofundada, incluindo uma amostra maior de artigos, é necessária para revelar tendências e possíveis considerações sobre este fenômeno.

Análise das Referências Bibliográficas dos Artigos Selecionados

A Figura abaixo apresenta a distribuição temporal dos trabalhos citados nas referências bibliográficas dos artigos selecionados. Não foram verificadas as possíveis repetições de referências entre os trabalhos ou referências que não eram trabalhos científicos.

É possível verificar uma grande concentração de publicações entre os anos 2000 e 2010. Também verifica-se um número muito pequeno de citações em trabalhos publicados antes de 1995.

A Figura abaixo, desenvolvida com a linguagem R, apresenta a relação entre a quantidade de citações de cada artigo selecionado e o número de citações aos autores destes mesmos artigos nas referências bibliográficas (os mais citados).

Para exemplificar a informação da coordenada X, segue um exemplo abaixo:

O artigo A tem os autores 1, 2 e 3 e o artigo B tem os autores 4, 5 e 6.
O artigo A possui referências aos seguintes grupos de autores: {1, 2, 5}, {3}, {1, 2} e {1, 5}.
O artigo B possui referências aos seguintes grupos de autores: {4, 5}, {3, 4} e {1, 6}.
O autor mais citado do artigo A tem 4 citações nas referências dos artigos A e B (autor 1 é mais citado).
O autor mais citado do artigo B tem 3 citações nas referências dos artigos A e B (autor 5 é mais citado).

Foi utilizado o Princípio de Pareto, ou regra do 80/20, para definir as retas que separam os grupos de citações dos artigos e dos autores das referências. O Princípio de Pareto diz que aproximadamente 80% dos efeitos vêm de 20% das causas. Neste caso, optou-se por destacar as causas (ou variáveis) 20% mais relevantes. O gráfico acima, portanto, apresenta os grupos de artigos que possuem mais citações, os que possuem mais citações aos autores nas referências, os que são mais relevantes em ambos os aspectos e os que possuem poucas ou nenhuma citação tanto aos artigos como aos autores nas referências.

A Figura abaixo, também desenvolvida com a linguagem R, apresenta a relação entre o número de artigos por revista/periódico e o número de citações a artigos destes periódicos nas referências bibliográficas dos trabalhos selecionados. Também foi destacado o fator de impacto de cada periódico através do tamanho de cada shape no gráfico.

Visualmente observa-se que a revista Computers and Eletronics in Agriculture possui não só uma maior quantidade de artigos sobre o tema como também um maior número de citações nas referências dos trabalhos selecionados. Já a Environmental Modelling and Software se destacou apenas nas referências, pois apenas um artigo do conjunto final selecionado era deste periódico (revista com maior fator de impacto das destacadas). A Ecological Informatics se destacou por ter dois trabalhos presentes no conjunto final selecionado. Os periódicos restantes foram agrupados no conjunto sem destaque relevante neste tipo de análise.

A Figura a seguir apresenta uma nuvem de palavras (Word Cloud) em que foram utilizadas as palavras-chave dos 29 artigos. A Figura foi gerada com o auxílio da ferramenta online WordArt.

Cabe destacar palavras como multidimensional e OLAP, extremamente relevantes no contexto de BI e que não foram incluídas no conjunto de termos de busca. Esta é uma sugestão de melhoria no processo de análise da literatura, em que podem ser ajustados os termos de busca com base nas palavras-chave dos artigos inicialmente selecionados.

A Figura abaixo apresenta um compilado das tecnologias que foram mencionadas ou aplicadas nos artigos selecionados.

É interessante observar que as tecnologias gratuitas e de código aberto tem maior predominância em comparação com soluções proprietárias nos trabalhos de BI e DW aplicados no setor agrário selecionados. É claro que tal afirmação é válida apenas para este caso, e não engloba, por exemplo, soluções desenvolvidas fora do ambiente acadêmico, como em setores governamentais ou empresas privadas.

Por fim, a última Figura apresenta as principais áreas de estudo dos artigos selecionados.

Observa-se uma predominância maior de soluções de BI e DW para análise de culturas, pecuária de corte, gerenciamento de pesticidas e análises da qualidade da água.

Considerações Finais

Bom pessoal, a ideia deste post foi apresentar de forma sucinta um exemplo objetivo de processo de revisão da literatura. Foi apresentada a forma de obtenção dos dados, orientação no uso das ferramentas necessárias, metodologia completa e apresentação e análise dos resultados. Outros resultados, trabalhos referenciados e as teorias que embasaram o estudo podem ser verificadas no link deste artigo. Abaixo cito as referências utilizadas para estas análises. Obrigado e até o próximo post !!

Referências Bibliográficas

BRUM, L. M. da L.; LAMPERT, V. do N.; CAMARGO, S. da S. Business intelligence and data warehouse in agrarian sector: a bibliometric study. Journal of Agricultural Science, Richmond Hill, v. 11, n. 2, p. 353-368, 2019. Acesso em: 17 set. 2019.

ELSEVIER. About Mendeley. Acesso em: Acesso em: 17 set. 2019.

GITHUB. Built for developers. Acesso em: 17 set. 2019.

MICROSOFT EXCEL. Excel. Acesso em: 17 set. 2019.

R. The R Project for Statistical Computing. Acesso em: 17 set. 2019.

WORDART. WordArt. Acesso em: 18 set. 2019.

Análise da Produção Leiteira Brasileira e Gaúcha - Parte 1

Tue, 10 Sep 2019 00:50:00 -0300

Resumo

Saudações pessoal. A ideia deste artigo é explorar os dados públicos sobre a produção leiteira Brasileira e Gaúcha disponibilizados pelo IBGE (Instituto Brasileiro de Geografia e Estatística) através do portal da SIDRA (Sistema IBGE de Recuperação Automática). Parte deste trabalho foi previamente publicado em um resumo expandido (BRUM; SILVA; LAMPERT, 2018).

Obtenção dos dados

Inicialmente serão obtidos os dados históricos da produção de leite no Brasil entre 1974 e 2017 da Pesquisa da Pecuária Municipal (PPM), na SIDRA (IBGE, 2019a), repositório com dados públicos brasileiros de setores como indústria, comércio, agricultura e pecuária. Não é evidenciado no site da SIDRA que a produção de leite é apenas de vaca, porém há um documento do IBGE que afirma que o valor de produção leiteira na PPM é apenas de vaca (IBGE, 2018c).

Na sequência, será obtida a quantidade de estabelecimentos rurais que produziram leite no Rio Grande do Sul e no Brasil, além de outras informações pertinentes associadas. Tais informações, como a do número de estabelecimentos rurais que produziram leite, estão disponíveis nos Censos Agropecuários brasileiros. Os censos agropecuários são executados no Brasil desde 1920, porém as informações disponíveis na SIDRA são dos anos/períodos de 1995, 2006 e 2017 (IBGE, 2019b).

Cabe mencionar que há diferenças entre os valores de produção leiteira da PPM e dos censos agropecuários, pois a metodologia de coleta dos dados entre as pesquisas é diferente. Há um artigo na internet que menciona essas diferenças (SCOT CONSULTORIA, 2018).

Metodologia

As seguintes ferramentas e linguagens foram utilizadas para a produção das análises e geração dos gráficos:

R (R, 2019): Linguagem de Programação utilizada para Ciência de Dados. Em nosso caso, utilizada específicamente para as etapas de importação, organização, limpeza e visualização de dados;
Jupyter (Jupyter, 2019): Ambiente de Programação Integrado para Ciência de Dados. Em nosso caso, é o ambiente utilizado para programar as soluções com o R;
Excel versão 2013 (Microsoft Excel, 2019): Programa de planilhas eletrônicas para armazenamento, manipulação e visualização de dados. Os dados são obtidos do IBGE no formato de planilha eletrônica e o software utilizado para manipulação destes dados é o Excel, que no nosso caso foi utilizado apenas para verificar o formato que os dados estão na planilha;
Github (Github, 2019): Plataforma com comunidades de desenvolvedores para descoberta, compartilhamento e criação de códigos e soluções de software com controle de versão. O Github foi utilizado para compartilhar o código utilizado neste tutorial para garantir a reprodutibilidade dos experimentos e isenção na realização das análises dos dados. Os códigos do projeto podem ser acessados neste link.

Descrição e Análise dos Resultados

Na Figura abaixo são comparadas as produções leiteiras do Brasil e do RS no período de 1974-2017, com o uso de dados da [PPM](https://sidra.ibge.gov.br/pesquisa/ppm/tabelas/brasil/2017) (IBGE, 2019a).

As duas linhas no gráfico representam um modelo de regressão linear em que foi utilizada a produção leiteira como variável dependente e o ano como variável independente para o Brasil e o RS. É possível observar que o Brasil e o RS possuem uma produção leiteira com tendência de crescimento aproximadamente linear. Foi possível observar que nas faixas de anos de 1974-1984 e 2008-2017 houve uma produção leiteira acima do esperado, enquanto que entre 1985 e 2007 ela foi abaixo do esperado. Também observa-se que, considerando todo o período em análise, houve uma redução na produção leiteira apenas no período 2014-2017 (mais recente). No caso do RS, observa-se padrões semelhantes ao do cenário nacional.

O RS foi o segundo estado com maior produção de leite no Brasil em 2017, conforme evidenciado na Gif abaixo, que apresenta o histórico de 1974 até 2017 da produção leiteira nos 10 estados com maior produção do Brasil, através dos dados da PPM (IBGE, 2019a).

Foi possível observar que o estado de Minas Gerais (MG) se manteve em primeiro no rank de produção leiteira em todo o histórico de 1974 até 2017. Também observa-se que os seis primeiros estados brasileiros no rank em 2017 foram responsáveis por aproximadamente 75% do leite produzido em 2017, representando aproximadamente 25.5 bilhões de litros. Também observa-se que destes seis estados, três são da região Sul (RS, SC e PR) e dois da região Sudeste (MG e SP) do Brasil.

Observada a produção leiteira no Brasil e em suas UF, é agora colocado em foco o número de estabelecimentos rurais que produziram leite, em nível nacional e municipal (apenas no estado do RS). Tais dados estão disponíveis nos Censos Agropecuários de 2006 e 2017 (IBGE, 2019b). As duas Figuras abaixo apresentam a variação absoluta e percentual dos estabelecimentos rurais que produziram leite entre 2006 e 2017 por faixa de área total no Brasil.

O NA (Not Available) nos gráficos apontam o somatório de produtores que não souberam informar a área total do estabelecimento rural. É possível observar uma distribuição aproximadamente normal nos dados que evidenciam um padrão de desistência dos produtores rurais da atividade leiteira no período 2006-2017 na primeira Figura. A afirmação anterior é válida para as faixas de áreas disponibilizadas pelo IBGE. Percebe-se uma maior desistência de produtores de leite com estabelecimentos com tamanhos nas faixas de 5 até 50 hectares. Apesar da redução dos estabelecimentos entre 0 e 5 hectares não representarem um valor significativo perante às de 5 até 50 hectares, se observada a segunda Figura, é evidenciado que, percentualmente, os produtores de estabelecimentos rurais de menores tamanhos têm abandonado mais a atividade leiteira do que os de estabelecimentos maiores. Ainda sim, um percentual significativo dos responsáveis pelos maiores estabelecimentos rurais estão desistindo da atividade leiteira, evidência visualizada na segunda Figura. Em resumo, observa-se uma redução no número de estabelecimentos que produzem leite em todas as faixas de área disponibilizadas, sendo que:

A redução absoluta mais significativa foi a das propriedades rurais com área entre 5 e 50 hectares.
As reduções percentuais mais significativas foram as de propriedades rurais com áreas entre 0 e 20 hectares e as de mais de 200 hectares.

Na Figura abaixo é análisada a variação de estabelecimentos rurais que produziram leite nos municípios do estado do RS entre 2006 e 2017. Tais dados também estão disponíveis nos Censos Agropecuários de 2006 e 2017 (IBGE, 2019b).

É possível observar a tendência geral de redução de estabelecimentos rurais produtores de leite apresentada no bloco anterior, só que nos municípios do RS. A redução foi percentualmente mais significativa na metade sul do RS. Há municípios no RS em que houve um crescimento percentual de estabelecimentos produtores de leite, porém, quando observados os valores absolutos da variação entre 2006 e 2017, temos o seguinte cenário:

Um aumento de 2553 estabelecimentos produtores de leite em 59 municípios do RS;
Uma redução de 77596 estabelecimentos produtores de leite em 438 municípios do RS;
No ano de 2006 haviam 204920 estabelecimentos produtores de leite e em 2017 este valor foi reduzido para 129877 estabelecimentos (redução de 36.62%);

Portanto, é possível verificar um cenário em que há uma forte tendência de abandono de produtores rurais da atividade leiteira na maioria dos municípios do RS e que o aumento de estabelecimentos em determinados municípios não representam uma quantidade significativa perante o cenário geral.

Na Figura abaixo é análisada a variação da produção leiteira nos municípios do estado do RS entre 2006 e 2017. Tais dados também estão disponíveis nos Censos Agropecuários de 2006 e 2017 (IBGE, 2019b).

De forma contrastante ao cenário anterior, é possível observar a tendência geral de aumento de produção de leite nos municípios do RS. O aumento foi percentualmente mais significativo na metade norte do RS, principalmente na mesorregião noroeste. Há municípios no RS em que houve uma redução percentual significativa da produção de leite, porém, quando observados os valores absolutos da variação entre 2006 e 2017, temos o seguinte cenário:

Um crescimento na produção de leite de 1.6 bilhões em 381 municípios do RS;
Uma redução na produção de leite de 0.06 bilhões em 116 municípios do RS;
No ano de 2006 foram produzidos 2.45 bilhões de litros de leite e em 2017 este valor aumentou para 3.99 bilhões de litros de leite (aumento de 62.86%);

Portanto, é possível verificar um cenário de aumento da produção leiteira na maioria dos municípios do RS e que a redução da produção leiteira em determinados municípios não representam uma quantidade significativa perante o cenário geral. Além disso, se combinada esta informação com a análise sobre a variação dos estabelecimentos rurais produtores de leite, observa-se que a produção de leite no RS aumentou em 62.86%, mesmo com a redução de 36.62% no número de estabelecimentos produtores de leite. Conclui-se, portanto, que tem ocorrido uma maior concentração da produção leiteira em um menor número de estabelecimentos rurais da atividade leiteira no estado do RS, observado o período 2006-2017. Em outras palavras, uma maior produção de leite por estabelecimento rural (um aumento de 11956 para 30721 litros de leite produzidos por estabelecimento no RS entre 2006 e 2017, um aumento de 156.95% na produção por estabelecimento).

Na Gif abaixo é observado, de forma dinâmica, a variação da produção leiteira nos municípios do estado do RS entre 1974 e 2017, através do uso de dados da PPM (IBGE, 2019a).

Considerações Finais

Bom pessoal, foi possível observar de uma forma genérica e ampla o histórico e o atual cenário do setor leiteiro Brasileiro e Gaúcho do ponto de vista da produção, do número de estabelecimentos produtores de leite e de seu tamanho em hectares. Em uma próxima postagem, irei investigar em maior profundidade outras informações que os Censos Agropecuários nos oferecem publicamente. Abaixo vou citar as referências utilizadas para estas análises e, na sequência, algumas recomendações pessoais de leituras para o público que quiser conhecer um pouco melhor o setor leiteiro brasileiro através de pesquisas acadêmicas de pesquisadores no Brasil. Obrigado e até a próxima análise !