Entrando no mundo “enterprise”

Em Maio/2016 fiz uma mudança radical em minha carreira profissional – optei por sair de uma empresa que trabalha com PHP, CakePHP e outras tecnologias que faziam parte da minha vida desde pelo menos 2008 para embarcar em um projeto novo, com pessoas novas e tecnologias completamente novas para mim.

Passei desde então a trabalhar com Java EE, Oracle Database, Bitbucket/Jira/Bamboo (sempre trabalhei com Github e Gitlab), Angular 2 + Typescript. Foi uma mudança e tanto de paradigmas. Tudo em nome do tão falado “enterprise” (não, eu acho que PHP/CakePHP pode ser tão enterprise quanto JavaEE, mas nem todo o mercado pensa assim).

Aprender a trabalhar com servidor de aplicação, pipelines de compilação – compilação a cada pequena alteração de código, a maior reclamação de um programador acostumado com linguagens interpretadas quando mudam, concorrência em sistemas que não são stateless… é um mundo todo novo, mas interessante.

Quero aproveitar todos esses aprendizados e experiências para voltar a escrever aqui, veremos o que vem a seguir.

CakePHP 3.0 – O Fim do Locale

 

A nova versão do meu framework favorito está em estágio avançado e trás uma infinidade de coisas legais.

Dentre as novidades, quero deixar uma dica rápida para um problema comum a qualquer um que não use data/decimais em formato dos EUA: até hoje, para o Cake 1.3 e 2.x eu utilizo o plugin Locale, que já falei a respeito aqui antes.

Com o CakePHP 3.0, o plugin é completamente desnecessário: o novo ORM é capaz de interpretar os dados enviados em formato local para o formato nativo da máquina, de forma transparente.

Você só precisa registrar que os tipos do ORM deve utilizar localização…

Diga ao seu ambiente qual seu locale (pode fazer isso no bootstrap.php):

ini_set('intl.default_locale', 'pt_BR');

Inclua as linhas abaixo no início do seu AppController:

use Cake\Database\Type;
// Habilita o parseamento de datas localizadas
Type::build('date')
 ->useLocaleParser()
 ->setLocaleFormat('dd/MM/yyyy');
Type::build('datetime')
 ->useLocaleParser()
 ->setLocaleFormat('dd/MM/yyyy HH:mm:ss');
Type::build('timestamp')
 ->useLocaleParser()
 ->setLocaleFormat('dd/MM/yyyy HH:mm:ss');
 
// Habilita o parseamento de decimal localizaddos
Type::build('decimal')
 ->useLocaleParser();
Type::build('float')
 ->useLocaleParser();

Pronto, os dados do seu formulário serão interpretados e convertidos antes de serem salvos.

Para alterar a validação de data, você deve usar algo assim:

$validator->add('birthday', 'valid', [
 'rule' => ['date', 'dmy'], // esse é o importante, onde você avisa que a data estará localizada
 'message' => __('Informe uma data válida')
 ]);

E em substituição ao LocaleHelper, você pode formatar suas datas com o método format disponível (já que o registro agora é um objeto), e no caso de float/decimal, você usa a lib Number.

use Cake\I18n\Number;
$data = $user->birthday->format('d/m/Y');
$salary = Number::format($user->salary);

E é isso, sem nenhum plugin, sua aplicação estará falando português (ou qualquer outra linguagem/localização que você deseje utilizar).

Mantendo uma base de código organizada e documentada

Uma problemática comum de quem desenvolve sistemas é como manter a documentação em dia, se que isso comprometa os prazos de desenvolvimento.

Digamos que isso é um problema de otimização:

  1. um código bem documentado facilita e muito a sua manutenção;
  2. documentar código leva tempo;
  3. tempo é um recurso escasso em desenvolvimento de software;

Olha o problema… sem tempo, não há documentação e sem documentação você precisará de mais tempo para dar manutenção – oras, mas você já não tinha tempo para documentar, como vai ter mais tempo agora para dar manutenção?

Tentando equacionar esse problema surgiram várias ferramentas que visam facilitar todas as atividades relacionadas ao desenvolvimento.

Como a maior parte do meu tempo dedico ao PHP e CakePHP, tomarei estes como base para as ferramentas, porém várias delas podem ser utilizadas com outras linguagens/frameworks sem grandes problemas ou então possuem similares em outras linguagens.

Padrão de código

A primeira etapa, e talvez a mais importante, seja definir e disponibilizar um conjunto de regras explicando como o código foi escrito.

Este padrão envolve nome de classes, atributos, métodos, comentários, tabelas e colunas do banco de dados, organização de diretórios dentre outras coisas. Até coisas simples como a indentação deve ser padronizada.

Veja alguns guias de codificação para ter um exemplo do que quero dizer:

Versionamento de código

Um dos recursos mais importantes durante o desenvolvimento é a capacidade de se desfazer determinada alteração e manter um registro de todas as alterações feitas durante o desenvolvimento.

Atualmente, minha ferramenta favorita para versionamento é o Git um sistema distribuído de controle de versão. Porém existem vários outros que podem agradar, como o centralizador SVN e os também distribuídos Mercurial e Bazaar.

É muito fácil trabalhar com qualquer um destes sistemas e após conhecer as facilidades que o versionamento de código lhe proporcionam, você terá dificuldade em trabalhar com código sem controle de versão, pode apostar.

Caso você opte por um sistema distribuído, dê uma olhada neste modelo de organização para seu código: A successful Git branch model

Versionamento do Banco de Dados

Por melhor que seja o projeto do seu sistema uma coisa sempre ocorrerá: mudança. E isso envolve mais do que código, muitas vezes alterações na estrutura do banco são necessárias.

Como controlar essas alterações? A resposta é “Migrations”

No CakePHP precisamos de plugins para dar essa capacidade a aplicação, há dois largamente utilizados:

Outros frameworks fornecem suporte “nativo” ao recurso, como o Ruby on Rails e Doctrine para PHP em geral.

Testes unitários

Acredito que todos os frameworks modernos fornecem suporte a criação de testes unitários em seus projetos. Os testes são uma fase importante do design do software e fundamental para documentação de qualidade.

O CakePHP até sua versão 1.3 utiliza o framework de testes SimpleTest, porém passará a utilizar o PHPUnit em sua versão 2.0 (atualmente em desenvolvimento).

Não sabe o que são testes unitários? Bom, segue alguns links sobre o assunto:

Testes são como controle de versão… depois que você usa, não vive sem.

Documentação

Como comentado anteriormente, um passo importante para documentação são os testes unitários. Porém não devem ser o único.

Uma forma muito eficiente de documentação são os blocos de comentários, no PHP, o padrão PHPDoc é o mais utilizado.

Existem várias ferramentas que varrem o código de sua aplicação e identificam esses blocos para gerar a documentação, alguns deles são:

Quando sua documentação é concisa e completa, entender o funcionamento da aplicação passa a ser fácil, independente de quando ela foi criada. Quando isso é aliado aos testes unitários, fazer manutenção passa a ser uma atividade mais fácil e gratificante.

Por fim, é preciso saber o que/quando está errado e como/quando foi corrigido, ajudando na manutenção do histórico e acompanhamento da evolução do software. Para isso temos o tópico a seguir.

Controle de Bugs/Atividades

Como controlar o que, quando e por quem uma determinada atividade deve ser feita? E como verificar por quem e quando determinada funcionalidade foi implementada? O controle de versão pode fornecer parte destas respostas, mas ficar analisando logs normalmente não é muito comodo. A melhor maneira é utilizar uma ferramenta de controle de bugs/atividades.

Utilizo no meu dia-a-dia o excelente Redmine, um sistema simples porém poderoso para controle de tarefas. Suporta diferentes projetos, sub-projetos, integra-se com vários sistemas de versionamento de código, permite criação de wikis para documentação além de vários outros recursos.

Além deste, existem vários outros sistemas como o Bugzilla, Trac, Mantis e PHProjekt.

Conclusão?

Não, não tem conclusão. O texto visa apenas apresentar algumas atividades que juntas ao planejamento e desenvolvimento de software tendem a tornar a vida dos desenvolvedores melhor, seja diminuindo o stress causado por alterações dos requisitos ou manutenção de código mal projetado/escrito, seja tornando o desenvolvimento mais ágil, permitindo mais horas de lazer e descanso e menos fios de cabelo branco.

A intenção nunca foi cobrir todos os tópicos a exaustão, mas sim apresentar alguns exemplos e motivos para adoção de tais ferramentas/ideias. Caso tenha surgido dúvida a respeito de qualquer item, deixe um comentário =]

Sentiu a falta de algum item? Utiliza algo de forma diferente? Deixe um comentário também.

————-
Postado originalmente no blog da Radig

Dica Rápida – Evitando problemas com uso de jQuery e imagens

Algumas vezes precisamos recuperar, em tempo de execução, o tamanho de uma determinada imagem para aplica-la corretamente ao layout da página, porém essa verificação pode acontecer antes da hora, o que geraria erros inesperados.

Todo mundo que trabalha com a biblioteca jQuery conhece a chamada:

$(document).ready({
//seu código javascript
});

Ela diz ao browser para executar o bloco interno somente quando o DOM do seu documento tiver sido totalmente carregado, isso permite que ele faça o parser de seu documento utilizando os seletores sem esquecer de nenhum item. Porém quando carregamos estruturas externas ao DOM, como uma imagem, não temos garantia de que o código dentro do bloco anterior será executado quando a imagem já tiver sido carregada.
Dessa maneira, caso você precise de informações sobre a imagem, seu script falhará.

Para contornar isso, podemos utilizar uma outra chamada, que é disparada somente quando TODO o documento tiver sido carregado:

$(window).load({
//seu código javascript
});

As duas diferenças, além do comportamento são:

  1. Saí o ‘seletor’ document para a entrada do window;
  2. Saí o evento ready para a entrada do load;

A primeira alteração ocorre por conta da segunda, já que o evento load não pode ser associado a um document.

Com essa pequena alteração você garante que seu script rodará apenas quando todo o documento tiver sido carregado – o que é essencial em algumas situações, como a citada anteriormente, porém dispensável na maioria das vezes.

Fonte: http://api.jquery.com/load-event/

Obrigado pelos peixes SVN

Há alguns anos descobri o fantástico mundo do controle de versão, naquele momento me perguntei “como vivi sem isso até hoje?”. Dali em diante podia alterar arquivos sem medo, qualquer erro era só voltar uma versão e tudo certo. Trabalhar em equipe finalmente se tornava algo fácil, graças ao Subversion – SVN.

Porém os anos passaram e algumas coisas começaram a fazer falta: como faço quando estou desenvolvendo algo grande, fico sem commitar até ter algo estável/usável? crio um branch para isso? mas e depois para unir os branches, e os conflitos? além disso, se só eu estou trabalhando em cima disso, porque commitar para todo mundo algo não pronto?

Foi aí que descobri o GIT, um sistema de controle de versão distribuído, open source e gratuito. Ok, ele é gratuito e open source, mas isso não é motivo suficiente. Como disse, ele é um sistema de controle de versão distribuído, isso quer dizer que cada um que tem uma cópia do repositório tem de fato uma cópia dele, e pode servir outras pessoas, ver histórico, tudo localmente.

Então de quebra, ele resolve o problema de ter de criar um branch para desenvolver uma funcionalidade que só eu vou mexer, posso controlar cada alteração minha localmente, e quando quiser – se quiser – posso sincronizar meu repositório local com um outro central (que eu considero central, já que essa figura não existe no GIT). E mais, ele é MUITO RÁPIDO. Acho que para ajudar na argumentação de que é rápido basta dizer que ele foi feito por alguns desenvolvedores do Kernel Linux, e gerencia todo o código trabalhado por eles – e não é pouca coisa.

Ainda estou caminhando com o GIT, tenho aproveitado minha ânsia de aprende-lo junto com a de contribuir com softwares open source para criar e disponibilizar projetos no GitHub.

A grande maioria dos projetos é voltado ao CakePHP, mas há outras coisas também. Alguns projetos que podem interessar são:

  • Comitiva – Sistema construído em CakePHP 1.3 para gerenciamento de eventos;
  • Plugin Mailer – Um plugin que ajuda na utilização da biblioteca PHP SwiftMailer dentro do CakePHP;
  • Behavior Locale – Um behavior para transformar dados vindo do usuário de seu padrão local para um padrão internacional (de banco de dados)
  • Libs – uma coleção de pequenos scripts PHP que fui fazendo ao longo da vida. Há coisas boas, coisas úteis, coisas não tão úteis, mas tudo pode ser usado ao menos como ponto inicial para uma implementação mais elaborada.

Classe para fazer Contagem de Linhas e Bônus

Classe para contar número de linhas “codadas” de uma aplicação. Foi escrita em PHP, pensando em extensões comuns nesse tipo de sistema, mas pode facilmente ser adaptado para contar linhas de sistemas em Java, C/C++ dentre outras.

A idéia por trás da classe foi matar a curiosidade geek de ver o tamanho de uma “criança” que ajudei a criar, além disso quero estudar uma forma de fazer melhores estimativas para custo e prazo para desenvolvimento de software.

A classe está disponível livremente, sob a licença MIT. Faça o download dela metrics.class.php. Qualquer dúvida sobre sua utilização, deixe nos comentários ou entre em contato comigo.

Vou aproveitar e disponibilizar a atualização da classe para validação de dados e outras “firulas” mais que já disponibilizei anteriormente, porém agora com pequenas adições. Visualize ela validation.class.php.

Qualquer sugestão sobre ambas as classes pode ser feita nos comentários. Espero que seja útil para alguém.

Até a próxima.

———–

Atualizado: troquei os arquivos por equivalentes compactados em arquivo .zip . Valeu Gelinho e Felipe ;]

———–

Atualizado novamente: à um bom tempo meu amigo Raphox indicou na lista do PHPMS uma classe criada pelo grande Sebastian Bergmann para mensurar softwares em PHP, o nome da classe é PHPLOC e ela está disponível neste endereço: http://github.com/sebastianbergmann/phploc . Vale a pena conferir

CakePHP – Dúvidas Comuns #2

Dúvida: Como usar habilitar a internacionalização – o famoso I18N – nos erros de validação de seu modelo? Fácil? Como fazer então no próprio modelo para não repetir frases em várias Views?

Habilitar a internacionalização e ter a localização em uma aplicação com CakePHP desde a versão 1.2  é relativamente simples: basta uma lida no nosso Cookbook e pronto.

Outra coisa que é relativamente simples de se fazer é validar os dados, basta termos um atributo em nosso modelo chamado “validate” e seguir as dicas do livro de receitas.

Mas pelo Cookbook somos induzidos a fornecer a mensagem de erro na hora de criar a View, algo que eu particularmente não gosto. É até comum termos um modelo que é usado por Controllers diferentes e consequêntemente por Views diferentes.

Uma maneira de evitar isso, é definir as mensagens de erro já na definição das regras de validação, dentro do atributo “validate” do seu modelo. O grande problema é que para traduzir uma determinada expressão utilizamos um método, e a chamada de método na definição estática de um atributo não é permitida no PHP (dúvida? tente fazer o código abaixo)

class Modelo extends AppModel {
var $validate = _('ola mundo');
}
//esse código não devera ser executado

A solução para isso é a atribuição das regras de validação no momento da instanciação da classe, ou seja, no seu método construtor, da seguinte maneira

 class Modelo extends AppModel {
var $validate;
function __construct(){
parent::__construct();
$this->validate = array( /* aqui você pode definir as regras e mensagens,mesmo chamando um método */ );
}
}

Qualquer dúvida não deixem de utilizar os comentários ;]

——–
Atualizado: havia esquecido da chamada ao construtor da superclasse AppModels ( através do parent::__construct() ) no último código mostrado.
——–
Atualizado

Obrigado ao José Tranca e Thiago Goulart pelos comentários, as soluções propostas por eles devem ser adotada em detrimento da minha, já que melhora consideravelmente a modularidade e reusabilidade das traduções.

CakePHP – dúvidas comuns #1

Como já comentei algumas vezes, estou desenvolvendo com um framework MVC em PHP chamado CakePHP. Ele foi construído com intuíto de provar o potencial do PHP (na época em comparação ao Ruby e o Ruby on Rails). Se precisar de mais informações sobre o framework sugiro leitura do seu Cookbook e de outros blogs a respeito.

Desde que descobri o CakePHP faço parte do grupo CakePHP Tuga e ocasionalmente no canal de IRC do grupo #cakephp-pt na rede Freenode.org, e já tive a oportunidade de aprender e ajudar diversas vezes.

Vamos as dúvidas:

  1. Como salvar dados de um formulário que envolva um relacionamenteo de “muitos para muitos”/many-to- many ou ainda de HasAndBelongToMany (HABTM) ?

Nesta dúvida temos que ter em mente que o CakePHP faz todas as ligações entre nossos modelos desde que sigamos suas convenções, caso façamos isso, não haverá dificuldades.
Mas quais são essas convenções? Veja você mesmo.

Um detalhe que não podemos esquecer é que por padrão o CakePHP está preparado para tratar suas convenções em inglês, então, se não quisermos ter de modificar as configurações padrões, temos de desenvolver em inglês. Ok?

Seguindo todas as conveções o que fica faltando? É preciso saber como um relacionamento HABTM se manifesta em um formulário, ou seja, como ele é apresentado. No CookBook temos um texto sobre o caso. Resumindo, o que temos de ter é:

  • Um formulário com o nome de um dos modelos envolvidos no relacionamento. Por exemplo, em um blog temos um modelo Post e outro Tags, os dois estão ligados por um HABTM, então no formulário para inserir um Post, o nome de formulário seria Post.
  • Um ou mais campos identificados com o outro modelo parte do relacionamento e sua chave. No nosso exemplo seriam um ou mais campos com o nome ‘Tag.Tag’.

No item anterior que surge a principal dúvida: como definir o nome do meu campo? que tipo de campo usar?

Primeiro definimos o tipo de campo a se utilizar: normalmente utilizamos um Select box para multiplas seleções OU um conjunto de Checkbox. Qualquer que seja a escolha o restante é bem simples:

/*
$tag é o retorno de um find('list') com os campos id e name selecionados
$tags = array( array('id' => 1, 'name' => 'tag 1'), array('id' => 2, 'name' => 'tag 2') );
 
o índice 'multiple' só deve ser utilizado quando quiser um conjunto de checkbox
*/
echo $form->input('Tag.Tag', array(
	'type' => 'select',
	'multiple' => 'checkbox',
	'options' => $tags,
	'labels' => 'Selecione as tags'
	));

Com isso seu formulário já retornará o que é esperado pelo CakePHP e tudo que será necessário para salvar os dados do relacionamento é utilizar o método ‘saveAll’ ao invés de ‘save’.

Ainda esta semana comentarei das dúvidas sobre validação.

AJAX com Prototype

Prototype é uma biblioteca javascript bastante utilizada, mas que pra mim nunca chamou atenção (ao contrário do JQuery), mas como tenho utilizado o CakePHP e em sua estrutura de Helpers ele usa esta biblioteca, tive de “perder” um tempinho estudando-a.

Para isso, fiz como meu amigo PorKaria e montei um sisteminha simples de comentários (na verdade o dele era o guestbook, mas no fim fazem a mesmo coisa, hehehe).

Descrição do sistema:

Sistema usando AJAX (na verdade o X aqui é de XHTML, porque não utilizo XML) Permite a inserção de comentários, salvando-os em um banco de dados (MySQL), tudo de forma assíncrona. A bibliote utilizada para implementação da parte em javascript é a Prototype, a formatação (CSS) foi retirada de um tutorial do Tableless sobre formatação de formulários e o PHP foi escrito por mim. Além do cadastro, fiz o que pode se chamar início de um sistema de busca com sugestão (famoso autocomplete). Digo o início porque ele não avalia bem o momento de se fazer a busca e não é possível clicar nos resultados, apenas vê-los.

Continue lendo

25 erros de programação mais graves

Foi divulgado pelo SANS Institute[en] uma lista com os 25 erros de programação que mais causam prejuízos no mundo. Esta lista foi elaborada por especialistas de mais de 30 instituições dos EUA e organizações internacionais de segurança digital.

tradicional erro de segurança
um erro tradicional

A lista foi subdivida em três categorias: “Interação Insegura entre Componentes”, “Risco no Gerenciamento de Recursos” e “Defesa Porosa” – no original: Insecure Interaction Between Components, Risky Resource Management e Porous Defenses.

Há na lista falhas como possibilidade de injeção de códigos, utilização de algorítmos de criptografia defasado e transferência de dados sensíveis sem criptografia.

No artigo original[en] há várias informações sobre os erros e comentários de renomadas empresas de segurança sobre a importância da lista.

Sem dúvida um texto que vale a pena para todo desenvolvedor.

via: IDG NOW!