É, meus amigos, este é o motivo da minha ausência nos ultimos tempos. Um projeto interessante me tomou bastante tempo, e quero hoje, junto com o Julio Greff, anunciar que ele está quase pronto. Pessoal, com vocês, o nosso Spaghetti* Framework. Um framework para pequenas e médias aplicações.

Desenvolver para Web hoje já requer certa maturidade, quem não desenvolve um workflow produtivo dificilmente consegue se manter no mercado. Sentimos necessidade de uma ferramenta que tornasse nosso trabalho mais rápido, produtivo e divertido, porém sem perder qualidade. Usamos alguns frameworks e cogitamos outras possibilidades. Porém os frameworks PHP existentes até então eram grandes e inflexíveis demais para nossas necessidades reais, e migrar de linguagem é algo custoso, que requer uma curva de aprendizagem maior e um tempo que não tínhamos.

Chegou a hora de fazer nosso próprio framework.

A proposta inicial era pouco pretenciosa: um framework simples, sem MVC, mas que contivesse um modelo de dados e suporte nativo às URLs amigáveis. Essa era a nossa primeira versão e nosso primeiro escopo. Porém os projetos foram crescendo em número e dimensões, e sentimos que MVC seria a melhor solução. O Julio fez a escolha certa ao escolher o design pattern mais badalado do meio. MVC nos trouxe uma grande flexibilidade, que nunca haviamos conseguido antes.

Foram alguns meses de trabalho, tanto meu quanto do Julio, e acreditamos que o diferencial do nosso framework é que durante todo o processo de desenvolvimento do Spaghetti ele foi utilizado na prática. Sem cookbooks, sem 15-minute blog tutorials. Para cada etapa do processo de desenvolvimento do core do Spaghetti foi desenvolvido um Website ou sistema real, que hoje encontra-se em produção, funcionando.

Desde a versão não-MVC, há sites de clientes da agência onde trabalhamos rodando o Spaghetti. No meu ponto de vista isso é positivo, pois desenvolvemos uma plataforma baseada em problemas reais, com clientes reais e ambientes reais de desenvolvimento. Por isso, pensamos no Spaghetti como um framework sem utopias. O que existe é o que é usado de verdade.

Flexibilidade é a palavra de honra. CMSs geralmente limitam as capacidades dos desenvolvedores Web / clientes. Frameworks são super flexíveis em todos os aspectos, e não queremos ser diferentes nesse quesito. As funcionalidades já embutidas podem ser expandidas e novas podem ser adicionadas com Componentes que você mesmo pode escrever.

A que pé estamos?

O Spaghetti hoje supre muito bem todas as necessidades de desenvolvimento da nossa equipe na agência. Porém, estamos tornando esse projeto público. Ou seja, precisamos documentar tudo excepcionalmente bem, gravar screencasts, tutoriais, e até fazer um cookbook. Ou seja, nosso framework está pronto para uso, porém ele ainda não está pronto para que vocês, que estão conhecendo ele agora, saibam de tudo que ele é capaz.

Caso você seja curioso – e garanto que é – deve estar pensando onde está o código. Caso você queira dar uma olhada (por enquanto por sua conta e risco – já que não há documentação ainda), você pode acessar nosso Trac, e lá há inclusive o histórico de versões e revisões.

Lançamento oficial do release estável

[UPDATE] O lançamento oficial do Spaghetti* aconteceu em 1 de janeiro de 2009, junto ao lançamento do site oficial em www.spaghettiphp.org.

Enfim, o assunto não é esse. Mesmo tendo mudado de título definitivamente (de quase-programador para aprendiz-de-designer), não nego a importância da programação para o Web designer. Você tem sim que saber um pouco de XHTML e CSS, mas um pouco de programação não faz mal. Não é questão de prioridades, de se focar num assunto específico, isso é bobagem. O profissional deve ser bom sim no que faz, mas sempre deve estar aberto e ter conhecimento do trabalho do colega ao lado.

Eis que então, meus amigos, como é de conhecimento de vocês, eu já tenho alguma experiência básica com CakePHP. Começamos a utilizá-lo na agência onde eu e o Julio trabalhamos, e eu realmente fiquei surpreso com o grande potencial tanto do framework quanto do PHP. Li por várias vezes a documentação, a API, e as entranhas do Cake, e vi como o funcionamento é simples.

PHP, de fato, não é uma linguagem ruim. Eu digo que não gosto da sintaxe do PHP, pois prefiro a do Ruby, mas nem por isso odeio o PHP. Essa é a minha opinião. Quanto mais eu conheço a linguagem, mais estou gostando dela. Até pouco tempo utilizava PHP4, mas em 2008 comecei a entender toda a lógica por traz da orientação a objetos. Isso me abriu as portas para entender esse potencial do PHP.

PHP, apesar da sintaxe não tão legal (opinião pessoal), está bastante madura, a julgar pela quantidade de extensões existentes, sem falar na grande abrangência desta linguagem.

Como eu havia dito, independente da linguagem cada um tem que procurar ser mais produtivo. Talvez eu não seja mais produtivo que o pessoal que comentou lá (cujo tom de arrogância de alguns faz parecer que estes sabem tudo de PHP), mas eu sei que estou amadurecendo e que estou me tornando produtivo se comparado a mim mesmo há um ano. Inclusive no design.

Espero não entrar mais nessas discussões, pois já disse aqui várias vezes o que penso e que estou me distanciando um pouco da programação pois – salvas excessões – há muita arrogância e ignorância entre os programadores.

Programar em seqüência, proceduralmente, sempre pareceu muito natural para mim. Até o momento que eu percebi que reinventar a roda não é lá o que se pode chamar de produtivo. Ainda não fiz nada, meus amigos, não esperem um grande lançamento de software de minha parte. Mas já é um bom começo ao menos entender a lógica por trás de tanta coisa abstrata.

Dica: Se alguém aí também não entende, o Danilo do Digital Minds publica infreqüentemente uma série de artigos muito bons sobre PHP OO para quem também está boiando no assunto.

Eu uso PHP, e estou estudando (e finalmente entendendo) orientação a objetos. E você, como programa?

Acontece que o FeedBurner disponibiliza a Awareness API, que serve justamente para acesso dos dados de tráfego do seu feed através de aplicativos que não são do FeedBurner. Para obter tais informações, você deve ativar esta API no menu Publicize > Awareness API, do seu painel de controle do FeedBurner.

A partir de então, você pode ter acesso aos dados do seu feed através do seguinte endereço:

http://api.feedburner.com/awareness/1.0/GetFeedData?uri=seuusuario

Lembrando que você deve substituir seuusuario pelo seu nome de usuário do FeedBurner. Este é o endereço da sua API, e você tem acesso livre a estes dados. Como uso WordPress, e meu servidor é PHP e suporta a versão 5, utilizando a extensão SimpleXML com duas linhas de código eu consigo retornar o número de assinantes. Veja como é simples.


<?php

$feedburner = simplexml_load_file('http://api.feedburner.com/awareness/1.0/GetFeedData?uri=seuusuario');


echo $feedburner->feed[0]->entry[0]['circulation'];
?>

Com quem usa ASP, eu já não manjo muito e não sei dizer como manipular XML. Se alguém souber, me mande que eu coloco e credito.

Respondido, Alexandre?

Chegou a época de receber os resultados do Exame Nacional do Ensino Médio, e com ele veio o desespero de muitos. Não pelo desempenho nas questões objetivas ou na redação, mas pelo fato de boa parte da galera ter esquecido de anotar a senha para acessar o boletim on-line lá, no site do INEP.

Ter o resultado do ENEM é importante, pois em muitas universidades as notas podem ser aproveitadas. Com o caótico congestionamento no site do Exame, a recuperação de senha ficou indisponível por dias.

Eis que então, em 5 minutinhos, eu fiz um script que – utilizando o algoritmo da senha do ENEM – gera a senha de acesso a partir do número de inscrição.

Fiz em 5 minutos, mesmo. Ou até menos. Só agora dei uma embelezada no negócio.

Clique aqui para saber a sua senha do ENEM

O algoritmo e a falcatrua

Na verdade, a senha não é um número randômico, salvo em um banco de dados, e nem usei API nenhuma (até por que o pessoal do governo nem deve saber o que é uma API). O cálculo da senha é feito com base no número da inscrição, que é uma string de 12 caracteres numéricos. E a senha, sendo também uma string numérica de 8 caracteres, é calculada da seguinte maneira (cada item é um dos caracteres da senha):

• 9 – 9° número da string
• 10° número da string
• 9 – 11° número da string
• 12° número da string
• 9 – 5° número da string
• 6° número da string
• 9 – 7° número da string
• 8° número da string

Alguém se habilita a fazer o script em Javascript?

Nada comparado a Ruby on Rails, Django, ou mesmo CakePHP. Tenho conversado com alguns amigos sobre qual é a escolha certa. Tentei começar com Ruby, tentei começar com Python. Nada feito. Gosto muito do PHP, e foi só essa semana que parei para pensar que não preciso sair do PHP para ser produtivo. E aí começa minha aventura.

Resolvi que escolhi o CakePHP. Acompanhando alguns tutoriais do Tulio Faria, estou vendo como é simples fazer a coisa acontecer com o Cake. Foi por isso que criei a categoria CakePHP aqui no blog. Quero, ao passo que for aprendendo, transmitindo isso para a comunidade.

Para mim é como se fosse aprender uma nova linguagem, pois não sou craque em orientação a objetos ainda. Mas como nada na vida vem de graça, a peleia é longa e a minha bakery está entrando em ação para colocar esse CakePHP para funcionar.

‘application/xhtml+xml’ SHOULD be used for serving XHTML documents to XHTML user agents. Authors who wish to support both XHTML and HTML user agents MAY utilize content negotiation by serving HTML documents as ‘text/html’ and XHTML documents as ‘application/xhtml+xml’.

Ou seja, o autor que deseja dar suporte tanto para user agents XHTML quanto para HTML, deve utilizar negociação de conteúdo para servir documentos com o MIME Type adequado a situação. Um simples script em PHP resolve o problema:

<?php
if (stristr($_SERVER[HTTP_ACCEPT], "application/xhtml+xml") ||
stristr($_SERVER["HTTP_USER_AGENT"], "W3C Validator")) {
header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
header("Vary: Accept");
echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\" ?>\n");
} else {
header("Content-Type: text/html; charset=iso-8859-1");
header("Vary: Accept");
}
?>


O script verifica se o agente de usuário suporta o application/xhtml+xml, ou se o agente de usuário é o W3C Validator. Caso um deles seja verdadeiro, o documento é servido como application/xhtml+xml, caso contrário, ele é servido como text/html. Além disso, se um deles for verdadeiro, o documento recebe a declaração XML.

O cabeçalho Vary: Accept é enviado para que agentes intermediários de cache, como proxy servers, saibam que o MIME Type varia, de acordo com o suporte que o agente de usuário oferece.

O benefício disso tudo é que em browsers como Firefox e Mozilla, que suportam o MIME Type application/xhtml+xml, o código XHTML é tratado como XML no que se refere a intolerância a erros. Ou seja, se um documento XHTML, com MIME Type application/xhtml+xml possuir erros de sintaxe, estes browsers não irão mostrá-lo, assim como acontece com o XML inválido. Somente serão exibidos os documentos assim que os erros de sintaxe estiverem corrigidos. Assim, nem o W3C Validator é necessário para apontar erros.

Veja também

• Content negotiation – 456 Berea Street
• Content negotiation, AdSense, and comments – 456 Berea Street
• Content negotiation – Japs.etc.br