Docker – Spring Data REST e H2

Docker No Comments

Introdução

Este post tem por objetivo, incluir a aplicação Spring Data REST e H2 sob o container Docker.

Premissa

Procedimento

Com a aplicação importada em sua IDE de preferência, crie o arquivo Dockerfile (sem extensão) na raiz do projeto.

IMPORTANTE: O arquivo deve ser criado com a primeira letra maiúscula e o restante minúscula (Dockerfile). Se não for respeitado o nome, não funcionará.

Dockerfile

FROM java:8
VOLUME /tmp
ADD target/spring-rest-data-h2-1.0.0.jar app.jar
ENTRYPOINT [ "sh", "-c", "java -Djava.security.egd=file:/dev/./urandom -jar /app.jar" ]

Prompt de Comando (Terminal)

# docker build .

Aguarde todo o processo de download e instalação.

# docker images

Mostrará a imagem criada, conforme o arquivo de configuração (ex: java:8).

# docker build -t java:8 .

Identificará o REPOSITORY e TAG.

# docker run -it -p 8000:8080 java:8

Isso fará subir a imagem (java:8) sob a porta local 8000 e porta no container 8080. Perceba também que já subirá sua aplicação Spring Boot (java -jar /app.jar).

Agora, basta abrir um navegador na máquina e digitar:

http://localhost:8000

Whitelabel Error Page

This application has no explicit mapping for /error, so you are seeing this as a fallback.

Wed Jan 17 22:28:41 UTC 2018
There was an unexpected error (type=Not Found, status=404).
No message available
Sob a URL http://localhost:8000/user/list

[]

Aparecerá 2 colchetes, informando que o banco de usuários está vazio.
Pronto! Sua aplicação agora, está rodando sob o container Docker.
# CTRL + p + q (sairá do container, mas continuará rodando)
# docker stats [[CONTAINER_ID]] (apresentará o consumo de CPU, Memória e IO)

CONTAINER    CPU % MEM USAGE / LIMIT     MEM % NET I/O          BLOCK I/O    PIDS
bbcf887896ac 0.09% 326.9MiB /  3.659GiB  8.72% 26.4kB / 4.44kB  90.2MB / 0B  34

# docker stop bbcf887896ac (baixará o container)

# docker start

Remover todas as imagens (CUIDADO)

# docker rmi $(docker images -q)

Docker no Ubuntu – Dockerfile

Docker No Comments

Introdução

Objetivo desse post é apresentar o Dockerfile, um arquivo de configuração para montar uma imagem, através de passos de comandos.

How to

# mkdir dockerfile

# cd dockerfile

# mkdir apache (OBS: só pode existir um arquivo Dockerfile no diretório, por isso criamos a pasta apache)

# cd apache

# touch Dockerfile

# vi Dockerfile

FROM ubuntu:17.10
MAINTAINER lfchaim@gmail.com
RUN apt-get update && apt-get install -y apache2 && apt-get clean

# docker build .

# docker images

REPOSITORY   TAG      IMAGE ID       CREATED         SIZE
<none>       <none>   142f04da6a70   2 minutes ago   229MB

ATENÇÃO: Veja que os campos REPOSITORY e TAG não estão preenchidos. Para preenchê-los, digite.

# docker build -t ubuntu/apache:1.0 .

OBS: ubuntu/apache é o nome do REPOSITORY que desejamos criar e 1.0 a TAG.

# docker images

REPOSITORY     TAG IMAGE ID       CREATED        SIZE
ubuntu/apache  1.0 142f04da6a70   6 minutes ago  229MB

# docker run -it ubuntu/apache:1.0 /bin/bash

# ps -ef

# /etc/init.d/apache2 start

# ps -ef

Saia do Container

# CTRL + p + q

# docker inspect 13fde0c3d9e4

Pegar o IP do Container e digitar.

# curl 172.17.0.2

Pronto, a imagem foi criada conforme o Dockerfile!

Docker no Ubuntu

Docker No Comments

Introdução

O objetivo desse post é aprender a utilização do Docker no Ubuntu.

Instalação

Verificar versão do Kernel

Esse comando serve para validar a versão do Kernel. Esta versão deverá ser superior a 3.8.

# uname -r

Instalando o Docker

# curl -sSL https://get.docker.com | sh

Subindo o Docker

# /etc/init.d/docker start

Verificando se o Docker está no ar

# docker ps

Ou

# ps -ef | grep docker

Rodando uma imagem

Verificando as imagens

# docker images

Rodando e instalando o Ubuntu

Rodando o comando abaixo, na primeira vez, será baixado o Ubuntu, na versão informada.

# docker run -i -t ubuntu:17.10 /bin/bash

Ao final do processo, o Container será iniciado, sendo possível verificar que mudou o prompt do console.

Exemplo: root@6d9436afdb02:/#

Matando o Container

# CTRL + d

ATENÇÃO: Esse comando fará com que o Container encerre. Não será mais possível executá-lo. Quaiques modificações e/ou instalações serão PERDIDAS!

Sair do Container sem encerrar.

root@6d9436afdb02:/# CTRL + p + q (control + p + q)

# docker ps (verifique que o processo continua rodando)

Voltando para o Container

# docker ps

# docker attach [[CONTAINER_ID]]

Exemplo:

root@CCE:/home/fernando# docker attach 6d9436afdb02
root@6d9436afdb02:/#

Instalando ferramentas / aplicativos

NGinx

  • Crie o Container – # docker run -i -t -p 8080:80 ubuntu:17.10 /bin/bash
    • Redirecionando a porta 8080 fora do Container, na porta 80 (dentro do Container)
  • Instale o NGinx – # apt-get install nginx
    • Caso falhe – # apt-get update
  • /etc/init.d/nginx start
  • Abra um navegador e digite: http://localhost:8080

Verificando instalações efetuadas no Container

Fora do Container, digite

# docker diff [[CONTAINER_ID]]

Salvando o Container modificado

Podemos gerar uma imagem, fazendo o commit.

# docker commit [[CONTAINER_ID]] [[NOME_DA_IMAGEM:[[VERSAO]]

Exemplo:

# docker commit bae5725fbdc2 nginx-ubuntu:1.0

# docker images

Subindo novo Container com base na imagem

# docker run -i -t -p 6660:80 nginx-ubuntu:1.0 /bin/bash

Agora, temos 2 containers respondendo na porta 8080 e 6660.

Parando um Container fora dele

# docker stop [[CONTAINER_ID]]

Rodando comandos fora do container

Preparação

# docker images

REPOSITORY TAG IMAGE ID CREATED SIZE
badtux/nginx-ubuntu 1.0 004a02a614ec 22 hours ago 192MB
ubuntu 17.10 26d147d2310f 25 hours ago 96.6MB

# docker run -ti -p 8080:80 badtux/nginx-ubuntu:1.0 /bin/bash

# /etc/init.d/nginx start

# CTRL + p + q

# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c0907ccd5120 badtux/nginx-ubuntu:1.0 “/bin/bash” 49 seconds ago Up 46 seconds 0.0.0.0:8080->80/tcp friendly_heisenb

# docker exec c0907ccd5120 ps -ef

UID PID PPID C STIME TTY TIME CMD
root 1 0 0 22:13 ? 00:00:00 /bin/bash
root 31 1 0 22:13 ? 00:00:00 nginx: master process /usr/sbin/nginx
www-data 32 31 0 22:13 ? 00:00:00 nginx: worker process
www-data 33 31 0 22:13 ? 00:00:00 nginx: worker process
www-data 34 31 0 22:13 ? 00:00:00 nginx: worker process
www-data 35 31 0 22:13 ? 00:00:00 nginx: worker process
root 38 0 0 22:14 ? 00:00:00 ps -ef

# docker exec c0907ccd5120 /etc/init.d/nginx stop

Verificando as informações do Container

# docker inspect c0907ccd5120

Mostra uma série de informações como o IP do Container, Porta do Container, quando foi criado, etc.

#docker stats

Mostra um resumo do Container em relação a consumo de CPU, Memória e Rede.

# docker stop c0907ccd5120

# docker ps

# docker start c0907ccd5120

# docker rm c0907ccd5120 (ATENÇÃO: remove o Container e não será possível utilizá-lo mais)

Removendo a Imagem

# docker images

# docker rmi [[IMAGE_ID]]

# docker rmi -f [[IMAGE_ID]]

Comunicação entre containers

# docker run -it –name web02 –link friendly_heisenb:web01 badtux/nginx-ubuntu:1.0

# ping web01

Criando Dockerfile

Aguarde!

Inbound Marketing para imobiliárias

Marketing No Comments

Desde 2010, o mercado imobiliário no Brasil sofre com uma queda no número de vendas que gera consequência em toda a cadeia – segundo dados da Folha de S. Pauloo número de empregos no setor é o mais baixo desde 2008. O cenário desde então não vem apresentando melhoras. A retração do setor chegou a mais de 30% em outubro de 2015, de acordo com a Embraesp (Empresa Brasileira de Estudos de Patrimônio).

Como as expectativas não são boas, muitas empresas encontraram um caminho sem volta: fechar as portas. Para as construtoras e imobiliárias que permaneceram no mercado, a queda na concorrência contribui para a melhoria da situação. Além disso, a busca por alternativas também tem mantido empresas de portas abertas.

Estratégias diferenciadas

Apesar da crise ter desestruturado diversas construtoras, existem imobiliárias que estão conseguindo manter o crescimento – ou pelo menos evitando a retração. Para isso, foi necessário investir em diferentes tipos de estratégias. Foi nesse momento que o Inbound Marketing ganhou espaço no segmento imobiliário.

A primeira vantagem encontrada é a redução de custos com marketing. Por exemplo, para realizar uma publicação de uma página aos domingos (dia com maior circulação) em jornal impresso na região de São Paulo Capital (impacto médio de 320 mil pessoas), o investimento gira em torno de R$440 mil. No digital, esse investimento cai pra R$6 mil (saiba mais aqui).

Além do custo reduzido, o Inbound Marketing permite que seja feita a mensuração de resultados com precisão – sabemos exatamente quantas pessoas clicaram em um anúncio no Google. Por outro lado, não conseguimos medir quantas pessoas foram impactadas por um outdoor, por exemplo.

Inbound Marketing Imobiliário

Com cada vez mais adeptos, é importante mantermos um alinhamento comum sobre como é a atuação do Inbound para imobiliárias, pois existe uma limitação. A forma mais simples de explicar é pensar que uma imobiliária não funciona como um ecommerce. Não conseguimos gerar toda a venda pela internet porque o ticket é muito alto e a venda é complexa. Existem muitas variáveis que influenciam a venda, que vão desde o trabalho do corretor até a aprovação de financiamento em banco, que depende de muitos fatores.

Entretanto, mesmo que o Inbound Marketing imobiliário não seja feito 100% online, as estratégias facilitam a venda e a tornam mais rápida, uma vez que os prospects abordados estão muito mais perto do momento da compra. Por isso, separamos neste post 4 dicas práticas para iniciar um planejamento de Marketing Digital para uma construtora ou imobiliária.

1- Qualificação de Leads

Todo corretor, imobiliária ou construtora possui uma pilha de cartões ou uma lista de emails de pessoas que foram abordadas em lançamentos, feiras e eventos. O que muitas empresas observam como simples dados, para o Inbound Marketing são informações extremamente valiosas. Serão esses contatos o nossos primeiros Leads a serem trabalhados e qualificados.

Importante: Se a sua imobiliária nunca fez nenhum tipo de comunicação via email, ou se faz muito tempo que você não troca mensagens com essas pessoas, vale a pena fazer a higienização da lista primeiro, ou seja, separar os contatos que podem ser usados dos que estão inválidos. Fazer essa prática economiza tempo na prospecção e aumenta as chances de conversão em vendas futuras.

Para esses contatos, devemos iniciar a comunicação com um template de email simples. Nosso objetivo é qualificar esses Leads, uma vez que eles já tiveram um primeiro contato com a sua imobiliária. Aqui valem desde estratégias básicas, como apresentar os novos empreendimentos, até mesmo algo agressivo para venda, como fazer ofertas.

Vale ressaltar que, em paralelo, esses Leads podem receber newsletters quinzenais sobre as novidades da sua imobiliária. Essa é uma ótima forma de ser lembrado, só precisamos tomar cuidado aqui para não enviar aos clientes que já realizaram uma compra a mesma oferta novamente.

Para ver como funciona, confira nosso case: Como a Cupola vendeu um apartamento por Email Marketing.

2- Geração de Leads

Ao mesmo tempo que os Leads já existentes estão sendo qualificados, é importante que novos Leads sejam gerados. Para isso, temos 2 opções principais:

Oferta fundo de funil (perto da venda)

As ofertas diretas contribuem para geração de Leads mais qualificados, que necessitam de menos tempo de nutrição, agilizando o processo de compra. No caso de imobiliárias, algumas práticas rápidas e simples podem cumprir essa função. Separamos algumas ideias para você colocar no ar já:

    • Landing Page com contagem regressiva para lançamento de novo empreendimento;
    • Ofertas com desconto ou com benefícios como “ganhe cozinha mobiliada” ou “ 2 garagens inclusas se fechar a compra neste mês”;
    • Agendamento de visita ao apartamento decorado;
    • Avaliação do seu imóvel para troca;
    • Vídeo de apresentação do imóvel com demonstração da planta baixa.

Ofertas topo de funil (primeiros passos do Lead)

Com a oferta de fundo de funil rodando, ganhamos tempo para preparar as personas e a jornada de compra, assim como os conteúdos para topo e meio de funil, que já podem servir para nutrição de Leads posteriormente. Aqui, conteúdos educativos que destacam diferenciais dos seus empreendimentos são muito bem-vindos:

    • Manual do inquilino;
    • Comparação entre bairros;
    • Dicas de como melhorar seu apartamento para venda;
    • Importância de ter um prédio com vigilância 24h;
    • Benefícios de morar perto do trabalho;
    • Vantagens de ter academia no prédio.

3 – Segmentação de Leads

Para essas Landing Pages que citamos na dica anterior, vale lembrar que incluir estratégias para segmentação de Leads desde o início facilita o trabalho de nutrição. Por exemplo, para o material de comparação entre bairros, já podemos pedir ao Lead qual a preferência dele e pensar em um fluxo de nutrição específico para aquele bairro. Dessa forma, você envia o conteúdo adequado para a persona ideal, otimizando o processo de decisão de compra.

Já para o “Manual do Inquilino” você pode questionar ao Lead qual o objetivo dele para saber se ele tem interesse em comprar, vender ou alugar. Caso o Lead selecione “alugar” e sua imobiliária não trabalhe com aluguéis, por exemplo, esse Lead não tem potencial para se tornar um cliente, ou seja, ele não precisa participar de um fluxo de nutrição de imediato.

Algumas outras opções de campo também contribuem para a segmentação de Leads, como:

  • Quantos quartos você precisa no apartamento? (Resposta: 2/ 2 a 3/mais de 3)
  • Você possui animais de estimação? (Resposta: sim/não)
  • Você possui filhos? (Resposta: sim/não)

Lembre-se apenas de que todas as informações perguntadas em formulários de Landing Pages devem ter um objetivo futuro. Perguntar apenas para saber, além de não ter finalidade, pode diminuir a conversão de visitantes para Leads.

4 – Parcerias com negócios locais

Se a sua imobiliária está explorando uma região desconhecida ou menos populosa, faz sentido que você procure negócios locais para fazer parcerias. Uma boa ideia é fechar parcerias com restaurantes que ficam nas redondezas para divulgar o novo empreendimento.

Por exemplo, sua imobiliária pode promover concursos culturais do tipo “Por que você moraria no bairro X”, estimulando os clientes a participarem em troca de um jantar grátis naquele mesmo restaurante. Além de você contribuir para o movimento do local, você também capta Leads através de uma Landing Page simples. Lembre-se de colocar um campo “você aceita receber emails sobre o empreendimento X” para garantir uma boa taxa de abertura e clique nas suas campanhas futuras.

O mesmo fluxo funciona para outros tipos de comércio, como salão de beleza, escolas e supermercados.

Resultado

A geração de Leads para topo e fundo de funil, com ações de qualificação de Leads em paralelo, são os primeiros passos para uma estratégia efetiva de Inbound Marketing imobiliário. Com ajustes rápidos e práticos, conseguimos ter pequenos benefícios como a redução no tempo do processo de venda.

Os números de mercado indicam que hoje a decisão de compra leva de 9 a 12 meses. Por isso, quanto antes você iniciar o planejamento a execução de estratégias, mais cedo sua imobiliária vai sentir o impacto dos resultados.

Spark

Big Data No Comments

O que é o Spark

O Spark é um framework para processamento de Big Data construído com foco em velocidade, facilidade de uso e análises sofisticadas. Está sendo desenvolvido desde de 2009 pelo AMPLab da Universidade de Califórnia em Berkeley e em 2010 seu código foi aberto como projeto da fundação Apache.

O Spark tem muitas vantagens se comparado as outras tecnologias de Big Data e do paradigma MapReduce, como o Hadoop e o Storm.

Inicialmente, o Spark oferece um framework unificado e de fácil compreensão para gerenciar e processar Big Data com uma variedade de conjuntos de dados de diversas naturezas (por exemplo: texto, grafos, etc), bem como de diferentes origens (batch ou streaming de dados em tempo real).

O Spark permite que aplicações em clusters Hadoop executem até 100 vezes mais rápido em memória e até 10 vezes mais rápido em disco, desenvolver rapidamente aplicações em Java, Scala ou Python. Além disso, vem com um conjunto integrado de mais de 80 operadores de alto nível e pode ser usado de forma interativa para consultar dados diretamente do console.

Além das operações de Map/Reduce, suporta consultas SQL, streaming de dados, aprendizado de máquina e processamento de grafos. Desenvolvedores podem usar esses recursos no modo stand-alone ou combiná-los em um único pipeline.

Nesta primeira edição dessa série de artigos sobre o Apache Spark, veremos o que é o Spark, como ele se compara com uma solução típica com MapReduce e disponibiliza um conjunto completo de ferramentas para processamento de Big Data.

Hadoop e Spark

O Hadoop já existe a mais de 10 anos e tem provado ser a melhor solução para o processamento de grandes conjuntos de dados. O MapReduce, é uma ótima solução para cálculos de único processamento, mas não muito eficiente para os casos de uso que requerem cálculos e algoritmos com várias execuções. Isso porque cada etapa no fluxo de processamento tem apenas uma fase Map e uma fase Reduce e, desse modo é necessário converter qualquer caso de uso para o padrão MapReduce para chegar a uma solução.

Os dados de saída do processamento de cada etapa devem ser armazenados no sistema de arquivo distribuídos antes do passo seguinte começar. Assim, esta abordagem tende a ser lenta devido à replicação e armazenamento em disco. Além disso, as soluções Hadoop incluem tipicamente clusters que são difíceis de configurar e gerenciar, além de precisar da integração de várias ferramentas para diferentes casos de uso de Big Data (como o Mahout para Aprendizado de Máquina e o Storm para o processamento de streaming).

Nesse cenário, caso seja necessário fazer algo complexo, seria preciso encadear uma série de jobs de MapReduce e executá-los em sequência. Cada um desses jobs terão alta latência e não poderá começar até que o anterior tenha terminado.

O Spark permite que os programadores desenvolvem pipelines compostos por várias etapas complexas usando grafos direcionais acíclicos. Além disso, suporta o compartilhamento de dados da memória através desses grafos, de modo que os diferentes jobs possam trabalhar com os mesmos dados.

O Spark usa a infraestrutura do Hadoop Distributed File System (HDFS), mas melhora suas funcionalidades e fornece ferramentas adicionais. Por exemplo, permite a implantação de aplicativos em cluster Hadoop v1 (com SIMR – Spark Inside MapReduce), ou em Hadoop v2 com YARN ou com Apache Mesos.

Devemos olhar para o Spark como uma alternativa para MapReduce do Hadoop em vez de um simples substituto, mas como uma solução abrangente e unificada para gerenciar diferentes casos de uso da Big Data.

Características do Spark

O Spark estende o MapReduce evitando mover os dados durante seu processamento, através de recursos como armazenamento de dados em memoria e processamento próximo ao tempo real, o desempenho pode ser várias vezes mais rápido do que outras tecnologias de Big Data.

Também há suporte para validação sob demanda de consultas para Big Data, o que ajuda com a otimização do fluxo de processamento de dados e fornece uma API de mais alto nível para melhorar a produtividade do desenvolvedor e um modelo consistente para o arquiteto de soluções Big Data.

O Spark detém resultados intermediários na memória, em vez de escrevê-los no disco, o que é muito útil quando se precisa processar o mesmo conjuntos de dados muitas vezes. Seu projeto teve por objetivo torná-lo um mecanismo de execução que funciona tanto na memória como em disco e, por isso, o Spark executa operações em disco quando os dados não cabem mais na memória. Assim, é possível usá-lo para o processamento de conjuntos de dados maiores que a memória agregada em um cluster.

O Spark armazenará a maior quantidade possível de dados na memória e, em seguida, irá persisti-los em disco. Cabe ao arquiteto do sistema olhar para os seus dados e casos de uso para avaliar os requisitos de memória. Com esse mecanismo de armazenamento de dados em memória, o uso do Spark traz vantagens de desempenho.

Outras características do Spark:

  • Suporta mais do que apenas as funções de Map e Reduce;
  • Otimiza o uso de operadores de grafos arbitrários;
  • Avaliação sob demanda de consultas de Big Data contribui com a otimização do fluxo global do processamento de dados;
  • Fornece APIs concisas e consistentes em Scala, Java e Python;
  • Oferece shell interativo para Scala e Python. O shell ainda não está disponível em Java.

O Spark é escrito na linguagem Scala e executa em uma máquina virtual Java. Atualmente, suporta as seguintes linguagens para o desenvolvimento de aplicativos:

  • Scala
  • Java
  • Python
  • Clojure
  • R

O ecossistema do Spark

Além da API do Spark, existem bibliotecas adicionais que fazem parte do seu ecossistema e fornecem capacidades adicionais para as áreas de análise de Big Data e aprendizado de máquina.

Estas bibliotecas incluem:

  • Spark Streaming:
    • O Spark Streaming pode ser usado para processar dados de streaming em tempo real baseado na computação de microbatch. Para isso é utilizado o DStream que é basicamente uma série de RDD para processar os dados em tempo real;
  • Spark SQL:
    • Spark SQL fornece a capacidade de expor os conjuntos de dados Spark através de uma API JDBC. Isso permite executar consultas no estilo SQL sobre esses dados usando ferramentas tradicionais de BI e de visualização. Além disso, também permite que os usuários usem ETL para extrair seus dados em diferentes formatos (como JSON, Parquet, ou um banco de dados), transformá-los e expô-los para consultas ad-hoc;
  • Spark MLlib:
    • MLlib é a biblioteca de aprendizado de máquina do Spark, que consiste em algoritmos de aprendizagem, incluindo a classificação, regressão, clustering, filtragem colaborativa e redução de dimensionalidade;
  • Spark GraphX:
    • GraphX ​​é uma nova API do Spark para grafos e computação paralela. Em alto nível, o GraphX ​​estende o Spark RDD para grafos. Para apoiar a computação de grafos, o GraphX ​​expõe um conjunto de operadores fundamentais (por exemplo, subgrafos e vértices adjacentes), bem como uma variante optimizada do Pregel. Além disso, o GraphX ​​inclui uma crescente coleção de algoritmos para simplificar tarefas de análise de grafos.

Além destas bibliotecas, outros componentes completam o ecossistema do Spark, como o BlinkDB e o Tachyon.

O BlinkDB é uma engine SQL para consultas por amostragem e pode ser usado para a execução de consultas interativas em grandes volumes de dados. Permite que os usuários equilibrem a precisão de consulta com o tempo de resposta. Além disso, o BlinkDB funciona em grandes conjuntos de dados, através de amostragem de dados e apresentação de resultados anotados com os valores de erros.

O Tachyon é um sistema de arquivos distribuídos em memória que permite o compartilhamento de arquivos de forma confiável e rápida através de frameworks de cluster, como Spark e MapReduce. Também armazena em cache os arquivos que estão sendo trabalhados, permitindo que a existência de diferentes processamentos / consultas e enquadramentos para acessar arquivos em cache na velocidade de memória.

Finalmente, há também adaptadores de integração com outros produtos, como Cassandra (Cassandra Spark Connector) e R (SparkR). Com o Cassandra Connector, é possível usar o Spark para acessar dados armazenados no banco de dados Cassandra e realizar com o R análises estatísticas.

O diagrama a seguir (Figura 1) mostra como as diferentes bibliotecas do ecossistema Spark estão relacionados uns com os outros.

Figura 1. Bibliotecas do Framework Spark.

Vamos explorar todas essas bibliotecas nos próximos artigos desta série.

A arquitetura do Spark

A arquitetura Spark inclui os seguintes componentes:

  • Armazenamento de dados;
  • API;
  • Framework de gerenciamento.

Vejamos cada um desses componentes em detalhes.

Armazenamento de dados:

O Spark usa sistema de arquivos HDFS para armazenamento de dados. Funciona com qualquer fonte de dados compatível com Hadoop, incluindo o próprio HDFS, HBase, Cassandra, etc.

API:

A API permite que os desenvolvedores de aplicações criem aplicações baseadas no Spark usando uma interface de API padrão para Scala, Java e Python.

A seguir, estão os links dos site da API Spark para as linguagens: Scala, Java e Python

Gestão de recursos:

O Spark pode ser implantado como um servidor autônomo ou em uma estrutura de computação distribuída como o Mesos ou o YARN. Na Figura 2, apresentam-se os componentes da arquitetura Spark.

Figura 2. Arquitetura do Spark.

Conjunto de dados resilientes e distribuídos

O conjunto de dados resilientes e distribuídos (base do trabalho de pesquisa de Matei Zaharia) ou RDD (Resilient Distributed Datasets) é o conceito central do framework Spark. Imagine o RDD como uma tabela do banco de dados que pode guardar qualquer tipo de dado. O Spark armazena os dados do RDD em diferentes partições. Isso ajuda a reorganização computacional e a otimização no processamento dos dados.

Os RDDs são imutáveis. Ainda que aparentemente seja possível modificar um RDD com uma transformação, na verdade o resultado dessa transformação é um novo RDD, sendo que o original permanece intocável.

O RDD suporta dois tipos de operações:

Transformação: Não retornam um único valor, mas um novo RDD. Nada é avaliado quando a função de transformação é chamada, ela apenas recebe um RDD e retorna um novo RDD.

Algumas das funções de transformação são map, filter, flatMap, groupByKey, reduceByKey, aggregateByKey, pipe e coalesce.

Ação: Esta operação avalia e retorna um novo valor. Quando uma função de ação é chamado em um objeto RDD, todas as consultas de processamento de dados são computadas e o valor é retornado. Algumas das operações de ação são reduce, collect, count, first, take, countByKey e foreach.

Como instalar o Spark

Existem algumas maneiras de instalar e usar Spark: É possível instalá-lo em sua máquina para execução stand-alone ou usar uma máquina virtual (VM) disponibilizadas por fornecedores como Cloudera, Hortonworks ou MapR. Ou também é possível utilizar um Spark instalado e configurado na nuvem (como na Databricks Cloud).

Neste artigo, vamos instalar Spark como um framework stand-alone e executá-lo localmente. Vamos usar a versão 1.2.0 para o código da aplicação exemplo.

Como executar o Spark

Durante a instalação do Spark em máquina local ou na nuvem, existem diferentes maneiras nas quais é possível acessar o engine do Spark.

A tabela a seguir mostra como configurar o parâmetro Master URL para diferentes modos de funcionamento do Spark.

Como interagir com o Spark

Uma vez que o Spark esteja instalado e funcionando, é possível conectar nele usando um shell para análise interativa dos dados. O Spark Shell está disponível em Scala e Python.

Para acessá-los, execute respectivamente os comandos spark-shell.cmd e pyspark.cmd.

Console Web do Spark

Independente do modo de execução, é possível visualizar os resultados e outras estatísticas através do Web Console disponível na URL:

http://localhost:4040

O Console do Spark é mostrado na Figura 3 a seguir com abas para Stages, Storage, Ecosystem e Executor.

(Clique na imagem para ampliá-la)

Figura 3. Console Web do Spark.

Variáveis ​​compartilhadas

O Spark oferece dois tipos de variáveis ​​compartilhadas para torná-lo eficiente para execução em cluster. Estas variáveis ​são dos tipos Broadcast e Acumuladores.

Broadcast: ou variáveis ​​de difusão, permitem manter variáveis somente leitura no cache de cada máquina em vez de enviar uma cópia junto com as tarefas. Essas variáveis podem ser usadas ​​para dar aos nós do cluster as cópias de grandes conjuntos de dados.

O seguinte trecho de código mostra como usar as variáveis ​​de broadcast.

//
// Variáveis de Broadcast
//
val broadcastVar = sc.broadcast(Array(1, 2, 3))
broadcastVar.value

Acumuladores: permitem a criação de contadores ou armazenar os resultados de somas. As tarefas em execução no cluster podem adicionar valores à variável do acumulador usando o método add. No entanto, as tarefas distintas não podem ler o seu valor pois apenas o programa principal pode ler o valor de um acumulador.

O trecho de código a seguir mostra como usar criar um acumulador:

//
// Acumulador
//
val accum = sc.accumulator(0, "My Accumulator")
sc.parallelize(Array(1, 2, 3, 4)).foreach(x => accum += x)
accum.value

Amostra de uma Aplicação do Spark

A aplicação de exemplo deste artigo é um aplicativo de contagem simples de palavras. Este é o mesmo exemplo apresentado em muitos tutoriais sobre o Hadoop. Vamos realizar algumas consultas de análise de dados em um arquivo de texto. Esse arquivo e o conjunto de dados desse exemplo são pequenos, mas as mesmas consultas Spark podem ser usadas para grandes conjuntos de dados sem quaisquer modificações no código.

Para facilitar a apresentação, usaremos o shell de comandos para Scala.

Primeiramente, veremos como instalar Spark em sua máquina local.

Pré-requisitos:

  • Será necessário instalar o Java Development Kit (JDK) para trabalhar localmente. A instalação da JDK é coberta no Etapa 1 a seguir.
  • Também precisar instalar o software do Spark na sua máquina local. As instruções sobre como fazer isso são abordadas na Etapa 2 a seguir.

Nota: Estas instruções estão preparadas para ambiente o Windows. Se estiver usando um sistema operacional diferente, será necessário modificar as variáveis ​​do sistema e caminhos de diretório de acordo com seu ambiente.

I. Instalar o JDK:

1) Faça download do JDK no site Oracle. A versão 1.7 do JDK é a recomendada.

Instale o JDK em um diretório sem espaços. Isto é, para usuários do Windows, instale o JDK em uma pasta similar a “C:\dev”, e não em “C:\Arquivos de Programas”. O diretório “Arquivos de Programas” tem um espaço no nome e isso pode causar problemas quando o software é instalado nesta pasta.

Nota: Não instale o JDK ou o Spark (descrito na Etapa 2) em “C:\Arquivos de Programas”.

2) Depois de instalar o JDK, verifique se ele foi instalado corretamente navegando via prompt até a pasta “bin” dentro do diretório do JDK 1.7 e digitando o seguinte comando:

java -version

Se o JDK está instalado corretamente, o comando exibirá a versão instalada do Java.

II. Instalar o software do Spark:

Baixe a versão mais recente do Spark. A versão mais recente no momento da escrita deste artigo é Spark 1.2. É possível escolher uma instalação Spark específico, dependendo da versão do Hadoop. Baixei Spark para Hadoop 2.4 ou posterior, cujo nome do arquivo é spark-1.2.0-bin hadoop2.4.tgz.

Descompacte o arquivo de instalação em um diretório local (por exemplo: “C:\dev”).

Para verificar a instalação o Spark, navegue até o diretório e execute o shell do Spark utilizando os comandos a seguir. Isto é para Windows. Se estiver usando Linux ou Mac OS, edite os comandos para trabalhar em seu sistema operacional.

c:
cd c:\dev\spark-1.2.0-bin-hadoop2.4
bin\spark-shell

Se o Spark foi instalado corretamente, será apresentado as seguintes mensagens na saída no console.

….
15/01/17 23:17:46 INFO HttpServer: Starting HTTP Server
15/01/17 23:17:46 INFO Utils: Successfully started service 'HTTP class server' on port 58132.
Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/
   /___/ .__/\_,_/_/ /_/\_\   version 1.2.0
      /_/

Using Scala version 2.10.4 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_71)
Type in expressions to have them evaluated.
Type :help for more information.
….
15/01/17 23:17:53 INFO BlockManagerMaster: Registered BlockManager
15/01/17 23:17:53 INFO SparkILoop: Created spark context..
Spark context available as sc.

Digitar os seguintes comandos para verificar se o Spark está funcionando corretamente:

sc.version

(ou)

sc.appName

Após esta etapa, pode sair da janela de shell do Spark digitando o seguinte comando:

:quit

Para iniciar o shell do Spark Python é preciso ter o Python instalado em sua máquina. Sugerimos o download e instalação do Anaconda, que é uma distribuição Python livre e inclui vários pacotes Python populares para matemática, engenharia e análise de dados.

Em seguida, execute os seguintes comandos:

c:
cd c:\dev\spark-1.2.0-bin-hadoop2.4
bin\pyspark

Aplicação Word Count

Uma vez que já tem o Spark instalado e funcionando, podemos executar as consultas de análise de dados usando API do Spark.

A seguir temos alguns comandos simples para ler os dados de um arquivo e processá-los. Vamos trabalhar com casos de uso avançados nos próximos artigos desta série.

Primeiro, vamos usar API Spark para realizar a contagem das palavras mais populares no texto. Abra uma nova shell do Spark e execute os seguintes comandos:

import org.apache.spark.SparkContext
import org.apache.spark.SparkContext._

val txtFile = "README.md"
val txtData = sc.textFile(txtFile)
txtData.cache()

Chamamos a função de cache para armazenar o RDD criado no passo anterior, então o Spark não tem de computá-lo em cada uso nas consultas posteriores. Note que cache() é uma operação lazy, portanto o Spark não armazena imediatamente os dados na memória. Na verdade, só será alocado se uma ação for chamada no RDD.

txtData.count()

Agora, podemos chamar a função contagem para ver quantas linhas existem no arquivo de texto.

val wcData = txtData.flatMap(l => l.split(" ")).map(word => (word, 1)).reduceByKey(_ + _)

wcData.collect().foreach(println)

Se quiser ver mais exemplos de códigos de uso Spark API Core, verifique a documentação Spark em seu site.

Scrum

Agile No Comments

Introdução

Scrum (subs): Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

Scrum é:
• Leve
• Simples de entender
• Difícil de dominar

Scrum é um framework estrutural que está sendo usado para gerenciar o trabalho em produtos complexos desde o início de 1990. Scrum não é um processo, técnica ou um método definitivo. Em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa de suas práticas de gerenciamento de produto e técnicas de trabalho, de modo que você possa continuamente melhorar o produto, o time e o ambiente de trabalho.

O framework Scrum consiste de times Scrum associados a papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum.

As regras do Scrum integram os papéis, eventos e artefatos, administrando as relações e interações entre eles. As regras do Scrum são descritas ao longo deste documento.

Estratégias específicas para o uso do framework Scrum variam e são descritas em outros documentos.

O Time Scrum

Product Owner

O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto resultado do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos.

O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui:
• Expressar claramente os itens do Backlog do Produto;
• Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
• Otimizar o valor do trabalho que o Time de Desenvolvimento realiza;
• Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,
• Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos.

O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem endereçar ao Product Owner.

Para que o Product Owner tenha sucesso, toda a organização deve respeitar as decisões dele(a). As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém pode forçar o Time de Desenvolvimento a trabalhar em um diferente conjunto de requerimentos.

O Time de Desenvolvimento

O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint. Um incremento “Pronto” é requerido na Revisão da Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.

Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo.

Os Times de Desenvolvimento tem as seguintes características:
• Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente liberável;
• Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.
• O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento, independentemente do trabalho que está sendo realizado pela pessoa;
• O Scrum não reconhece sub-times no Time de Desenvolvimento, independente dos domínios de conhecimento que precisam ser abordados, tais como teste, arquitetura, operação ou análise de negócios; e,
• Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo;

Tamanho do time

O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar um trabalho significativo dentro da Sprint. Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando um Time de Desenvolvimento incapaz de entregar um
incremento potencialmente liberável. Havendo mais de nove integrantes é exigida muita coordenação. Times de Desenvolvimento grandes geram muita complexidade para que um processo empírico seja útil. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, a menos que eles também executem o trabalho do Backlog da Sprint.

O Scrum Master

O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum.

O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor
criado pelo Time Scrum.

O Scrum Master trabalhando para o Product Owner

O Scrum Master serve o Product Owner de várias maneiras, incluindo:
• Garantindo que objetivos, escopo e domínio do produto sejam entendidos o melhor possível por todos do Time Scrum
• Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
• Ajudando o Time Scrum a entender as necessidades para ter items de Backlog do Produto claros e concisos.
• Compreendendo o planejamento do Produto em um ambiente empírico;
• Garantindo que o Product Owner saiba como organizar o Backlog do Produto para maximar valor;
• Compreender e praticar a agilidade; e,
• Facilitar os eventos Scrum conforme exigidos ou necessários.

O Scrum Master trabalhando para o Time de Desenvolvimento

O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo:
• Treinando o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;
• Ajudando o Time de Desenvolvimento na criação de produtos de alto valor;
• Removendo impedimentos para o progresso do Time de Desenvolvimento;
• Facilitando os eventos Scrum conforme exigidos ou necessários; e,
• Treinando o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

O Scrum Master trabalhando para a Organização

O Scrum Master serve a Organização de várias maneiras, incluindo:
• Liderando e treinando a organização na adoção do Scrum;
• Planejando implementações Scrum dentro da organização;
• Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;
• Causando mudanças que aumentam a produtividade do Time Scrum; e,
• Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na organização.

Eventos Scrum

Sprint

O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, incremento de produto potencialmente liberável é criado. Sprints tem durações consistentes ao longo de todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.
As Sprints contém e consistem de um planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e uma retrospectiva da Sprint.

Durante a Sprint:
• Não são feitas mudanças que possam por em perigo o objetivo da Sprint;
• As metas de qualidade não diminuem; e,
• O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido.

Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem uma meta do que é para ser construído, um plano previsto e flexível que irá guiar a construção, o trabalho e o produto resultante do incremento.

Sprints são limitadas a um mês corrido. Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer. Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido.

Cancelamento da Sprint

Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master.

A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem. Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido.

Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente liberável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado.

O cancelamento de Sprints consome recursos, já que todos se reagrupam em outro planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns.

Planejamento da Sprint

O trabalho a ser realizado na Sprint é planejado durante o planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum.

O Planejamento da Sprint é um um time-boxed com no máximo oito horas para uma Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box.

O planejamento da Sprint responde as seguintes questões:
• O que pode ser entregue como resultado do incremento da próxima Sprint?
• Como o trabalho necessário para entregar o incremento será realizado?

Definição de Pronto na Sprint

O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint. O Product Owner debate o objetivo que a Sprint deve realizar e os itens de Backlog do Produto que, se completados na Sprint, atingirão o objetivo da Sprint. Todo o Time Scrum colabora com o entendimento do trabalho da Sprint.

A entrada desta reunião é o Backlog do Produto, o mais recente incremento do produto, a capacidade projetada do Time de Desenvolvimento durante a Sprint e o desempenho passado do Time de Desenvolvimento. O número de itens selecionados do Backlog do Produto para a Sprint é o único trabalho do Time de Desenvolvimento. Somente o Time de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima Sprint.

Durante o Planejamento da Sprint, o Time Scrum também determina a meta da Sprint. A meta da Sprint é o objetivo que será satisfeito dentro da Sprint através da implementação do Backlog do Produto, e que fornece a orientação para o Time de Desenvolvimento sobre o porquê dele estar construindo o incremento.

Como o trabalho será Pronto?

Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog da Sprint.

O Time de Desenvolvimento frequentemente inicia o desenho do sistema e do trabalho necessário para converter o Backlog do Produto em um incremento funcional do produto. O trabalho pode ser de vários tamanhos ou esforços. Contudo, o trabalho suficiente é planejado durante o planejamento da Sprint pelo Time de Desenvolvimento para prever o que este acredita que poderá fazer durante a próxima Sprint. O trabalho planejado pelo Time de Desenvolvimento para os primeiros dias da Sprint é decomposto até o final desta reunião, frequentemente em unidades de um dia de duração ou menos. O Time de Desenvolvimento se auto-organiza para realizar todo o trabalho do Backlog da Sprint, tanto durante o planejamento da Sprint quanto no que for necessário durante a Sprint.

O Product Owner pode ajudar a clarificar os itens de Backlog do Produto selecionados e nas decisões conflituosas de troca. Se o Time de Desenvolvimento determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint podem ser renegociados com o Product Owner.

O Time de Desenvolvimento também pode convidar outras pessoas para participar desta reunião para fornecer opinião técnica ou de domínios específicos.

No final do planejamento da Sprint, o Time de Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe auto-organizada para completar o objetivo da Sprint e criar o incremento previsto.

Meta da Sprint

A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do Produto. Este fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento. Este é criado durante a reunião de planejamento da Sprint. O objetivo da Sprint dá ao Time de Desenvolvimento alguma flexibilidade a respeito da funcionalidade que será completada dentro da Sprint. Os itens do Backlog do Produto selecionados entregam uma função coerente, que pode ser o objetivo da Sprint. O objetivo da Sprint pode ser qualquer outro coerente que faça o Time de Desenvolvimento trabalhar em conjunto em vez de em iniciativas separadas.

Conforme o Time de Desenvolvimento trabalha, eles mantêm o objetivo da Sprint em mente. A fim de satisfazer o objetivo da Sprint, implementando funcionalidade e tecnologia. Caso o trabalho acabe por ser diferente do esperado pelo Time de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo do Backlog da Sprint dentro da Sprint.

Daily Meeting

A Reunião Diária do Scrum é um evento time-boxed de 15 minutos para o Time de Desenvolvimento. A Reunião Diária é realizada em todos os dias da Sprint. Nela o Time de Desenvolvimento planeja o trabalho para as próximas 24 horas. Isso otimiza a colaboração e a performance do time através da inspeção do trabalho desde a última Reunião Diária, e da previsão do próximo trabalho da Sprint. A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade.

O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o progresso tende na direção de completar o trabalho do Backlog da Sprint. A Reunião Diária aumenta a probabilidade do Time de Desenvolvimento atingir o objetivo da Sprint. Todos os dias, o Time de Desenvolvimento deve entender como o mesmo pretende trabalhar em conjunto, como um time auto-organizado, para completar o objetivo da Sprint e criar o incremento previsto até o final da Sprint.

A estrutura da reunião é definida pelo Time de Desenvolvimento e pode ser conduzida de diferentes formas desde que estas foquem no progresso em direção à Meta da Sprint. Alguns Times de Desenvolvimento utilizarão perguntas, outros se basearão em discussões. Aqui segue um exemplo do que pode ser utilizado:
• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint?
O Time de Desenvolvimento ou membros da equipe frequentemente se encontram imediatamente após a Reunião Diária para discussões detalhadas, ou para adaptar, ou replanejar, o restante do trabalho da Sprint.

O Scrum Master assegura que o Time de Desenvolvimento tenha a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária. O Scrum Master ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos.

A Reunião Diária é uma reunião interna do Time de Desenvolvimento. Se outros estiverem presentes, o Scrum Master deve garantir que eles não perturbem a reunião. Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento do Time de Desenvolvimento. Esta é uma reunião chave para inspeção e adaptação.

Review Sprint

A Revisão da Sprint é realizada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento destina-se a motivar e obter feedback e promover a colaboração.

Esta é uma reunião de no máximo 4 horas de duração para uma Sprint de um mês. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam o seu propósito. O Scrum Master ensina todos os envolvidos a manter a reunião dentro do Time-box.

A Revisão da Sprint inclui os seguintes elementos:
• Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner;
• O Product Owner esclarece quais itens do Backlog do Produto foram “Prontos” e quais não foram “Prontos”;
• O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos;
• O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento;
• O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta os prováveis alvos e datas de entrega baseado no progresso até a data (se necessário);
• O grupo todo colabora sobre o que fazer a seguir, e é assim que a Revisão da Sprint fornece valiosas entradas para o Planejamento da Sprint subsequente;
• Revisão de como o mercado ou o uso potencial do produto pode ter mudado e o que é a coisa mais importante a se fazer a seguir; e,
• Revisão da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima versão esperada de funcionalidade ou de capacidade do produto.

O resultado da Revisão da Sprint é um Backlog do Produto revisado que define os prováveis Itens de Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades.

Retrospective Sprint

A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.

A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes do planejamento da próxima Sprint. Esta é uma reunião de no máximo três horas para uma Sprint de um mês. Para Sprint menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito.

O Scrum Master garante que o evento seja positivo e produtivo. O Scrum Master ensina todos a manter o evento dentro do time-box. O Scrum Master participa da reunião como um membro auxiliar do time devido a sua responsabilidade pelo processo Scrum.

O propósito da Retrospectiva da Sprint é:
• Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos
processos e às ferramentas;
• Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,
• Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;

O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo do framework do Scrum, seu processo de desenvolvimento e suas práticas para torná-lo mais efetivo e agradável para a próxima Sprint. Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar a qualidade do produto melhorando o processo de trabalho ou adaptando a definição de “Pronto”, se apropriado e sem entrar em conflito com os padrões do produto ou
organização.

Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio. Apesar de que melhorias podem ser implementadas a qualquer momento, a Retrospectiva da Sprint fornece uma oportunidade formal focada em inspeção e adaptação.

Artefatos do Scrum

Product Backlog

O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação.
Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. Se um produto existe, seu Backlog do Produto também existe.

O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor. Os itens do Backlog geralmente incluem descrições de testes que comprovarão sua completude quando “Prontos”.

Enquanto um produto é usado e ganha valor, e o mercado fornece feedback, o Backlog do Produto torna-se uma lista maior e mais completa. Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo. Mudanças nos requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças no Backlog do Produto.

Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto. Um Backlog do Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog do Produto que agrupe itens pode ser então aplicado.

O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto. Este é um processo contínuo no qual o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto. Durante o refinamento do Backlog do Produto, os itens são inspecionados e revisados. O Time de Scrum decide como e quando o refinamento está “Pronto”. Este refinamento usualmente não consome mais de 10% da capacidade do Time de Desenvolvimento. Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner.

Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior detalhamento; Quanto menor a ordem na lista, menos detalhes. Os itens do Backlog do Produto que irão ocupar o Time de Desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro do time-boxed da Sprint. Os itens do Backlog do Produto que podem ser “Prontos” pelo Time de Desenvolvimento dentro de uma Sprint são considerados “Preparados” para seleção no Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem este grau de transparência através das atividades de refinamento descritas acima.

O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve influenciar o Time de Desenvolvimento, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalho fazem a estimativa final.

Monitorando o progresso

Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser somado. O Product Owner acompanha o total do trabalho restante pelo menos a cada Revisão da Sprint. O Product Owner compara este valor com o trabalho restante nas Revisões das Sprints anteriores, para avaliar o progresso na direção de completar o trabalho previsto pelo tempo desejado para alcançar o objetivo. Esta informação deve ser transparente para todas as partes interessadas.

Várias práticas para prever tendências foram usadas para prever o progresso, tais como burndowns, burn-ups, ou fluxos cumulativos. Estas tem se provado úteis. Contudo, não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido.
Somente o que já acorreu pode ser usado para uma tomada de decisão a respeito do que virá.

Sprint Backlog

O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint.

O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”.

O Backlog da Sprint torna visível todo o trabalho que o Time de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint. Para garantir melhoria contínua, é incluído no mínimo um item de prioridade alta sobre melhoria do processo identificado na última Reunião de Retrospectiva.

O Backlog da Sprint é um plano com detalhes suficientes que as mudanças no progresso sejam entendidas durante a Reunião Diária. O Time de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre quando o Time de Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para atingir o objetivo da Sprint.

Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o Time de Desenvolvimento planeja completar durante a Sprint, e que pertence exclusivamente ao Time de Desenvolvimento.

Monitoramento do progresso da Sprint

Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do Backlog da Sprint pode ser somado. O Time de Desenvolvimento monitora o total do trabalho restante pelo menos a cada Reunião Diária para projetar a probabilidade de alcançar o objetivo da Sprint. Ao acompanhar o trabalho restante ao longo de toda a Sprint, o Time de Desenvolvimento pode gerenciar o seu progresso.

Incremento

O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição de ser utilizado e atender a definição de “Pronto” do Time Scrum. Um incremento é uma parte principal inspecionável de trabalho pronto que suporta empirismo no final da sprint. O incremento é um passo na direção de uma visão ou de um objetivo. O incremento deve estar na condição de ser utilizado independente do Product Owner decidir por liberá-lo ou não.

Transparência do Artefato

Scrum invoca transparência. Decisões para otimizar o valor e o controle de riscos são feitos com base na percepção existente do estado dos artefatos. Na medida em que a transparência é plena, estas decisões tem uma base sólida. Na medida em que os artefatos não são completamente transparentes, estas decisões podem ser falhas, valores podem diminuir e riscos podem aumentar.

O Scrum Master deve trabalhar com o Product Owner, Time de Desenvolvimento, e outras partes envolvidas para entender se os artefatos estão plenamente transparentes. Há práticas para lidar com transparência incompleta, o Scrum Master deve ajudar todos a aplicar a mais apropriada prática na falta de uma transparência plena. O Scrum Master pode detectar transparência incompleta pela inspeção dos artefatos, percebendo padrões, ouvindo atentamente o que está sendo dito, e detectando diferenças entre o esperado e os resultados reais.

O trabalho do Scrum Master é trabalhar com o Time Scrum e com a organização para aumentar a transparência dos artefatos. Este trabalho geralmente envolve aprendizagem, convencimento e mudança. Transparência não ocorre de um dia para o outro, mas é um caminho.

Definição de Pronto

Quando um item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa. Embora, isso possa variar por Time Scrum, os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho esta completado no incremento do produto.

A mesma definição orienta o Time de Desenvolvimento no conhecimento de quantos itens do Backlog do Produto podem ser selecionados durante o Planejamento da Sprint. O propósito de cada Sprint é entregar incrementos de funcionalidades potencialmente liberáveis que aderem à definição atual de “Pronto” do Time Scrum.

O Time de Desenvolvimento entrega um incremento de funcionalidade do produto a cada Sprint. Este incremento é utilizável, então o Product Owner pode escolher por liberá-lo imediatamente. Se a definição de “Pronto” para um incremento é parte das convenções, padrões ou diretrizes de desenvolvimento da organização, todos os Times Scrum devem seguila como um mínimo.

Se “Pronto” para um incremento não é uma convenção de desenvolvimento da organização, o Time de Desenvolvimento do Time Scrum deve definir uma definição de “pronto” apropriada para o produto. Se há múltiplos Times Scrum trabalhando no sistema ou versão do produto, os Times de Desenvolvimento de todos os Times Scrum devem mutuamente definir uma definição de “Pronto”.

Cada incremento é adicionado a todos os incrementos anteriores e completamente testado, garantindo que todos os incrementos funcionam juntos.
Como um Time Scrum maduro, é esperado que a sua definição de “Pronto” seja expandida para incluir critérios mais rigorosos de alta qualidade. Novas definições, quando usadas, podem descobrir trabalho a ser feito em incrementos “Prontos” anteriormente. Qualquer produto ou sistema deve ter uma definição de “Pronto” que é um padrão para qualquer trabalho feito sobre ele.

 

Kinesis Streams

Motor de Busca No Comments

Introdução

O Amazon Kinesis Data Streams consome uma grande quantidade de dados em tempo real, armazena os dados de forma durável e os torna disponíveis para consumo. A unidade de dados armazenada pelo Kinesis Data Streams é um registro de dados. Um streamrepresenta uma sequência ordenada de registros de dados. Os registros de dados em um stream são distribuídas em shards (fragmentos).

Uma shard é um grupo de registros de dados em um stream. Quando você cria um stream, você especifica o número de shards desse stream. Cada shard pode suportar até 5 transações por segundo para leituras, até uma taxa total máxima de leitura de dados de 2 MB por segundo. Shards também suportam até 1.000 registros por segundo para gravações, até uma taxa total máxima de gravação de dados de 1 MB por segundo (inclusive chaves de partição). A capacidade total de um stream é a soma das capacidades de suas shards. Você pode aumentar ou diminuir o número de shards em um stream de acordo com a necessidade. No entanto, você é cobrado por shard (e muito bem cobrado).

Um produtor coloca registros de dados em shards e um consumidor obtém registros de dados a partir delas.

Como determinar o tamanho inicial do Kinesis Stream

Antes de criar um stream, você precisa determinar um tamanho inicial para ele. Depois de criá-lo, você pode aumentar ou diminuir dinamicamente a capacidade de seu shard usando o Console de gerenciamento da AWS ou a API UpdateShardCount. Você pode fazer atualizações enquanto houver umaAmazon Kinesis Data Streams application consumindo dados do stream.

Para determinar o tamanho inicial de um stream, você precisa dos seguintes valores de entrada:

  • O tamanho médio do registro de dados gravado no stream do em kilobytes (KB) arredondando para o próximo 1 KB, o tamanho dos dados (average_data_size_in_KB).
  • O número de registros de dados gravados e lidos no stream por segundo (records_per_second).
  • O número de Amazon Kinesis Data Streams applications que consomem dados simultânea e independentemente do stream, ou seja, os consumidores (number_of_consumers).
  • A largura de banda de gravação de entrada em KB (incoming_write_bandwidth_in_KB), que é igual a average_data_size_in_KBmultiplicado por records_per_second.
  • A largura de banda de leitura de saída em KB (outgoing_read_bandwidth_in_KB), que é igual a incoming_write_bandwidth_in_KBmultiplicado por number_of_consumers.

Você pode calcular o número inicial de shards (number_of_shards) que seu stream precisará usando os valores de entrada na seguinte fórmula:

number_of_shards = max(incoming_write_bandwidth_in_KB/1000, outgoing_read_bandwidth_in_KB/2000)

Criar um Stream

Você pode criar um stream usando o console do Kinesis Data Streams, a API do Kinesis Data Streams ou a AWS CLI.

Para criar um stream usando o console

  1. Abra o console do Kinesis Data Streams em https://console.aws.amazon.com/kinesis/.
  2. Na barra de navegação, expanda o seletor de região e escolha uma região.
  3. Selecione Create Stream.
  4. Na página Create Stream, insira um nome para o stream e o número de shards necessárias e, em seguida, clique em Criar.

    Na página Stream List, o Status de seu stream será CREATING enquanto ele estiver sendo criado. Quando o stream fica pronto para uso, o Status é alterado para ACTIVE.

  5. Escolha o nome do fluxo. A página Stream Details exibe um resumo da configuração do fluxo com informações de monitoramento.

Para criar um stream usando a API do Kinesis Data Streams

  • Para obter informações sobre a criação de um stream usando a API do Kinesis Data Streams, consulte Criar um stream.

Para criar um stream usando a AWS CLI

  • Para obter mais informações sobre a criação de um stream usando a AWS CLI, consulte o comando create-stream.

Atualizar um Stream

Você pode atualizar os detalhes de um stream usando o console do Kinesis Data Streams, a API do Kinesis Data Streams ou a AWS CLI.

nota

Você pode ativar a criptografia no lado do servidor para streams existentes ou para os recém-criados.

Para atualizar um stream usando o console

  1. Abra o console do Kinesis Data Streams em https://console.aws.amazon.com/kinesis/.
  2. Na barra de navegação, expanda o seletor de região e selecione uma região.
  3. Escolha o nome do fluxo. A página Stream Details exibe um resumo das informações de configuração e monitoramento do stream.
  4. Para editar o número de shards, selecione Editar na seção shards e, em seguida, insira uma nova shard.
  5. Para ativar a criptografia de registros de dados no lado do servidor, selecione Editar na seção de Criptografia no lado do servidor. Escolha uma chave do KMS para usar como chave mestra de criptografia, ou use a chave mestra padrão, aws/kinesis, gerenciada pelo Kinesis. Se você ativar a criptografia para um stream e usar sua própria chave mestra do KMS, seus aplicativos produtores e consumidores precisam ter acesso à chave mestra do KMS que você usou. Para atribuir permissões a um aplicativo para acessar uma chave do KMS gerado pelo usuário, consulte Permissões para usar as chaves mestras do KMS geradas pelo usuário
  6. Para editar o período de retenção de dados, selecione Editar na seção de Período de retenção de dados e, em seguida, insira um novo período de retenção de dados.
  7. Se você tiver ativado as métricas personalizadas na sua conta, selecione Editar na seção Métricas em nível de shard e, em seguida, especifique as métricas de seu stream. Para obter mais informações, consulte Monitorar o serviço do Amazon Kinesis Data Streams com o Amazon CloudWatch.

Atualizar um Stream usando a API

Para atualizar os detalhes do stream usando a API, consulte os seguintes métodos:

 

JHipster – Introdução

NodeJs No Comments

Conceito

JHipster é um poderoso framework que ajuda a criar aplicações Java, Spring Boot e Angular.

Instalação

Pré-requisitos

  • Java 8
  • Node.js
  • Yarn

Instalando JHipster

Para instalação, execute os itens abaixo.

  • npm i -g bower
  • npm i -g yeoman-doctor
  • npm cache clean -f
  • npm i -g yo
  • npm install -g generator-jhipster

Criando projeto

Para criar um projeto.

  • Crie um diretório onde deseja que seja criado o projeto, por exemplo /opt/jhipster-teste/.
  • Execute o comando
    • yo jhipster
  • Ele poderá fazer algumas perguntas sobre ajuda anônima

Tipo de Aplicação

? Which *type* of application would you like to create? (Use arrow keys)
> Monolithic application (recommended for simple projects)
Microservice application
Microservice gateway
JHipster UAA server (for microservice OAuth2 authentication)

Nome da Aplicação

? What is the base name of your application? (jhipster)

Nome do Pacote

? What is your default Java package name? (com.mycompany.myapp)

Configuração de Monitor

? Do you want to use the JHipster Registry to configure, monitor and scale your application? (Use arrow keys)
> No
Yes

Tipo de Banco de Dados

? Which *type* of database would you like to use? (Use arrow keys)
> SQL (H2, MySQL, MariaDB, PostgreSQL, Oracle, MSSQL)
MongoDB
Cassandra
[BETA] Couchbase

Tipo de BD – Produção

? Which *production* database would you like to use? (Use arrow keys)
> MySQL
MariaDB
PostgreSQL
Oracle (Please follow our documentation to use the Oracle proprietary driver)
Microsoft SQL Server

Tipo de BD – Development

? Which *development* database would you like to use? (Use arrow keys)
> H2 with disk-based persistence
H2 with in-memory persistence
MySQL

Tipo de Cache

? Do you want to use the Spring cache abstraction? (Use arrow keys)
> Yes, with the Ehcache implementation (local cache, for a single node)
Yes, with the Hazelcast implementation (distributed cache, for multiple nodes)
[BETA] Yes, with the Infinispan (hybrid cache, for multiple nodes)
No (when using an SQL database, this will also disable the Hibernate L2 cache)

Hibernate 2nd level

? Do you want to use Hibernate 2nd level cache? (Y/n)

Ferramenta de build

? Would you like to use Maven or Gradle for building the backend? (Use arrow keys)
> Maven
Gradle

Outras tecnologias

? Which other technologies would you like to use? (Press <space> to select, <a> to toggle all, <i> to inverse selection
)
>( ) Social login (Google, Facebook, Twitter)
( ) Search engine using Elasticsearch
( ) WebSockets using Spring Websocket
( ) API first development using swagger-codegen
( ) Asynchronous messages using Apache Kafka

Client Framework (Angular)

? Which *Framework* would you like to use for the client? (Use arrow keys)
> Angular 5
AngularJS 1.x

Biblioteca SASS

? Would you like to enable *SASS* support using the LibSass stylesheet preprocessor? (y/N)

Internacionalização

? Would you like to enable internationalization support? (Y/n)

Idioma nativo

? Please choose the native language of the application (Use arrow keys)
> English
Estonian
Farsi
French
Galician
German
Greek
(Move up and down to reveal more choices)

Idiomas adicionais

? Please choose additional languages to install (Press <space> to select, <a> to toggle all, <i> to inverse selection)
>( ) Arabic (Libya)
( ) Armenian
( ) Catalan
( ) Chinese (Simplified)
( ) Chinese (Traditional)
( ) Czech
( ) Danish
(Move up and down to reveal more choices)

Frameworks de testes

? Besides JUnit and Karma, which testing frameworks would you like to use? (Press <space> to select, <a> to toggle all,
<i> to inverse selection)
>( ) Gatling
( ) Cucumber
( ) Protractor

Geradores adicionais

? Would you like to install other generators from the JHipster Marketplace? (y/N)

Geradores adicionais – escolha

? Which other modules would you like to use? (Press <space> to select, <a> to toggle all, <i> to inverse selection)
>( ) (ignite-jhipster-1.5.1) A React Native boilerplate for JHipster apps.
( ) (generator-jhipster-module-2.3.1) JHipster module, used to create a JHipster module
( ) (generator-jhipster-docker-2.4.0) Additional Docker support: Docker Hub, Local SMTP Server, NGinx
( ) (generator-jhipster-primeng-2.0.18) Generate PrimeNG Components
( ) (generator-jhipster-circleci-2-1.1.2) Generating CircleCI configuration file version 2 for a JHipster project
( ) (generator-jhipster-ci-1.0.0) JHipster module, Continuous Integration support in your JHipster application
( ) (generator-jhipster-bootstrap-material-design-3.5.1) Add Material design to your JHipster application
(Move up and down to reveal more choices)

Processo de instalação

yarn install v1.3.2
info No lockfile found.
[1/5] Validating package.json…
[2/5] Resolving packages…

Server application generated successfully.

Run your Spring Boot application:
./mvnw (mvnw if using Windows Command Prompt)

Client application generated successfully.

Start your Webpack development server with:
yarn start

Application successfully committed to Git.

Importando arquivo JDL

É possível criar um arquivo de modelagem do JHipster (arquivo .jdl) através do JDL-Studio:

https://start.jhipster.tech/jdl-studio/

Após gerar e baixar o arquivo (geralmente será jhipster-jdl.jh), no diretório do projeto.

Executar o comando para importar as entidades (veja que o arquivo foi renomeado):

$ jhipster import-jdl ./jhipster-jdl

Rodando a aplicação

Entre no diretório da aplicação e digite:

$ mvnw

Abrir um navegador e digitar:

http://localhost:8080 (usr e pwd: admin)

JSON Server

NodeJs No Comments

Introdução

Para simulação de aplicações REST, existe uma poderosa ferramenta que pode ser utilizada, o JSON Server.

Conceito

Entender o funcionamento dessa ferramenta é simples. Ele utiliza a definição de um arquivo de dados no formato Json e, disponibiliza os métodos para interagir, através de chamadas http (GET, POST, PUT, DELETE, etc).

Se fizermos request do tipo POST, PUT, DELETE, etc, o conteúdo do arquivo json será atualizado, através do lowdb.

Exemplo

Instalar a ferramenta

A instalação é feita através do comando npm.

  • Abra um prompt de comando
  • Digite o comando para instalar o json-server
  • $ npm install -g json-server
  • Pode-se constatar a instalação com o comando
  • $ json-server -v
    • 0.12.1

Criar arquivo json

Devemos, agora, criar um arquivo db.json, que servirá para armazenar os dados que desejamos utilizar.

Exemplo (db.json):

{
   "posts": [
      { "id": 1, "title": "json-server", "author": "typicode" }
   ],
   "comments": [
      { "id": 1, "body": "some comment", "postId": 1 }
   ],
   "profile": { "name": "typicode" }
}

Subindo o servidor

Para subir o serviço, utilizamos o comando json-server.

  • Abra um prompt de comando
  • Vá ao diretório, onde encontra-se o arquivo db.json
  • Digite o comando
  • $ json-server db.json

Como resultado, será apresentado alguns exemplos de chamada. Utilizando CTRL+C pára o servidor.

\{^_^}/ hi!

Loading db.json
Done

Resources
http://localhost:3000/posts
http://localhost:3000/comments
http://localhost:3000/profile

Home
http://localhost:3000

Type s + enter at any time to create a snapshot of the database

Exemplos:

http://localhost:3000/comments

http://localhost:3000/comments/1

 


							
 
		
		

											
 
	
 
									
	

				

							

					Dados em streaming
				

						
  
Mensagens No Comments
					
 

					

				
Introdução


Dados em streaming são dados gerados continuamente por milhares de fontes de dados, que geralmente enviam os registros de dados simultaneamente, em tamanhos pequenos (na ordem dos kilobytes). Os dados em streaming incluem uma ampla variedade de dados, como arquivos de log gerados por clientes usando seus aplicativos móveis ou da web, compras de e-commerce, atividade de jogador durante o jogo, informações de redes sociais, pregões financeiros ou serviços geoespaciais, como também telemetria de serviços conectados ou instrumentação em datacenters.


Esses dados devem ser processados sequencial e incrementalmente por registro ou durante períodos móveis, e usados para uma ampla variedade de dados analíticos, como correlações, agregações, filtragem e amostragem. As informações derivadas de tais análises proporcionam às empresas visibilidade sob vários aspectos de suas atividades de negócios e de clientes, como uso de serviços (para medição/faturamento), atividade do servidor, cliques no site, além da geolocalização de dispositivos, pessoas e mercadorias, permitindo que elas respondam de imediato a situações emergentes. Por exemplo, as empresas podem monitorar alterações na percepção pública de suas marcas e produtos, analisando continuamente streams de mídias sociais e respondendo em tempo hábil, conforme o surgimento das necessidades.


Benefícios


O processamento de dados em streaming é benéfico na maioria dos cenários em que novos dados dinâmicos são gerados continuamente. Ele se aplica à maior parte dos casos de uso de segmentos do setor e de big data. Geralmente, as empresas começam com aplicações simples, como a coleta de logs do sistema, e processamentos rudimentares, como a rotação de computações mín/máx. Então, essas aplicações se desenvolvem, tornando-se um processamento mais sofisticado praticamente em tempo real. Inicialmente, as aplicações podem processar streams de dados para produzir relatórios simples e executar ações pouco complexas em resposta, como emitir alertas quando medidas fundamentais excederem determinados limites. Eventualmente, essas aplicações executam modelos de análise de dados mais sofisticados, como a aplicação de algoritmos de aprendizagem de máquina e a obtenção de informações mais profundas dos dados. Com o tempo, são aplicados algoritmos complexos de processamento em streams e de eventos, como períodos cada vez menores para a localização de filmes, enriquecendo ainda mais as informações obtidas.


Exemplos


    

  • Sensores em veículos de transporte, equipamentos industriais e máquinas agrícolas enviam dados para uma aplicação de streaming. A aplicação monitora o desempenho, detecta de antemão qualquer defeito em potencial e faz automaticamente pedidos de peças extras, o que evita períodos de inatividade do equipamento.
    • 

  • Uma instituição financeira monitora alterações na bolsa de valores em tempo real, calcula o valor em risco e recompõe carteiras com base nas flutuações de preço das ações.
    • 

  • Um site do setor imobiliário monitora um subconjunto de dados de dispositivos móveis de consumidores e recomenda em tempo real propriedades a visitar com base em sua localização geográfica.
    • 

  • Uma empresa de energia solar precisa manter a produtividade da energia para seus clientes, ou pagará multas. Ela implementou uma aplicação de dados em streaming que monitora todos os painéis em campo, e programa serviços em tempo real, o que minimiza os períodos de baixa produtividade de cada painel e os pagamentos de multas associados.
    • 

  • Uma editora transmite bilhões de registros de sequências de cliques de suas propriedades on-line, agrega e enriquece dados com informações demográficas sobre usuários e otimiza a disposição do conteúdo no site, proporcionando relevância e uma melhor experiência para o público.
    • 

  • Uma empresa de jogos on-line coleta dados em streaming sobre as interações dos jogadores com o jogo e alimenta os dados em sua plataforma de jogos. Em seguida, a empresa analisa os dados em tempo real, oferece incentivos e experiências dinâmicas para envolver seus jogadores.
    • 



Processamento em lote vs. Processamento em streams


Antes de utilizar dados em streaming, vale a pena comparar o processamento em streams e o processamento em lotes. O processamento em lotes pode ser utilizado para computar consultas arbitrárias sobre diferentes conjuntos de dados. Ele geralmente computa resultados derivados de todos os dados que engloba e permite a análise profunda de conjuntos de big data. Sistemas baseados em MapReduce, são exemplos de plataformas compatíveis com trabalhos em lote. Em comparação, o processamento em streams exige a ingestão de uma sequência de dados e a atualização incremental de métricas, relatórios e estatísticas de resumo em resposta a cada registro de dados recebido. Ele é mais adequado para funções de monitoramento e resposta em tempo real.











Processamento em lotes
Processamento em streams




 Escopo de dados
Consultas ou processamento de todos ou da maioria dos dados no conjunto de dados.
Consultas ou processamento de dados dentro de um período rotacional, ou apenas do registro de dados mais recente.




Tamanho dos dados
Grandes lotes de dados.
Registros individuais ou microlotes compostos de alguns registros.




Desempenho
Latências em minutos para horas.
Exige latência na ordem dos segundos ou milissegundos.




Análise
Dados analíticos complexos.
Métricas simples de funções, agregação e rotação de respostas.














Muitas empresas estão criando um modelo híbrido ao combinar as duas abordagens, além de manter uma layer em tempo real e uma layer em lote. Primeiro, os dados são processados por uma plataforma de dados em streaming, para extrair informações em tempo real, e depois são mantidos em um armazém, como o S3, onde podem ser transformados e carregados para uma variedade de casos de uso de processamento em lotes.


Funcionamento




O processamento de dados em streaming exige duas layers: uma de armazenamento e outra de processamento. A layer de armazenamento precisa suportar a solicitação de registros e uma forte consistência para permitir leituras e gravações rápidas, de baixo custo e reproduzíveis, de grandes streams de dados. A layer de processamento é responsável pelo consumo de dados da layer de armazenamento, realizando cálculos sobre esses dados e, em seguida, enviando notificações para a layer de armazenamento excluir os dados desnecessários. Você também deve planejar a escalabilidade, a durabilidade de dados e a tolerância a falhas nas layers de armazenamento e processamento. Como resultado, surgiram muitas plataformas que disponibilizam a infraestrutura necessária para criar aplicações de dados de streaming, como Amazon Kinesis Streams, Amazon Kinesis Firehose, Apache Kafka, Apache Flume, Apache Spark Streaming e Apache Storm.