Configurando VM para ambiente de Desenvolvimento linux PHP com banco Postgresql

Ao completar esse tutorial você terá configurado ambiente de desenvolvimento para PHP e banco de dados PostgreSQL em uma máquina virtual para trabalhar via Windows.

Baixar a ultima versão da VBOX:

https://www.virtualbox.org/wiki/Downloads

Baixar a imagem da ultima versão do Ubuntu Server (14.04.02 LTS)

http://www.ubuntu.com/download/server

Instalar VBOX

Criar uma maquina virtual para ubuntu, nas configurações apontar a imagem da ultima distribuição utuntu na aba armazenamento. Tenha cuidado para baixar e utilizar uma distribuição ubuntu que tenha a mesma quantidade bits (32 ou 64) que a VM criada.

Ao iniciar a maquina virtual ele verificará que tem uma midia de ubuntu e começara a instalação, após a instalação seguir os passos abaixo.

Transformar em super usuario

# sudo su

Realizar update no ubuntu

# apt-get update

Instalar o apache, php, postgres e samba.

Para achar a ultima versão de cada pacote deve-se digitar o seguinte comando:

# apt-cache search php

# apt-cache search postgres

para instalar use os seguintes comandos:

# apt-get install apache2

# apt-get install php5 php5-cli php5-pgsql

# apt-get install postgresql-9.3

# apt-get install samba

Mudar as configurações de Rede para:

Conectado a: Placa em modo Bridge

Configurando o samba (para acessar a VM pelo windows)

Localização do arquivo: /etc/samba/smb.conf

# cd /etc/samba/

# vim smb.conf

Logo abaixo de [printers] adicionar o seguinte código:

[raiz]

path=/

user=seu_usuario

browseable=yes

writeable=yes

Devemos dar acesso ao usuario do sistema no samba, utilizando o seguinte comando:

smbpasswd -a seu_usuario

O sistema pedira para definir a senha e deverá ser 'restartado'

# service samba reload

Com o comando abaixo você descobrirá o seu endereço ip, que permitirá se conectar na sua pasta de arquivos da VM a partir do windows.

# ifconfig

Agora vamos configurar o Postgres:

as configurações abaixo permitiram o acesso via pgAdmin do windows

# sudo su postgres

# psql

# alter role postgres password '123456';

# vim /etc/postgresql/9.3/main/pg_hba.conf

abaixo do IPv6 local connection

host   all    all 0.0.0.0/0   md5

# vim /etc/postgresql/9.3/main/postgresql.conf

descomentar a linha

listen_addresses = 'localhost'

e substituir o localhost por *

# sudo /etc/init.d/postgresql restart

JSON vs XML

Por muito tempo, XML foi a única opção para transferir dados via web. Como não existiam outras opções, XML era utilizado para todas as aplicações que necessitavam transferir dados. Este formato era utilizado para transferir dados de texto e numérico, e também utilizado para transferência de documentos, imagens, áudio, vídeo e muito mais. Agora que temos outras opções, o XML foi sobrepujado em diversas maneiras. Nos dias de hoje temos a opção de escolher entre JSON e XML quando criamos arquivos de dados.

Com o JSON, você estará limitado a enviar apenas dados do tipo texto e numérico, já o XML lhe dá a liberdade de enviar qualquer tipo de dado que você deseja. Esta habilidade permite o XML ser mais flexível que o JSON. Entretanto, isto dificulta a leitura do XML, deixando o arquivo mais extenso, para que possam ser trafegados arquivos de imagens, gráficos, e outros tipos de arquivos. Como a transferência de arquivos clássicos, que contem somente dados, não se torna necessária toda essa ‘extensabilidade’ podendo ser beneficiado da simplicidade do JSON, onde os arquivos são gravados na forma de array, utilizando de uma familiar a linguagem orientada a objetos. Esta formatação permite uma fácil importação de dados do JSON para as linguagens de programação.

Essa simplicidade com a qual o JSON cria os arquivos é o que deixa muito mais rápido o tráfego dos arquivos, pois o arquivo já vem no formato de dados, enquanto no XML você tem que transformar o arquivo no formato de dados antes de importar, o que faz o JSON ser um tipo de formato superior para web APIs.

fonte:
https://www.udemy.com/blog/json-vs-xml/

Agile vs Fragile

Test Driven Development (TDD) em PHP

Neste post vamos abordar o Test Driven Development (TDD) em PHP, que é um dos principios core do XP e está disponivel nativo para linguagem java no netbeans. Entretanto, para habilitar essa ferramenta para o PHP no ambiente Windows devemos fazer algumas configurações no ambiente que seguem:

1. Instalar o NetBeans;
2. Instalar o Xampp;
3. Configurar o PHPUnit pelo pear no xampp com os seguintes comandos:
4. Abrir o Shell;
5. Digitar “pear config-set auto_discover 1”
6. Digitar “pear install pear.phpunit.de/PHPUnit”
7. Agora o PHPUnit já está configurado na pasta c:\xampp\php\
8. Baixar o arquivo phpunit.phar em https://phar.phpunit.de/phpunit.phar
9. Baixar o arquivo phpunit-skelgen.phar em https://phar.phpunit.de/phpunit-skelgen.phar
10. Salvar os dois arquivos em c:\xampp\php\
11. Para configurar o phpunit no netbeans faça o seguinte:
1. Vá em ferramentas;
2. Em opções aponte os arquivos conforme as imagens abaixo:

Agora o NetBeans já está configurado para aceitar projetos com a criação de classes de testes. A proxima etapa é criar um novo projeto PHP. Com o projeto criado deve-se criar a classe PHP que será desenvolvida a partir de testes. Agora deve-se criar os testes. Clique com o botão direito sobre a pasta “Arquivos de Código-Fonte” ir em “Ferramentas” e depois “Criar Testes”.

Deve-se criar uma pasta de testes dentro do projeto, onde serão geradas as classes de testes pelo skelgen, e durante o assistente de criação dos testes assinalar a opção de utilizar o PHPUnit.

O ultimo passo é criar a classe de testes, que é criada automaticamente clicando com o botão direito em cima do arquivo da classe PHP, que foi criada anteriormente e onde serão desenvolvidos os métodos,  ir em “Ferramentas” e depois “Criar Testes”.

Agora o arquivo o testes já foi criado, só tem que ter cuidado de sempre começar o método de testes começando com “testAlgumaCoisa”, segue abaixo uma sugestão de código para as classes onde estarão os métodos e onde estarão os testes:

Salario.php

<?php

/*

* To change this license header, choose License Headers in Project Properties.

* To change this template file, choose Tools | Templates

* and open the template in the editor.

*/

/**

* Description of Salario

*

* @author GUSTAVO

*/

class Salario {

   //put your code here

   

   public function index($bonus = null){

       $salario =  1500.35;

       

       if($bonus){

           $salario += $bonus;

       }

       

       return $salario;

   }

   

   public function desconto($salario){

       

       $desconto = 8;

       

       if(($salario > 1317.07) and ($salario < 2195.13)){

           $desconto = 9;

       } elseif($salario > 2195.12){

           $desconto = 11;

       }

       

       return $desconto;

   }

   public function descontoINSS($salario) {

       

       if($salario > 4390.24){

           $salario = 4390.24;

       }

       

       $percentual = $this->desconto($salario);

       

       $desconto = $salario * $percentual / 100;

       

       return number_format($desconto, 2);

   }

}

SalarioTest.php

<?php

require_once "../Salario.php";

/**

* Generated by PHPUnit_SkeletonGenerator on 2014-10-21 at 14:01:05.

*/

class SalarioTest extends PHPUnit_Framework_TestCase

{

   /**

    * @covers Salario::index

    * @todo   Implement testIndex().

    */

   public function testIndex(){

       $salario = new Salario();

       $this->assertEquals(1500.35, $salario->index());

   }

   

   public function testIndexComBonus(){

       $salario = new Salario();

       $this->assertEquals(1550.35, $salario->index(50));

   }

   public function testDesconto(){

       $salario = new Salario();

       $this->assertEquals(11, $salario->desconto(10000));

   }

   

   public function testValorINSSMinimo(){

       $salario = new Salario();

       $this->assertEquals(80, $salario->descontoINSS(1000));

   }

   

   public function testValorINSSMedio(){

       $salario = new Salario();

       $this->assertEquals(180, $salario->descontoINSS(2000));

   }

   

   public function testValorINSSAlto(){

       $salario = new Salario();

       $this->assertEquals(440, $salario->descontoINSS(4000));

   }

   

   public function testValorINSSTeto(){

       $salario = new Salario();

       $this->assertEquals(482.93, $salario->descontoINSS(9390.24));

   }

}

Resumindo o Disciplined Agile Delivery

Livro do Scott W. Ambler sobre a metodologia aplicada na IBM.

Essa metodologia de trabalho promove uma colaboração entre os desenvolvedores e os contratantes do software. Este método visa a adicionar valor à organização, mantendo a agilidade e se focando na qualidade do sistema a ser entregue (e.g., work smarter, not harder).

Não deveria ser uma surpresa que trabalhar em uma equipe unida e colaborativa que visa a produzir software em funcionamento obtém melhores resultados do que times que trabalham em locais separados onde se importam somente em sucesso individual ao invés do desempenho de equipe. Também não seria uma surpresa que reduzir documentação e a burocracia administrativa reduziria custos e diminuiria o tempo de entrega do produto.

Utilizar metodologias ágeis não é desculpa para ser indisciplinado. A execução destas novas metodologias, como XP, por exemplo, sempre demandaram uma abordagem disciplinada, e certamente muito mais do que as metodologias tradicionais como waterfall. Não se deve misturar o alto nível de burocracia e controle dos métodos tradicionais como sinal de disciplina.

Pessoas em Primeiro Lugar

O DAD promove uma busca para ajudar os times de desenvolvimento a melhorar sua efetividade, entretanto não prescreve procedimentos obrigatórios para se chegar neste objetivo.

Alguma documentação será exigida, mas raramente tanto quanto é exigida nos métodos tradicionais. A integração entre pessoas (clientes e desenvolvedores) dá oportunidades para sanar mal-entendidos e diminuir os defeitos dos sistemas a serem entregas, o que é tratado na cultura de prevenção de desperdícios da metodologia Lean. Pois quando criamos um documento raramente pomos no papel nosso completo entendimento do que estamos descrevendo, e inevitavelmente algum conhecimento é ‘deixado para traz’ eis o que o conhecimento tácito não é passado adiante.

Os membros de um time que aplica a metodologia DAD devem possuir os seguintes atributos:

•   Disciplina para se comprometer apenas com o trabalho que conseguem realizar e trabalhar da melhor maneira possível para realizar o seu trabalho;
• Organização para estimar e planejar o seu trabalho de uma maneira que possam realizar entregas constantes;
• Autodidata para identificar o que melhor funciona para si e o que não funciona, tendo oportunidade de aprender e se ajustar.

Metodologias Ágeis

Times de desenvolvimento que buscam trabalhar de maneira iterativa tem mostrado que produzem soluções de maior qualidade, proporcionando um maior retorno do investimento, bem como a satisfação dos clientes e entregando as soluções mais rápido que as abordagens tradicionais, como a waterfall. A satisfação dos clientes está diretamente ligada a participação deles no projeto durante cada iteração, e em conjunto com eles melhorando os requisitos do software que será desenvolvido no final do projeto.

Processo Hibrido de Desenvolvimento

DAD é um conjunto de diversas estratégias e praticas de tanto de metodologias ágeis quanto dos métodos tradicionais. No DAD é utilizado o ciclo de vida do Scrum adotando entregas continuas de software bem como utilizando técnicas Lean de desenvolvimento. Muitas das praticas sugeridas pelo DAD são comumente discutidas na comunidade ágil, tais como integração contínua, reuniões diárias e refatoração bem como algumas praticam avançadas que são muito aplicadas, porém pouco discutidas por alguma razão. São, dentre outras, o levantamento inicial de requisitos, estudo da arquitetura a ser utilizada, e testes no final do ciclo de desenvolvimento.

Consciência Empresarial

Os times DAD trabalham dentro do seu ecossistema empresarial, assim como outros times, e visam a aproveitar as vantagens apresentadas a eles – personificando o clichê: “agir localmente e pensar globalmente”. Em outras palavras, os times DAD devem adotar como mentalidade ‘a empresa como um todo’.

Ter uma consciência empresarial é importante que os times busquem, como profissionais, o que é melhor para organização e não somente o que lhes interessa.

Foco no Risco e Valor

DAD adota um ciclo de vida voltado ao chamado foco no risco e valor, o que é muito comum nos métodos ágeis como Scrum e XP. Trabalhando com foco no risco e valor o time acaba produzindo material entregável em cada iteração, ou mais precisamente a partir da perspectiva do DAD, um material potencialmente consumível em cada iteração. Essas entregas representam aqueles que tem maior valor na perspectiva dos clientes. Deve ser considerado também o risco de entrega nos itens de alta prioridade e não somente os de maior valor. Sempre tomando cuidado com os três principais riscos:

1.       O risco de não entregar nada;

2.       O risco de entregar o software sem funcionalidade;

3.       O risco político de ter pouca visibilidade sobre o que o time esta produzindo.

Conclusão

Disciplined Agile Delivery (DAD) é um processo hibrido que combina as praticas e estratégias do Scrum, Extreme Programming (XP) e Agile Modeling (AM) e complementa com algumas outras, como Agile Data e Kanban, adotando um ciclo de vida de entrega total.

Disciplined Agile Delivery – Scott W. Ambler

Essa postagem é uma introdução ao livro do Scott Ambler, que trata de DAD.

Scott Ambler percebeu que a realidade de muitas empresas era algo parecido com uma water-scrum-fall, na forma de que a maioria das empresas não aceitava iniciar seus projetos sem que antes tenham uma lenta fase de definição de requisitos, planejamento detalhado do projeto e até fazendo algum design. Essa abordagem não é de todo mal, ela permite que as empresas se beneficiem de práticas ágeis, como trabalho iterativo, desenvolvimento voltado a testes e entregas contínuas. Entretanto não é liberado todo o potencial da abordagem ágil. Empresas ágeis não somente criam os softwares de maneira mais eficiente, mas o mais importante é que entregam um software com grande valor de negocio.  

Porque Disciplined Agile Delivery?

Está constatado que métodos ágeis, como Scrum, funcionam muito bem para times de pequenos projetos, onde são trabalhados problemas com baixo risco ou consequências de falhas. Entretanto, esses métodos não trazem segurança para projetos de maior escala, e o resultado acaba sendo que as empresas investem muito esforço criando processos híbridos, combinando metodologias de diferentes fontes. O processo Disciplined Agile Delivery (DAD), como é descrito no livro do Scott Ambler, é uma abordagem hibrida, que busca técnicas do Scrum, Agile Modeling, EX, Unified Process e Kanban dentre outras metodologias. O processo do DAD inclui praticas que estão faltantes no Scrun e XP como modelagem e documentação. O mais importante é que o DAD permite que o processo seja ajustado efetivamente as necessidades da situação em que você se encontra. Descrevendo o que funciona e o que não funciona, e o mais importante porque, o DAD ajuda a aumentar as chances de adotar estratégias que vão funcionar para você. 

Bad Smell

- 4 características que eu considero essenciais, presentes em um código ruim:

Código duplicado: Esse smell geralmente acontece quando temos uma classe god, e acabamos escrevendo duas ou mais vezes a mesma lógica, que poderia ser escrita uma vez só, caso aplicássemos as regras de orientação a objetos e polimorfismo.  Nesse caso é gerado código muito grande e desnecessário.

Lista de parâmetros longa: Essa regra é muito utilizada quando começamos a programar, mas pode causar um transtorno quando não vamos utilizar todos os parâmetros, bem como dificulta o entendimento do código. A ideia de passar um objeto ao invés de parâmetros.

Classes alternativas com diferentes interfaces: Esse smell é gerado quando temos duas ou mais classes que fazem (ou fazem quase) a mesma coisa, porém com nomes diferentes.

Classe de dados: São classes que só contem atributos (getters e setters), que geralmente são acessadas e manipuladas por outras classes. Geralmente são nada mais que depósitos de dados

- 4 características que eu considero essenciais, presentes em um código bom:

Nomes significativos: Usar nomes nos atributos e métodos que transcrevam o modelo de design ajuda na manutenção e no entendimento do código por outros desenvolvedores.

Indentação de código: Deixar o código bem organizado e ter um padrão a ser seguido pelo time é essencial para o bom entendimento da estrutura lógica do código.

Uso de Exceções: Além de deixar o código mais legível, previne o código contra falhas nos tratamentos de arquivos, entradas de dados inválidas, erros de consultas à base de dados, entre outras.

Test Driven Development:  Ajuda a focar no resultado final, e nos garante uma refatoração mais segura das classes, garantindo que ao alterar um método, todos os requisitos do software serão atendidos, sem a necessidade de testar os mesmos a cada mudança, deixando essa parte automatizada.