Executando testes unitários em paralelo com o paratest

Não consigo contar o número de horas economizadas graças ao uso de testes unitários e todo o conceito de TDD. Mas o número de horas que eu gastava na execução de toda a suite de testes estava me irritando, por isso pesquisei por uma forma de melhorar este processo.

O primeiro passo foi otimizar ao máximo os códigos e estrutura dos testes mas chegou a um ponto que não consegui aumentar a performance apenas desta forma. Este é o momento que podemos partir para o próximo estágio, que é executar os testes em paralelo.

Encontrei duas ferramentas para executar esta tarefa, a PHPUnit Cluster Runner e o paratest. O ClusterRunner me parece bem mais completo e complexo, mas o paratest resolveu meu problema.

Foi preciso apenas alterar o composer.json do projeto para incluir:

"require": {
    "brianium/paratest": "dev-master"
}

e atualizar o vendors com o composer update.

Ao executar o comando ./vendor/bin/paratest é possível ver o seu help. As opções mais importantes são a -p que serve para indicar o número de processos e o -c para indicar onde está seu phpunit.xml com a configuração da sua suite de testes.

O que o paratest faz é criar um processo PHP para cada arquivo de sua suite de testes e executá-los em paralelo.

Rodando um ps -aux | grep php é possível ver os processos executando, algo como:

php vendor/bin/phpunit --configuration tests/phpunit.xml Api\Controller\RestControllerTest module/Api/tests/src/Api/Controller/RestControllerTest.php

Você pode usar o comando -f para que cada processo execute um teste apenas, um método de cada arquivo de teste. Ao rodar o ps -aux | grep php você deve ver algo parecido com isso:

php vendor/bin/phpunit --configuration tests/phpunit.xml --filter /testGetListNotFound(?:\s|$)/  module/Api/tests/src/Api/Controller/RestControllerTest.php

Como resultado do paratest eu consegui rodar um conjunto de testes grande, que estava demorando 17.67 minutos em apenas 4.91 minutos, usando 5 processo em paralelo.

Um ponto interessante foi que na primeira execução do paratest encontrei alguns testes que funcionavam perfeitamente quando executados em sequência, mas que davam erro ao serem executados em paralelo. Ou seja, não estavam seguindo corretamente o conceito de que cada teste não deve influenciar ou depender de outro.

Desta forma o paratest serve tanto para aumentar a performance da execução dos testes, algo muito útil em um ambiente de integração contínua, quanto como uma forma extra de validar seus testes.

elton

Elton Luís Minetto
No Code Squad, ministra os seguintes treinamentos: http://code-squad.com/perfil/eminetto#cursos-ministrados
Possui graduação e especialização em Ciência de Computação. Trabalha com PHP/MySQL desde 2000, com Linux desde 1997 e com MacOSX desde 2007. Também é autor do livro Frameworks para Desenvolvimento em PHP e co-autor do livro Grid Computing in Research and Education. É professor e co-fundador da Coderockr e Zend Framework Evangelist

Twitter

Server Render – a nova proposta de uma moda antiga

Server Render, ou renderização pelo servidor em uma “xula” tradução livre, é considerado uma má prática, ou pelo menos me ensinaram assim, e devo concordar que nunca vi esse tipo de técnica com bons olhos, todos os códigos que vi na vida que criavam algum script javascript em lado de servidor, ou uma montagem de html no lado do servidor, era de difícil manutenção e de difícil compreensão (normalmente uma gambiarra adaptação técnica para contornar alguma situação bem específica).

Pois bem, em um outro post comentei sobre o ReactJS e como ele vem oferecendo uma nova proposta dessa técnica de uma forma prática e produtiva, o que vem contra muitos conceitos e padrões de desenvolvimentos web que vemos no mercado, pois bem, fiquei devendo uma explicação e uma aplicabilidade desse comentário, e eis-me aqui para pagar essa dívida.

Todo o projeto está disponível aqui.

O README já é bem explicativo, mas irei detalhar os fontes envolvidos.

  • App.js – Fonte com instruções do ReactJS, nada além disso.
  • Browser.js – Fonte com as instruções para integração do browser (front end).
  • Server.js – Fonte com as instruções de renderização do server (sem framework, apenas nodejs puro).

Gostaria de ressaltar o seguinte, aqui não foi usado um builder, ou seja, foi utilizado apenas o ReactJS com javascript puro, assim como no lado do servidor foi utilizado apenas NodeJS, sem utilizar um framework (como o express) ou gerador de conteúdo estático (como o middleman ou o jekyll), obviamente a produtividade vai além abrangendo outras tecnologias, mas como o objetivo é apenas denotar a forma de utilização da renderização no lado do servidor, foi optado utilizar dessa forma.

// <![CDATA[

function safeStringify(obj) {
return JSON.stringify(obj).replace(/<\/script/g, '<\\/script').replace(/<!–/g, '

Twitter

Conceitos da Construção Civil na Construção de Softwares

Introdução

Uma coisa que gosto de citar é que a construção de software não é uma “arte”; a construção de software é um produto da engenharia e funciona como na construção civil, ou seja: podemos prever e acompanhar o andamento de suas etapas.

Mas por que ‘prever e acompanhar o andamento de suas etapas’ nem sempre é possível na construção de um software ?

edificacoes

Construção Civil

A grande sacada na construção civil é que muito antes do seu início (na maioria da vezes) temos um escopo bem definido, o proprietário já definiu o quanto deseja gastar, o engenheiro ou empreiteiro lhe repassa se é possível ou não fazer aquela obra com aquele valor e no tempo desejado.

Após algumas reuniões, ambas as partes entram em acordo com as definições completas do projeto, como quantidade e tamanho dos cômodos, qual material será utilizado, tempo de entrega e todos os stakeholders sabem que qualquer alteração feita no escopo pode acarretar em alteração no valor ou no prazo de entrega e que isso refletiria no custo e prazo de entrega da obra.

A aprovação do projeto por parte dos donos ou responsáveis é fácil porque antes de iniciar já foram demonstradas as plantas baixas e já se sabe como será a área construída.

Para isso são dispostas maquetes do projeto e em alguns casos utiliza-se até de renderização 3D para montar maquetes virtuais.

Isso já deixa bem fixado na mente do cliente qual será o resultado final de seu produto.

Depois de tudo definido antes de se iniciar as obras são preparados os materiais a serem utilizados em cada etapa.

Existe a preparação do terreno, onde serão feitas as primeiras estruturas – os fundamentos – para que seja de fato realizada a construção.

Essa estrutura é sempre construída de forma cautelosa, pois é sobre ela que tudo será construída e é ela que limitará muitas coisas no projeto e fará com que essa edificação não venha a desabar.

Construção de Software

software

Se olharmos bem como uma edificação é construída, vamos ver que esses conceitos são básicos e funcionam de forma são eficiente. Para uma construtora a não entrega de um projeto no prazo acarreta perda de dinheiro e isso talvez seja  pior comparado à má reputação da empresa diante dos clientes.

Agora os softwares em sua maioria das vezes não são bem definidos ou quase nada definidos, começam como uma idéia que é iniciada pelo programador e sofre alterações ao longo do tempo até chegar no produto do cliente, que nem sempre é o que ele desejou, fora os problemas encontrados no meio do caminho devido a problemas técnicos que não foram previstos.

Imagine se uma obra inicia-se dessa forma, uma idéia de construir uma casa mais ainda não se sabe como vai ser quantos cômodos e tal ? seria um caos, existiria muito dinheiro perdido, paredes quebradas, tempo investido sem necessidade e o final disso seria uma catástrofe, uma  parede mais alta que a outra, pisos quebrados, de cores diferentes..

Bom, é assim que os softwares são construídos e assim que eles ficam.

A diferença é que toda essa bagunça é coberta pela “linda” interface gráfica que é disposta para o usuário, porem devemos ser sinceros: em muitos casos o software não faz exatamente o que o cliente pediu ou que ele realmente precisa.

Existem inúmeras funcionalidades que ele não utiliza.

Ao iniciar o projeto o cliente ainda não sabe o que ele terá de resultado fazendo que suas expectativas sejam altas com o projeto, ainda mais se ele for “salgado”($$).

Outra coisa que ocorre é que muitas vezes não só o cliente, mas também os desenvolvedores não sabem seu resultado final e muitas coisas são criadas na “tentativa e erro”;  sua estrutura é criada de forma singular e faz com que o projeto nem sempre suporte todos os itens que devem ser adicionados, causando assim problemas técnicos na implementação de novas funcionalidades no futuro, pois sua base não foi construída para suportar suas verdadeiras necessidades.
Construção Civil vs Construção de Softwares

Sabemos que os conceitos da organização da construção civil são eficientes e fáceis de se implementarem, se formos reparar veremos desde pequenos a médios projetos sendo implementados por “mestre de obras”, que na sua maioria das vezes são pessoas com pouco estudo, mas os projetos implementados por essas pessoas são eficientes e entregues com qualidade e no prazo.

Qual a dificuldade de implementar esses processos no desenvolvimento de softwares ?

Vamos pegar como exemplos obras de pequenos portes e comparar com desenvolvimento de pequenos softwares

  1. Falta da clara definição de todo o escopo do projeto
    Na construção civil sempre existe uma definição de o que se deseja no final.
    Na construção de softwares em muitos casos se desenvolve a pedido do cliente e existe a velha história do “vamos vendo no que vai dando”.
  2. A disponibilidade no tempo hábil dos recursos
    Na construção civil sabemos que antes de começar a obra existem caminhos de areia, pedra, cimentos ou qualquer outro material que são deixados no local.
    O mestre de obra faz a conferência e após a confirmação do material adequado inicia o trabalho e em alguns casos pode ocorrer de nem todo o material ser disponibilizado no inicio, mais isso é um risco que o mestre calcula e se prepara para que o restante do matéria esteja disponível logo que necessário.
    Na construção de softwares vemos muito a iniciação de um projeto sem nenhum tipo de recurso adequado, há casos que esses recursos nem foram calculados e são disponibilizados sobre demanda e na maioria das vezes em tempo tardio.
  3. A adequada utilização de ferramentas é um ponto essencial
    Na construção civil  todos esses recursos são disponibilizados antes de sua real utilização, assim não atrasando o projeto
    Na construção de softwares as ferramentas não são pensadas, nem sempre são as adequadas e nem sempre estão disponível na hora necessária.
  4. Definição de papel 
    Na construção civil  temos três papeis bem definidos: servente ou ajudante, o pedreiro e por fim o mestre de obra.
    Os serventes tem o papel fundamental de fazer os serviços mais braçais e “servir” ; o pedreiro é o responsável por executar tarefas mais especializadas e tem um maior conhecimento e mais tempo de obra, porem não executam tarefas simples pois sua mão de obra é mais cara e seria um desperdício de dinheiro colocar um pedreiro para puxar massa, e por fim temos o nosso “mestre de obra” responsável por coordenar toda a obra, não deixar ocorrer a falta de matérias, controlar o tempo e os gastos.
    Na construção de softwares  em sua maioria apenas dois papeis: os programadores e gerente do projeto, para um software pequeno raramente vamos ter o papel de analista de sistema.
    O programador podemos comparar com o pedreiro o papel dele seria fazer serviços especializados porem vemos que no desenvolvimento de softwares não temos a figura de uma auxiliar ou o servente que seria o responsável por fazer o trabalho “pesado” e fazer com que o programador não perca tempo em soluções simples e até mesmo perca tempo tendo que “carregar o tijolo”, ou seja isso pode ser considerado como uma deficiência, pois os programadores tem que se preocupar em fazer todo o trabalho e muitas das vezes de forma desordenada fazendo com que o foco seja perdido, já o gerente tem o papel semelhante ao mestre de obra, deve ser responsável por controlar coordenar a equipe, prazos e insumos do projeto.
  5. Planejamento
    Na construção civil o responsável pela obra consegue se planejar de forma eficaz dos prazos para cada etapa da obra, assim se um dos prazos não forem cumpridos ele sabe se a obra vai se atrasar num todo e antes disso ele consegue reverter essa situação. Existem um acompanhamento no mínimo semanal do andamento da obra e posso dizer que ele sabe com exatidão se esta no prazo ou não. Outra coisa impressionante é que a obra tem documentação, por menor que seja existe um mínimo de documentação, seja ela a planta baixa do projeto ou um rascunho onde sofreu a aprovação do cliente.
    Na construção de softwares nem sempre existe um planejamento, tudo é feito de forma desorganizada e nem sempre priorizam-se as reais necessidades. Outra coisa é a falta de documentação: não são gerados nem rascunhos de como o projeto deve ser.

Conclusão

Existem outras inúmeras razões para os processos da construção civil serem mais eficientes do que os processos da construção de software e que não serão abordadas nesse artigo.

Porém,  é interessante saber que são processos simples: à ponto de serem feitos de forma transparente sem a necessidade de tanta “burocracia”, ou que essa burocracia não seja sentida pelos seus participantes. São processos de certa forma organizados “naturalmente”, tão “simplórios” que os participantes desse processo em muitos casos não tem a necessidade de sequer ter uma quarta série do ensino fundamental, e a inclusão de um novo participante no processo é simples e natural.

Torço para ver o dia em que o processo para a construção de um software seja tão ou mais organizado que o processo para a construção de um edífício

 

Gutierry Antonio Neto Pereira

No Code Squad ministra os seguintes treinamentos:  http://code-squad.com/perfil/gutierryantonio.netopereira#cursos-ministrados

Gutierry Antonio Neto Pereira – Engenheiro de Software Experiência em desenvolvimento com visual Fox Pro, Delphi, Ruby on Rails, Action Script 3.0 , nos bancos de dados Firebird, MySQL, gerencia de projetos de software e aplicação de métricas de software. Conhecimentos nas linguagens de programação Java, C# e C++, no banco de dados SQL Server.Participação de desenvolvimento de Framework em Delphi para desenvolvimento de softwares, desenvolvimento de framework para importação e exportação de dados entre banco de dados e Framework para BI.

Twitter

20 anos de PHP: Evoluir é sexy

A segunda-feira, dia 8 de Junho de 2015, marcou o aniversário de 20 anos da linguagem PHP.

Pouco tempo depois da linguagem ter sido criada ela foi lançada como Software Livre e hoje conta com mais de 700 programadores contribuindo para o seu desenvolvimento, incluindo Brasileiros.

Assim como em diversos outros acontecimentos na história destes 20 anos da linguagem, neste detalhe existe uma lição importante a ser aprendida.

Em 1995 o dinamarquês Rasmus Lerdorf decidiu, “do alto” dos seus quase 30 anos de idade tornar a linguagem que havia criado um Software Livre.

Rasmus_Lerdorf_August_2014_(cropped)

Embora eu tenha tido o privilégio de conversar com o próprio pessoalmente, é impossível para mim – ou para qualquer outra pessoa – imaginar como essa decisão pode ter sido difícil.

Trabalhamos em um mercado onde “complexo” é um termo diário.

O aprendizado muitas vezes acontece de hora em hora e a frequência com que nos descobrimos equivocados é muito maior do que imaginamos.

Um mercado onde impera a “Síndrome do Impostor”, como comentei em outro artigo.

Abrir o seu software para olhos alheios, portanto, é compreensivamente um processo que causa, pra dizer o mínimo, uma certa dose de ansiedade.

Uma vez mais o que nos impede e nos bloqueia é este orgulho tolo que temos de nossa suposta inteligência.

Todos queremos, em maior ou menor grau, nos tornarmos “a referência”, “o mestre”, “o gênio”.

O que custamos a aprender é que isso raríssimamente – se é que ocorre – acontece em um momento “Eureka!”, onde temos uma idéia genial depois de uma quase overdose de cafeína. E certamente não  acontece no isolamento de nossas próprias cabeças.

Neste nosso mercado complexo não existe aprendizado melhor do que abrir o seu código-fonte.

 

Ao fazê-lo você se torna imediatamphp-logo-php-721782ente um alvo, mas isso não precisa necessariamente ser algo negativo: ao receber críticas ao seu trabalho você pode refutá-las por teimosia, refutá-las com argumentos ou aceitá-las – com ou sem argumentos.

Você pode aprender sobre aquele design pattern que parecia impossível de entender.

Você pode descobrir que o mercado recomenda soluções diferentes das suas e, principalmente, entender o motivo dessas recomendações.

E você pode até mesmo – veja só – descobrir que a sua solução tem uma aceitação muito maior do que você imaginava.

Independente do resultado, o importante é que você aprende.

  • Aprende alternativas para o que você está trabalhando;

  • Aprende o quanto você tem razão… e o quanto não tem;

  • Aprende a defender os seus posicionamentos;

  • Aprende a aceitar os seus erros e, tão importante quanto, crescer com eles;

  • Aprende que não existem “obras-primas” que tudo neste nosso mercado evolui.

A linguagem PHP evoluiu tremendamente nestes 20 anos, tornando-se a linguagem que está presente em mais de ¾ de todos os servidores conectados a web no mundo. Falo disso em uma palestra que já tive o prazer de apresentar em diversas instituições e eventos, e esta palestra, que muito pouco tem de técnica, atrai sempre a atenção e os elogios do público. A razão de toda essa atenção e elogios é simples: a evolução é sexy.

Sim, você leu certo: Evoluir é sexy.

É um processo extremamente difícil, muitas vezes doloroso, mas ao vermos os benefícios deste processo é impossível não nos encantarmos.

É impossível não sorrirmos hoje, passados estes 20 anos, quando lembramos o quanto a linguagem foi vítima de críticas injustas, piadas tolas e previsões de sua morte prematura.

Foram dificuldades que tornaram o processo de evolução feio, difícil e caótico, mas isso tudo faz parte de um processo evolutivo, de aprendizado e crescimento.

Aprendemos a rebater as críticas injustas, aprendemos a ignorar as piadas tolas e aprendemos a rir dos futurólogos do mercado, que adoram prever a morte das coisas.

Hoje, 20 anos depois, aprendemos que podemos nos tornar “um Rasmus da vida”, se estivermos dispostos a encarar as dificuldades.

E ao olhar para o PHP 5.6.9 e dar aquela “espiadinha” no que vem por aí no PHP 7, aprendemos o quanto algo pode evoluir ao se tornar coletivo e o quão brilhante pode ser o futuro.

Vida longa ao PHP!

Referencias:
Histórico da Logo do PHP: http://blog.tetranet.com.br/o-motivo-de-o-mascote-simbolo-do-php-ser-um-elefante/

Er Galvão Abbott
No Code Squad, ministra os seguintes treinamentos: http://code-squad.com/perfil/galvao#cursos-ministrados

Er Galvão Abbott – É o Presidente da ABRAPHP – Associação Brasileira de Profissionais PHP, Diretor da PHP Conference Brasil, o principal evento de PHP da América Latina e fundador do PHPBR, Grupo de Usuários com mais de 1.200 associados. Trabalha há mais de 20 anos desenvolvendo sistemas e aplicações com interface web, sendo 15 anos com PHP e 7 anos com Zend Framework. Trabalhou com diversas empresas de grande porte, tanto nacionais como internacionais. Palestra em eventos e ministra cursos em diversas instituições, bem como in company. – See more at: http://code-squad.com/perfil/galvao#perfil

Twitter

A Tecnologia de armazenamento RAID

Introdução
Hoje no mundo das informações ainda vemos muitas empresas ( de pequeno,  médio e até algumas de grande porte) que não tem nenhum tipo tecnologia de armazenamento.

346955637_9f3002fbb2_n

Hoje temos no mercado placas domésticas que já dispõem de sistemas de tecnologia de armazenamento.

Mais o que são essas tecnologias de armazenamentos ?

Ao final dos anos 80 foi proposto uma forma de não só recuperar dados com velocidade mais também que os mesmo sejam armazenados com segurança, esse modelo proposto se é conhecido como RAID.

O que é RAID?
RAID do inglês Redundant Array of Independent Disks trazendo isso para uma tradução literária Conjunto de Redundante de Discos Independentes.

O RAID consiste de uma técnica na utilização de dois ou mais discos para ganhar desempenho ou segurança em casos em que podemos combinar o desempenho com a segurança.

Essa implementação será sempre transparente para o usuário, o sistema interpreta essa combinação de discos como uma única unidade de disco e todo o trabalho é feito pela controladora RAID.
Implementações
Um sistema RAID pode ser implementado de duas formas, ou via software ou diretamente via hardware.

A Implementação via Software: A implementação via software é mais barata não exigindo a necessidade de uma placa controladora RAID porem todo o processamento de controle é manipulação de dados é feito sobre o sistema operacional e com isso existe um custo computacional sobre o processador e memória.

Implementação via Hardware: A implementação por Hardware exige uma controladora RAID que será a responsável por gerir os discos e entregar ao sistema operacional o disco pronto, com isso temos um ganho maior em performance e até mesmo em segurança na sua maioria as controladoras são elaboradas com um sistema de baterias, fazendo com que se houver uma falha de energia haja uma garantia do armazenamento dos dados que estavam pendentes. As controladoras tem seu próprio núcleo de processamento assim aliviando o processador e deixando isso de forma transparente até mesmo para o sistema operacional

Tipos de RAID?
Temos hoje alguns tipos de RAID e cada RAID com suas particularidades, porem todas elas estão preocupadas na velocidade e gravação dos dados ou na segurança da guarda dessas informações e alguns casos combinadas a velocidade e segurança, contamos hoje com os seguintes tipos de RAID:
RAID 1
RAID 2
RAID 3
RAID 4
RAID 5
RAID 6
RAID 01 ou RAID 0+1
RAID 10 ou RAID 1+0
RAID 50
RAID 100
As RAID’s que serão vistas nesse artigo serão as mais utilizadas, algumas delas ficaram defasadas devido ao uso de novas tecnologias e outras foram substituídas por outras como é o caso da RAID 2 que se tornou obsoleta devido aos discos mais atuais possuírem checagem de erros e a RAID 4 que é substituída pela RAID 5 que supera os problemas mais comuns pela RAID 4.
RAID 0
No RAID 0 os dados são divididos em pequenos fragmentos e armazenados em paralelos nos discos disponíveis, com isso o tempo de gravação e leitura é reduzido pela quantidade de discos que participam do conjunto.

Exemplo: Se temos dois discos em nosso conjunto significa que metade dos dados serão armazenados no disco 1 e a outra metade no disco 2, se o tempo de gravação de um determinado dado em um disco é de 1s em nosso conjunto esse tempo será de 0,5s visto que essa dado será fragmentado e armazenado em simultâneo nos dois discos.

A controladora RAID é responsável por quebrar esses dados e enviar para os discos, que irão pegar os dados que lhe foram passados e efetuar sua gravação de forma independente. Com esse conjunto quanto mais discos mais rápido será o tempo de gravação e leitura visto que a leitura e quanto mais disco mais espaços teremos disponível.

raid-figura-1
Na Figura 1 temos um exemplo de 2 discos em um conjunto RAID 0, onde a soma desses discos nos dá uma disponibilidade de 240GB e ao se gravar uma informação em um disco outro fragmento dela é gravado em outro.

Podemos observar isso através das cores laranjas e verdes considerando-as como dados diferentes e vemos que ambas estão nos dois discos.

Um grande problema nesse conjunto é que se um dos discos falhar nossos dados não servem mais de nada, visto que eles estão distribuídos em fragmentos entre os discos.
RAID 1
O RAID 1 diferente do RAID 0 preza pela segurança e não pela velocidade, ele utiliza dois ou mais discos e os discos são espelhados, ou seja: os dados que são gravados em um disco são automaticamente replicados para os demais discos que participam desse conjunto em caso de um dos discos falhar o próximo entra em ação imediatamente.

Nosso computador contendo um um RAID 1 tem alta disponibilidade, se estamos sobre uma controladora RAID podemos efetuar a troca do disco com problema com nosso computador ainda em funcionamento assim não parando com nosso serviço disponibilizado nessa maquina, diferente do RAID 0 que em caso de falhas os dados são perdidos o RAID 1 garante a integridade dos dados. O problema do RAID 1 é que os discos adicionados a esse conjunto são considerados apenas como um, fazendo dessa solução uma solução cara pois espaço são perdidos para que possamos criar a redundância.

Na próxima figura podemos observar o uso do RAID 1, como podemos ver os dados no primeiro disco estão replicados no segundo disco e a capacidade de nosso conjunto é apenas de 120GB.

raid-figura-2

RAID 5
Podemos definir o RAID 5 como um “Super” RAID 1 com inúmeros aprimoramentos pois este é o sucessor do RAID 4, o RAID 5 é voltado a ganhos de desempenho como o RAID 1 porem dispõem de um sistema de segurança chamado de paridade. A paridade é uma espécie de soma de segurança que é armazenada nos discos de paridade diferente do RAID 4 que armazena a paridade em apenas um dos discos o RAID 5 distribui essa paridade para todos os discos do conjunto e se um dos discos falhar, pode ser recuperado através dos dados de paridade contido nos demais discos.

RAID 0+1
O RAID 01 ou RAID 0+1 combina a velocidade do RAID 0 com a segurança do RAID 1, para a montagem desse conjunto é necessário no mínimo quatro discos sendo os dados são divididos para melhorar a performance mais também são replicados para garantir a segurança dos dados. No RAID 01 se um dos discos falhar o sistema irá trabalhar como RAID 0 pois isso compromete a redundância. Na Figura 3 podemos observar a montagem de um conjunto em RAID 01, temos um conjunto principal em RAID 0 onde os dados serão fracionados e gravados em paralelo nos discos desse conjunto, e um conjunto “secundário” com as mesmas configurações do primeiro ligados entre si através de uma ligação RAID 1 garantindo assim a redundância de um conjunto para o outro.

raid-figura-5

RAID 1+0
O RAID 10 ou também conhecido com RAID 1+0 assim como o RAID 01 combina a velocidade RAID 0 com o RAID 1, assim como o RAID 01 necessita de ao menos 4 discos para sua formação. Sua diferença entre o RAID 01 é que sua formação nos blocos de baixo são formados pelo RAID 1 e a ligação entre eles é feita através do RAID 0, nesse conjunto podem haver a perda de até metade dos discos, desde que a perda não seja em um bloco de espelhamento. Assim como no RAID 1 temos a possibilidade de trocar os discos em pleno funcionamento. Na Figura 4 vemos como é montado o conjunto de um RAID 10, podemos observar que detro dos conjuntos baixos os dados são replicados mais entre um conjunto e outros os dados estão fracionados.

 

raid-figura-6

Conclusão
Com isso vemos que podemos combinar a velocidade e asegurança e termos um sistema robusto, tolerante a falhas, segurança e com alta disponiblidade

Referencias
Hardware, o Guia Definitivo – Carlos E. Morimoto – 2007
http://pt.wikipedia.org/wiki/RAID
http://www.intel.com/support/pt/chipsets/imsm/sb/cs-009337.htm

Fonte Foto: Flickr – John Athayde

Gutierry Antonio Neto Pereira

No Code Squad ministra os seguintes treinamentos:  http://code-squad.com/perfil/gutierryantonio.netopereira#cursos-ministrados

Gutierry Antonio Neto Pereira – Engenheiro de Software Experiência em desenvolvimento com visual Fox Pro, Delphi, Ruby on Rails, Action Script 3.0 , nos bancos de dados Firebird, MySQL, gerencia de projetos de software e aplicação de métricas de software. Conhecimentos nas linguagens de programação Java, C# e C++, no banco de dados SQL Server.Participação de desenvolvimento de Framework em Delphi para desenvolvimento de softwares, desenvolvimento de framework para importação e exportação de dados entre banco de dados e Framework para BI.

Twitter

ReactJs para jovens gafanhotos

Introdução
Há muito vem se falado de como não devemos mesclar o html com nosso código javascript, assim também vemos que não é uma boa prática renderizar o html em lado do servidor.Pois bem, o facebook anda discordando disso e querendo inventar uma nova moda (ou seria voltar uma moda antiga?)

react

O que é ReactJs?
O ReactJs é uma biblioteca para interação com usuário, o dito UI, exclusivamente pensada em atender a necessidade de uma interface interativa esquivando dos terríveis gargalos de desempenho oriundos do DOM (document object model) para as interfaces nesse modelo, de forma que para que isso seja possível, utiliza-se algumas técnicas como unidirectional data flow, ou algo tipo “one-way-data-binding”, e um relativamente conceito novo no mercado, o DOM virtual.

DOM Virtual
O DOM virtual é a representação em memória do DOM que os navegadores interpretam, com a diferença de ser disponibilizado apenas em memória e não no documento real apresentado pelo navegador.

Seu benefício específico é a questão performática em comparação à manipulação direta do DOM representativo (você pode ver esta discussão do stackoverflow que vai bem além nessa história, até porque o DOM Virtual vai merecer um post próprio).

O site oficial é este, e a versão atual, no momento que escrevo este post, é a 0.13.3

Instalação
Por ser apenas uma biblioteca e o nosso escopo é de aprendizado inicial, o código abaixo demonstra sua inclusão utilizando o CDN do facebook mesmo.


<div id=”meu-app”></div>
<script type=”text/jsx”>
//Código ReactJs vem aqui jovem padawan
React.render(
<h2>Olá jovem Padawan, bem vindo ao mundo UI do facebook</h2>,
document.getElementById(‘meu-app’)
);
</script>

See the Pen Instalação básica do ReactJS by Fabricio Eduardo Reche (@fabricioereche) on CodePen.

Veja o código na íntegra por Fabricio Eduardo Reche (@fabricioereche) no CodePen.

Gostaria de ressaltar que o código acima é apenas para aprendizado inicial, nunca use o builder em produção (sério, não faça isso!).

JSX
Você deve ter notado o tal do “text/jsx” no script não é mesmo?Pois bem, o JSX é uma linguagem que mescla javascritp com XML, com o intuito de deixar mais declarativa a forma de declarar os componentes do ReactJS, pois como foi visto antes, não iremos usar o DOM tradicional, mas um DOM virtual e essa linguagem veio para nos ajudar.

Ela é opcional, então se você quiser utilizar o javascript puro, fique a vontade para ver na documentação do React as alternativas utilizando a sintaxe do javascript e não do JSX, porém aqui iremos utiliza-lo.

Quando falamos de atributos, tem algumas sacadas do JSX, como por exemplo, o atributo class dos elementos é className e o atributo for é htmlFor, dá uma lida aqui e fique esperto.

Em versões antigas a 0.12, era obrigatório um comentário específico para utilização do JSX, como no exemplo abaixo:

/** @jsx React.DOM */

Isso não é necessário desde a versão 0.12.

Componentes
Vamos analisar o seguinte código:


<div id=”meu-app”></div>
<script type=”text/jsx”>

var MeuComponente = React.createClass({
render: function(){
return (
<h1>Olá pequeno gafanhoto</h1>
);
}
});

React.render(
<MeuComponente/>,
document.getElementById(‘meu-app’)
);

</script>

See the Pen Exemplo ReactJS – Create Class by Fabricio Eduardo Reche (@fabricioereche) on CodePen.

Veja o código na íntegra por Fabricio Eduardo Reche (@fabricioereche) no CodePen.

Quando utilizamos o método render do React, ele recebe dois parâmetros, um é o nosso componente criado pelo React.CreateClass e o segundo é o único DOM real que vamos utilizar, um contêiner da nossa aplicação, por assim dizer, simples, direto e reutilizável.

Propriedades
Vamos alterar mais um pouco no código para dinamizar a brincadeira:


<div id=”meu-app”></div>
<script type=”text/jsx”>

var MeuComponente = React.createClass({
render: function(){
return (
<h1>Olá {this.props.nome}</h1>
);
}
});

React.render(
<MeuComponente nome=”Pequeno gafanhoto”/>,
document.getElementById(‘meu-app’)
);

</script>

See the Pen Exemplo ReactJS – Create Class by Fabricio Eduardo Reche (@fabricioereche) on CodePen.

Veja o código na íntegra por Fabricio Eduardo Reche (@fabricioereche) no CodePen.

Ao definirmos nosso componente, podemos adicionar acesso a propriedades, criando dinamismo no componente, utilizando a configuração “props”.

Especificações, ciclos de vida e estados
Dentro do componente, a única especificação obrigatória é o render, método que efetua a renderização do componente em si, porém existem várias especificações para serem utilizadas, para gerar mais dinamismo e comportamentos, assim também como métodos de ciclos de vida, as propriedades (props) e os estados (states).
Você pode dar uma olhadinha aqui para ter uma noção de quantas especificações você pode fazer.

Estados
Se fossemos falar quem é a “bola da vez” no react, seriam os estados.

Através deles que são feitos as mudanças na interface, quando chamado o método setState, porque quando esse método é chamado, aí é que acontece a “magia” do React, atualizando a interface, alterando apenas o que foi alterado em seu estado atual.

Vamos ver essa brincadeira na prática:


<div id=”meu-app”></div>
<script type=”text/jsx”>

var Contador = React.createClass({
incrementar: function(){
this.setState({
contagem: this.state.contagem + 1
});
},
getInitialState: function(){
return {
contagem: 0
}
},
render: function(){
return (
<div>
<h1>Contagem: {this.state.contagem}</h1>
<button type=”button” onClick={this.incrementar}>Incrementar</button>
</div>
);
}
});

React.render(<Contador/>, document.getElementById(‘meu-app’));

</script>

See the Pen Exemplo ReactJS – Estados by Fabricio Eduardo Reche (@fabricioereche) on CodePen.

Veja o código na íntegra por Fabricio Eduardo Reche (@fabricioereche) no CodePen.

Veja que no código, utilizamos o evento onClick do botão para alterar o estado do nosso componente “Contador”, cada vez que chamamos a função “incrementar”, o estado é alterado, mas apenas aquilo que foi alterado é que é renderizado novamente, sem decorrer todo o DOM criado.

Fluxo de dados unidirecional
No reactjs o fluxo das informações são unidirecionais, via estados e propriedades, ou seja, ao alterarmos o estado do componente e chamarmos o método setState, estamos enviando informação e informando que houve uma mudança, na prática, teremos um componente pai, que vai falando para seus filhos que houve uma mudança, alterando apenas o que foi alterado e mantendo o que não foi.

Para vermos esse exemplo de fluxo de dados funcionando, abaixo um exemplo de lista filtrada:


<div id="meu-app"></div>
<script type="text/jsx">
var ListaFiltrada = React.createClass({
filtrarLista: function(event){
var listaNova = this.state.itensIniciais;
listaNova = listaNova.filter(function(item){
return item.toLowerCase().search(
event.target.value.toLowerCase()) !== -1;
});
this.setState({itens: listaNova});
},
getInitialState: function(){
return {
itensIniciais: [
"facebook"
,"twitter"
,"linkedin"
,"google+"
,"flicker"
],
itens: []
}
},
componentWillMount: function(){
this.setState({itens: this.state.itensIniciais})
},
render: function(){
return (
<div className="lista-filtrada">
<input type="text" placeholder="Busca" onChange={this.filtrarLista}/>
<List itens={this.state.itens}/>
</div>
);
}
});

var List = React.createClass({
render: function(){
return (
<ul>
{
this.props.itens.map(function(item) {
return <li key={item}>{item}</li>
})
}
</ul>
)
}
});

React.render(<ListaFiltrada/>, document.getElementById("meu-app"));

</script>

See the Pen Exemplo ReactJS – Create Class by Fabricio Eduardo Reche (@fabricioereche) on CodePen.

Veja o código na íntegra por Fabricio Eduardo Reche (@fabricioereche) no CodePen.

Conclusão
Agora que pudemos ver um pouco do que o ReactJS faz, espero que isso abra a mente para sua utilização, pois talvez, assim como eu, você tenha ficado com um pé atrás por ver código javascript no meio do html e lendo ainda que renderizar html pelo servidor pode ser uma boa coisa (veremos isso em um post futuro, sobre renderização no lado do servidor).

Nota: Se você estava procurando uma forma de comparar o react com o angular, sinto muito, são coisas distintas usadas para atender necessidades distintas, porém eu já vi gente usando e dizendo que dá liga, afinal, o React é para ser a interface. Qualquer coisa, dá uma pesquisada sobre o ngReact e seja feliz.

Fabricio Eduardo Reche

No Code Squad, ministra os seguintes treinamentos: http://code-squad.com/perfil/FaBritze#cursos-ministrados

Entusiasta no desenvolvimento de sistemas web desde 2008, eterno estudante e apreciador de softwares livres. Experiência profissional no desenvolvimento web utilizando .NET, PHP e Ruby On Rails, como back-end e jQuery, ExtJs e AngularJS como front-end, utilizando banco de dados relacionas SQL Server, Postgresql e Mysql.

Twitter

Shaw, Einstein e o mercado de TI: A “Síndrome do Impostor” e o suco de limão

“Expert”, “Especialista”, “Mestre”, “Jedi”, “Ninja”…

Não é irônico que um mercado tenha criado tantas expressões para indicar o alto nível de conhecimento de seus profissionais e maioria destes profissionais tenha receio em adotá-las?

Se você trabalha há algum tempo no mercado de TI e especialmente se você decidiu se tornar instrutor, professor ou palestrante há boas chances de que você já

tenha se sentido… bem, uma espécie de fraude.

É o que chamamos de “Síndrome do Impostor”: o sentimento de que você não é tão bom quanto as pessoas pensam; que você não deveria realmente estar ocupando aquele espaço na grade de programação de um evento, ou contribuindo na formação de outros profissionais: que existem pessoas muito melhor qualificadas do que você pra isso.

O que muita gente desconhece é que a “Síndrome do Impostor” é real: ela se chama “Efeito Dunning–Kruger”: O pré-conceito cognitivo que indivíduos de pouca habilidade têm de que seus talentos são muito superiores do que realmente são e, em um sentido oposto, que indíviduos de muita habilidade têm de que seus talentos não são bons o bastante.

A inspiração para o estudo que determinou a existência do Efeito Dunning–Kruger foi um ladrão de bancos chamado McArthur Wheeler: ele roubou dois bancos usando como único disfarce… suco de limão (sério).

McArthur sabia que suco de limão pode ser usado como tinta invisível, revelado apenas pelo calor. O que ele não possuía era o conhecimento de porque este efeito de tinta invisível funciona, ou como câmeras funcionam, e portanto simplesmente imaginou que o suco de limão tornaria seu rosto invisível para as câmeras de segurança.

O Efeito Dunning–Kruger nasce, no caso de indivíduos de pouca habilidade, de uma impressão errônea que a pessoa tem de si mesma: ao ter pouca proficiência e/ou conhecimento em uma atividade, a pessoa imagina que esta atividade é simples, fácil e que portanto não há muito mais a saber a respeito.

No caso de pessoas de muita habilidade ele nasce de uma impressão errônea que a pessoa tem dos outros: de que eles não considerarão o seu conhecimento tão bom, ou ainda que eles possuem o mesmo nível de conhecimento.

O fato é que quanto mais se conhece381321976_620b11019a_n sobre um assunto, mais noção temos do quanto o assunto é complexo e vasto e portanto nos damos conta da dimensão de nossa ignorância.

No sentido contrário, ao conhecermos pouco sobre um tema, ignoramos a sua dimensão e portanto cremos que sabemos “tudo o que há para saber”.

George Bernard Shaw em certa ocasião criticou Albert Einstein, dizendo que “A Ciência está sempre errada: nunca resolve um problema sem criar outros dez”.

Einstein  não discordou: ele usou geometria para ilustrar como a ignorância cresce mais rapidamente do que o conhecimento, dizendo “Enquanto nosso círculo de conhecimento expande, também expande a circunferência de escuridão que o cerca. Aprender, estudar, lançar luz em um campo de pesquisa também revela o quão no escuro continuamos a estar”.

Um dos problemas que ainda existem em nosso mercado é a dificuldade em aceitar o erro. Do lado dos profissionais, é normalmente doloroso aceitar que erramos; sentimos que isso nos diminui, nos rebaixa.

Na ótica do “público” a dificuldade não é menor: o público deseja alguém que os conduza pela mão, que o assegure de verdades absolutas e soluções facilmente implementáveis e reproduzíveis.

Precisamos aprender a lidar com nosso conhecimento e com a falta dele. Precisamos aprender a errar e principalmente aprender a admitir o erro e… aprender com ele.

 

Não somos “Experts”. Não somos “Especialistas”. Não somos “Mestres”, “Jedis” ou “Ninjas”. Somos profissionais. Somos estudiosos, eternos pesquisadores e como tal estatisticamente estaremos com muito mais frequência errados do que certos e existe beleza nisso: é assim que o processo de crescimento e amadurecimento ocorre.

Senhoras e Senhores Profissionais: errem mais, admitam mais, cresçam mais.

Senhoras e Senhores do Público: tenham mais paciência conosco e por gentileza reduzam a altura de nossos pedestais.

Referências:
Dunning–Kruger effect,Wikipedia;

What Is The Speed of Dark?, Vsauce, a partir de 8’49”;

The Dunning-Kruger Effect, Huffington Post

Foto do Ninja, Seth Werkheiser (Flickr.com)

Er Galvão Abbott
No Code Squad, ministra os seguintes treinamentos: http://code-squad.com/perfil/galvao#cursos-ministrados

Er Galvão Abbott – É o Presidente da ABRAPHP – Associação Brasileira de Profissionais PHP, Diretor da PHP Conference Brasil, o principal evento de PHP da América Latina e fundador do PHPBR, Grupo de Usuários com mais de 1.200 associados. Trabalha há mais de 20 anos desenvolvendo sistemas e aplicações com interface web, sendo 15 anos com PHP e 7 anos com Zend Framework. Trabalhou com diversas empresas de grande porte, tanto nacionais como internacionais. Palestra em eventos e ministra cursos em diversas instituições, bem como in company. – See more at: http://code-squad.com/perfil/galvao#perfil

 

Twitter

Desafios do Projeto de Software

Este artigo é baseado em uma parte do quinto capítulo do livro Code Complete, por McConnell, 2ª edição

Esse foi um dos melhores livros que eu li sobre criação de software, cujos princípios não entram em obsolescência com o passar do tempo, ao contrário das implementações das linguagens de programação.

McConnel sabe o valor da metáfora no mundo abstrato da programação de computadores.

Ele inclusive trata disso em seu livro.

Eu também sou um grande adepto da metáfora como ferramenta de comunicação.

Sem metáforas, fica muito difícil discutir arquitetura de software.

Falar sobre milhares de linhas de código para uma equipe com a limitada capacidade de retenção de informação que temos não é prático.

Uma das primeiras metáforas que McConnel propõe é a de comparar a criação de sistemas de informação com a construção de edificações.

É melhor do que a métafora da escrita de documentos, pois leva o ouvinte ou leitor a imaginar (um real) esforço na criação de software.

Construir software não é uma tarefa fácil, pois há muitos desafios que tem de ser superados a cada projeto.

Mais do que otimizar algoritmos, é preciso organizar o software, para mantê-­lo funcionando depois que ele for colocado em produção.

128345994_e037b5a511_z

Segundo McConnel, o problema de software é um problema perverso!

Isso não quer dizer que os problemas que envolvem a construção de software são criados por supervilões.

Isso significa que você precisa resolver o problema uma vez para defini­-lo claramente, depois resolvê­-lo mais uma vez para criar uma solução que funcione.

O que implica dizer que você só irá compreender realmente o negócio que o software implementa depois que implementá-­lo pela primeira vez.

Não que a primeira versão só software seja errada, que não faça o que o cliente pediu.

Ela pode atingir os objetivos mas de uma forma inadequada.

E essa inadequação só será percebida quando uma modificação for solicitada e você perceber que é extremamente difícil modificar seu software.

E essa dificuldade só aumenta a cada novo lançamento.

Por mais planejamento que haja em um projeto de software, ele só controla o atendimento ao requisito e não o código que o implementa.

O código que implementa um requisito pode se dividir em várias funções ou classes, o que não permitirá ter conhecimento completo, com um simples olhar, de como o requisito é implementado em detalhes.

imagem-artigo-flavio-livro

Além disso, ocorrem bugs no software. E eles são corrigidos. E as correções geralmente aumentam a quantidade de código.

Como as correções geralmente são feitas de forma emergencial, elas não são implementadas da melhor forma possível e isso causa degradação do código.

Um código degradado é um código difícil de manter e que contém operações inúteis ou desnecessárias.

Após perceber que o código está degradado, geralmente quando você já não consegue mais entender o que o código faz, é necessário reorganizá-­lo, para torná-­lo compreensível e remover o que não é mais necessário.

E eventualmente corrigir um bug que paradoxalmente foi introduzido pela correção de outro bug.

Por isso o processo de software é um processo desordenado (mesmo que conduza a um resultado ordenado).

Você comete vários erros até distinguir a diferença entre uma solução boa e outra ruim.

Isso é natural quando precisamos entregar uma funcionalidade no prazo ou corrigir um bug de um dia para outro.

Você naturalmente age nessas condições como alguém que tem de fugir de alienígenas zumbis e precisa ligar o motor do primeiro carro que encontrar.

Você nem procura a chave, já faz uma ligação direta, porque sua vida depende disso.

Mesmo quando criamos software com tempo para planejamento, podemos não compreender realmente o contexto dos problemas a serem resolvidos, pois nossa visão é limitada.

E isso não é nenhum sintoma de burrice, é tão somente uma consequência da falta de experiência.

A compreensão de um problema às vezes exige a experiência de ter resolvido outro.

Isso é algo natural na ciência. A compreensão do átomo, por exemplo, foi sendo ampliada conforme os instrumentos de observação foram aperfeiçoados e os pesquisadores tinham conhecimento anterior para estender.

A solução de um problema em software só irá se revelar ruim se você tiver implementado essa solução.

Não é possível corrigir ou aperfeiçoar o que não existe.

Ao resolver o problema pela primeira vez, você não o compreende direito. Mas após estudar sua solução em funcionamento, o problema fica mais claro, e você percebe o que pode ser melhorado.

Ou seja, não espere que qualquer implementação em software seja definitiva, por mais planejamento que você faça. Ela sempre poderá e precisará ser aperfeiçoada.

Se os programadores de sua equipe não puderem assimilar isso, então Ultron terá razão ao dizer para eles: “Vocês querem salvar o mundo, mas não querem que ele mude”.

A mudança é a única certeza constante.

flisboa

Flávio Gomes da Silva Lisboa
No Code Squad, ministra os seguintes treinamentos: http://code-squad.com/perfil/flaviogomeslisboa#cursos-ministrados

Flávio é Bacharel em Ciência da Computação com pós-graduação em Aplicações Corporativas usando Orientação a Objetos e Tecnologia Java pela Universidade Tecnológica Federal do Paraná. Programador formado pelo Centro Estadual de Educação Tecnológica Paula Souza, já atuou em empresas privadas de TI e foi funcionário de carreira do Banco do Brasil, onde chegou a analista na diretoria internacional.

É funcionário do Serviço Federal de Processamento de Dados (Serpro), onde já trabalhou na Superintendência de Soluções de Desenvolvimento e na Coordenação Estratégica de Tecnologia. Atualmente é chefe do setor de adequação da solução e mobilidade do projeto Expresso 3 na Coordenação Estratégica de Ações Governamentais.

Foi membro do time oficial de tradução do Zend Framework e é autor dos livros: Zend Framework Desenvolvendo em PHP 5 Orientado a Objetos com MVC, Zend Framework Componentes Poderosos para PHP (2ª ed.) e Criando Aplicações PHP com Zend e Dojo (2ª ed.). É associado da ABRAPHP, Zend PHP Certified Engineer, Zend Framework Certified Engineer, Zend Framework 2 Certified Architectcontribuidor oficial do projeto Tine 2.0, suíte livre de comunicação em PHP.

 

 

Twitter

Usando o Deployer

Segundo a Wikipedia, “software deployment” significa:

“todas as atividades necessárias para tornar um software disponível para uso”

Esta lista de atividades pode ser algo simples como enviar um diretório de arquivos para um FTP ou um processo complexo, envolvendo migrações de banco de dados, múltiplos servidores, vários níveis de cache, etc.

Geralmente o processo de deployment automatizado é uma sequencia natural do processo de integração contínua e exitem diversas ferramentas e formas de se automatizar esse processo, tanto gratuitas quanto pagas.

Vamos considerar os dois extremos de complexidade no quesito deploy automatizado.

De um lado o mais simples: um shell script que realiza uma série de comandos Linux (ou outro sistema operacional) para colocar o software em produção.

De outro lado um sistema de deploy ligado a uma ferramenta de integração contínua como o Jenkins, Codeship ou Travis.

Em dois projetos de clientes da Coderockr resolvemos adotar uma solução intermediária: scripts PHP.
imagem-artigo-elton-deploy

Para isso estamos usando o Deployer.

Continue reading

Twitter

© 2016 Bussola Code Squad

Theme by Anders NorenUp ↑