O PHP Macarrônico é assim

Esse método é justificável dentro da PHP até certo ponto: a própria linguagem tem por princípio a simplicidade e velocidade na codificação e resolução de problemas. O próprio Rasmus Lerdorf, criador do PHP, já se mostrou bem contrário aos frameworks atuais pois eles são lentos e não escaláveis, culpa do feeling de  ”faz-tudo” que a maioria delas leva no sentido de continuar ostentando a bandeira de “desenvolvimento rápido” da PHP, que muita gente confunde com gambiarras e que transformou a PHP em sinônimo de POG (Programação Orientada à Gambiarras).

Por muito tempo eu, como muitos desenvolvedores/empresas que conheço e já conversei, pensava assim:

“Porque vou abandonar toda aquela minha infra-estrutura pronta de gerenciamento de conteúdo e minhas bibliotecas caseiras que funcionam muito bem para adotar uma framework MVC e perder $$tempo$$ precioso ou impactar no $$prazo$$ que dei para o meu cliente. Não tem porque eu correr esse ri$co“.

Existem duas situações muito especiais que consigo identificar na hora de desenvolver uma aplicação e que impactam de forma crítica na decisão correta da arquitetura a ser seguida: necessidade de escalar a aplicação e potencial expansão de funcionalidades durante e depois do projeto.

Quantas aplicações de alta consumo de banda você já desenvolveu em sua empresa com PHP ? E dessas, quantas você realmente tem que dar uma atenção e implementação contínua de funcionalidades novas ? Se você não contou nenhuma, o seu caso é bem comparável ao de muitos desenvolvedores PHP por aí. Se você contou alguma e não teve dores de cabeça com a manutenção ou testes em sua aplicação, você é um cara de sorte.

O feijão com arroz do desenvolvimento PHP no Brasil é muito atrelado à gerenciadores de conteúdo, front-end de websites e muitos projetos que geralmente são desenvolvidos por times por vezes multi-disciplinares. Um ecossistema comum são agências digitais, bureau de mídias digitais e várias outras que precisam desenvolver da forma mais simples e eficaz possível, muitas vezes devido até ao orçamento apertado e a menor margem de chance de que as coisas deêm errado para não ferrar um cronograma geralmente apertado e sem vez para os mais lentos. Juntamos isso à realidade dessas empresas que nem sempre tem um desenvolvedor com uma boa experiência, sem background de programação ou “migrados” de outras áreas e a lenha está feita.

Mesmo em ambientes mais profissionais, ainda existem aqueles que ainda resistem à idéia e são os “super-homens” que desenvolvem coisas que só eles conhecem e são difíceis de disseminar conhecimento válido na equipe.

Dentro desse contexto, algumas situações abaixo concerteza já rolaram com você ou na empresa em que você trabalha:

• Designers sobrescrevendo páginas com lógica de negócio embutida
• Programadores detonando CSS dos outros
• Classes das regras de negócio sendo alteradas a torto e direito ferrando algo que ja estava funcionando
• Métodos espalhados pela aplicação com nomes bizarros e/ou funcionalidades redundantes ou no mínimo estranhas
• Lógica de negócio repetidas, implementadas de formas diferentes e sem um lugar comum
• Registros no banco de dados com dados incompletos e inconsistentes
• Formulários que não validam tudo o que deveriam validar e que deixam cadastrar assim mesmo
• e por ai vai ….

Puxadin ali, patchzin aqui e geralmente temos monstros burocráticos ou incontroláveis que temos que lidar com o passar do tempo: fruto de uma arquitetura por vezes equivocada mas que por N motivos não pode ser substituída. E aí José ?

Adote um framework!

A solução mais sustentável para esse tipo de situação seja provavelmente a adoção de um framework, mas existe uma resistência muito grande que é completamente justificável: voltamos àquelas perguntas relativas à “para que mexer num time que está ganhando?“.

A resposta é:  ”Você pode ganhar muito mais a curto prazo e com mais qualidade de vida”.

Algumas perguntas e afirmações que já ouvi (e eu mesmo me fiz) antes de tudo:

• Meus programadores (ou eu) tem nível técnico para trabalhar com isso?
• E tudo o que eu tenho? O que eu faço que isso ?
• Isso vai atrasar o projeto cara!
• MVC ? ORM? Que p*rra é essa ?
• As funções dos meus includes já fazem tudo isso e muito melhor!
• Bah! Já temos nosso ADM pronto: é só copiar, colar e alterar os campos.
• O cliente disse que quer apenas produtos e não vai precisar de nada mais.

Todo esse tipo de pensamento/sentimento as vezes não vem de comodismo ou preguiça, mas da falta de conhecimento ou estudo de como uma framework pode ajudar no trabalho, até onde ela pode ir e principalmente em equipe multi-disciplinares com prazos ultra-curtos.

Então, vão algumas observações/pontos de vista em relação às principais frameworks PHP do mercado que podem resumir de certa forma alguns pontos positivos e relevantes para a adoção de uma framework:

• Elas já estão bem difundidas, com boa documentação e geralmente tem uma curva de aprendizado mínima: com um mês um programador iniciante estará fazendo cadastros simples e bacanas;
• Por serem frameworks de conhecimento público, a disseminação do conhecimento e uso é muito maior e não fica atrelado à uma ou duas pessoas;
• Você não tem apenas uma ou duas pessoas pra fazer “aquela melhoria no envio de e-mail”: você terá uma comunidade para te ajudar com isso;
• Se o “dono da framework” morrer, você não perder todo o investimento na ferramenta porque não existe “dono”. Acaba aquela falácia do “super-homem” ou do “cara que fez a framework e só ele sabe mexer nisso”.
• Estatisticamente comprovado, desenvolver e manter uma framework caseira é muito mais custoso que usar e customizar uma framework já extensamente utilizada no mercado, tanto à nivel de suporte quanto à melhoria da ferramenta e correção de bugs;
• O que traz diferencial para o negócio de seu cliente (e o seu) é o conhecimento de negócio: a ferramenta será apenas um meio e é mais que bacana que ela esteja pronta e você se preocupe apenas com o negócio e não como “fazer aquele usuário logar e se manter autenticado em página X e Y”.
• Frameworks trabalham com padrões de design testados e refatorados continuamente por pessoas com anos de experiência em software: é jogar dinheiro no lixo tentar re-inventar a roda ou re-implementar tudo se não for completamente necessário.
• Programadores experientes terão uma ferramenta amplamente testada e na maioria das vezes bem flexíveis quando precisar adaptar “aquela regra de negócio extraterrestre do cliente XPTO“;
• Frameworks tem um conjunto grande de plugins/componentes que cobre a maior parte das tarefas comuns como controle de sessão/cookies, envio de e-mails, upload de imagens, internacionalização, autenticação e por ai vai. Se não existir, geralmente é fácil (e muito didático) desenvolver algo novo e que a comunidade vai concerteza agradecer;
• A parte de visualização dos dados (view) fica separada do controle das ações possíveis no sistema (controller), que por sua vez tem que respeitar as regras de negócio implementadas no acesso ao banco (model) que ficam centralizadas num lugar apenas: ou seja, o MVC (Model-View-Controller) vai diminuir bastante o quebra pau entre designers e programadores e evitar bastante re-trabalho. No caso de sistemas, vai melhorar e muito a manutenção deste;
• O trabalho com testes é praticamente embutido nessas frameworks e é uma forma ótima para iniciar os trabalhos com TDD nos projetos. Testes não são moda e sim uma tendência natural do mercado onde as aplicações precisam ser cada vez mais confiáveis para não trazer prejuízo para seu cliente;

Boa parte das dúvidas que geralmente se tem recaem principalmente na preocupação de comprometer um projeto com questões técnicas e impedimentos ou na parte do aprendizado em si da ferramenta. Felizmente, com o tempo se percebe que com empenho em cerca de um ou dois meses uma boa framework é absorvida naturalmente.

De certa forma, ela até mesmo promove uma auto-reciclagem de todos os profissionais pois começam a envolver questões como padrões de projeto, orientação à objetos, testes, controles de versão e tudo o que há mais de novo no mundo de desenvolvimento e que volta e meia não chega ao mundo das agências ou software houses mais caseiras.

Em resumo

A adoção de uma framework MVC não é um bixo de 15 cabeças cuspindo fogo e destruindo, mas assim como qualquer novidade apresenta riscos e custo, que CONCERTEZA são altamente recompensadores mesmo que no final ela não seja aproveitada: idéias são concebidas e o nível de conhecimento pós-experimentação é notadamente maior.

Para quem quiser tentar, algumas dicas podem ajudar (ao menos me ajudaram):

• Inicie com projetos pequenos ou internos para sentir como a framework funciona e até mesmo descobrir características a favor ou contra sua adoção na empresa. Após conhecer pontos fortes e fracos, decida se ela é realmente viável em seu projeto;
• Se você tem um time, escolha uma pessoa para estudar a ferramenta escolhida e depois faça um hands-on com a equipe pois assim as dúvidas/conclusões fluem de uma maneira surpreendente;
• Procure conhecer sobre OO (Orientação à Objetos), ORM (Object-Relational Mapping), MVC (paradigma Model-View-Controller), TDD (uso bastante o SimpleTest), controle de versão (estamos usando bastante o GIT) e metodologias ágeis (uso bastante o Scrum): essas coisas “puxam” junto um monte de outras coisas que vão fazer o aproveitamento de qualquer framework MUITO maior;
• Participe ativamente de listas para tirar dúvidas suas e dos outros: em pouco tempo se tornar um commiter em um projeto pode ser uma experiência e tanto de aprendizado;
• Mantenha-se antenado nas novidades da framework: a maioria delas tem atualizações constantes e as vezes até chave para alguma coisas que sua empresa pretende fazer;

Existem, claro, frameworks com diferentes abordagens e  vantagens. Então, para tentar encurtar o caminho mas sem traçar um comparativo muito técnico, vão algumas bacanas para se começar:

• CakePHP, hoje uma das frameworks mais conhecidas e utilizadas no PHP, é uma ferramenta bem influenciada pelo Ruby On Rails, com documentação bacana e uma comunidade grande pacas. Sua curva de aprendizado é bem fácil e os resultados saem bem rápido também, devido ao enorme número de coisas prontas para serem utilizadas. Um ponto fraco é sua performance que não é tão rapida quanto às concorrentes;
• CodeIgniter, é uma framework que vai no caminho contrário da CakePHP: ela é mais enxuta e sem muitos componentes para rodar bem rápido. Sua curva é tranquila e a documentação bem bacana. Um ponto fraco é a ausência nativa de ORM para mapeamento do banco de dados.

Existem várias frameworks, com vários “sabores” a serem degustados: é ver, testar e ver qual mais agrada e ser feliz!

Simbora.

Mas e quando não temos nada instalado e precisamos fazer um fluxograma descente e rapidin ? Já vi gente até apelando para aquelas bizarrices do Word: pra alguns funciona, mas vai fazer um rascunho de UML/Diagrama pra ver o lado bom da vida.

Para quem precisa de algo assim, vale a pena demais experimentar o Gliffy.

Descobri por esses dias o Gliffy, uma ferramenta online de geração de diagramas bem bacana, fácil de mexer e o melhor: GRÁTIS por 30 dias na versão Premium! A diferença crítica entre a versão Basic (que você terá após 30 dias se não quiser pagar pela versão Premium) além das adições significativas, é que você poderá ter apenas 5 mapas e todos eles serão públicos.

Então, se a sua idéia é mesmo fazer organogramas e coisas do tipo rapidim pra complementar aquele trabalho, essa é a ferramenta. Se você usa pra caramba, ainda acho que valeria avaliar a ferramenta, pois são apenas 5 dólares por mês.

Para usar o serviço, basta se cadastrar e começar a usar. Enquanto estiver na versão Premium (que é a que você começa assim que se cadastra) você pode criar quantos documentos quiser.

Interface e uso

A interface é bem simplista e tem vários shapes (formas) acessíveis que podem ser usados e manipulados. Os menus também apresentam várias opções como agrupar elementos e afins.

A interface do Giffly é simples e intuitiva

A manipulação dos elementos é bem fácil também, com guias para aumentar, diminuir, rotacionar e inserir texto quando clicados duas vezes.

Manipulação de elementos

Outro lance bem bacana são as opções de propriedades e customizações, que são apresentadas num menu contextual, que apresenta diferentes opções dependendo do elemento selecionado.

Menu de opções contextualizado

Exportando

O Gliffy permite a exportação fácil para JPG/PNG. Ele possuiu um exportador para o Microsoft Visio também (formato SVG). Nunca se sabe né ?

Exportação

E é isso

Para quem quer algo pra fazer algo simples e no pulo, taí uma ótima ferramenta para quebrar o galho. Para quem quer algo para substituir ferramentas desktop tradicionais, vale a avaliação: eu sinceramente achei bem mais prático e com opções que o OmniGraffle para Mac, um dos que o pessoal mais fala bem.

$imbora.

Continuando nossa sequência de artigos sobre o SimpleTest, já aprendemos como fazer testes unitários e agrupa-los para facilitar a execução em lote: agora vamos falar um pouco sobre mock objects.

Até agora, nossos testes unitários se resumiram a testar métodos e funcionalidades que envolviam apenas uma classe como nossa calculadora: tínhamos um método chamado “somar” que fazia parte da própria classe e recebia como parametro de entrada apenas dois inteiros.

A idéia do teste unitário (ou de unidade), como o próprio nome diz, é isolar e testar apenas aquele ponto e funcionalidade do software: então é imprescindível que possamos isolar da melhor maneira apenas a classe/métodos que desejamos testar para que, caso apresente falha, possamos identificar exatamente onde a falha ocorreu.

Mas e quando nossa classe depende de outra(s) classe(s) para fazer um método funcionar ?

Conceituando o problema

Então, vamos imaginar a seguinte situação: estamos desenvolvendo um software de e-commerce e em dado momento precisamos validar se um usuário existe em nosso banco de dados. Apesar das possibilidades abrangentes de um sistema de validação/autenticação, vamos nos preocupar com o básico e implementá-lo de uma forma simples como abaixo:

As classes usadas no validador

Vamos criar uma classe chamada Validator, que receberá o login do usuário, verificará no banco de dados se ele existe ou não e validará seu acesso. Para tanto, nossa classe de validação terá um método chamado validate, que receberá um parâmetro string representando o nome do usuário a ser validado.

Para conectar-se ao banco de dados, nossa classe receberá em sua criação um objeto referente à classe Conexao, que disponibilizará um método chamado query, que consulta o banco e retorna uma array de resultados.

classe validator.php

classe conexao.php

Para que tudo fique mais claro, podemos dar uma olhada em como ficaria nosso código final da aplicação:

Como aprendemos em nosso primeiro artigo sobre TDD, primeiro fazemos os testes e depois fazemos nossa aplicação passar nos neles, implementando a lógica de negócio válida. Nosso objetivo nesse momento é testar o método validate: fazendo um pouco de nossa flexão mental chegamos a dois comportamentos válidos para o método:

• Se o usuário existir, ele retornará true;
• Se o usuário não existir, ele retornará false;

O problema

Então, pensamos “Bacana! Então vou fazer um caso de teste chamado ValidatorTestCase e um teste chamado testValidarSeUsuarioExistir que irá validar se um usuário foi validado se ele existir!“.

Partimos para o código então:

Tudo ok ? NADA OK! O código acima pode funcionar mas temos alguns problemas:

• Como garantir que nosso banco de dados vai estar disponível na hora do teste ?
• Como vamos saber se existe o usuário que queremos testar está no banco, para testarmos se a validação realmente vai passar no teste e se comportar como queremos ?
• E se ocorrer um erro de conexão ao banco no meio do teste ?
• E se a conexão banco for demorada e nosso caso de teste ter 50 testes acessando o banco? oO
• Como saber se as configurações estão exatas para a conexão no banco? Aliás, eu nem sei nada sobre config até agora!
• E principalmente: e se ocorrer um problema na pesquisa da query que não tenha nada haver exatamente com nosso validador, já que nosso objetivo é testar unicamente se “ao receber um usuário, verificar se ele existe no banco e validar em caso afirmativo”.

Haja coisa né ?

Mock Objects (nosso boneco de testes)

Pensando nesse problema, foram criados os Mock objects. Um mock object (vou usar o termo em inglês pois a esmagadora maioria das referências TDD estão assim) nada mais é que um objeto que simula e imita o comportamento de um objeto real.

Imagine os bonecos de teste de batidas de carro: os engenheiros os constroem com peso, altura, juntas e vários aspectos que imitam o corpo de um ser humano para poderem fazer seus testes. Eles colocam esses bonecos nas mais variadas situações e posições possíveis para testarem a segurança de um carro entre outras coisas, sem precisar matar ninguém para isso.

No nosso caso, nossos mock objects são representações de classes reais onde podemos simular e forçar qualquer comportamento que desejamos para testarmos certas situações que talvez não seriam possíveis de serem alcançadas “explicitamente” sem gambiarra-las ou mesmo que sejam de dificil configuração.

Em resumo, usamos um mock quando nossa classe real (colado do wikipedia – thank’s god):

• gera resultados não deterministicos (e.g. a hora ou temperatura atual);
• tem estados que são difíceis de criar ou reproduzir (e.g. erro de comunicação da rede);
• é lento (e.g. um banco de dados completo que precisa ser inicializado antes do teste);
• ainda não existe ou pode ter comportamento alterado;
• teriam que adicionar informações e métodos exclusivamente para os testes (e não para sua função real).

Analisando nosso problema anterior, podemos constatar que nossa classe Conexao é forte candidata à ser “mockeada”: assim nos livramos de todos aqueles problemas de conexão, de existência de registros e tudo mais que não tem nada haver com nosso teste unitário em si, que diz respeito pura e diretamente à nossa classe Validator.

Ou seja, ao invés de usar a classe Conexao real, vamos usar uma “imitação” dela, muito mais simples e fácil de manipular para chegarmos de forma mais simples ao nosso resultado esperado no teste unitário. Vamos utilizar esse mock pois não faz sentido testar a conexão nem nenhum método dessa classe e sim utilizar o comportamento referente ao código que vamos utilizar no nosso teste.

Codando!

Como vimos, nossa classe Conexao não tem nada implementado ainda. Mas isso não nos interessa pois vamos fazer um mock da classe, para podermos simular o que precisamos: o retorno dos resultados que desejamos para testar o método validate do Validator.

Para criar um mock de nossa classe, simplesmente fazemos o include dessa classe em nosso teste e “geramos” esse mock com o método generate da classe Mock (que é importada automaticamente no nosso include do autorun.php do Simpletest).

Com isso, vamos gerar um clone mockeado da classe Conexao para podermos usa-la em nossos testes.

Fácil né ?

Mocks como atores

Agora que sabemos como criar um mock, vamos aprender a “imitar” o que a classe original faz afim de “simular” os resultados que queremos ter para fazer nossos testes passarem.

Os Mocks podem se comportar de duas maneiras:

• como Atores (Actors), onde o Mock é usado para simular o retorno de propriedades e métodos (e o que vamos usar aqui).
• como Críticos (Critics), onde o Mock é usado para guardar e verificar as interações entre os objetos num teste.

Quando trabalhamos com o Mock apenas como Ator, apenas simulando o retorno de propriedades e métodos, ele é considerado um “server stub”, que nada mais é que um objeto que simula um comportamento. Existe uma grande discussão existe em torno disso, mas por enquanto vamos deixar pra lá pois vamos falar sobre os Mocks como uma ferramenta para testes baseados em interação no próximo post e isso vai ficar mais claro.

Se analisarmos a classe Conexao novamente, vamos chegar à conclusão que o método que vai ser utilizado em nosso teste será apenas o query: vamos fazer uma consulta à base dados buscando todos os usuários cujo nome seja igual ao parametro que enviarmos ao método validate.

Nosso mock da Conexao ainda não sabe fazer nada, mas podemos instrui-lo a retornar o que a quisermos. Por exemplo, em nosso teste chamado testValidarSeUsuarioExistir vamos ter que dizer ao mock para retornar sempre um resultado que satisfaça nosso teste. Ou seja, como no exemplo da implementação, se eu envio “Léo” ele tem que me devolver um resultado onde “Léo” esteja presente, pois queremos testar o comportamento do validate e não o retorno de valor da conexão.

Então, vamos fazer nosso mock devolver sempre um resultado onde exista o usuário “Léo” no resultado.

Como vimos, nosso método query retorna uma array com os resultados da consulta. Vamos então instruir o mock a retornar sempre um array quando o método query for chamado. Quando o objeto é mockeado, ele ganha vários métodos, entre eles o setReturnValue: esse método diz ao mock “retorne sempre X resultado quando tal método for chamado”.

Pronto! Agora podemos testar nosso validate:

O que aconteceu em nosso teste:

• Criamos um mock do nossa classe Conexao
• Instanciamos esse mock em nosso teste
• Instruimos ao mock para que ele devolvesse sempre um array com o usuário Léo quando o método query fosse chamado
• Instanciamos nosso validator, passando como parâmetro nossa conexao mockeada
• fizemos o teste para verificar se a validação deu certo

Fui roda-lo e ….

Opsss! Falhou!

Temos nosso resultado esperado, afinal não implementamos ainda nosso método validate. Então, vamos resolver isso:

Implementamos uma lógica onde fazemos uma pesquisa ao banco pedindo para selecionar o id e o nome da tabela users onde o nome seja igual ao parâmetro enviado. A mágica acontece finalmente: nossa ” falsa conexao” foi instruída a retornar sempre um array com uma posição apenas, onde o resultado sempre é Léo.

Agora quando rodamos o teste:

Teste do validator agora com a implementação

Bingo! Nosso teste passou!

Para comprovarmos que o funcionamento do validate está correto, vamos complementar nosso caso de teste adicionando um teste pra verificar se informarmos um usuário que não existe, ele retornar false.

Vamos testar denovo e …

Fazendo dois testes

Mantemos o nosso mock retornando apenas “Léo” nos resultados, mas dessa vez passamos o nome “Jeveaux” para procurar e como esperado, ele retornou false, dado que o usuário “Jeveaux” não existe. Show!

Ufa! Vamos resumir o testamento

O aprendizado de mock objects é um pouco abstrato inicialmente mas com alguma prática se revela uma técnica perfeita e viável para fazemos nossos testes unitários funcionarem de forma correta e independente. A utilização do Mock Object apenas como ator (ou server stub como você lerá muito por ai) é apenas uma parte do poder real de um mock.

Dentro de nosso entendimento, podemos resumir que um mock object é uma imitação de nosso objeto real que podemos manipular de forma fácil e simples para que ele faça exatamente o que quisermos, facilitando assim a implementação de nossos testes unitários e isolando nossas classes.

Algumas leituras legais melhorar o entendimento dos Mock Objects:

• Mock Objects no SimpleTest [ doc oficial do SimpleTest ]
• Testes de unidade com mock objects [ ImproveIt ]
• Mock Objects and Stubs: The Bottle Brush of TDD
• Mock Objects [ Wikipedia]

Outra referência bem bacana é o blog do Jeveaux, meu revisor TDD oficial e grande conhecer de causa.

No próximo post vamos ver como trabalhar com nosso Mock Object em sua forma mais plena e com um exemplo um pouco mais complexo para partir também para o modo Critic.

Simbora.

Nesta quarta-feira, dia 02/12, rola no Canto da Roça da Praia do Canto o 4º Quarta Web, um evento que reúne vários profissionais da internet capixaba todo mês e vem se tornando uma referência no estado. Geralmente o evento ocorre sempre na última quarta do mês, mas excepcionalmente dessa vez será feito na primeira quarta-feira do mês.

O evento é um evento da comunidade WebCapixaba, organizado pelo André Fiorini @castiglioni, Celso Hora @cchcreative, Filipe Giacomin @filipegb e Paulo Henrique “PH” @ph_etc_br. O WebCapixaba é uma comunidade online de profissionais da internet capixaba bem bacana: se não conhece acessa agora rapá!

O assunto dessa vez será “O que esperar do mercado web em 2010″ e terá um formato de mesa redonda, onde irão participar pessoas de grandes agências envolvidas diretamente com web, como o Gilber Machado (E-brand) e o Rodrigo Quintão (4Ps), respectivamente sócios-diretores das empresas em questão.

Tive a honra de ser convidado para participar da mesa redonda também, afim de representar a Giran e também tentar contribuir um pouco com a vivência de internet que tenho. Acredito que vá ser uma oportunidade legal das pessoas verem diretamente o que grandes agências e empresas novas como a nossa pensam à respeito de carreira, tecnologia, tendências e tudo mais.

O mediador da mesa será o Rafael Silveira, do Gazeta Online, e o papo está previsto para iniciar-se às 19:00.

O evento é freeware: basta inscrever-se no do evento e aparecer lá com idéias, perguntas e tudo o que você achar interessante ser discutido. =) Para mais informações sobre o evento, clique aqui para acessar o tópico sobre o evento.

Nos vemos por lá.

Me fiz essas reflexões à alguns dias e me considerei uma pessoa moderadamente organizada na vida profissional, mas ainda num caos quando se fala de contas pra pagar e tarefas pessoais. Isso era um tanto diferente, mas com sorte hoje estou bem melhor. Ajuda de alguns tarados por organização, como meu sócio Paulo Jeveaux, e algumas ferramentas que hoje me fazem trabalhar menos mas com mais efetividade.

Então, afim de compartilhar experiências e inspirado pelo post de Procrastinação do Jeve, acho que vale relatar o que estou usando hoje para organizar melhor o meu dia de trabalho.

Organizando as pendências, idéias e tudo mais

Antes eu ficava pensando e resolvendo os problemas sob demanda: os problemas iam se acumulando e anotava em papéis ou na minha finada agenda. O problema disso era que papéis e agenda me induziam à utilização de listas, o que nunca me deixava ter uma visão macro dos problemas que eu tinha.

Se eu começava com minhas pendências pessoais, deixava minhas pendências profissionais lá no final da folha ou numa folha avulsa: isso me levava inconscientemente à ficar rodando feito barata tonta lendo e vendo o que eu poderia resolver naquele momento.

Outro ponto negativo era “quando” eu iria resolver: as idéias acabavam se misturando as coisas que concretamente deveriam ser resolvidas, com datas de vencimento e tudo mais.

A solução foi repartir o processo em três fases:

1) Organizar as idéias num mapa mental, de modo que eu tivesse uma visão macro e organizada de todas as pendências, idéias e tudo mais. A forma de organização agrupada e ramificada do mapa mental ajudou e muito a fugir das listas e assim conseguir enxergar “de uma vez” tudo o que eu tinha pra fazer. Rapaz, tinha coisa pra caramba.

Estou usando ultimamente o MindMeister (http://www.mindmeister.com/), que é online, gratuito e o mais irado: você pode fazer brainstorms com outras pessoas em tempo real. Existem outras opções open source (como o FreeMind) e outras mais robustas e pagas como o MindManager.

2) Decompor as pendências e idéias em partes menores e tarefas mais simples. Imagine que você tem uma tarefa “Fazer cartões de visita”. Vamos pensar direito: será que a tarefa é mesmo apenas fazer o cartão ??? Eu fiz a decomposição assim:

- fazer a arte do cartão
- fazer orçamentos de impressão do cartão
- escolher o melhor orçamento e enviar a arte do cartão
- fazer o pagamento do cartão
- buscar o cartão

 Pronto! Agora tenho tarefas pequenas que eu posso resolver durante dois ou três dias em pequenos intervalos de tempo.

A decomposição das tarefas foi quase um exercício de refatoração de software: olhar, repensar, re-escrever. Esse exercício contínuo vai fazendo nosso “bom senso” crítico melhorar e assumir que somos atarefados e que  o achismo não adianta muito. Então, porque não conseguir fazer algo com aqueles 15 min de ociosidade que você fica olhando pra tela sem saber o que vai fazer. Aposto que muitos tem esses momentos “E agora, o que eu vou fazer?“.

Outro ponto que ajudou muito foi meu contato diário com Scrum/XP na Giran: ora bolas, será que se eu transformar minha pendência numa user storie e o que preciso fazer para resolver isso em tarefas não daria certo ? Pior que deu.

Ai entra em cena as ferramentas de gerenciamento e organização de tarefas: existem várias por aí mas a que estou usando e tem me dado um resultado surpreendente é a Things, da Cultured Code. A ferramenta permite você organizar tarefas com datas de expiração, sem data mas que precisam ser feitas e outras que você pode fazer “qualquer dia desses”. Além disso, o programa aceita tagear cada tarefa.

O pulo do gato com ela foi a versão para iPhone: com isso eu tenho sempre as tarefas sincronizadas e alarmes tanto no meu Macbook quando no iPhone quando estou na rua. Perfeito.

3) Definir as prioridades para serem feitas na próxima semana. Isso é feito continuamente e tem que ser feito num momento de tranquilidade e de preferência num ambiente relaxante de sua casa ou seu dia. Define-se para a próxima semana o que tem que ser feito, organizando isso por prioridade e importância.

Contas a serem pagas, ligações para clientes, processos com vencimento próximo ou definido, feedback de propostas e afins são geralmente os que entram nessa lista. No caso das contas, é legal botar sempre elas com um dia da antecedência, para evitar problemas aos 45 do segundo tempo (uma vez tinha uma conta pra pagar que minha transferência online não permitia pagar – paguei juros à toa).

Em seguida, vem as tarefas de trabalho dos projetos correntes, ligações para resolução de pendências futuras e tarefas corriqueiras do cotidiano, leitura técnica (na Giran a gente tem uma hora diária de leitura) e coisas que não precisam de algo muito pontual mas precisam ser resolvidas logo.

Em terceiro lugar, eu penso: “Agora que ja resolvi o que é prioridade e o que precisa ser feito em algum momento, o que eu vou priorizar dos meus outros projetos“. Aí entram meus projetos pessoais, leituras avulsas, pesquisa de alguma coisa nova fora do escopo e tudo mais.

Hora de trabalhar!!!

No Things, as tarefas ficam organizadas em projetos. Por exemplo, a Giran tem um projeto com várias tarefas, com tags comuns como por exemplo “novosite”, “cursosdeverao” e por ai vai. Com elas distribuidas no meu Things, é hora de arregaçar as mangas.

O fluxo de trabalho então segue diário. Não que se precise ser feito algo cíclico e repetitivo do tipo “cara-cracha-cara-cracha”: isso é o que me induzia a tornar o cotidiano uma coisa f*da de aguentar. A idéia foi transformar o cotidiano em pontos que devem ser satisfeitos e não numa check list de conferência.

Então, organizo as tarefas que vou fazer pela manhã e à tarde, sem definir exatamente a ordem delas. Por exemplo: eu sei que devo ligar para o Paulo para resolver um problema, mas vai ser algo que pode atrapalhar um pouco meu “astral”. Então, de manhã eu deixo pra fazer as coisas mais tranquilas, priorizando aquelas que eu TENHO que concluir no dia, e deixo pra resolver problema a tarde.

Muita gente acha que o trabalho de um desenvolvedor é apenas “lógico”, mas existe muito do “criativo” na resolução de problemas e estratégias, não no sentido de re-inventar a roda ou gambiarrar a coisas, mas na definição da melhor solução. E como criativos, sabemos que interferências, problemas e tudo mais complica mesmo o aproveitamento 100%. Por isso a regra é: faça as coisas de cabeça fresca e deixe para resolver, se possível, os verdadeiros “problemas” após fazer o que deve ser feito.

Na Hora de fazer a coisa em si, entra a necessidade de foco: mas como manter o foco com Twitter, MSN, telefone e piadistas natos ao meu lado? A algum tempo pensei até que eu tinha DDA (Disturbio de Déficit  de Atenção), tamanho eram os gaps e lags entre uma coisa e outra pra fazer e mesmo durante.

Entrou em cena algumas formas de manter o foco, como fechar tudo, trabalhar com fones de ouvido. Mas a coisa melhorou bastante depois do Pomodoro. A Pomodoro Technique é uma forma de você trabalhar com auto-recompensa: você trabalha num box de tempo de 25 minutos focado numa tarefa apenas. Por exemplo, “Ligar para agência para ver como andam os cartões de visita”. O Paulo Jeveaux tem um ótimo post sobre isso, como tinha dito.

Durante 25 minutos você se mantem COMPLETAMENTE focado nisso. Após os 25 minutos, você ganha um intervalo de 5 minutos para fazer QUALQUER COISA. Isso mesmo: qualquer coisa. Tomar um café, responder seu amigo no MSN, tuitar. Acabado os 5 minutos, é hora de fazer mais pomodoros.

Depois de 4 pomodoros, você tem 15 minutos de intervalo: tempo o bastante até pra jogar uma partida de video game.

Pensei no início que isso quebraria meu raciocínio para tarefas mais longas: mas o que aconteceu foi que as tarefas se tornaram peças bem definidas dentro do meu turno matutino e vespertino de trabalho, já que entre o trabalho codando, existe todo o trabalho de gerência e resolução de problemas do dia-a-dia da Giran.

Resumindo a epopéia

Acredito que cada um tenha uma forma bacana de organização, mas quando realmente tive que começar a separar os problemas pessoais, de projeto e cotidianos profissionais, precisei de um foco de Jedi para manter-se na linha e tentar produzir a contento.

Existem N técnicas e formas de organização, mas até para mim que assumidamente é uma pessoa desorganizada, essa forma deu certo e acredito que possa ao menos ajudar na vida de pessoas que vivem a 300 km/h no dia-a-dia.

Em poucas palavras:

1. Organizar TODAS as pendências num mapa mental para você ter uma visão macro de tudo o que você tem de pendente, de preferência organizando em grupos e subgrupos as pendências co-relacionadas;
2. Pegar cada pendência e tentar decompor em várias pequenas tarefas que possam ser concluídas em momentos separados, tornando assim a possibilidade de conclusão da tarefa menos penosa quando você tem um zilhão de coisas pra fazer ao mesmo tempo;
3. Com as tarefas separadas, cataloga-las num gerenciador de tarefas de forma que você possa agrupar essas tarefas por dia, prioridade e tags.
4. Escolher quais as tarefas serão feitas na próxima semana, priorizando contas, ligações e problemas que tem datas de “vencimento”, em segundo lugar o que se tem de trabalho normal e em último lugar os extras como leituras avulsas, visitas à sites esquisitos, pesquisa de coisas novas e tudo relacionado ao seu ócio criativo.
5. Manter o foco nas tarefas de forma individual e concentrada. Para quem tem problemas com isso, usar a Pomodoro Technique pode ajudar pra caramba.

Ufa! O post ficou meio longo mas espero que para quem chegou até essa linha curta um pouco.

Simbora!

Verão é praia, cerveja, sombra, água fresca e … JAVA!

A partir do dia 07/12 vamos iniciar as turmas de verão da Formação Java Profissional, curso da Caelum já famoso no Brasil e agora oferecido no estado pela Giran. Durante esse período ofereceremos a formação mais básica da plataforma, bastante requisitada pelo público local.

Os cursos oferecidos serão:

FJ-11 | Java e Orientação à Objetos
O intuito do curso é quebrar o paradigma procedural, apresentando aos poucos seus problemas e encontrar suas soluções mediante a orientação a objetos com a linguagem Java e suas principais bibliotecas. Da leitura de arquivos a conexões TCP.
Clique aqui para mais detalhes sobre o curso

FJ-21 | Java para desenvolvimento Web
Diante do tamanho do mercado de desenvolvimento web em Java, este curso não visa apenas mostrar os conceitos básicos de uma web application, mas também apresentar frameworks conhecidos para aplicar o padrão arquitetural Model View Controller, de hibernate e struts a JSP com JSTL e EL.
Clique aqui para mais detalhes sobre o curso

FJ-16 | Laboratório Java com Testes, XML e Design Patterns
Um laboratório para aplicar as boas práticas da Orientação a Objetos em um projeto Desktop com Swing, XML, JFreeChart, Testes Unitários com JUnit, Ant, Maven, Refactoring e mais.
Clique aqui para mais detalhes sobre o curso

Teremos turmas pela manhã, a tarde e à noite para atender tanto estudantes como profissionais que trabalham durante o dia inteiro. Por se tratar da inauguração oficial de nossa nova sala de treinamento, teremos descontos especiais para as turmas do dia para compensar a praia, as cervejas e gratificar pela vontade de aprender mais.

Sobre o treinamento em si, o material será composto por apostila, pasta, caneta e bloco de anotações. O inscrito, ao final do curso, ganha umcertificado Giran/Caelum reconhecido nacionalmente.

Para quem não nos conhece ainda, a Giran é uma empresa especializada em consultoria e treinamentos localizada em Jardim da Penha e conta com uma sala de treinamento nova em folha, com laptops Dell de ponta, ar condicionado e sala de descanso com TV, video-game, balas, água e café. Nos intervalos do curso, é oferecido um coffee break bem bacana para acompanhar o bate-papo.

O treinamento será ministrado por profissionais com bastante experiência não apenas em Java, mas também no mercado de software capixaba e brasileiro. Isso significa que além do que há na apostila, um monte de informação sobre o dia-a-dia e cotidiano de um desenvolvedor/analista/arquiteto de soluções é passado, discutido e ensinado em nossas aulas.

Então, deixe seu guarda-sol e protetor solar na gaveta e venha para a Giran passar algumas horas descontraídas de muito Java, programação e conhecimento. Ligue para 3026-0264 e informe-se sobre datas, valores e formas de pagamento.

Atenção estudantes: não faremos “meia” mas daremos um desconto no preço final do curso para alunos de algumas faculdades parceiras. Consulte-nos! 

E para quem quiser ajudar na divulgação, segue o flyer virtual abaixo:

A algum tempo, tive um problema curioso: a chave primária de uma tabela teria valores alfanuméricos. Ou seja: valores como “205-A”, “JB02″ e outros bizarros seriam possíveis. Regra de negócio definida, modificação do modelo para o nome de chave fora da convenção e tudo corria bem até que populei um select.
Qual não foi minha surpresa em ver que o CakePHP, além de não marcar o valor correto, em certos casos ainda selecionava mais de um valor no select. #fail total.

Pesquisa na internet, perguntas na lista de discussão oficial do CakePHP e as respostas eram:

• Coisas que não tinha nada haver com o problema
• Sugestões pra mudar a estratégia para resolver o problema
• Gente falando que o CakePHP só trampa com valores numérico (o que de fato acontece )

O problema

Então, mexendo no código pra cima e pra baixo (sem conotações sexuais por favor) consegui achar o problema.

No arquivo  cake/libs/views/helpers/form.php (cakephp 1.2.5), na linha 1710:

if ((!$selectedIsEmpty && $selected == $name) || ($selectedIsArray && in_array($name, $selected))) {

Depois de fuçar e testar um pouco, vi que o problema principal na verdade é um problema com o próprio operador == do PHP: ele trata as operações entre strings e numéricos (http://php.net/manual/en/language.operators.comparison.php) de uma forma que gera os seguintes resultados:

• um valor como 206-1 por exemplo, o helper casava tanto o valor 206-1 (o correto) quanto 206 (string == integer).
• um valor como JB01 por exemplo, o helper casava tanto o valor JB01 (o correto) quanto 0 (string == integer).

Devido à característica do PHP de resolver qual o tipo da variável em tempo real, ele tenta fazer o casting da variável sempre e acaba gerando resultados não esperados pra gente.

Solução

A solução então foi forçar (type casting) as variáveis para serem tratadas como strings. Assim, evitamos que o PHP transforme nossas variáveis em tipos distintos (no nosso caso string e integer) e consequentemente faça a comparação de valores do jeito que precisamos.

A linha 1710 (no cakephp 1.2.5 ou 1748 no cakephp 1.3-dev) ficou assim:

if ((!$selectedIsEmpty && (string)$selected == (string)$name) || ($selectedIsArray && in_array($name, $selected))) {

Note o type casting sendo feito nas variáveis $selected e $name.

Se alguem conseguir uma solução mais bacana ou encontrou outro bug bizarro do CakePHP, compartilhe!

Simbora!

Update: Eu tinha reportado esse erro a algum tempo no track de bugs do CakePHP  e hoje vi que já corrigiram isso. Então, quando sair a versão stable do cake 1.3, não precisa mais se preocupar com isso.

Estou devendo vários posts sobre o SimpletTest, CakePHP, PHP e blablablabla. Esse lance de twitter realmente me afastou no blogging mas o mundo não para e nem a gente!

Amanhã é nóis! Keep blogging! \\//

No próximo sábado (17/10) será realizado em Vila Velha o IV Encontro de Java do Espírito Santo – IV EJES.

O EJES é um evento anual realizado pelo ESJUG (Grupo de Usuários Java do Espírito Santo – esjug.org) e já está em sua quarta edição. Este ano o evento será realizado no Cineteatro da UVV das 08:00h às 18:00h.

Este ano, assim como nas outras edições, o evento foi pensado e organizado de modo a trazer assuntos quentes e atuais, colocados em pauta por palestrantes capixabas e de fora do estado, que são referências na comunidade Java. Esta é, com certeza, uma oportunidade rara para conhecer as novidades do mundo Java e se aprofundar em conceitos e ferramentas já consagradas. E por último mas não menos importante: O Networking! Encontrar pessoas da sua área, rever antigos amigos de trabalho e fazer muitos novos contatos são coisas que só um evento como este podem te proporcionar.

Participe, não fique de fora. A próxima edição agora só em 2010 =)

Mais informações e inscrições: http://ejes.esjug.org

Sumida boa a que rolou, mas foi por bons motivos.

A Giran, empresa minha com meu sócio-irmão Paulo Jeveaux, está em franco crescimento e o último mês foi “frenético”: muitos projetos, pessoas e oportunidades novas e bacanas. Então, tive que pisar no freio com o blog. Agora vamos voltar com os posts semanais.

A novidade agora é que adquiri um Macbook Pro 13″ e um iPhone 3GS: sim, sou tarado na maçã.

Voltando aos artigos técnicos, vamos ter Mock Objects no Simple Test essa semana e provavelmente mais dois que estou rascunhando. =)

Simbora!