Author Archives: Luis Fernando Chaim

Comandos do Docker

Docker No Comments

Docker info

docker info

Quando nós acabamos de subir o Docker Engine, nós utilizamos esse comando para verificarmos as informações do nosso Docker Host.

Docker version

docker version

Com o version nós conseguimos ver a versão do nosso Client, para esse artigo estou utilizando o Windows e o Server que para esse exemplo estamos utilizar o Linux. Quanto ao OS/Arch do server nós podemos trabalhar com Windows ou Linux, caso você esteja utilizando o Docker for Windows basta clicar em Swith to Windows Containers que ele irá realizar essa alteração.

Docker images

docker images

Nós utilizamos ele para listarmos as imagens que nós temos no nosso host, como eu acabei de instalar o Docker no meu Windows a lista está vazia como podemos ver na imagem a baixo:

  • Repository: repositório;
  • TAG: tag utilizada no repositório;
  • IMAGE ID: o id na nossa imagem;
  • Created: data de quando nós criamos a nossa imagem;
  • Size: tamanho da imagem;

Docker search

docker search (parametro)

Para que possamos procurar uma imagem, nós podemos utilizar o comando a baixo com o parâmetro nome Ex.: ubuntu, dotnetcore, node … etc, assim ele irá buscar as imagens que são compatíveis com o nosso server que para esse exemplo estamos utilizando o Linux.

Docker pull

docker pull (parametro)

Quando encontrarmos a imagem que precisamos para a nossa aplicação, nós precisamos baixar ela para o nosso host.

Docker run

docker pull (nome da imagem)

Para que nós possamos criar um contêiner, nós precisamos de uma imagem. Caso você não tenha essa imagem no seu host ainda ele irá até o repositório central e irá baixar ela para o seu host, em seguida ele irá criar o contêiner.

Docker ps

docker ps

Agora vamos verificar o status do nosso contêiner, execute o comando acima no seu terminal.

Docker status

docker stats (id ou apelido do container)

Para que possamos ter informações sobre um contêiner nos executamos o comando acima, ele nos retorna dados como:

  • CONTAINER — ID do Container;
  • CPU % — uso de CPU em porcentagem;
  • MEM USAGE / LIMIT — Memória usada/Limite que você pode ter setado;
  • MEM — uso de memória em porcentagem;
  • NET I/O — I/O de Internet;
  • BLOCK IO — Outros processos de I/O;

Docker inspect

docker inspect (id da imagem ou container)

Caso você precise de mais detalhes sobre a sua imagem ou o seu contêiner, podemos utilizar o comando inspect. Ele irá retornar um json com todas as informações relacionadas a nossa busca.

Docker rmi

docker rmi (nome da imagem)

Caso você tenha baixado uma imagem errada ou queira deletar alguma por um outro motivo, basta executar o comando a cima que ele deleta ela do seu host.

Docker rm e ps

Você pode excluir todos os containers criados

$ sudo docker rm ($ sudo docker ps -a)

Ou remover os criados e parados

$ sudo docker rm ($ sudo docker ps -a -q)

Docker exec

docker exec (id_container ou nome_container)

Com o exec nós podemos executar qualquer comando nos nossos contêineres sem precisarmos estar na console deles.

Vejamos a baixo alguns dos parâmetros que podemos utilizar com ele:

  • -i permite interagir com o container
  • -t associa o seu terminal ao terminal do container
  • -it é apenas uma forma reduzida de escrever -i -t
  • --name algum-nome permite atribuir um nome ao container em execução
  • -p 8080:80 mapeia a porta 80 do container para a porta 8080 do host
  • -d executa o container em background
  • -v /pasta/host:/pasta/container cria um volume ‘/pasta/container’ dentro do container com o conteúdo da pasta ‘/pasta/host’ do host

Docker attach

docker attach (id_container ou nome_container)

Vamos agora entrar dentro do nosso contêiner e verificar o nosso novo arquivo criado. Para isso execute o comando acima + o nome do ou id do seu contêiner, podemos observar que a execução dele irá nos dar acesso de root no nosso contêiner.

Docker start

docker start (id do container)

Quando nós saimos do nosso container com o comando exit, ele mata o nosso processo.

Para que possamos dar um dettach ou em outras palavras sair sem fecharmos ele, nós precisamos dos comandos: Ctrl+p + Ctrl+q. Para que possamos subir ele novamente vamos utilizar o comando start.

Agora execute o comando attach novamente para entrar no seu contêiner e depois os comandos : Ctrl+p + Ctrl+q, em seguida podemos verificar que o nosso contêiner ainda está em execução.

Docker stop

docker stop (id ou nome container)

Para que possamos parar um contêiner que esteja sendo executado, nós utilizamos o comando stop. Sua execução é bem simples, nós passamos o mesmos parâmetros que utilizamos no start.

Mapeamento de Portas

-p host:container

Para que possamos testar o mapeamento de portas iremos baixar a imagem do ngnix e passarmos para ele a porta 80. Para isso execute o comando a baixo no seu terminal:

docker run -it -p 8080:80 nginx

Ele irá baixar a imagem do nginx para o seu host e abrir ele na porta 8080 do seu host. Para testar assim que ele finalizar a execução do comando acima, abra no seu navegador o endereço: http://localhost:8080/, podemos ver o seu retorno na imagem a baixo.

Mas executando ele dessa forma nós ficamos com o nosso console travado.

Para que possamos ter um contêiner sendo executado em background, nós podemos utilizar eles em segundo plano. Para isso, só precisamos passar o comando -d. Caso ainda esteja o seu contêiner ainda esteja sendo executado, execute o comando control c para sair dele, em seguida execute o mesmo comando anterior só que agora com o parâmetro -d:

docker run -it -d -p 8080:80 nginx

Instalando MongoDB no Ubuntu em 4 passos

Banco de Dados No Comments

Introdução

Este post tem por objetivo demonstrar como instalar o MongoDB no Ubuntu, de forma fácil. O procedimento foi executado no Ubuntu 16.04 LTS e funcionou perfeitamente.

Configurando o Repositório

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4

Adicionar o Repositório

Ubuntu 18.04 LTS

$ echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb.list

Ubuntu 16.04 LTS

$ echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb.list

Atualizar biblioteca

$ sudo apt update

Instalar o MongoDB

$ sudo apt install mongodb-org

Pronto! A etapa de instalação esta concluída. Agora veremos como utilizar o MongoDB.

Gerenciando MongoDB Service

Habilitando o MongoDB

$ sudo systemctl enable mongod

Iniciando o MongoDB

$ sudo systemctl start mongod

Parando o MongoDB

$ sudo systemctl stop mongod

Verificando a versao

$ mongod --version

Fonte: https://tecadmin.net/install-mongodb-on-ubuntu/

Cucumber – Exemplo prático de Calculadora

Teste Automatizado No Comments

Introdução

Este post tem o objetivo de demonstrar, de forma prática, a metodologia do uso do Cucumber, usando Eclipe e Java.

Aprenda mais sobre o Cucumber aqui.

Criação do Projeto

Vamos criar um projeto Maven Java no Eclipse.

  1. Abra o Eclipse.
  2. Clique no menu File / New / Maven Project
  3. Deixe os valores padrão e clique em Next
  4. Utilize o archetype quickstart (padrão) e clique em Next
  5. Configure os parâmetros do projeto
    1. Group Id: com.maxidica.tdd
    2. Artifact Id: calculadora
    3. Deixe os demais campos padrão
    4. Clique no botão Finish

Ajustando pom.xml

Agora vamos incluir as dependências necessárias para o projeto.

  1. Abra o arquivo pom.xml
  2. Clique na aba Dependencies
  3. Remova o junit 3.8.1
  4. Adicione o junit 4 (4.1.2)
  5. Adicione as dependências do Cucumber
    1. cucumber-java
    2. cucumber-junit
    3. cucumber-picocontainer
    4. Configure as dependências com escopo test

Criando arquivo de estórias

Iremos criar o diretório de fonte, chamado resource.

  1. Clique com o botão direito no projeto
  2. Escolha New / Source Folder
  3. Digite src/test/resource
  4. Clique em Finish

Eliminando classes desnecessárias

Exclua todos os arquivos .java do projeto (App.java e AppTest.java).

Criando a classe CalcRunner

Essa classe é responsável pela execução do teste.

  1. Clique com o botão direito em src/test/java
  2. Escolha New / Class
  3. Digite CalcRunner
  4. Clique em Finish

package com.maxidica.tdd.calculadora;

import org.junit.runner.RunWith;

import cucumber.api.CucumberOptions;
import cucumber.api.junit.Cucumber;

@RunWith(Cucumber.class)
@CucumberOptions(
plugin = {“html:target/cucumber-html-report”, “json:target/cucumber-json-report.json”},
features = “src/test/resource”
)
public class CalcRunner {

}

Criando arquivo feature

Esse arquivo é responsável pela execução dos testes.

  1. Clique com o botão direito em src/test/resource
  2. Escolha New / File
  3. Digite o nome Calc.feature
  4. Digite o conteúdo abaixo
#language: en
Feature: Calc
   Como usuario entrar com 2 valores
   Com objetivo de obter um resultado

   Scenario: Somar
   Given que eu escolha somar
   When eu preencho o primeiro número com o valor '1'
   And eu preencho o segundo número com o valor '1'
   Then eu devo ver o resultado como '2'

 

Rodando o 1º teste

Esse teste criará a estrutura para definirmos a classe de execução.

  1. Clique com o botão direito na classe CalcRunner.java
  2. Escolha Run As / JUnit Test
  3. Na aba Console, aparecerá o resultado com os métodos a serem codificados
1 Scenarios (1 undefined)
4 Steps (4 undefined)
0m0,000s


You can implement missing steps with the snippets below:

@Given("^que eu escolha somar$")
public void que_eu_escolha_somar() throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

@When("^eu preencho o primeiro número com o valor '(\\d+)'$")
public void eu_preencho_o_primeiro_número_com_o_valor(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

@When("^eu preencho o segundo número com o valor '(\\d+)'$")
public void eu_preencho_o_segundo_número_com_o_valor(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

@Then("^eu devo ver o resultado como '(\\d+)'$")
public void eu_devo_ver_o_resultado_como(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

Criar classe com os passos do teste

Agora, iremos criar a classe responsável pela execução dos passos do teste.

  1. Clicar com o botão direito em src/test/java
  2. Escolher New / Class
  3. Defina o nome como CalcSteps
  4. Então, basta copiar os métodos (apresentados no Console) para dentro da classe
package com.maxidica.tdd.calculadora;

import cucumber.api.PendingException;
import cucumber.api.java.en.Given;
import cucumber.api.java.en.Then;
import cucumber.api.java.en.When;

public class CalcSteps {

@Given("^que eu escolha somar$")
public void que_eu_escolha_somar() throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

@When("^eu preencho o primeiro número com o valor '(\\d+)'$")
public void eu_preencho_o_primeiro_número_com_o_valor(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

@When("^eu preencho o segundo número com o valor '(\\d+)'$")
public void eu_preencho_o_segundo_número_com_o_valor(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

@Then("^eu devo ver o resultado como '(\\d+)'$")
public void eu_devo_ver_o_resultado_como(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

}

Criar a aplicação

Essa classe é que conterá as regras de negócio que queremos, neste caso, calcular a soma de números.

  1. Clique com o botão direito em src/main/java
  2. Escolha New / Class
  3. Defina o nome Calc
package com.maxidica.tdd.calculadora;

public class Calc {

public int somar( int a, int b ) {
return a + b;
}

}

Codificando os métodos na classe CalcSteps

Agora, precisamos codificar os métodos.

package com.maxidica.tdd.calculadora;

import static org.junit.Assert.assertEquals;

import cucumber.api.java.en.Given;
import cucumber.api.java.en.Then;
import cucumber.api.java.en.When;

public class CalcSteps {

Calc calc;
int num1, num2;

@Given("^que eu escolha somar$")
public void que_eu_escolha_somar() {
calc = new Calc();
}

@When("^eu preencho o primeiro número com o valor '(\\d+)'$")
public void eu_preencho_o_primeiro_número_com_o_valor(int arg1) {
num1 = arg1;
}

@When("^eu preencho o segundo número com o valor '(\\d+)'$")
public void eu_preencho_o_segundo_número_com_o_valor(int arg1) {
num2 = arg1;
}

@Then("^eu devo ver o resultado como '(\\d+)'$")
public void eu_devo_ver_o_resultado_como(int arg1) {
assertEquals(arg1,calc.somar(num1,num2));
}

}

Teste final

Então podemos executar o teste final na classe CalcRunner.

  1. Clique com o botão direito na classe CalcRunner.java
  2. Escolha Run As / JUnit Test
  3. Verifique o resultado no Console
1 Scenarios (1 passed)
4 Steps (4 passed)
0m0,146s

Provocando erro no teste

Para executar a falha, devemos alterar o arquivo feature.

  1. Edite o arquivo Calc.feature
  2. Altere o texto, eu devo ver o resultado como ‘3’
  3. Salve o arquivo
  4. Rode o teste na classe CalcRunner.java
  5. Perceba que no Console, apresentará erro de execução
1 Scenarios (1 failed)
4 Steps (1 failed, 3 passed)
0m0,163s

java.lang.AssertionError: expected:<3> but was:<2>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at com.maxidica.tdd.calculadora.CalcSteps.eu_devo_ver_o_resultado_como(CalcSteps.java:31)
at ✽.Then eu devo ver o resultado como '3'(Calc.feature:10)

Essa é a parte interessante do teste. Alterando o arquivo feature, podemos validar se a aplicação está funcionando de forma correta.

Você pode baixar o projeto pronto no Github.

 

Cucumber – Linguagem Gherkin

Teste Automatizado No Comments

Cucumber é uma ferramenta que suporta Behavior Driven Development (BDD), traduzindo ao pé da letra significa: “desenvolvimento orientado por comportamento”, simples assim,ou seja, BDD nada mais é do que descrever os COMPORTAMENTOS de um sistema utilizando linguagem Gherkin.

O que é Gherkin ?

Gherkin é uma linguagem natural que tanto o cucumber quanto todos os interessados(usuários, desenvolvedores, testadores, etc…) entendem, dessa forma, todas as necessidades reais do usuário e projeto são descritas, gerando uma documentação viva e valor pro negócio.

Não altere a estrutura padrão

Como já sabemos, o cucumber utiliza linguagem gherkin, que é uma linguagem natural e de fácil entendimento, porém possui algumas palavras “chaves” e são elas:

Dado (Given)
O “Dado” seria básicamente as pré-condições do cenário.

Quando (When)
O “Quando” serve descrever as ações chave que o usuário executa, resumidamente seria qualquer ação de interação do usuário com o sistema.

Então (Then)
O “Então” visa mostrar as saídas, os resultados das ações executadas, seriam basicamente os resultados esperados.

Exemplo:

Dado número A
Quando somar A+B
Então resultado deve ser C

Portanto mantenha sempre esse padrão: Dado, Quando, Então. NÃO altere isso e NÃO repita essas palavras no mesmo cenário, para não repetir essas palavras, caímos no segundo tópico das melhores práticas.

Faça uso do “E” e “Mas”

E (And)
O “E” visa complementar qualquer uma das palavras chaves citadas anteriormente, por exemplo:

Dado número A
E número B
Quando somar A+B
E dividir por C
Então resultado deve ser D

Mas (But)

O “Mas” seria a forma negativa do “Então”, basicamente, quando o resultado esperado for que o usuário NÃO DEVE receber.

Dado número A
E número B
Quando somar A+B
E dividir por C
Então resultado deve ser exibido
Mas não deve ser igual a D

Use “Contexto” e ganhe tempo

Uma regra básica que serve para a vida, se você está fazendo o mesmo trabalho duas vezes, de duas uma, ou você não fez direito, ou algo de errado não está certo.

No cucumber é para isso que existe o contexto(background), para remover aquilo que está sendo repetido em todos os cenários e centralizar em um único lugar, no caso o contexto. Vamos dar um exemplo para ficar bem mais fácil e compreensível.

Reparem que no exemplo acima, a seguinte linha está sendo repetida em todos os cenários:

Dado que eu esteja logado

Vamos ao “Contexto”

Viu como diminuímos o retrabalho? Mais fácil do que fazer regime!

O “Contexto” é bom quando usado para coisas simples, não é recomendável utilizar para cenários mais complexos complexas.

O “Contexto” é executado antes de cada um dos cenários, mas após qualquer um dos Hooks.

Use tags

#VemNeMimSextaFeira, é praticamente a mesma coisa, só que no lugar da hashtag, utiliza o @. Com isso você consegue filtrar e executar cenários específicos, por exemplo:

@validar_login @crítico @wip @cadastrar_cliente

Pode utilizar mais de uma tag por funcionalidade

Seja mais comportamental do que procedural

Não escreva todos os passo a passo de cada cenário, basta descrever o comportamento. exemplo:

Dado que o usuário esteja na tela de login
Quando preencher o campo usuário
E preencher o campo senha
E clicar no botão entrar
Então o sistema deve logar
e exibir dashboard

Pode isso Arnaldo ? Poder pode, mas não é recomendável, o mais correto seria:

Dado que o usuário esteja na tela de login
Quando informar os dados válidos
Então o sistema realizar o login
E o sistema exibir mensagem de “Bem Vindo”

Sempre descreva na terceira pessoa

Pare de utilizar “eu” nas descrições dos cenários, procure utilizar sempre na terceira pessoa. Reparem no cenário abaixo:

Dado que eu esteja…

Quando eu adiciono…

Não, não é assim! utilize na terceira pessoa.

Dado que o usuário ou o cliente esteja logado

Quando usuário ou cliente adicionar um produto no carrinho

Melhorou ?

Utilize Scenario Outline

Quando os cenários têm validações e resultados parecidos, podemos utilizar os Scenarios Outline, ou Esquemas de cenário. Vamos ao exemplo:

Cenário: mostrar o resultado quando executar uma operação de adição
Dado que o usuário esteja na calculadora
Quando pressionar o número 4
E pressionar o número 2
E escolher adição
Então o sistema devera mostrar o resultado igual à 6

Cenário: mostrar o resultado quando executar uma operação de subtração
Dado que o usuário esteja na calculadora
Quando pressionar o número 4
E pressionar o número 2
E escolher subtração
Então o sistema devera mostrar o resultado igual à 2

Cenário: mostrar o resultado quando executar uma operação de multiplicação
Dado que o usuário esteja na calculadora
Quando pressionar o número 4
E pressionar o número 2
E escolher multiplicação
Então o sistema devera mostrar o resultado igual à 8

Repare que são praticamente as mesmas validações, para facilitar tanto na implementação e na manutenção, existe no cucumber os scenarios outline. E ficaria da seguinte maneira:

Cenário: mostrar o resultado quando executar uma operação na calculadora
 Dado que o usuário esteja na calculadora
 Quando pressionar o <número1>
 E pressionar o <número2>
 E escolher a <operação>
 Então o sistema devera mostrar o <resultado>
Exemplo:
    | numero1    | numbero2   |    operação    | resultado|
    |     4      |      2     |      soma      |   6      |
    |     4      |      2     |   subtração    |   2      |
    |     4      |      2     | multiplicação  |   8      |
    |     4      |      2     |     divisão    |   2      |

A primeira linha da tabela representa as variáveis escritas assim <variável> nos cenários e as outras linhas são os exemplos para execução dos testes com seus respectivos resultados esperados.

Viu como fica mais fácil de escrever e manter os cenários? Além de serem mais legíveis também.

Organize Diretórios

Existem outras formas de organizar os diretórios dentro do projeto. Porém uma boa prática é criar uma pasta Features e dentro dela criar as seguintes subpastas: pages, onde vão ficar todos os objetos de cada pagina(não precisa se preocupar com isso agora), specifications, onde vão ficar todos os comportamentos do sistema escrito em cucumber, step_definitions, onde vão ficar todos os passo a passo gerados a partir das nossa especificações e support, onde vão ficar algumas configurações, conforme exemplo abaixo:

Lean no Desenvolvimento de Software

Agile No Comments
Mary e Tom Poppendieck (gurus de Lean voltado a TI, defensores do agile e autores do livro: “Lean Software Development – An Agile Toolkit” que mostra como os princípios Lean podem ser aplicados em abordagens de desenvolvimento de software ágil) usou a seguinte frase para definir Lean:
“What is Lean?

•  Deliver continually increasing customer value
•  Expending continually decreasing effort
•  In the shortest possible timeframe
•  With the highest possible quality
A journey, not a destination. ”

E acrescentam:  “Acelerar a produção do desenvolvimento de Software é geralmente uma questão de melhorar o processo ao invés de adicionar pessoas. Pare de fazer coisas que o cliente não valoriza! Vista os óculos do cliente! ”

Tentando resumir em uma frase, Lean é um princípio ágil cujo foco é cortar a “gordura” do processo de software, focando na eliminação de desperdícios.

Princípios Lean aplicados ao software:

  1.    Elimine Desperdícios
  2.    Inclua a Qualidade no Processo
  3.    Crie Conhecimento
  4.    Adie Decisões e Comprometimentos
  5.    Entregue o quanto antes
  6.    Respeite as Pessoas e “Empower” a equipe
  7.    Otimize o Todo

Vamos ver os 7 princípios de Lean e como transforma-los em práticas ágeis.

Princípio #1 – Eliminar desperdícios
Desperdícios: tudo aquilo que não agrega valor para cliente final e que não são percebidos pelo cliente. Exemplo: passos extras, processo pesado e rígido, burocracia, documentação que nunca vai ser lida, que está na prateleira juntando poeira – não necessária, etc. Outro tipo de desperdício são trabalhos parcialmente prontos, tudo que começa e não termina, funcionalidades extras que não serão utilizadas, etc.image

  1. Enfim, software útil e de funcionando (de qualidade) é o que vai trazer valor ao cliente. Os sete desperdícios de software:
  2. Inventory = Requirements / Partially done work
  3. Extra Processing Steps = Extra processes, steps
  4. Overproduction = Extra features
  5. Transportation = Handoffs, tasks switching
  6. Waiting = Waiting
  7. Defects = Defects
  8. Motion = Finding Information
Não se iluda, embora alguns sejam gritantes não é fácil identificar alguns tipos de desperdício. É preciso aprender a enxergar os desperdícios e existem algumas práticas e exercícios que podem ajudar, tais como: Seeing waste e Value Stream mapping.
Vejamos os tipos de desperdícios mais detalhadamente:
1 – Requisitos
Requisitos, especificados muito cedo que perdem sua credibilidade, eficácia e compromete a usabilidade do sistema.
Trabalho incompleto (“em-progresso”) – Parcialmente feitos
Trabalhos parcialmente iniciados / terminados tendem a se tornar obsoletos.
O maior problema é não ter idéia se eventualmente funcionam ou não. Enquanto os trabalhos não são integrados, não podem ser utilizados e não temos como saber quais problemas podem aparecer. Funcionalidades pela metade apenas atravancam o caminho para trabalhos que poderiam ser feitos. Tornando-se facilmente obsoleto.
Consomem recursos sem trazer retorno.
Exemplos: Documentação não codificada, código não sincronizado, código não testado, código não implantado.
2 – Processos/Passos a mais
Burocracia, atividades, métricas, etc que não geram valor e que diminui o tempo de resposta.
Você alguma vez já se perguntou, toda aquela documentação e papelada é realmente necessária?
Documentação desnecessária e documentação que são esquecidos ou perdem valor e se tornam obsoletos ou documentos que ninguém se importa em ler.
O seu cliente realmente acha que isso torna o produto dele mais eficiente?
Dica: Faça esse questionamento para descobrir quando a documentação tem valor agregado : Tem alguém esperando ou dependendo do que você esta produzindo?.
Ainda assim lembre-se: Mantenha-o enxuto, em alto-nível e documente o mais tardar possível.
3 – Funcionalidades a mais
80% das funcionalidades implementadas não são utilizadas.
20% das funcionalidades é que são realmente úteis.
Código não-utilizado introduz complexidade e a complexidade é um inimigo da manutenção. Mais código para ser mantido. Mais testes para serem realizados. Mais documentos de especificação para serem criados. Se o código não é necessário agora colocá-lo no sistema é desperdício.
4 – Troca de tarefas (Task switching, Handoffs)
Corrida de revezamento deve ser substituída pela equipe multi-funcional.
Quanto maior os handoff’s maior é a perda de conhecimento. Organizar pessoas em múltiplos projetos é outra forma de desperdício.
Quanto tempo se perde para parar uma determinada atividade e iniciar outra, relembrar onde parou, concentrar-se e finalmente produzir algo?
5 – Atrasos
Atrasos na entrega, atrasos em geral são puro desperdício e irão gerar aumento do custo do projeto.
Em muitos casos, atrasos são apenas a ponta do iceberg para problemas muito maiores.
Espera: Um dos maiores desperdícios no desenvolvimento de Software é a espera para que as coisas aconteçam. Espera para o início do projeto, pela montagem da equipe, espera pela produção de documentação extensa, espera por processo de revisão ou aprovação, espera para testar, etc.  Veja, analise o que deve ser mantido, o que agrega valor e o que é puro despedício.
6 – Defeitos
Equipes ágeis se esforçam ao máximo para evitar defeitos.
 “Inspecionar para prevenir defeitos é bom;
Inspecionar para encontrar defeitos é desperdício” — Shigeo Shingo
Defeitos (Bugs) não agregam valor, não satisfazem o cliente, e custam muito muito caro.
7 – Movimento
Tempo e esforço gasto para encontrar informações.
Equipes ágeis valorizam a conversa e por isso trazem o cliente para perto, não devemos perder tempo lendo páginas e páginas de um documento para encontrar uma informação que ao mesmo tempo por estar na forma escrita muitas vezes são imprecisas e pode trazer mais dúvidas do que resolver o problema.
Princípio #2 – Qualidade embutida
Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus clientes, se eles perceberem isso, significa que foi uma entrega de qualidade. Mary e Tom Poppendieck em seu livro identificaram duas dimensões de integridade: integridade percebida e integridade conceitual. A integridade percebida significa que a totalidade do produto alcança um equilíbrio entre as funções, usabilidade, confiabilidade, economia e isso encanta o cliente. A integridade conceitual significa que os conceitos centrais do sistema de trabalho em conjunto são facilitados e coesos. Essa última é fator crítico de sucesso para a integridade percebida.
Um produto possui integridade percebida quando o cliente o experimenta e diz: Isso! Era exatamente isso que eu queria! Software com integridade possui boas arquiteturas, possuem um alto nível de usabilidade e facilidade de uso, são fáceis de dar manutenção, de adaptar e de estender.
Dicas:
  • Não verificar a qualidade só no final, verificar durante todo processo e também toda equipe testa!
  • Quanto antes um problema é verificado mais barato ficará
  • Foco na prevenção, não na verificação no final do processo – Ao invés de se esforçar para gerenciar defeitos, evite-os.
  • “Logar” defeitos é desperdício, corrija-os imediatamente.
Práticas sugeridas para promover a qualidade:
  • 4 quadrantes de teste
  • TDD  – Test Driven Development
  • Refactoring
  • Integração contínua
  • Code review / code inspection
  • Standards
  • Testes contínuos e automatizados
Princípio #3 – Criar conhecimentos
Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de reduzir a variação. Desenvolvimento é como fazer uma nova receita, enquanto produção é como fazer um prato. Receitas são formuladas por chefes de cozinha experientes que de certa forma desenvolveram habilidades e capacidade de combinar os ingredientes disponíveis para produzir o prato desejado. Desenvolver uma receita é um processo de descoberta, até os chefes mais experientes produzem diversas variações de um novo prato, fazem iterações, experimentações, até encontrar a melhor combinação de ingredientes que resulte em um prato rápido e sabor agradável. Não se espera que os chefes obtenham uma receita perfeita de primeira; espera-se produzir diversas variações como parte do processo de aprendizagem. Desenvolvimento de software é melhor concebido se este fizer parte de um processo de aprendizado similar ao de criar uma nova receita. A melhor abordagem para melhorar o ambiente de desenvolvimento de software é pela expansão do conhecimento.
Práticas sugeridas para promover o conhecimento:
  • Ciclos de feedback e inspeções e adaptações;
  • Desenvolvimento iterativo;
  • Equipes pequenas e cross-functional;
  • Treinamentos e Mentoring;
  • Criação e utilização de standards, guidelines e qualquer outro artefato;
  • Code Reviews;
  • Meios de compartilhamento de informações como um Blog ou Wiki;
Princípio #4 – Adiar decisões / compromissos
O principal conceito deste princípio é diminuir as incertezas retardando as decisões até que possam serem feitas com base em acontecimentos mais firmes, previsíveis e conhecidos. Decisões tardias tendem a ser mais acertadas porque as melhores decisões são feitas baseadas em fatos, e não em suposições ou especulações. Uma estratégia chave para adiar decisões/comprometimentos quando desenvolvendo um sistema complexo e com muitas incertas é usar a capacidade e práticas que permitam abraçar as mudanças tardiamente.
Práticas sugeridas para adiar compromissos:
  • Iterações
  • Planning meetings
  • Behaviour/Feature Driven Development
  • Outros
Princípio #5 – Entregar rápido
Sem entregas rápidas não é possível colher feedback. Sem entregas rápidas não é possível aprender com erros. Velocidade na entrega garante que o cliente receberá o que ele precisa hoje e não o que ele precisava ontem.
Práticas sugeridas:
Princípio #6 – Respeitar as pessoas
Envolver os desenvolvedores nos detalhes das decisões técnicas é fundamental para o atingimento da exelência.
Dicas:
  • Um ambiente que favoreça o desenvolvimento das pessoas.
  • Uma empresa que respeita as pessoas, assim as pessoas irão respeitar a empresa
O Software produzido é como um espelho da equipe de desenvolvimento.
Para que as pessoas possam assumir responsabilidades, se sentir motivados e atuar como uma equipe eles precisam de confiança e de respeito.

Práticas sugeridas para promover o empowering do time:

  • Auto-gestão
  • Trabalho em equipe
  • feedback
 

Princípio #7 – Otimizar o todo

Otimizar desde o começo até o final:
  • Utilize Métricas
  • Diminua o número de métricas de desempenho individual mas valorize o desempenho da equipe.
  • Meça para cima:
  • Tempo de ciclo +Mapa de Fluxo de Valor
  • ROI + Modelo de Lucros e Perdas
  • Satisfação do Cliente + Entendimento das suas necessidades
Para tornar o seu processo ágil, pense Lean!
Mas lembre-se Lean requer uma mudança da cultura e dos hábitos organizacionais para que esta possa usufruir das melhorias de performance que um processo enxuto pode proporcionar.
É UMA MUDANÇA DE MENTALIDADE E COMPORTAMENTO !

IBM Watson Assistant

Machine Learning No Comments

Introdução

Este post, demonstra a configuração do processo de conversação com IBM Watson.

Premissas

  1. Vá para Watson Developer Console Services, aqui.
  2. Selecione “Watson Assistant”
  3. Clique “Incluir Serviços / Add Services”
  4. Forneça um nome, por exemplo: watson-assistant-tutorial
  5. Clique em “Criar Projeto / Create Project”

Ativar a Ferramenta

Com o projeto watson-assistant-tutorial aberto:

  1. Clique em “Ferramenta Ativar / Launch Tool”
  2. Se desejar, veja o vídeo da ferramenta, aqui

Criar Workspace

  1. Selecione o menu Workspaces
  2. Clique em “Create” para criar um novo workspace
  3. Defina um nome, por exemplo “Watson Assistant tutorial”
  4. Selecione a linguagem Portuguese (Brazilian)
  5. Clique em “Create”

Criar Intents

Intent representa o propósito de input de um usuário. De forma simples, são ações que o usuário pode executar, dentro de sua aplicação.

  1. Clique em “Add intent”
  2. Digite o nome “hello” e clique em “Create intent”
  3. Abrirá uma tela solicitando “Add user example”, forneça “hello” novamente
  4. Clique em “Add example”
  5. Adicione mais 4 examples
    1. good morning, greetings, hi, howdy
  6. Clique em “Close” (ícone de seta para esquerda)
  7. Criar outro Intent (#goodbye)
    1. Examples: bye, farewell, goodbye, I’m done, see you later

Examples informam ao serviço do Assistente do Watson quais tipos de entrada do usuário você deseja corresponder à intenção. Quanto mais exemplos você fornecer, mais preciso será o serviço ao reconhecer as intenções do usuário.

 

Jupyter Notebook no Windows

Big Data No Comments

Introdução

Este post apresenta o Jupyter Notebook, uma aplicação Web, Open Source, que permite criar e compatilhar dados e resultados de análises, juntamente com o código.

Executando

Através do Anaconda, clique no botão “Launch” do Jupyter Notebook.

Abrirá o navegador padrão com a URL: http://localhost:8888/tree

Selecione “New” (canto direito) e escolha “Python 3”.

Teclas de Atalho

Shift+Enter: Executa o código fornecido na caixa “In [xx]”.

Alt+Enter: Insere uma nova linha de código (“In []”), abaixo da linha onde está o foco.

Instalando Jupyter no Windows

Big Data No Comments

Introdução

Este post tem o objetivo de demonstrar a instalação do Jupyter no Windows.

Pré-Requisitos

Para a instalação do Jupyter, precisamos do ambiente Python pronto.

Anaconda

Anaconda é uma plataforma Open Source para cientista de dados. Ela possui o R (linguagem de programação para estatística), o Python e módulos do Scala. O Anaconda para Windows pode ser baixado aqui.

Após a instalação, executar o Anaconda Navigator.

Path

Na instalação do Anaconda, recomenda-se não configurar o Path, automaticamente.

Neste caso, após a instalação é necessária a configuração na variável de ambiente, se deseja utilizar o prompt de comando.

  1. Localize “Meu Computador”, clique com o botão direito e selecione “Propriedades”
  2. Clique em “Configurações avançadas do sistema”
  3. Clique em “Variáveis de Ambiente…”
  4. Duplo clique em “Path”
  5. No final da linha acrescente (no meu caso, foi instalado para qualquer usuário):
    1. C:\ProgramData\Anaconda3\
    2. C:\ProgramData\Anaconda3\Library\bin
  6. Clique nos 3 botões “OK”
  7. Abra um promp de comando e digite:
    1. python (deverá abrir o editor do python – para sair, digite “quit()”

Anaconda Client

Para utilização do Anaconda Cloud, é necessário instalar o anaconda-client. Para isso, basta abrir um prompt de comando e digitar:

conda install anaconda-client

Executando o Jupyter

Com o Anaconda Navigator aberto, clique no botão “Launch” do componente Jupyter.

Abrirá no navegador padrão a seguinte URL: http://localhost:8888/tree

Cassandra no Docker e Java no Ubuntu

Big Data No Comments

Introdução

Este post tem por objetivo apresentar a utilização do Cassandra, rodando sob um container Docker e teste de integração com Java.

Pré-requisitos

Docker e ferramentas Java instalados

Dockerfile para o Cassandra

Para executar o Cassandra sob o container Docker, devemos criar o arquivo Dockerfile. Para este exemplo, criei no próprio diretório do projeto Maven.

Dockerfile

# Partir do docker inicial do cassandra no DockerHub
FROM cassandra:latest

Build do Dockerfile

  1. Entrar no diretório onde encontra-se o arquivo Dockerfile (no meu caso esta em /opt/workspaces/java-cassandra/Dockerfile)
  2. Executar o comando
    1. # docker build .
  3. Ao terminar o download e extração dos arquivos, digite o comando
    1. # docker images
      1. REPOSITORY    TAG         IMAGE ID                CREATED            SIZE
      2. cassandra           latest      0fb9df189322        2 weeks ago      323 MB
  4. Executar o comando para subir o docker da imagem gerada
    1. # docker run -it cassandra

Projeto Maven

Para facilitar, está disponível no Github o projeto para teste.

https://github.com/lfchaim/java-cassandra

 

Soluções Big Data

Big Data No Comments

Introdução

Este post tem a finalidade de apresentar as principais soluções de Big Data.

Integração

Talend

Talend é um ETL de código aberto, desenvolvido pela empresa francesa Talend. Ele permite que você crie graficamente manipulação de dados e processos de transformação e, em seguida, gere o executável correspondente como um programa Java.

Sqoop

Sqoop é um projeto da Fundação Apache, que visa permitir uma melhor coabitação de sistemas tradicionais de tipo DBMS com a plataforma Hadoop. Assim, é possível exportar dados do banco de dados e realizar processamento caro, explorando o cluster Hadoop. Os bancos de dados tradicionais são generalizados e o Sqoop permite que aplicativos tradicionais aproveitem um cluster Hadoop.

Mensagem

Kafka

Kafka é um sistema de mensagens distribuídas, desenvolvido originalmente pela equipe de Jay Kreps no LinkedIn, e publicado em 2011 como um projeto open source Apache.

Armazenagem

Redis

Redis é um repositório de dados de chave / valor criado pelo NoSQL e criado em 2009 por Salvatore Sanfilippo e Pieter Noordhuis. O projeto é patrocinado pela VMware e Pivotal.

Uma das principais características do Redis é manter todos os dados na memória. Isso proporciona um excelente desempenho, evitando o acesso ao disco, especialmente caro. Quando o tamanho dos dados é muito grande para manter a memória, o Redis também pode usar a memória virtual (swap).

Cassandra

Inicialmente desenvolvido pelo Facebook em 2008, foi lançado mais tarde e seu desenvolvimento agora é fornecido pela Fundação Apache. Datastax oferece suporte, bem como uma versão Enterprise com alguns recursos adicionais.

Cassandra é uma base de dados orientada a colunas. Estudou para implantações massivamente distribuídas (possivelmente em vários datacenters). Cassandra permite armazenar um elemento que é um conjunto de valores conectados entre si por um identificador exclusivo.

HBase

O HBase é um subprojeto do Hadoop, é um sistema de gerenciamento de banco de dados não-relacional distribuído, escrito em Java, com armazenamento estruturado para grandes tabelas.

HBase nasceu para fornecer acesso em tempo real a um cluster Hadoop. Ao contrário do HDFS, o acesso aos dados é aleatório e, portanto, mais eficiente, apesar da volumetria muito alta.

O Facebook no entanto, na origem de Cassandra, decidiu abandoná-lo em 2010 para o benefício da HBase.

O HBase é inspirado nas publicações do Google no BigTable, por isso é um banco de dados baseado em uma coluna e sem esquemas (em teoria). HBase está muito ligado ao Hadoop e o modo de cluster HDFS é necessário.

Cada valor de uma célula (campo no mundo relacional) é marcado com o tempo (como Cassandra), o que torna possível recuperar uma versão antiga do conteúdo.

HDFS

O HDFS é um sistema de arquivos Java usado para armazenar dados estruturados e não estruturados em um conjunto de servidores distribuídos.

O HDFS é um sistema de arquivos distribuído, extensível e portátil desenvolvido pela Hadoop a partir do sistema desenvolvido pelo Google (GoogleFS).

Escrito em Java, foi projetado para armazenar volumes de dados muito grandes em uma grande quantidade de máquinas equipadas com discos rígidos padrão.

A HDFS depende do sistema de arquivos do sistema operacional nativo para apresentar um sistema de armazenamento unificado baseado em um conjunto de sistemas de arquivos e arquivos heterogêneos.

MongoDB

MongoDB é um banco de dados orientado a documentos da mobilidade NoSQL que permite o armazenamento de documentos no formato BSON (uma forma binária de JSON). O seu idioma de consulta também está no formato JSON.

Possui mecanismos de replicação e fragmento para garantir resiliência e escalabilidade, mesmo que sua arquitetura seja mestre / secundária. Um mecanismo de eleição assegura a continuidade do serviço no caso de uma falha do mestre.

MongoDB é schemaless, o que significa que os documentos da mesma coleção não têm todos os mesmos campos.Os campos podem ser adicionados / removidos para um documento sem migração.

Neo4j

Neo4j é um dos mais antigos bases de dados NoSQL (primeira versão em 2000). É um banco de dados baseado em gráficos escrito em Java.

Os dados são armazenados no disco como uma estrutura de dados otimizada para redes gráficas.

Os bancos de dados orientados por gráfico são particularmente adequados em contextos onde os dados estão fortemente conectados e organizados de acordo com modelos complexos. A estrutura da entidade (nó ou relação) é definida no momento do armazenamento de dados (estrutura de schemaless), o que lhe confere uma grande flexibilidade.

Couchbase

O CouchBase é um banco de dados baseado em documento nascido em 2011, que é o resultado de dois projetos de código aberto: Membase (baseado em memcached) e Apache CouchDB com os quais ele continua compatível.

O CouchBase armazena documentos no formato JSon e oferece as seguintes formas de acessar dados:

  •  usando a chave exclusiva,
  •  através das visualizações (de dois tipos MapReduce / espaciais criados a partir de funções JavaScript),
  •  usando uma linguagem pseudo SQL (N1QL),
  •  através de pesquisa de texto completo.

Assim como o MongoDB, o formato JSon permite que o CouchBase seja simplificado, também é possível definir uma vida útil automática dos dados (TTL).

O CouchBase suporta o gerenciamento de vários datacenter no modo bidirecional.

Isso garante a continuidade do serviço em caso de indisponibilidade de um datacenter, mas também do usuário para consultar o datacenter mais próximo em operação normal.

O CouchBase fornece filtros de replicação que permitem que você selecione os dados para replicar entre dois centros de dados (somente versão corporativa).

Transformação

Spark

Spark nasceu em 2009 no laboratório AMPLab da Universidade de Berkeley na premissa de que:

  •  Por um lado, a memória custa menos e mais barata e os servidores, portanto, estão cada vez mais disponíveis.
  •  Por outro lado, muitos conjuntos de dados denominados “Dados grandes” têm um tamanho da ordem de 10 GB e, portanto, estão na memória.

Por isso, era necessário um sistema de tratamento que privilegie o processamento em memória dos dados.

O projeto se juntou à incubadora Apache em junho de 2013 e se tornou um projeto de nível superior em fevereiro de 2014.

O projeto foi progressivamente enriquecido para propor hoje um ecossistema completo.

O ecossistema da faísca agora inclui várias ferramentas:

  •  Spark para tratamentos “lote”
  •  Spark Streaming para o processamento contínuo de fluxos de dados
  •  MLlib para aprendizagem de máquinas, completado pela SparkML desde 2012
  •  GraphX ​​para cálculos de gráficos
  •  Spark SQL, uma implementação semelhante a SQL da consulta de dados.

Finalmente, o framework está escrito em Scala e oferece uma ligação Java que permite usá-lo sem problemas em Java. No entanto, o Java 8 é recomendado para explorar as expressões de lambdas que permitirão escrever um código mais funcional.

Existem versões específicas do Spark para Python e R para capitalizar as linguagens normalmente dominadas pelos Data Scientists.

MapReduce

MapReduce é uma estrutura de processamento paralelo, criada pelo Google para indexar o conteúdo de seu mecanismo de pesquisa na web. Disponível como um documento de pesquisa, sua primeira implementação apareceu no momento do desenvolvimento do Hadoop em 2005.

É uma estrutura que permite a decomposição de uma consulta importante em um conjunto de consultas menores que produzirão cada um um subconjunto do resultado final: esta é a função Map.

Todos os resultados são processados ​​(agregação, filtro): esta é a função Reduzir.

Em um processo MapReduce, diferentes atores irão intervir:

  •  Trabalhadores: lista de nós Hadoop que podem lidar com empregos MapReduce
  •  Mestre: um trabalhador dedicado ao gerenciamento de tarefas
  •  Cliente: lança o processamento MapReduce (muitas vezes chamado de driver)

As diferentes fases (Hadoop)

  1. Inicialização: o cliente / driver carrega um / mais arquivos no HDFS e envia um processamento MapReduce para a grade
  2. Split: os dados de entrada são opcionalmente divididos em blocos (16-64 MB)
  3. Atribuição: o mestre atribui as tarefas (Mapa e Redução) aos trabalhadores; a configuração define o número de tarefas Map e Reduce suportadas por cada um dos nós
  4. Mapa: leitura de divisões passadas para a função Map; Os conjuntos de chave / valor produzidos pela função são primeiro armazenados na memória antes de serem periodicamente escritos localmente e não em HDFS
  5. Shuffle: os resultados das funções Map são agregados pelo valor da chave para produzir uma lista de valores processados ​​pelo Reducer
  6. Reduzir: o mestre distribui para o Redutor a lista de dados a serem processados; os resultados são enviados para o fluxo de saída (HDFS, serviços web, …)
  7. Combinar: otimização, usa os resultados intermédios do mapa de entrada para um tratamento geralmente equivalente ao redutor (sem garantia de passagem)
  8. Fim: o mestre retorna ao programa do cliente

Flink

O Apache Flink é um projeto Apache de nível superior desde dezembro de 2014.

Anteriormente chamado Stratosphere e projeto de pesquisa da Data Artisans, foi criado em 2009 (como Spark).

O objetivo é fornecer uma estrutura de processamento distribuída em memória adaptada ao processamento em tempo real.

Diferenças com Spark:

  •  O Flink foi projetado desde o início por tempo real.
  •  Flink foi originalmente escrito em Java e suporta Scala com wrappers.
  •  O Flink pode realizar tratamentos Hadoop diretamente (ideal para uma transição suave).

O Flink inclui:

  •  APIs em Java / Scala para processamento em lote e em tempo real,
  •  Um mecanismo de transformação do programa em fluxos de dados paralelos,
  •  Um mecanismo de execução para distribuir processamento em um cluster.

Análise

Hive

Hive é um projeto iniciado pelo Facebook em 2008.

Como Pig, Hive permite a escrita de tarefas de processamento / consulta de dados para desenvolvedores que não conhecem o Java.

Onde Pig define uma linguagem processual para explorar o cluster, o Hive permite definir tabelas estruturadas do tipo SQL e alimentá-las com dados do cluster ou fontes externas.

Hive é baseado nas seguintes noções:

  •  Tabelas: uma tabela é uma sucessão de colunas e linhas, assim como para o mundo do SGBD. A diferença vem do sistema de armazenamento distribuído (HDFS ou outro). Outra diferença importante é a ausência de uma noção de chave primária.
  •  Partições: uma tabela do Hive pode ser particionada para distribuir dados no cluster (dependendo do valor de vários campos)
  •  Baldes: uma vez que particionado, os dados podem ser divididos em uma única coluna da tabela para dividir o armazenamento de dados. O Bucketing melhora o desempenho das juntas e permite que você trabalhe apenas em amostras.
  •  Metastore: este é o lugar onde a Hive armazena os metadados das tabelas (esquema, direitos de acesso, estatísticas, …)

Uma tabela Hive pode ser:

  •  internamente, os dados são duplicados em um diretório HDFS dedicado a Hive (armazém).
  •  externamente, os dados são armazenados em um diretório HDFS externo e somente os metadados são mantidos em Hive.

consultas

Uma vez que o esquema da tabela é definido e os dados inseridos, é possível usar a linguagem HiveQL para consultar essas tabelas. O HiveQL possui uma sintaxe próxima ao SQL e possibilita a realização das operações essenciais de leitura possibilitando a realização de análises clássicas (seleção de campos, soma, agregação, triagem, junção, …).

Pig

Pig é uma ferramenta de processamento de dados que faz parte do conjunto Hadoop e permite a escrita de scripts que são executados na infraestrutura Hadoop sem ter que passar pela escrita da tarefa em Java através da estrutura MapReduce. Ele também possui recursos para carregar dados de uma fonte externa para o cluster HDFS ou recursos para exportar dados para uso por aplicativos de terceiros.

Pig depende de sua própria língua chamada Pig Latin. Ele também fornece acesso à camada de aplicação Java. Esse idioma é bastante simples, o que permite que o desenvolvedor venha de um mundo diferente do Java para produzir scripts de processamento executados no Hadoop muito mais rapidamente.

Drill

O projeto Drill foi colocado na incubadora da Fundação Apache em agosto de 2012, é um mecanismo de consulta SQL para o Hadoop, desenvolvido inicialmente no MapR.

Inspirado no projeto Dremel do Google, o Drill permite consultas SQL interativas sobre o Hadoop, com o objetivo primordial de dar aos usuários não-desenvolvedores acesso a análises a partir de dados armazenados em HDFS e Hadoop.

Mesmo que a comparação não seja totalmente justa (a broca é como um Spark fácil de acessar), encontramos os mesmos casos de uso que o Hive.

Apache Impala

O Apache Impala é um mecanismo de consulta SQL de processamento massivamente paralelo de código aberto para dados armazenados em um cluster de computador que executa o Apache Hadoop. O Impala foi descrito como o equivalente ao código aberto do Google F1, que inspirou seu desenvolvimento em 2012.

 

Indexação

Elastic (Elasticsearch)

O ElasticSearch é um motor de busca aberto, distribuído e baseado em Lucene. Elasticsearch foi criado por Shay Banon, iniciador do projeto Compass, para substituir o último.

Ao contrário do Lucene, é um cluster de indexação, que depende de uma base de documento NoSQL interna usando o formato JSON para armazenamento de documentos. Além disso, exatamente como Solr e, ao contrário do Lucene, seu modo de consulta é de tipo cliente / servidor (não precisa ser implantado na mesma JVM que o cliente)

Os documentos são replicados para diferentes nós de armazenamento para melhorar o desempenho da pesquisa, mas também para gerenciar alta disponibilidade.

O papel da decomposição é o seguinte:

  •  Lucene gerencia operações de “baixo nível”, como indexação e armazenamento de dados,
  •  A pesquisa Elastic fornece várias camadas de abstração para aceitar o JSON, fornecendo uma API REST sobre HTTP e facilitando o clustering.

Ao contrário de alguns bancos de dados NoSQL, Elasticsearch não é esquemático. É possível indexar um documento sem qualquer informação sobre o seu formato (apenas os dados), mas o ElasticSearch criará um automaticamente a partir do formato de dados.

A pesquisa elástica está em constante evolução e, em desenvolvimentos recentes, deve-se notar:

  •  abandono do famoso sistema fluvial a favor de uma abordagem de tipo push por parte dos clientes,
  •  abandono de facetas em favor das agregações.

A linguagem de consulta é proprietária (Query DSL) e usa uma abordagem DSL e é baseada no formato JSon.

Ecossistema

Elastic, o editor da Elasticsearch, oferece um ecossistema cada vez mais rico em torno de seu mecanismo de busca.

Logstash

Logstash, permite coletar os logs, aplicar alguns tratamentos simples nas mensagens recebidas e depois transmiti-las a uma terceira solução, em particular, pesquisa Elastic para poder realizar pesquisas entre essas mensagens.

Kibana

A Kibana, outra solução bem conhecida, oferece uma interface gráfica para explorar e visualizar dados empurrados para o Elasticsearch ou aqueles armazenados em outras soluções além do editor.

Essas três soluções formam o trio mais comum para análise de log: ELK. Infelizmente, esses produtos tinham até recentemente um ciclo de vida independente que às vezes poderia levar a problemas de compatibilidade.

A nova embalagem foi renomeada como Elastic Stack. A Elastic Stack integra uma nova solução dedicada ao monitoramento, Beats, que é composto pelos seguintes produtos:

  •  PacketBeat: supervisão de rede,
  •  TopBeat: monitoramento de memória e CPU,
  •  FileBeat: supervisão de arquivos
  •  WinlogBeat: Monitoramento de eventos do sistema operacional (somente Windows),
  •  LibBeat: utilitários.

Aprendizagem

Spark ML e ML lib

MLlib

MLlib é um subprojeto Spark desde a versão 0.8. Como Spark, ele se originou no Berkeley Lab (AMPLab).

MLlib é a biblioteca de Aprendizagem de máquinas do Spark. Os algoritmos são projetados para aproveitar a computação paralela em um cluster Spark.

Por isso, é particularmente adaptado para volumetria elevada

MLlib, assim como o resto do framework Spark é desenvolvido em Scala. As operações de álgebra linear são baseadas nas bibliotecas Breeze e JBlas.

Algoritmos disponíveis:

  •  classificação: regressão logística, máquina de vetor de suporte linear (SVM), Bayes ingênuo,
  •  regressão: regressão linear generalizada (GLM)
  •  Filtragem colaborativa: alternando mínimos quadrados (ALS)
  •  agrupamento: k-means,
  •  decomposição: decomposição de valor singular (SVD), análise de componentes principais (PCA),
  •  dados escassos. (Dados escassos),
  •  Árvores de decisão (CART), Regressões Logísticas,
  •  Método Broyden-Fletcher-Goldfarb-Shanno (L-BFGS),
  •  avaliação modelo
  •  discretização.

Além de aproveitar o kernel Spark MLlib integra-se com:

  •  Spark SQL (DataFrames em entrada),
  •  Streaming (fluxo de previsão em tempo real),
  •  GraphX

Spark ML

Este subprojeto (disponível como pacote no Mllib desde a versão 1.5) é uma evolução para introduzir novos recursos (DataFrame, Pipeline) e padronizar APIs.

Mahout

Apache Mahout é um projeto da Fundação Apache desde 2011 com o objetivo de criar implementações de algoritmos de aprendizado de máquinas e mineração de dados.

Embora os principais algoritmos de aprendizagem sejam baseados no MapReduce, não existe a obrigação de usar o Hadoop.

O Apache Mahout foi projetado para funcionar sem essa dependência.

Precursor histórico, o Mahout enfrenta novas bibliotecas mais adaptadas aos algoritmos iterativos, como o MLlib da Spark (completado pela Spark ML), ou do mundo dos cientistas de dados, como o Scikit-learn ou o idioma R.

É por isso que, desde a versão 0.10.0 (abril de 2015), a Mahout usou Apache Spark e H2O (dependendo dos algoritmos).

Uma integração com o Flink está em andamento.

Este novo ambiente matemático é chamado Samsara.

Mahout-Samsara é um remake de Mahout para promover escalabilidade e desempenho, mas também fornecer uma tela para criar seus próprios algoritmos (desenvolvimento em Scala).

Samsara também oferece um shell interativo para lançar os tratamentos em um Spark cluster

O Mahout é muito rico em algoritmos de aprendizagem, agrupamento, classificação, filtragem colaborativa, análise de itens freqüentes, etc.

Clustering:

  •  K-means (paralelizável),
  •  Fuzzy K-means (paralelizável),
  •  K-means Spectral (paralelizável).

classificação:

  •  Regressão logística (não paralelizada),
  •  Naive Bayes (paralelizável),
  •  Floresta aleatória (paralelizada)
  •  Perceptron multicapa (não paralelizado).

Dimensionamento reduzido:

  •  Decomposição de valor singular (paralelizada)
  •  PCA (paralelizável),
  •  Decomposição Lanczos (paralelizada)
  •  Decomposição QR (paralelizada).

Texto:

  •  TF-IDF (paralelizável)

Akka

A Akka é uma estrutura para construir aplicativos concorrentes, distribuídos e resilientes com a JVM. A Akka é uma implementação orientada por ator que começou em 2009 por Jonas Boner e foi integrada pela primeira vez com a Scala.

A fonte de inspiração é a linguagem Erlang, que oferece uma arquitetura altamente competitiva e baseada em eventos. Akka agora é uma estrutura OpenSource suportada pelo TypeSafe (como Play e Scala), disponível tanto no Scala quanto no Java.

A programação por atores propõe os seguintes postulados:

Um ator é uma entidade que, após a recepção de um evento (mensagem) pode:

  •  enviar mensagens a outros atores
  •  criar novos atores,
  •  especifique o comportamento a seguir ao receber as mensagens que se seguem.

A execução dessas tarefas acima não está ordenada, para que elas possam ser paralelizadas.

O paradigma do ator dissocia o transmissor da mensagem da própria mensagem, permitindo assim o assincronismo das comunicações e a introdução de estruturas dedicadas ao gerenciamento das mensagens. Um ator deve conhecer o endereço do ator a quem ele deseja enviar uma mensagem. Os endereços podem ser trocados por mensagem.

Em resumo, um ator é:

  •  sistemas stateful,
  •  responde no recebimento de mensagens,
  •  envia mensagens aos atores:

> por nome ou endereço,

> em troca de receber uma mensagem,

> para um ator progenitor, …

Akka não é apenas uma implementação do modelo de ator:

  •  O apelido de transação que, no caso de um erro, permite cancelar as alterações e reiniciar o processo automaticamente.
  •  ordenou mensagens para um par transmissor / receptor.

Lista de estruturas construídas com Akka:

  •  Apache Spark,
  •  Gatling
  •  Fluxo Apache.

Akka, no entanto, tem os seguintes defeitos:

  •  processa as mensagens sequencialmente (mas podemos multiplicar o número de atores),
  •  nenhuma garantia de entrega / processamento de mensagens (entrega na maioria das vezes).