PHP on Rails

Mas esse pessoal não perde a oportunidade para tirar um sarro. Foto tirada daqui.

25 anos de GNU

Pois é, faz 25 anos que a maior frente no mundo open source iniciou seu trabalho. O dia da festa foi 27 de Setembro (sab) e mesmo que atrasado sou mais um a manifestar meus parabéns a todos aqueles que contribuem de alguma forma ( desenvolvendo, testando, usando ou evangelizando). É isso ae moçada!

Abaixo coloco um vídeo feito pela Globo News com o polémico Richard Stallman. Apesar do cara ser meio doido, ele é o cara que faz a balança funcionar. De um lado, extremistas que querem capitalizar tudo, por outro extremistas like Richard Stallman que quer liberar tudo.



O vídeo acima esta hospedado no site do Augusto Campos, um ativista brazuca do opensource.

Ubuntu Kung Fu

Boa notícias para os fãs do Ubuntu: o grupo The Pragmatic Programmers acaba de lançar o livro Ubuntu Kung Fu, ressaltando os poderes da distro ( e como as pessoas os desconhecem). Embora não concorde com a frase It’s the best Linux distribution ever, o livro promete trazer mais de 300 dicas sobre o famoso filho do Debian, com foco em usuários que vieram do Windows e do MacOS (sério? E como ficam os milhares de usuários do FreeBSD e do BeOS ?).

Quem quiser um trecho do livro, eles disponibilizaram um PDF aqui.

Materiais online de Stanford e MIT

A universidade de Stanford disponibiliza alguns materiais de suas aulas do curso de Ciências da Computação online, através do programa Stanford Engineering Everywhere. Confesso que peguei o video de introdução ao curso de CC e o carinha fala rápido hein... Mas nada impossível de pegar, principalmente com o tempo.

Abaixo a aula de introdução ao curso de CC:



Procurando por algum similar do MIT achei um tal de MIT Open Courseware, que tem uma sessão de "Ciência, Tecnologia e Sociedade". Não é tão bom quanto o curso online de Stanford, mas já é alguma coisa também.

Vale lembrar que as duas universidades tem canais no Youtube: Stanford e MIT.

Test Driven Development

Estamos aqui na 3Jane nos policiando para seguirmos as regras pregadas pelos processos ágeis. Uma delas é o desenvolvimento orientado a testes. Na verdade todos nós aqui já tinhamos lido sobre o assunto, mas agora vai ser lei.

Falando de mundo PHP, temos basicamente dois frameworks para testes : o PHPUnit e o SimpleTest. Até onde tenho lido, ambos fornecem diversos recursos para escrita de testes, entretando como o CakePHP já possui um caso de amor com o SimpleTest, estou lendo mais sobre ele.

Deixo abaixo um slide que encontrei no slideshare falando sobre TDD:

Software Testing Basics

View SlideShare presentation or Upload your own.

Poster sobre desenvolvimento ágil

A VersionOne possui um poster bastante claro sobre os subprocessos dentro do processo ágil. Para fazer o download, você tem que preencher um pequeno cadastro (nome e email). A página é essa.

História de falha de um projeto

Recebi por email a newsletter do InfoQ e tinha o anuncio de um vídeo interessante de um projeto que parecia ser bem-sucedido mas foi considerado um fracasso pelo cliente.
Palestra foi gravada na Agile 2008 Conference, pelo Mitch Lacey um CST e PMP.

Para ver o vídeo, clique aqui.

PHP + YAML via SPYC

O Rails usa um formato muito simples de documentos para a substituição do XML, o YAML. Esse formato além de extremamente ágil é mais "human friendly" que o XML.

Procurando algum loader em PHP para esse formato, achei o SPYC. A implementação é simples, basta dar um Spyc::YAMLLoad('arquivo.yml') que ele carrega e gera um array - e você também pode fazer dump com ele.

Enquanto isso na Zend Conference 08

Pois é, esta rolando na Califórnia a conferência mais importante de PHP, a Zend Conference. E esta começando a pipocar vários vídeos e materiais decorrentes das palestras. Listo abaixo alguns materiais que já encontrei por ai:

Rickroll to go with PHP, WURFL e other Open Source tools

Brian Deshong fala sobre conteúdo móvel e as tecnologias que circulam ao redor do tema.

Material :
PDF (sem transições)
Vídeo (quicktime)

PHP Developer Best Practices

Matthew Weier O’Phinney fala sobre melhores práticas no desenvolvimento com PHP.

Material:
PDF

Static and Dynamic Analysis at Ning

David Sklar fala sobre o Ning, uma ferramenta que permite a criação de redes sociais. Muito bacana.

Material:
PDF

Distribution and Publication With Atom Web Services

Ben Ramsey da uma passada rápida sobre Atom, um "novo" formato de comunicação.

Slide:

Distribution and Publication With Atom Web Services

View SlideShare presentation or Upload your own. (tags: http rest)

Por enquanto só achei esses materiais, mas vale lembrar que a conferência vai até amanhã. Pra quem não pode ir (como eu), pelo menos dá uma olhada no material para saber o que esta acontecendo no mundo PHP.

Dinheiro não é tudo

Em pleno século XXI, eu, cidadão das Américas (ainda que do Sul), venho com esse papo mole de que dinheiro não é tudo. Sei que a proposta do post não é nova, mas sei também que tem muita gente que vai concordar comigo que dinheiro não é tudo.

Nós como meros desenvolvedores que somos por vezes somos a menor parte do processo de desenvolvimento de um software ( que paradoxo não ?). Constantemente trabalhamos sobre pressão, com prazos apertados, especificações falhas e com legados de softwares que sofremos pra manter. Mas se é tão ruim assim, por que continuamos ? Simples: porque amamos desenvolver software. Achamos mágico construir soluções que acelerem o processo de comunicação entre os seres humanos, sejam eles quem forem. Gostamos de bits, patterns, miracle driven developments, aprender coisas novas pra agilizar os processos e por ai vai.

Por isso nos envolvemos muito com o nosso trabalho. Saimos da empresa onde trabalhamos e vamos pra casa fazer o que ? Programar ou estudar programação ainda mais - e isso normalmente invade nossos finais de semana. Por essa razão não é difícil imaginar que nos envolvemos e muito com o que fazemos, já que fazemos por que somos apaixonados por isso.

E o que acontece quando percebemos que no ambiente onde trabalhamos existem processos ruins, que podiam ser otimizados mas que por "força maior" não os são ? Perdemos nosso humor. Parece que a "inspiração" para programar acabou, perdemos o ânimo para digitar um ponto-e-vígula sequer. Programador que ama o que faz não consegue digerir muito bem essa coisa de "isso é problema da empresa, as 18h vou pra casa tranquilo".

E é ai que entra o titulo do post "Dinheiro não é tudo". Ok, gostamos de dinheiro por que precisamos e por que nos trás conforto, mas dinheiro não compra entusiasmo - muito menos patrimônio intelectual.

Por exemplo, sempre tem aquele papo de que todo programador deve virar gerente de projetos. Por quê ? Simples, porque gerente ganha mais. Mas, e se eu não gostar de ficar "o dia todo de frente pro Project?" (hei isso foi uma piada, por favor ria) E se eu achar graça em outra coisa? E se o que me deixa feliz é digitar um bando de palavras em inglês e apertar o F5 ? (preciso dizer que foi outra piada?). Quem disse que eu estou programando só por dinheiro?

Por isso saiba discernir se você esta construindo o seu futuro simplesmente pelo que vai ganhar ou pelo que vai viver. Não deixe seu prazer em desenvolver softwares da maneira correta enferrujar junto com os processos administrativos da sua empresa. Dinheiro é bom, mas quando a gente morre fica tudo pra um bando de filhos ingratos que não vão saber quantas linhas de código você teve que escrever para consegui-lo. E se você morrer sem filhos, alguma mulher vai acabar gastando sua grana mesmo. (Suellen isso foi só força de expressão tah amor...) Não substitua talento por desculpas. Se quando você esta no trabalho, só fica pensando em ir embora e quando esta em casa fica com aquela sensação de frustação de voltar pra empresa, é melhor você dar uma olhada nesse vídeo aqui.

Ps.: A propósito, a foto do post é do filme A procura da felicidade. Acho que fui o único que achou o filme sensacional do inicio ao fim, mas mesmo assim se você não viu aconselho a fazê-lo.

Dica : Desenvolvimento Web Ágil com Rails

Pois é, o ultimo livro que comprei acabou rápido ( terminei de ler até mesmo antes da fatura do cartão de crédito ser emitida. Será que posso devolver o livro ? ). Logo no inicio do The Pragmatic Programmers os autores falam sobre expandir continuamente seu conhecimento, lendo bons livros a todo momento e aprendendo pelo menos uma linguagem de programação nova por ano. Tentando cumprir isso, tomei vergonha pra começar a estudar Ruby on Rails de verdade.

Como gostei muito do estilo usado pelo grupo The Pragmatic Programmers, comprei o livro deles sobre Rails. Já li umas 60 páginas e estou sentindo que vai dar namoro. Provavelmente os posts sobre Rails no blog vão começar aparecer ;-)

LHC usa Linux

Legal não ? Pelo menos agora eu já sei que o mundo não vai acabar com uma tela azul. O texto a seguir foi tirado da Internet News :

"The most powerful physics project in the history of the known universe - The $10 Billion Large Hadron Collider (LHC)- shot its first light speed beam this morning around its 27 km circuit. Beyond the 20 years it took to build and half of all the world's astrophysicists, it also takes another key ingredient to make LHC work -- Linux.

CERN which is the organization that runs the LHC project is using something called CernVM which is is custom Linux distribution. According to VMware, CernVM runs inside of VMware virtual machines that include PC and Macs across a grid that encompases the power of approximately 40,000 CPUs and some 15 petabytes of data a year.

CERN itself is no stranger to Linux and is one of the lead backers of the Scientific Linux distribution, which is a recompiled version of Red Hat Enterprise Linux.

**UPDATED** Got a comment (listed below) from a commenter with an IP within CERN that writes,".. the primary configuration for machines in the LHC computing grid (http://lcg.web.cern.ch/LCG/) is based on Scientific Linux distribution running directly on the hardware. This grid is used to receive and distribute the 15PB of data across the 100,000s of CPUs across the world" **

Considering that the LHC, according to some, could be powerful enough to destroy the Earth, create a blackhole or rip a hole in the fabric of space itself, it is somewhat re-assuring that at least some of the key software behind it is not at risk from the blue screen of death."

Usando o Authenticate do CakePHP

Estou trabalhando ultimamente com o CakePHP (1.2) e achei um componente muito útil: o AuthComponent. Ele centraliza todo o fluxo de autenticação no sistema e se você seguir algumas regras básicas dele, poderá fazer toda parte de login do seu site com praticamente esforço zero.

Primeiro passo é definir se a maior parte do seu site será publica ou privada por que isso dirá onde você deve acionar o Auth. Se você notar que quase todas as áreas do seu site será de acesso publico, é melhor chamar o Auth direto nos controllers que terá actions privadas. Caso não, você pode colocar direto no app_controller da sua aplicação.

Não que você não possa colocar direto na configuração de chamada do auth a lista de controllers e/ou actions e suas respectivas visibilidades, mas é só por uma questão de economia de esforço

A idéia é simples, e vou assumir que o controller com o auth será o app_controller

class AppController extends Controller {

 var $components = array('Auth');

 function beforeFilter() {

  // Auth config
  $this->Auth->allow(array('action_publica'));
  $this->Auth->loginError = __("Usuario nao encontrado", true);
         $this->Auth->loginAction = array('controller' => 'users', 'action' => 'login');
    $this->Auth->loginRedirect = array('controller' => 'users', 'action' => 'profile');
 }

}

No exemplo acima, coloquei a chamada do componente no var $components = array('Auth');, logo depois no beforeFilter ( que sempre é executado antes do controller) configurei o Auth da seguinte forma: o allow() serve para você dizer quais actions são de acesso publico, o loginError() é a mensagem de erro, o loginAction() define onde esta o action de login e o loginRedirect() serve pra apontar pra onde o usuário será redirecionado após o login. Agora basta no meu controller login colocar as actions login() e logout() que ficaria parecido com o seguinte:

class UsersController extends AppController {

   function login() { }

  function logout() {
     $this->redirect($this->Auth->logout());
   } 

}

Assim ficar o login e o logout. Simples não ? O action login() pode ficar completamente em branco e o logout() faz um redirect pro logout do Auth. E a view do login também é bem simples:

<div class="users">

<?php if ($session->check('Message.auth')):?>
        <?php $session->flash('auth'); ?>
<?php endif;?>

<?php echo $form->create('User', array('action' => 'login'));?>
 <fieldset>
   <legend><? __('Login') ?></legend>
  <?= $form->input('username'); ?>
  <?= $form->input('password'); ?>
 </fieldset> 
<?php echo $form->end('Logar');?>
</div>

Na view eu coloquei o $session->flash('auth'); principalmente para mostrar a mensagens do tipo "usuário não encontrado", que você configura previamente no Auth.

Algumas considerações finais

O Auth tem várias configurações que podem ser alteradas, mas por default ele assume que você tem um modelo chamado User, que tem dois campos: username e password. Ele também assume que o campo password foi criptografado com um hash dele. A questão da criptografia do password é a única coisa que não pode ser alterada - ele sempre assume que o password esta criptografado.

Para saber mais sobre o Auth, vá na página da API dele e da documentação no CookBook. Agora vou continuar estudando sobre o ACL para definir as permissões de usuário automaticamente pelo grupo que ele pertence. Quando estiver com melhores conhecimentos tento escrever algo sobre isso.

Alterando configurações do php.ini via apache

Pra quem trabalha com vários projetos PHP em um mesmo servidor, sabe que ficar alterando o PHP.INI para cada besteira que algum projeto queria fazer não é uma coisa muito legal. Para falar a verdade não é nada legal... Por exemplo, não é legal trocar a pasta temporária de upload para um diretório que não possui permissão de escrita ou que esta em uma partição com pouco espaço disponível.

Entretanto ficar confiando no ini_set() do PHP realmente não é legal, pois ao meu ver caímos em dois problemas: as configurações do php.ini ficam extremamente espalhadas ( não queremos violar o DRY correto ?), e segundo é que não podemos fazer tudo com as funções ini_set() like.

Para quem não sabe, algumas configurações do php.ini não pode ser alteradas "on the fly". A Zend criou um nível de segurança chamado PHP_INI_SYSTEM, que não podem ser alteradas em runtime ( clique aqui para ver a lista de funções e privilégios necessários).

A solução que encontrei foi simples mas eficaz ( além de seguir as orientações da própria Zend) : usar uma diretiva de diretório do Apache, lançando um PHP Admin Value. Fazendo isso você pode redefinir algum parâmetro do php.ini para um diretório específico no servidor. A idéia é mais ou menos a seguinte: No httpd.conf do apache, dentro da sessão Ifmodule , crie um diretório para sua aplicação e coloque o seguinte parâmetro:

<Directory "/caminho/para/o/projeto/">
php_admin_value parametro_do_php_ini "novo_valor"
</Directory>

Com isso você pode sobrescrever o comportamento do php.ini inclusive em configurações mais avançadas. Sei que é redundante, mas como se pode perceber tive que usar o php como módulo para poder proveitar essa diretiva.

Gerenciamento de campanhas via OpenX

Vejo pouca gente comentando sobre uma ferramenta de gerenciamento de publicidade online muito interessante feita na dupla PHP & MySQL: OpenX.

O OpenX é uma ferramenta já estável usada para o gerenciamento de banners e texto publicitários de N anunciantes (advertisers) para N publicadores (publishers) no esquema de campaigns. No início é meio complexo entender como funciona as campaigns, zones, filters e os esquemas de clicks, mas não é nenhum ciplope. Eu estive futucando o design do software e os caras que desenvolveram focaram muito (muito mesmo) em desempenho - o que às vezes não os deixam seguir algumas regras da cartilha do "bom desenvolvedor", mas nada alarmante.

Outra coisa muito legal é os diversos relatórios que ele gera, além de um instalador que torna a vida mais fácil para o primeiro deployment.

Para saber mais sobre a ferramenta, clique aqui.

Cheat Sheets

Precisa de uma lista rápida das funções do programa ou da linguagem que esta trabalhando? Pois é, o cheat-sheets.org possui diversos cheat sheets de inúmeros sistemas.

Joomla Security Strike Team

Usei por algum tempo o Joomla e achei esse CMS bem feito, principalmente pelo esquema das suas extensões. Eu comecei a usar na versão 1.0.12 - que ainda tinha umas coisas a resolver quanto ao design da framework, mas com a versão 1.5 ele ficou bem redondo.

Acontece que esse CMS sempre teve seu "tendão de Aquiles" no quesito segurança, e não são poucas pessoas que tem medo de usá-lo por causa das más notícias que o rapazinho tem. Parece que os desenvolvedores do projeto decidiram criar uma divisão só para cuidar da questão segurança do CMS - a Joomla Security Strike Team. O nome até é bonitinho e parece até a nova versão dos Power Rangers, agora só nos resta saber se as falhas de segurança vão continuar acontecendo.

O que é Scrum, segundo Danilo Bardusco.

Ocorreu aqui no Rio da XII Amostra PUC (que não pude ir...). Uma das palestras foi ministrada pelo Danilo Bardusco, onde ele conta como foi a adoção de Scrum na Globo.com.

| View | Upload your own

Outro slide do Danilo, quebrando alguns mitos sobre o Scrum:

| View | Upload your own

Estimando com bola de cristal

Chegou a hora de começar o projeto e o gerente pede uma estimativa em horas. E como bons funcionários que somos, analisamos os requisitos, geramos as especificações, quebramos em partes tangíveis e calculamos cientificamente o prazo de cada item do nosso WBS (ou qualquer outro nome que você dê a isso) para então conseguir o tempo ideal.

Óbvio que depois disso você acorda, toma um banho frio e vai pro trabalho, aonde você provavelmente vai iniciar um projeto ainda participando do deployment ou manutenção de outros sistemas paralelos, o gerente (que provavelmente esta sendo pressionado por alguma força superior mediúnica detentora de conhecimentos profundos sobre o trabalho alheio, como por exemplo clientes ou executivos) solicita um "cornograma" pra ontem, não temos todos os requisitos e geramos especificações que sabemos que não são reais, para então gerar um WBS com estimativas de horas completamente furadas.

Mas o projeto tem que andar, alguém tem que dar o primeiro chute na bola correto? Errado. O problema é que na maioria das vezes esse chute é contra o seu time. Gerar estimativas em horas é sempre uma tarefa sacal, que na verdade funciona muitos mais como aquela brincadeira da "batata-quente" do que com uma métrica técnica. Todos que participam da brincadeira sabem que é tudo um jogo de faz de contas, mas temos que arranjar alguém pra passar a bomba adiante. Principalmente em modelos waterfall, onde já vi casos do time ter até mesmo dois cronogramas: um para os clientes/supervisores (que provavelmente viaja na maionese) e outro para o time de desenvolvimento (com os diagnósticos menos utópicos) e os dois cronogramas acabam batendo no prazo final.

Eu entendo o desespero dos gerentes de projeto, que precisam ter algum recurso tangível para medir o progresso do grupo, mas questiono seriamente a forma maquiavélica como isso é feito. O livro The Pragmatic Programmer traz uma sessão falando sobre esse problema que é tão velho quanto o desenvolvimento de sistemas:

How Accurate is Accurate Enougth ?

To some extent, all answers are estimates. It's just that some are more accurate than others. So the first question you have to ask yourself when someone asks you for an estimate is the context in which your answer will be taken. Do they need high accuracy, or are they looking for a ballpack figure?

- If your grandmother asks when you will arrive, she's probably wondering whether you lunch do dinner. On the other hand, a diver trapper underwater and running out of air probably internested in an answer down to the second.

- What's the value of π ? If you're wondering how much edging to buy to put around a circular flower bed, then "3" is probably good enought. If you're in school, then may be "22/7" is a good approximation. If you're in NASA, then maybe 12 decimal places will do.

One of the interesting things about estimating is that the units you use make a diference in the interpretation of the result. If you say that something will take about 130 working days, then people will be expecting it to come in pretty close. However, if you say "Oh, about six months" then they know to look for it any time between five and seven months from now. Both numbers represent the same duration, but "130 days" probably implies a higher degree of accuracy than you feel.

Trabalhar com estimativas em horas é muito mais empírico do que matemático. Por isso acredito que os processos ágeis trazem soluções mais proveitosas para todas as partes envolvidas no processo de desenvolvimento: do cliente, que recebe prazos mais reais e o ROI mais cedo, ainda que tenhamos que pensar nos moldes de iterações, o desenvolvedores que vão trabalhar mais focadamente (tendo como tarefa principal fazer só o seu trabalho) e o gerente, que vendo ambas as partes felizes, vão poder dormir mais tranqüilos.

Por fim, deixo alguns links interessantes: esse, esse e esse.