Manipulando o retorno de um include

function get_content($_file, $_vars = array()) {
ob_start();
extract($_vars, EXTR_OVERWRITE);
require $_file;
$_content = ob_get_contents();
ob_end_clean();
return $_content;
}
Essa simples função retorna toda o conteudo de um arquivo incluído para ser armazenado numa string, tratado e manipulado conforme necessário. Essa função é muito útil para criar templates para o conteúdo de emails, partials e components para um template principal.

As variáveis utilizadas pelo template são passadas usando o parâmetro $_vars, bastanto agregar as variaveis numa relação chave => valor. Ex.

$conteudo = get_contents('mail.php', array(
'relatorio' => $relatorio,
'resultados' => get_resultados(),
));

KISS: Keep it Simple Stupid

Se em tudo o mais forem idênticas as várias explicações de um fenómeno, a mais simples é a melhor”

William de Ockham, frade franciscano do século XIV

o principio KISS (keep it simple stupid, ou keep it short and simple) parte da premissa de que você deve fazer as coisas da maneira mais simples e estupida possível.

O principio foi definido por um engenheiro de aeronautica americana, Kelly Johnson, ao entregar uma caixa de ferramentas mecânicas para uma equipe de engenheiros que desenvolviam um avião e instruir a equipe que o avião que estes construiam deveria ser reparável por um mecânico em campo com apenas aquele conjunto simples de ferramentas.

O princípio não implica que as coisas devam fazer menos, mas sim que elas devam desempenhar suas funções com menos e de maneira simples. Deve-se eliminar o supérfluo, mas apenas isso.

Ubuntu, Firefox e Flash

“Ubuntu: Linux for Human Beings“… yeah right. Uma das coisas mais irritantes que existe em qualquer distro linux é a inabilidade de facilmente rodar flash. Parte da culpa é da Adobe, que somente ano passado passou a oferecer um release oficial do Flash para linux. Ubuntu, por mais que tente ser user-friendly, não é uma excessão à esta regra.

Anyway, fiz uma atualização do linux ontem quando voltei das férias and guess what? A atualização do ubuntu ferrou com o flash no meu firefox-2. Procurei por diversos foruns como fazer esta joça funcionar, em vão. Removi plugins, reinstalei os plugins usando o gerenciador do firefox, usando o synaptic, dancei a macarena e fiz macumba na frente do computador… e nada do flash funcionar.

Foi então que encontrei este blog e meus problemas acabaram </valtermercado>. O cara reclama de tudo quanto é problema que ele tambem teve para habilitar o flash, e exibe a solução que finalmente funcionou para mim.

1. Remova completamente (enfase no ‘completamente’) todos os plugins de flash que você já instalou… eles não vão servir para nada.
2. Accesse o site do adobe http://get.adobe.com/flashplayer/
3. Baixe a ultima versão do flash player (eu baixei o arquivo tar.gz)
4. Extraia os arquivos para alguma pasta (de preferencia no seu home)
5. Usando o terminal, acesse esta pasta
6. sudo ./flashplayer-install
7. siga as instruções do prompt, e indique qual a pasta onde está instalado o firefox

Normalmente a pasta onde o firefox está instalado é a /usr/lib/firefox. Eu atualizei meu firefox para a versão 3.0.5 agora, mas mantive o firefox-2 para testar backwards compatibility (assim como costumava manter o IE 5.5, IE 6.0 e IE 7.0 no windows), portanto a pasta onde eu deveria instalar o flash era a pasta do firefox 3.0.5, que é /usr/lib/firefox-3.0.5 (wow, tão dificil de imaginar).

Anyway, com estes passos (que não tornam o ubuntu um “linux for human beings”) consegui abilitar o flash na minha maquina. YAY. Agora, aonde está aquele CD de instalação do Debian ? Cansei de ter de atualizar meu linux diariamente e ver ele ficar ferrado ocasionalmente.

programe simples

Durante o 9o. Forum de Software Livre tive a oportunidade de assistir uma palestra do criador do PHP, Rasmus Lerdorf. Entre diversas pérolas de conhecimento que ele distribuiu para os presentes, uma que realmente tenho cultuado desde então é a seguinte:

Passar horas, dias, escrevendo um código altamente complexo para resolver um problema pela primeira vez não é ser esperto, é ser idiota. Se você teve grande dificuldade em escrever o código da primeira vez, multiplique por 1000 e e este será o grau de dificuldade para fazer manutenção neste mesmo código¹

Desde então tenho evitado soluções “mágicas” e ofuscadas para criar soluções inovadoras, sempre buscando na medida do possível simplificar todo e qualquer raciocionio que crio.

____

1 Tradução livre e independente das reais palavras de Rasmus Lerdorf.A palestra foi em abril, e não lembro exatamente quais foram as palavras utilizadas por ele.

onsubmit on form.submit()

Descobri recentemente que os padrões da W3C não permitem que, ao executar a função javascript form.submit(), as funções inseridas no parametro onsubmit de um formulário sejam executadas, somente realizando onsubmit através do input especifico (<input type=submit>). Achei isso muito estranho, e as circunstâncias em que eu trabalhava exigia que eu fosse capaz de criar um botão de submit que pudesse ser utilizado com qualquer formulario, esteja o botão declarado dentro ou fora do formulario, quer existam ou não funções declaradas no campo onsubmit;

Primeira Solução

Após uma simples busca encontrei a seguinte função:

if(form.onsubmit()) {
return form.submit();
}

Excelente e simples solução para o problema. Ele tenta executar as funções descritas no onsubmit, e então executa o submit.

Mas e se o formulário não possuir um onsubmit ? Oops… um erro ocorre…

Solução Final

Para gerar uma função genérica, que pudesse com qualquer formulário, tive de decair ao nivel do gambi-development, os quais quem me conhece sabe que repudio com fervor. A função final ficou parecida com isto:

if(typeof form.onsubmit == "function") {
if(!form.onsubmit()) {
return false;
}
}
return form.submit();

Ele verifica se existe a função onsubmit, executa ela se existente, retorna false se o retorno dela for false, e por fim executa o submit se o resultado do onsubmit for verdadeiro ou a função não existir

Não me orgulho do resultado encontrado, nem um pouco elegante, mas resolve o problema de minha aplicação.

Deixando a Solução mais Elegante

Quando eu idealizei a função acima, em julho de 2008, eu a utilizava em apenas um local que era invocado automaticamente com o template de formulários do gerenciador de nosso sistema. Porém, esta função facilita muito a vida de todos em qualquer outra ocasião onde um formulario deve ser preenchido e tu tem usar a função form.submit() para envia-lo. A solução, portanto, permaneceu não-elegante devido ao fato de não ter ser reutilizada em outro lugar.

Anyway, um jeito bem simples de deixar a solução elegante é criar uma função que a executa passando o formulario por parâmetro.


// form_submit
// submits a form, checking if there is a onsubmit function defined for it
//
// @author hagnat
// @see http://hagnat.wordpress.com/2008/07/22/onsubmit-on-formsubmit
// @param object[form] the form being submitted
function form_submit(form)
{
if(typeof form.onsubmit == "function") {
if(!form.onsubmit()) {
return false;
}
}
return form.submit();
}


Eu podia meter ainda uns testes para prevenir erros usando try-catch, mas dae é complicar desnecessariamente a função. Imagino que quem utilizar esta função saberá colocar os pontos nos i’s e passar os parâmetros corretos para a função

Tadah! Agora basta invocar a função form_submit(form) dentro do onClick de um a ou input. E aquela solução tosca fica um pouco menos tosca

Sem comentários

Se você não comenta seus códigos, é melhor começar: cada função não comentada que você escreve é uma incomodação a mais que você está criando, gratuitamente, na hora de realizar manutenção no sistema que está desenvolvendo.

Comentários possuem diversos beneficios na manutenção de código, como explicar qual a linha de raciocínio que o programador possuia ao desenvolver uma função, quais os parametros de entrada e saída de uma função, alem de descrever em linguagem humana o que determinada função realiza. Basicamente, comentários funcionam como uma documentação rudimentar para sistemas que não possuem uma documentação redigida.

Imaginem um sistema com dezenas de milhares de linhas de código, e você tendo de realizar manutenção neste. Por onde começar ? Você procura a documentação, mas ela não existe; Você segue seus instintos e encontra os arquivos que iniciam o processo do sistema, e consegue encontrar (com dificuldade ou não) os módulos do sistema que precisa realizar manutenção. Analisando o código, você encontra referencias para dezenas de classes e funções que você não tem a menor idéia de onde se localizam, ou o que estas realizam defact.

É importante não apenas comentar, mas faze-lo direito. Um código mal-comentado é quase tão ruim quanto um não-comentado. A ausência de comentários retira a total esperança de uma fácil compreensão do código, enquanto o mal-comentado dá um pouco de esperança apenas para retira-la mais tarde, porém, ainda assim existem comentários com o qual o programador terá com que se basear na manutenção do código.

Programando orientado a objetos, faço questão de que cada função que desenvolvo tenha pelo menos um cabeçalho com o nome da função e uma descrição simples do que esta faz, quando o nome da função não for o suficiente para descrever a função. Cada bloco de código é comentado, determinando o que estou codificando e aonde estas informações serão utilizadas. Existem funções onde comentários são a maior parte referente à estas, de modo que qualquer pessoa que tiver de realizar manutenção em um módulo onde estas funções são invocadas terá pequena dificuldade em compreender o que a função faz.

Escrever comentários pode parecer uma grande perda de tempo no curto prazo, mas no longo prazo acaba se revelando num grande beneficio para os programadores que tiverem de trabalhar neste sistema.

Imaginava que isto já fazia parte do bom-senso da sub-cultura dos programadores, mas alguns códigos que vi recentemente me provaram o contrario. A seguir: sobre a importância de boa nomenclatura de funções.

Como a Apple conseguiu fazer tudo certo fazendo tudo errado

A wired escreveu uma interessante reportagem sobre como a Apple conseguiu se tornar uma empresa muito bem sucedida indo completamente contra a maré, e como o culpado por isto funcionar é uma pessoa apenas: steve jobs.

Enquanto a maioria das empresas trata seus funcionários como deuses, oferecendo as maiores regalias para eles, na apple eles são tratados como lixo por jobs. Basta lembrar o filme “Piratas do Vale do Silicio” para imaginar como ele trata seus subordinados. Todos são humilhados, ridicularizados e temem por seus empregos, porem todos apreciam seu chefe, e fazem de tudo para agradá-lo.

Na apple todos são iguais. Se o vice-presidente chegar atrasado, ele terá de buscar por uma vaga no estacionamento como qualquer outro funcionario. Porem, Steve Jobs não. Se ele estiver atrasado e a vaga de deficientes estiver vaga, é ela que ele irá ocupar. E ele geralmente o faz, a ponto de que os funcionarios da empresa trocaram o emblea de deficientes pelo emblema da Mercedes.

Empresas como a microsoft produzem apenas o sistema operacional, empresas como a macromedia produzem software de qualidade e empresas como a dell produzem o processador. Ou seja, cada empresa se especializa em uma área e nela produz os melhores resultados. Não na apple. Na apple todo o pacote é desenvolvido. Do mouse ao processador, do sistema operacional ao emoticon. Isto faz com que todo o pacote possua a qualidade que a Apple espera de seus produtos, e se seus clientes estão insatisfeitos é por sua falha, não por que terceiros relaxaram no desenvolvimento de produtos.

A maioria das empresas ve blogs e fãs como publicidade gratuita. Diversos presidentes de empresas possuem blogs aonde anunciam quais os futuros projetos da companhia, e incentivam seus funcionários a comentarem sobre suas atividades em seus blogs pessoais, mesmo que seje para reclamar. Na apple, por outro lado, cobre-se de segredo todo e qualquer novo projeto da empresa. Seus funcionarios tem de assinar contratos aonde se prontificam a não comentar com ninguem, até mesmo parentes, no que estão trabalhando. Até o próprio Steve Jobs cuida para manter o trabalho da empresa em segredo, chegando a cobrir com um pano o protótipo do iPod Hi-Fi que levara para casa para experimentar. Tal absurdo chega ao ponto de que os funcionários de um projeto são proibidos de comentar com outros funcionários da empresa sobre o que estão a desenvolver. Muitos sequer sabiam que existia algo chamado iPod sendo desenvolvido na empresa até pouco antes deste haver sido lançado para o publico,

Curioso ver como uma pessoa com uma mentalidade tão retrograda de administração consegue produzir tanto sucesso. Desde que retornou à Apple em 1997 (ele havia sido demitido da empresa que ele próprio fundara), Steve Jobs consguiu tirar a empresa do fundo do poço e fazer com que ela se tornasse um gigante, lider no mercado de mp3 players, inovadora no ramo de celulares e alvo do desejo de dezenas de pessoas em termo de sistema operacional (eu sempre quis ter um OsX pr’eu).

Talvez seja sua aura de realidade distorcida. Steve Jobs faz com que mesmo o mais rudimentar projeto pareça inovador, com que a mais entediante tarefa seja uma tarefa vinda de deus. Jobs possui um estilo quase único de administração, aonde ele tenta se envolver em todas as camadas de desenvolvimento. Do angulo do monitor, à quantos parafusos vao haver na base do notebook, chegando ao cumulo de discutir coisas ao nivel do pixel!

É uma antitese esta empresa, que se propóe a pensar diferente com algumas táticas tão antiguadas de gerncia.

Fonte: Wired

Sincero Pedido de Desculpas

Lembro quando eu estava apenas engatinhando em programação, quando eu trabalhava no laboratório de pesquisas, a famosa Sala 1734. Lá eu dedicava parte da minha vida acadêmica aos estudos de algoritmos genéticos, vida artificial, resolução de problemas de quimiometria, além das normais atividades ligadas à jogatina, bebida e festas. Somente depois de três anos estudando computação foi que finalmente pude dedicar de corpo e alma à esta profissão.

Apesar da minha inexperiência, produzi excelente resultados, otimizando algoritmos já existentes para que aproveitassem melhor os recursos disponíveis, alem de ajudar no desenvolvimento de versões mais rápidas destes (o processo de otimização de um algoritmo genético levava horas, e tão cedo terminava a máquina ficava osciosa. Eu ajudei a reduzir o tempo consumido e a criar filas de testes de modo a permitir melhor aproveitamento das máquinas). Dediquei-me de corpo e alma, e por vezes fazia da minha univesidade minha segunda casa defacto.

Foi então que entrei em discussão com um de meus professores, na cadeira de Engenharia de Software. Me fervia a mente ter de me sujeitar a preencher os sem números de diagramas e organizar as dezenas de tabelas de documentação que meu professor ensinava como ferramentas básicas de um bom e estruturado projeto. Lembrava dos meus códigos, bem estruturados em arquivos ordenados, encapsulados de modo a permitir que um pudesse ser substituido por outro conforme a necessidade, e como para nenhum deles havia um diagrama sequer, uma tabela de documentação (apesar de que eles possuiam alguma documentação… eu SEMPRE documentei meus codigos), uma página de referencia citando o que já havia sido feito e o que poderia ser feito. Meu raciocinio era de que “O trabalho de pesquisa as vezes é algo momentaneo. Eu tenho uma idéia e preciso verificar se ela está correta ou não, e não posso perder tempo documentando isso quando poderia estar programando defacto”.

Alguns semestres mais tarde me vi frente a um problema onde eu sabia a resposta, porem não possuia as habilidades de programação necessárias para realizá-lo. Um de meus colegas possuia as habilidades para realizá-lo, mas não sabia como responder. Juntou-se a fome com a vontade de comer. Tentei explicar para ele como fazer, mas somente depois que rabisquei em uma folha de papel um diagrama com todos os passos que o sistema deveria realizar que este foi programado corretamente. Um excelente sucesso. Mais tarde, com o papel ainda em mãos, percebi o quão errado eu estivera na discussão com meu professor.

Alguns anos mais tarde, quando iniciei minha recente carreira como programador web, me vi novamente frente a diversos problemas onde a falta de documentação dificultava a capacidade de dar manutenção à códigos antigos. E me vi eu sendo o defensor de padronização, reutilização e documentação de código, enfrentando resistência daqueles que acreditam que “perder tempo documentando” iria somente atrasar suas já atrasadas tarefas de programação.

O mundo dá voltas. Nunca substime qualquer ensinamento que lhe for dado.