Balão Vex

Nas primeiras semanas, tratei de me envolver em alguns projetos para conhecer mais sobre como tudo funcionava, afinal, entrei como um programador jovem e a gerência não sabia ao certo se teria maturidade suficiente com prazos e horários.

Meses após entrar para o time Vex, eu comecei a perceber alguns pontos onde poderíamos tentar melhorias significantes. Meu primeiro passo foi esboçar com BPMN um diagrama elucidando o processo instável de desenvolvimento web. À partir disto, assumi como meta pessoal melhorar como pudesse o processo. Comecei a incentivar a adoção e aplicar as melhorias que seguiram por quase 2 anos. Em meados de abril do ano passado, apresentei internamente para os fracos de memória (como eu) tudo o que tentamos, o que deu errado e o que deu certo. Sinceramente, só reparei na imensa evolução de todos durante a montagem daquela apresentação!

Meados de 2011

Graças ao empenho da pequena equipe, saímos de um deploy manual, instável e sem product backlog por versão para um ambiente controlado, deploy automatizado; Git; Migrations; Resque (e meu PHPResqueBundle); product backlog; bug tracking e muitos testes automatizados divididos por unidade, integração e até funcionais com Behat.

Meados de março/2011

Hoje, deixo o recém criado cargo, “Líder de engenharia web” do time da Vex e feliz por tudo que pude aprender; aplicar; e confesso, testar para ver no que daria. Saio para aventurar-me em projetos pessoais com PHP, Ruby, Rails, Node, DevOps tasks e tudo mais o que aparecer pela frente.

Diferentemente dos outros anos, em 2011 eu estarei na PHPConference como palestrante. Meu maior impasse era quanto ao tema, por fim, decidi submeter algo polêmico que foi aceito! Acredito conseguir abrir a mente de alguns possíveis espectadores com o tema:

Definir classe não é programar com orientação a objetos.

Do que não falarei:

• Como definir uma classe com PHP;
• Classe e Objeto no âmbito técnico do PHP;
• Parâmetros, métodos e objetos;
• Padrões de projeto (design patterns).

Do que falarei:

• Design (projeto) orientado a objetos;
• Princípios de orientação a objetos;
• Como não definir uma classe (code smell);
• Composição, agregação, value object e entidades;
• Ubiquitous Language (ourindo do Domain-Driven Design)
• Getters, setters burros;
• Ciclo de vida de um objeto.

O objetivo é abrir a mente dos presentes para uma orientação a objetos pura, legível e realmente manutenível. Minha palestra será na sexta-feira, 2 de dezembro às 11hs (de acordo com a grade atual). Interessou? Aparece por lá!

Você tem um sistema de upload e parser de imagens em seu sistema. Várias pessoas enviando imagens o tempo todo. Como fazer para não explodir sobrecarregar o servidor com múltiplos filhos e ainda não segurar toda essa gente na tela de upload do site ? Simples! Você pode criar uma fila de upload e parser! Toda requisição de upload é direcionada para um euqueue que receberá e colocará a requisição no final da fila. Do outro lado, há um (ou mais) Workers trabalhando para que os itens da fila sejam processados um a um por ordem de entrada na fila. Sem sobrecargas, sem esperas por atendimento, etc.

Quando precisei utilizar o Resque, busquei uma solução em PHP e felizmente, encontrei! PHP-Resque é um port fiel ao original Resque (Ruby). Vi o projeto e como funcionava. Tudo perfeito, exceto pelo fato de não ser separado com namespaces e não ter suporte ao Symfony. Buscando mais, encontrei um plugin para o Symfony 1.x, mas nada referente ao Symfony 2.x, daí, resolvi eu criar um bundle do php-resque para o sf2.

Na página do projeto, explico como funciona o PHP Resque Bundle com todo detalhamento possível. Tenho mais alguns itens a implementar no projeto como criar namespaces para as filas, algo possível no Resque (Ruby) mas impossível ainda no PHP-Resque – vide thread. Trabalharei nisto em breve, pois precisarei deste recurso também =D

Como o PHP-Resque não possui interface gráfica (como o Resque), uma alternativa é baixar o Resque e utilizá-lo somente para este fim – ou então, forkear o php-resque e implementar isto por lá!

Dúvidas, sugestões ou contribuições podem ser feitas diretamente no Github dos projetos. Happy hacking!

Com key em mãos, basta baixar um binário, típico installer.bin para Linux no site da Zend.

1. Instalação

Ao rodar o binário, é solicitado a versão do PHP que deseja instalar. Na versão que testei, Zend Server 5, PHP 5.2 ou PHP 5.3. Neste passo é possível também definir qual branch você irá utilizar: Developer Edition ou Community Edition (CE).

Para Linux, o binário funciona apenas com distros Debian-like ou RedHat-like. Para as demais, o choro ainda é livre nada ainda.

Instalação rápida e sem complicações. Após tudo instalado, você poderá controlar o daemon em /etc/init.d/zend-server (start|stop|restart|…)

2. Iniciando…

Basta acessar: http://server.me:10081 e aguardar o redirect para tela de autenticação do Zend Server.

Após logar, recebe-se o Dashboard que  contém um grande overview (óbvio) de tudo que ele poderá fazer por nós.

Os destaques são:

• Gerenciamento de eventos;
• Configuração do php.ini ultra-simplificada;
• Restart do container (Apache, PHP) na GUI;
• Profiler e code backtrace de todas URLs do server;
• Logs;
• Fila de atividades;
• Configuração de cache para conteúdos estáticos (html, css, javascript…);
• Ativação/desativação de módulos facilmente, e;
• Integração com Zend Studio para debugging em ambiente de produção.

Gerenciamento de eventos

Os eventos são completamente configuráveis e estão listados em Rule Management -> Monitoring .
As configurações incluem:

• Definir os alertas
• Definir os critérios (por tempo de carregamento em milésimos de segundo; ou tamanho da página em Kb)
• Setar ações (lançar email; salvar code backtrace; registrar apenas..)

Zend Server 5 - Monitoring

Para acompanhar cada evento, temos pelo dashboard (os últimos) ou diretamente na página dos eventos a listagem completa com data, etc.

Zend Server 5 - Monitoring details page

Ao clicar em show code tracing uma nova janela é aberta exibindo o trace da aplicação com várias opções de filtragem (mais do que no próprio Zend Studio na aba Profile).

Zend Server 5 - Code tracing popup

Configuração do php.ini

Todas as configurações do php.ini ficam em Server Setup -> directives.

Basta editar o campo desejado, salvar e depois reiniciar o webserver para recarregar com as novas configurações. Tudo graficamente !

Zend Server 5 - PHP.ini directives setup

Integração com Zend Studio para debug

Aqui não há muito segredo. O Zend Server vem com o Zend Debugger configurado e pronto para uso. O mesmo debugger que também já está facilitado o acesso pelo Zend Studio. A única coisa pendente é liberar acesso remoto do Zend Studio na sua rede no seu Zend Server remoto e voilà.

As configurações de liberação de acesso estão em Server Setup -> debugger. Basta adicionar o IP/range e salvar.

Resumo

Facilidades por todos lugares com o Zend Server 5. Como de praxe, a Zend enfia a faca nos preços, acredito eu que poderia ser mais acessível, assim, mais empresas – aqui incluem-se os freelas – teriam como pagar tranquilamente pela ferramenta, gerando mais receita à Zend.

O ponto alto da ferramenta é realmente o Code Trace e facilidade nas configurações e eventos do sistema em produção. Aliado ao Zend Studio, fica ainda melhor !

Extra: Zend Server @ Amazon EC2

A Zend disponibiliza uma ISO Linux já com o Zend Server totalmente configurado no serviço de cloud da Amazon Elastic Compute Cloud na modalidade “small”. Essa instância Small da Amazon custaria no mínimo 60 dólares/mês rodando diariamente sem adicionais (disco, dns, etc). *A Zend dá a licença gratuitamente quando utilizado na Amazon. 

Deixei rodando em teste por dois dias e me custou 9 dolares. Cancelei e montei eu mesmo o Zend Server sob uma ISO Linux padrão na Amazon EC2, porém com uma instância “micro” que dada restrições, é gratuita. E mesmo que eu venha a pagar por mais disco ou núcleo de proc, será MUITO menos do que 60 dólares. Acredito que fique mais em conta do que uma VPS com 512MB de ram.

Ao invés desse marketing todo em cima do software, é melhor explicar aqui os motivos que fazem eu utilizá-lo atualmente.

Git é descentralizado. Sim, isto é uma maravilha ! Sem delongas, permite que eu gerencie meus branches localmente, sem a necessidade daquele role todo para de criar um branch no servidor e depois fazer um checkout dele. Em miúdos, isso dá a agilidade necessária para eu parar o que estou fazendo atualmente para corrigir algum imprevisto, a.k.a, bug, em um branch separado voltando versões se necessário, fazer merge com meu branch principal e subir no servidor de homologação.

Git comunica-se com vários repositórios remotos sem complicações.

Eu, faço uns testes mirabolantes com meus códigos, logo, preciso comitar um mesmo código em servidores diferentes, inclusive em servidor SVN. Ora, isso é bem simples com os “remotes” do Git.

$ git remote add <remote_name> <url_address>
$ git remote show

Para mostrar as informações de um remote específico:

$ git remote show <nome_do_remote>

No SVN, consigo facilmente receber e mandar commits para o servidor.

$ git svn rebase  #para receber do servidor svn os commits que você ainda não possui
$ git svn dcommit #para enviar os commits locais ao servidor

Ou caso queira você criar o merge manualmente das revisões:

$ git svn fetch
$ git merge remotes/git-svn

Isto supondo que você está no branch master, claro.

Git tem um “ponteiro” com índices e mais…

Esse é o nome que dou aos stashes do Git. Quebra um galho imenso e muitas vezes acabo utilizando um stash ao branch. O Stash, salva em um “vetor” as modificações que estão no seu “stage” – em miúdos: arquivos já trackeados pelo Git e arquivos novos no stage - para uma memória temporária.

Seu uso é simples:

$ git stash                       #salva os arquivos modificados dentro do stage.
$ git stash list                  #lista os stashes existentes em memória (Sim, armazena mais de um)
$ git stash pop  <stash name>     #recupera os arquivos do stash e apaga o stash.
$ git stash drop                  #limpa o stash sem recuperar os arquivos
$ git stash branch <name> <stash> #cria um branch <name> com o <stash>

Git tem Ctrl + Z

Claro, afinal este é o propósito de qualquer VCS. Mas no Git a coisa é mais fácil voltar em qualquer ponto após quaisquer ações, digamos, não desejadas.

$ git reflog

Para aplicá-lo, basta pegar o nome que o reflog lhe dirá

$ git checkout <hash>

Pode-se usar também, o git merge, a depender do que quer fazer.

A solução para um problema que eu penei até encontrar uma resposta: como ignorar alterações em arquivos que já estão sob o controle de versão do Git ?

Quer um exemplo ? O databases.yml ; config.yml; … A solução era bem simples:

$ git update-index --assume-unchanged <file> #adiciona o arquivo na lista de índices ignorados
$ git update-index --assume-changed <file>   #volta o arquivo para o índice de arquivos à comitar.

Para fechar, para aqueles que não desejam criar um workspace ao iniciar um repositório Git, deve-se criar um repositório do tipo bare.

$ git init --bare <diretorio>

Isto é útil para você criar o repositório em sua VPS para salvar ou/e compartilhar  seus códigos remotamente.

O problema

Documentar para a eternidade.

1. pseudossolução: texto e mais textos

No ano de 2009, eu entrei  no time de web da Vex e como tal fiz minha primeira tentativa a fim de resolver o problema da documentação do que eu fazia. Tentei documentos de especificação técnica.

Escrevia em um arquivo .odt tudo o que eu havia entendido sobre o projeto e com aquilo, começava as atividades de design e codificação. Era engraçado, pois essa atividade assemelha-se ao renomado processo cascata e increvelmente, era simples e parecia solucionar o problema. Não satisfeito em escrever o .odt eu o salvei no servidor de versão e ainda por cima mandei por email para toda equipe Web.

Após algum tempo, novos requisitos apareceram e eu até mudei o .odt, mas não enviei novamente à Web, pois, na primeira vez, percebi que ninguém leu o arquivo, afinal, não era do interesse deles aquele montante de informação escrita e até, confusa.

Mais modificações vieram e eu modifiquei direto o sistema sem passar pelo documento.

Resultados: após algumas semanas, o documento já não servia para mais nada.

2. pseudossolução: report email

Como documentos extensos não deram resultados para a equipe – incluindo-me nisto – resolvi em outro projeto, enviar um pequeno email report relatando como estava o processo e o que estava adotando para seguir. Ficou parecendo um diário de bordo resumido do projeto, enviado apenas umas duas vezes. Não fui buscar resultados, mas alguma coisa me diz que ninguém leu ou lembra-se disto.

Resultados: fail.

3. pseudossolução: diagramas

Durante os projetos comecei a pensar: porque não disponibilizar os esboços de diagramas de classe que faço de meus designs ? Assim, ajudaria os demais a visualizar por um nível macro o que relaciona com quem. Esta ideia ficou somente na ideia, pois eu me deparei com a situação: como disponibilizar isto e manter atualizado ?

E foi daí que venho minha quarta ideia…

4. pseudossolução: wiki !

Ferramenta utilizada na Vex antes de 2009 sem sucesso, o Wiki foi uma forma que eu vi para documentar os projetos. Cheguei a comentar com o @esampaio sobre isto, mas ele disse que na primeira tentativa (antes de 2009) somente dois ou três desenvolvedores preocupavam-se em atualizar a ferramenta e por fim, acabou morrendo por desatualização.

Após idas e vindas do trabalho pra aula e para casa pensando sobre isto, percebi que o ponto de interseção entre todas as pseudossoluções era: fazer algo além do sistema funcionar.

Eu como programador sei bem o quão relutante eu era para escrever documentos e realizar processos burocráticos de software. Incrivelmente, com estas ditas soluções eu acabaria adicionando (mais) um processo burocrátivo na minha vida, desfocando daquilo que realmente importa: software funcionando. Percebi também que ao longo do tempo eu escrevia testes e aquilo sim agregava valor ao “software funcionando” e mais do que isto, me auxiliava à ver codificadamente as soluções de design tomadas no processo. Possibilitou que eu mudasse a funcionabilidade sem medo de side-effects pois os testes diziam exatamente o que era esperado daquele software.

É aí que entra a escrita de bons testes. Simples, coesos e desacoplados. Para atingir tal estágio não é fácil, requer muitas tentativas e erros (eXtreme Go Horse), mas que no final recompensam cada hora focada na melhoria da técnica de escrever testes.

Meu próximo passo é tentar as retrospectivas. Por isto, realizo hoje uma palestra interna na Vex com o título: Retrospectiva. Nela, apresento a timeline idêntica a este post – com muito mais detalhes, claro – com o objetivo de mostrar para o resto da equipe de TI o que a Web passou durante 2 anos. Pedi que levassem também, um “problema” que cada um vê em seu trabalho atualmente, visando assim encontrar soluções em grupo para tais problemas – que podem até serem recorrentes.

Até o momento não vi motivos para as retrospectivas não funcionarem, mas isto só poderei afirmar daqui algumas semanas.

Antevejo ele, os Traits. E mais, consigo prever que será algo assim:

<?php
trait Hello {
 public function ola() {
   echo "Olá";
 }
}

class Mundo {
 use Hello;

 public function world() {
   echo "{$this->ola()} trait !";
  }
}

$ola = new Mundo();
$ola->world();
// Olá trait !

Ok, não sou bidu. Realmente os Traits estão na lista do possível-futuro PHP 5.4 e eu, baixei a build de 31/03/2011 para testar.

Traits

O PHP não suporta herença multipla – amém – e por este motivo, às vezes ficamos limitados em algumas decisões de projeto (design). O maior problema neste ponto é que toda herença até agora (PHP 5.3.x) é vertical, ou seja, se eu precisar de um nível de abstração diferente no meio do processo, ou precisarei adicionar a nova abstração e reescrever tudo abaixo dela, ou ainda, terei que duplicar o código pois não conseguirei satisfazer a herença.

É nesse ponto que os Traits aparecem. Diferentemente da herença (vertical), os Traits possibilitam-nos criar herenças horizontais.

Exemplo, dada a necessidade:  haverão Funcionários, Supervisores, Gestores e Diretores no sistema e estes possui em comum o fato de receber salário. (capitalismo). Uma possibilidade seria:

Pessoa > Funcionario
Pessoa > Supervisores
Pessoa > Gestores
Pessoa > Diretores

Tudo perfeito. Porém, chega outra necessidade: Gestores e Diretores tem a capacidade de demitir. Gestores precisam gerenciar cronogramas, assim como os Supervisores fazem.

Pessoa.demitir(pessoa) não faz sentido, pois afetiria todos.
Gestor.demitir(pessoa) e Diretor.demitir(pessoa) atende, mas duplicaria o código.

Pessoa > Supervisor > Gestor
Pessoa > Diretor

Shi, apareceu outro nível hierarquico. Traits auxilia exatamente neste ponto ! Vejamos:

Trait Cronograma
Trait Evil (que contém recursos para demitir uma pessoa)
Pessoa > Funcionario
Pessoa > Supervisor : Cronograma
Pessoa > Gestor : Cronograma : Evil
Pessoa >  Diretor : Evil

Note que o Pessoa > Supervisor : Cronograma – os dois pontos para indicar o Trait são de minha autoria – era o Pessoa > Supervisor antigo. Isso porque as atribuições para gerenciar cronogramas foram passadas para o Trait.

Neste pequeno exemplo, o Trait nos auxiliou com um problema de domínio. Acredito que ele também aplique-se e muito bem para problemas onde temos domínios transversais, pois, nele ficariam as atividades do outro domínio pode o domínio principal teria acesso aos recursos sem quebrar a SRP.

Traits em PHP

Como disse no começo, o futuro-provável PHP 5.4 virá com o Trait. Por enquanto essa implementação funcionaria:

<?php
trait Cronograma {
 private static $ATRASADO = "sempre";

 public function cobrarDe(Pessoa $funcionario) {
   $funcionario->definirPressao(self::$ATRASADO);
   $this->youTube();
 }

 private function youTube() {

 }
}

class Funcionario extends Pessoa {
}

class Supervisor extends Pessoa {
 use Cronograma;
}

$colaborador = new Funcionario();
$controlador = new Supervisor();
$controlador->cobrarDe($colaborador);

Os Traits possuem boas capacidades com métodos de instância e estáticos. Vamos explorar um pouco mais:

<?php
trait Hello {
 public function sayHello() {
   echo "Olá";
 }
}

trait World {
 public function sayWorld() {
   echo "Mundo";
 }
}

class View {
 use Hello, World;
}

$view = new View();
$view->sayHello();
$view->sayWorld();
// exibe: Olá Mundo

Pegando informações da Classe

<?php
trait QuemSou {
 public function eu() {
   return get_class($this);
 }
}

class Foo {
 use QuemSou;
}

$foo = new Foo();
echo $foo->eu();
// exibe: Foo

Usando Variáveis de instância da classe

<?php
trait World {
 public function help() {
   return "{$this->hello} world";
 }
}

class Hello {
 private $hello = "Hello";
 use World;
}

$hello = new Hello();
echo $hello->help();
// exibe: Hello world

Modificadores de acesso dos traits na classe

<?php
trait Hello {
 public function ola() {
   echo "Olá mundo";
 }
}

class Modificadores {
 use Hello { ola as private };
}

$ola = new Modificadores();
$ola->ola();
// Fatal Error....

Modificadores de acesso com alias para nome de método

<?php
trait Hello {
 private function ola() {
   echo "Olá mundo";
 }
}

class Modificadores {
 use Hello { ola as public aloha };
}

$ola = new Modificadores();
$ola->aloha();
// Olá mundo

Há outros vários recursos como métodos abstratos nos Traits, precedência, métodos estáticos, late static bindings, métodos mágicos, alias para nome de método do Trait ao usá-lo na classe. Para Rubistas ou Scalistas (?) as possibilidades são as mesmas dos Mixins e Traits de Ruby e Scala respectivamente.

• RFC do PHP Trait (offline por enquanto devido a problemas no servidor deles)

Cenário:

Uma timeline com os últimos 10 commits apenas locais contendo uns testes malucos seu. Destes 10, você precisa tirar um para um push no servidor remoto, porém ele está lá no meio, entre o quinto e sétimo commit. E agora ?

Solução:

git reset + git  diff + git apply

Primeiro, peguei o hash do commit que me interessa da lista. Com ele em mãos, fiz um reset para ele:

$ git reset d3fb9

Fiz um diff entre o commit HEAD (ele próprio) e o penúltimo commit da timeline gerando um .patch da diferença:

$ git diff -u 691ac > meu_commit_importante.patch

Após ter meu patch a salvo, fiz o reset apontando para o último commit que tenho sincronizado com meu servidor remoto:

$ git reset 12345

Após, eu utilizei o git apply –check para verificar se meu patch não ocasionaria problemas e por fim o apliquei:

$ git apply meu_commit_importante.patch

Como eu não preciso logar no histórico que fiz isso (eram commits locais, lembra ?) não utilizei o git am conforme o pessoal costuma utilizar. Após isto, git commit -a -m “Modificação XPTO” e done.

Como me é interessante manter o que estou fazendo vivo, obviamente o coloquei em um branch separado após isto.

Ele abordou rapidamente o que é ALM (Application Lifecycle Management); dedicou uma boa parte do tempo explicando o que realmente é o framework Scrum e da junção de ambos no desenvolvimento de software. O interessante da palestra foi ele propor duas atividades de 5 minutos para que os participantes pensassem sobre a situação-problema por ele anunciada e após abriu para debate.

Após a palestra dele, José Papo assumiu o palco para abordar o tema ALM com governança e qualidade. Ele defendeu que é possível agradar gregos e troianos equipes que gostam da utilização do Scrum no ciclo de vida do software sem esquecer daquele gestor ou diretor que vive de planilhas e gráficos de Gantt daquela empresa que você sabe o nome.

Aliás, uma coisa – ao meu ver – quebrou o brilho do evento: o marketing invasivo da Microsoft. Ridículo, imaturo e desnecessário são as palavras que cabem para o que fora lá praticado.

O José papo por ser da área técnica do Visual Studio no Brasil, precisou ao longo de sua palestra, puxar sardinha pro lado da empresa que paga parte de seu salário de tal forma que ficou nítido que ele era forçado a fazer aquilo.

Utilizar gráficos para exibir uma autoafirmativa liderança no mercado de ferramentas para developers no meio da palestra – inclusive foi citado isso – foi feio; “Utilizem o ‘Bing’ caso não saibam o que é tal coisa” – e não era uma brincadeira quando falava isto. Para não ser injusto, a única descontração que houve foi o diretor de produto Visual Studio citar: “A Microsoft faz coisas boas, com exceção ao [Windows] Vista !”

Apesar do marketing burro da Microsoft, a palestra do Papo agregou muito e desmistificou outras tantas também.

Após o almoço, voltamos com um convite para uma espécie de “Mão na Massa” com a plataforma Team Foundation Server e Visual Studio. Não sei se todas as vagas foram preenchidas, o que posso afirmar é que a palestra que concorria com esse laboratório estava cheia.

Scrum na prática @ ALM Conference Brasil

O pessoal da Programmer’s, apresentou de forma bem didática como eles aplicam Scrum e melhor: a palestra foi instrumentada com Scrum elucidando ainda mais o que era por eles explicado. Destaque para o Kanban 3D com monitor touch screen que estava em exposição no stand deles.

O evento foi proveitoso, grátis e incrivelmente tranquilo. A divulgação deste evento ao meu ver foi fraca, haja vista que sobraram muitas vagas em um evento que eu aposto que seria bem baladado ainda mais por ser gratuito.

Espero que ano que vem ocorra o “II ALM conference Brasil”, mas por favor: eu topo pagar a entrada à ter que ouvir e ver um marketing tão “brutal” praticado por algumas empresas de software.

Pensando sobre o quanto nós testamos ferramentas  - de tracking inclusos – abri uma pesquisa para saber a sua experiência com tais ferramentas. Quem sabe do resultado final não sai algo legal ?

O link para a pesquisa: http://pesquisa.helio.arq.br