Aumentando a produtividade com os snippets

Uma ótima dica para quem usa uma IDE ou editor decente é usar os snippets, blocos de códigos reutilizáveis que “brotam” no seu código após o uso de uma keyword e um tab.

É impressionante como a maioria sabe disso mais deixam essa ferramenta de lado. Utilizando o Gedit hoje resolvi checar como criar novos snippets com coisas mais úteis que for, if e foreach. Como tenho trabalhado em um projeto com CodeIgniter, fiz em poucos minutos snippets completos para criação de controllers, models, helpers, libraries, etc. Além do código em si, embuti os esqueletos dos comentários no formado do phpDocumentator.

Tive uma sensível diferença de produtividade, mesmo tendo parado para criar os snippets. Agora entendo porque o Pragmatic Programmer bate na tecla dos script generators. Realmente ajuda.

Para habilitar os snippets no GEdit, basta ir em Edit -> Preferences -> Plugins e selecionar o plugin snippets.

Clicando no botão Configure Plugin na mesma janela, você pode ver todos os Snippets criados e criar os seus. Para criar um snippet novo não tem mistério algum, basta olhar os outros que você pega o jeito da coisa fácil fácil.

A única coisa que achei estranho no GEdit é que você só pode configurar o plugin do snippet se tiver com um arquivo de extensão reconhecida aberto no Editor. Se estiver só com um Unsaved Document aberto por exemplo, ele não deixa.

Para quem ainda não conseguiu “visualizar” a coisa toda, veja as duas imagens abaixo:

Criei o snippet cicontroller para construir controllers do CodeIgniter. Agora, depois de digitar essa keyword dar um tab, tenho isso:

Usando Google como ferramenta Wiki

Não sei se todos sabem, mas o Google Sites é também um eficiente Wiki empresarial. Basta criar o site, não defini-lo como público, convidar os envolvidos no projeto e pronto. O Google Sites tem todas as ferramentas de um Wiki decente.

Sei que para algumas empresas colocar suas documentações em uma ferramenta externa (e de terceiros) pode ser um pesadelo, mas para outras poder terceirizar a manutenção de um sistema de apoio ao desenvolvimento é um alívio.

Outras ferramentas para Wiki interessantes são: o MediaWiki (gratuito) em php, o TWiki (gratuito) em perl ou o Confluence (comercial) em Java.

Update 1: O Rafael Dx7 achou o projeto Instiki no RubyForge, que também é free. Como o site estava fora e eu não sabia que ele estava hospedado em outro lugar, acabei deixando de fora. Vlw pela dica!

Update 2: Ótima réplica do Rafael, para ler clique aqui.

The Lego Hypothesis

Concorrendo ao prêmio de Palestra que Mais Usou Analogias do ano, o professor James Noble conseguiu criar bons paralelos entre o desenvolvimento de softwares e lego. A máxima da palestra é desenvolvermos software menos acoplados e mais reaproveitáveis – “Programs can be built out of many small independent components”.

Para assistir o vídeo, clique aqui.

Layout e Elements no CodeIgniter

Primeiramente quero pedir desculpas a galera que acessa o blog diariamente, já que notaram que o blog tem uma semana sem atualizações! Mas não fiquem com raiva : como recompensa consegui autorização de um grande autor gringo para publicar seus artigos traduzidos. Em breve falo mais sobre isso.

Estamos na correria aqui na 3Jane passando um projeto do CakePHP para o Code Igniter. Uma das primeiras coisas que precisamos criar no Code Igniter foi o esquema de Layouts e Elements (como no Cake). Não dá pra acreditar que o Code Igniter não venha com algo built-in, mas, felizmente o CI tem algumas formas de você construir adds.

Eu sei que quem trabalha com o Code Igniter mais tempo vai reclamar feito uma velha ranzinza “mas já existem uns 10 sites falando sobre como plugar algum esquema de layout no CI”. Eu realmente achei algumas soluções na web mas nem sempre se propunham a resolver meu problema de uma maneira simples e “desacoplada”. Um simples exemplo é a Layout Library do próprio site do CodeIgniter, que é bem completa mas, para funcionar você tem que substituir a chamada da view das actions dos seus controllers por um método próprio. Além do problema da refatoração do código, isso acaba fugindo do padrão do CodeIgniter ( que é o que eu tenho mais medo). E nem me venha falar daquelas soluções que usam hooks…

Para chegar a algo que me atendesse, eu peguei a Library acima e dei uma adaptada para funcionar sobreescrevendo o Loader padrão para trabalhar com o esquema de Layouts – e acrescentei um método para trabalhar com Elements também. Vamos lah:

Crie uma library parecida com a seguinte:

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');

/**
* Customized Loader Class
*
* Overwrite default Loader which loads views and files
*
*/
class MY_Loader extends CI_Loader {

var $layout = "default";

function MY_Loader() {
parent::CI_Loader();
}

/**
* Load View
*
* This function is used to load a "view" file, including layout. It has three parameters:
*
* 1. The name of the "view" file to be included.
* 2. An associative array of data to be extracted for use in the view.
* 3. TRUE/FALSE - whether to return the data or load it. In
* some cases it's advantageous to be able to return data so that
* a developer can process it in some way.
*
* @access public
* @param string
* @param array
* @param bool
* @return void
*/
function view($view, $data = null, $return = FALSE) {

$loadedData = array();
$loadedData['content_for_layout'] = parent::view($view,$data,true);

if($return) {
$output = parent::view('layouts/' . $this->layout, $loadedData, true);
return $output;
} else {
parent::view('layouts/' . $this->layout, $loadedData, false);
}
}

/**
* Load View Element
*
* This function is used to load a "view" element file, simulating CakePHP's elements.
*
* 1. The name of the "element" file to be included.
* 2. An associative array of data to be extracted for use in the element.
*
* @access public
* @param string
* @param array
* @return string
*/
function element($element, $data = null) {
return parent::view('elements/' . $element, $data, TRUE);
}

/**
* Set Layout
*
* This function is used to set layout name
*
* 1. The name of the "layout" file to be renderized in view function.
*
* @access public
* @param string
* @return void
*/
function set_layout($value) {
$this->layout = $value ;
}

}

Teoricamente é só isso, copiar a library acima para o diretório de bibliotecas, criar os diretórios layouts e elements dentro do diretório views e criar um layout padrão. Com isso seu site já estará funcionando com layouts, sem precisar mudar suas actions ou criar hooks.

Explicando melhor, a library primeiro renderiza a view solicitada e depois coloca o resultado dentro do layout e o renderiza. Como já disse, fixei que todos os layouts estarão dentro da pasta layouts dentro das views, mas você pode mudar isso. Criei também o set_layout, que me recurso a explicar pra que funciona. E por fim os elements são “views” disfarçadas, que sempre retornam a view renderizada como string. Acho que os elements nem são tão necessários pra todos, mas os fiz só pra forçar o pessoal a concentrar o elementos no mesmo lugar.

Um layout (já usando um elemento) poderia ser o seguinte:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title> Titulo </title>

</head>

<body>

<h1> Esta carregando o layout </h1>

<?= $this->load->element('banner.php'); ?>


<!-- Conteudo -->
<?=$content_for_layout?>

</body>

</html>

O elemento banner acima é uma view normal, por isso nem vou postar o exemplo. Quem quiser uma cópia do framework seco só com o esquema de layouts funcionando, eu coloquei no rapidshare. A versão da framework é 1.6.3 então cheque no site do CodeIgniter qual é a versão atual antes de começar a desenvolver em cima da cópia que estou disponibilizando.

Projetos PHP e Integração Contínua

Estamos lutando aqui na 3Jane para alcançarmos um formato indolor de Continuous Integration ( aqui e aqui ) em nossos projetos – que são (até então) em PHP.

Existe um número relevante de ferramentas disponíveis, o problema esta sendo fazer com que elas sigam um fluxo natural no projeto. Ou as ferramentas precisam de uma adaptação para PHP (como o CruiseControl com o PHPUnderControl), ou as ferramentas não se encaixam, ou são muito limitadas.

Embora um pouco complexo, estamos achando algumas coisas boas. Para começar, tinhamos decidido apostar no CakePHP, um framework sólido e com grande similaridade com o Rails. Ficamos realmente satisfeitos com a organização da “criança” e de como ele é bem feito. E também tem o fato de que o CakePHP já vem com uma integração com o SimpleTest, que até onde pude ver, a ponte entre eles é sólida e sem “adaptações” incomodas – até porque o SimpleTest também é em PHP.

Acontece que pelo CakePHP ser bem completo, ele também é mais lento que outros frameworks e por motivos de força maior decidimos trocar para o Code Igniter, que também é um bom framework, mas não possui tantas camadas quanto o CakePHP e teremos que “digitar mais”. Outro ponto fraco do Code Igniter com relação ao CakePHP é o bake, que é um script generator do CakePHP que agiliza muito a vida.

Quanto aos testes no Code Igniter ele já vem com uma library bem simples para teste unitário, mas é tão simples que estou propondo aqui que troquemos para o SimpleTest ou PHPUnit. Como este último parece ter uma integração com o PHPUndercontrol, estou lendo como plugá-lo ao CodeIgniter.

Já construímos o Tracer Bullet para os testes do ambiente e estamos implantando-o. Estou vendo o Phing para automatizar o processo de deploy, mas ainda não parei para estuda-lo de verdade. Essa é uma das minhas metas nos próximos dias.

Para controle de código, migramos do SourceSafe para o SubVersion e apesar de alguns problemas com o Tortoise, valeu a pena. Pra ser bem sincero, o engraçado é como sempre os problemas envolvem o Windows. Para controle de bug/issues estamos usando o Jira e como Wiki o Confluence. Ah, e para a documentação do nosso código estamos usando o phpDocumentator.

Ufa! Acho que é isso… O problema é conseguir tempo pra ver tudo isso e dar continuidade no projeto. Mas posso dizer que demos um “salto quântico” no processo de desenvolvimento aqui na 3Jane. Se você quiser uma lista organizada e decente das ferramentas que podem te ajudar no desenvolvimento em projetos PHP, o Dave Marshall publicou um top 10 no blog dele.

Por fim, deixo com vocês um slide falando sobre PHP + Continuous Integration :

Htacces Generator


Cansado de configurar o htaccess na mão ? O Cooletips disponibiliza um página que após fornecido os parâmetros desejados monta um pra você. Clique aqui para acessar.

Max Gehringer e sua opinão sobre o profissional de TI no futuro


A ComputerWorld publicou uma entrevista com Max Gehringer sobre sua visão do profissional de TI do futuro. Embora meio óbvia, destaca como as empresas devem se posicionar para conseguir manter algum empregado de TI nos próximos anos.

Infelizmente a ComputerWorld não permite o sharing total/parcial de seus textos (no donuts for u), portanto, o máximo que posso fazer é deixar o link.

Gerenciador de pacotes para Slackware

Ótima notícia para os usuários do Slackware: o Slackbuilds.org, site conhecido como uma das principais fontes de pacotes para Slackware, disponibilizou uma ferramenta chamada Sbopkg, que é uma uma ferramenta que cria uma ponte entre o pkgtool e repositório do próprio Slackbuilds, permitindo atualizar ou instalar seus pacotes.

Ainda não tive tempo pra testar mas prometo dar um feedback quando usar a ferramenta. Confesso que de uns tempos pra cá estava usando mais o linuxpackages para baixar os pacotes do Slack, mas se a ferramenta funcionar será o improvement que faltava para a nossa estimada distro linux.

Pra quem esta por fora, existe também o slapt-get que tenta ser uma cópia do apt-get dos Debians da vida para o Slack. Eu não sei se é preconceito meu mas eu não gosto muito. A única coisa que pode vir a me fazer gostar da Sbopkg, além da integração com o pkgtool é o próprio Slackbuilds, que cujos pacotes sempre rodaram redondo na minha máquina… Vamos ver no dá.

Fearless Change Pattern

Mais um vídeo interessante do InfoQ, uma entrevista com Linda Rising ( autora do Livro Patterns Almanac ). Ela fala sobre algo muito importante presente em qualquer mudança de paradigmas: o medo de mudança.

Qualquer padrão novo envolve o medo do erro. Quanto maior o risco de erro, maior o medo. E por isso muitas empresas param no tempo. Com essa introdução ela segue a entrevista identificando fatores para uma mudança sem medo. Para ver a entrevista, clique aqui.