@felipernb: Planeta dos Macacos (original, old school) na Band :-)
(Updated 6 hours, 21 minutes ago)
Mais uma excelente tirinha do Geek and Poke:
Muitas outras estão disponíveis em: http://geekandpoke.typepad.com
Caching é fundamental para a escalabilidade de aplicações Web. Existem diversas ferramentas que oferecem diferentes maneiras de se fazer isso, seja no Smarty, no APC, nos diversos frameworks, ou Memcached para os mais drásticos…
Mas essa é a “maneira Rasmus Lerdorf” de se fazer cache com PHP sem nenhuma ferramenta externa e com uma sacada fenomenal.
Para um servidor Web é muito mais rápido servir arquivos estáticos do que esperar que aquele arquivo seja interpretado por algum módulo ou que seja executado em CGI e é isso que esse método faz, gera arquivos estáticos sob demanda, utilizando os recursos que o Apache oferece.
Agora imagine que você tem um site de notícias e quer que elas sejam tratadas como arquivos estáticos, e os links para cada notícia seria algo como:
http://meusite.com.br/noticias/000001.html
1º passo: Setamos nas configurações do Apache para que a página de erro 404 seja um arquivo .php (isso pode ser feito no .htaccess da pasta ou nas configurações do Apache propriamente dito). No caso do .htaccess, basta colocar isso:
ErrorDocument 404 /noticias/gera_cache.php
2º passo: Criamos o arquivo gera_cache.php, que irá tratar as requisições que teriam como resposta o erro 404 (Not Found) com o seguinte codigo:
<?php
$id = basename($_SERVER['REDIRECT_URL'], '.html');
/* Acessa a página dinâmica */
$html = file_get_contents(sprintf("http://meusite.com.br/noticias.php?id=%d",$id));
/* O ideal é fazer algum tratamento de erros, para evitar a
criação de arquivos para ids inválidos */
/* Exibe o conteúdo */
header(sprintf('%s 200', $_SERVER['SERVER_PROTOCOL']));
echo $html;
/* Salva o conteúdo em um arquivo .html */
$fp = fopen(sprintf(dirname(__FILE__)."/%d.html", $id), "w");
fputs($fp, $html);
fclose($fp);
?>
Sendo assim, o que vai acontecer:
Quando o usuário acessar pela primeira vez o link http://meusite.com.br/noticias/000001.html, o arquivo /noticias/000001.html não existirá e o usuário será redirecionado para o gera_cache.php. O gera_cache.php acessa a página dinâmica que exibe o conteúdo da página com o id passado (000001) e salva em um html. Nos acessos consecutivos ao http://meusite.com.br/noticias/000001.html o arquivo existirá e não passará mais pelo PHP.
É uma técnica bem “tricky” e que precisa de cuidados, por exemplo, você precisa ter uma rotina que expira os arquivos em cache após algum tempo e quando houver alguma alteração em determinada informação que interfere na página que está em cache, para garantir consistência dos dados. Uma maneira muito simples de se fazer isso é usando a função filectime do PHP para checar a idade dos arquivos em uma rotina que rodaria em background e apagaria os que fossem mais velhos que o tempo desejado. Mas funciona muito bem!
P.S.: Um artigo que li dizia que apesar dessa técnica ter se tornado pública através do Rasmus, ela foi criada mesmo pelo Stig Bakken
No último fim de semana (18 e 19 de outubro) houve em São Paulo o CONAPHP (www.conaphp.com.br), um evento feito pela comunidade PHP e que rolou dentro do CONISLI na FIAP.
O evento em geral foi bom, com bom nível de palestras mas o público foi um pouco abaixo do que eu esperava.
Para mim, o ponto alto foi quando estava assistindo a palestra do Elton Minetto (slides aqui) e “reconheci” um slide sobre o compilador JIT e o cache do opcode do PHP, um slide que fazia parte da apresentação que fiz em Recife no Encontro Pernambucano de SL, e para confirmar vi lá meu link nas referências, e isso me deixou bastante honrado por ter um material meu usado como referência por um ícone como o Elton.
A minha palestra foi a última e falei sobre PHP RESTful Web Services, por ser a última, o título não ser apelativo para o pessoal mais iniciante e eu ser um ilustre desconhecido da comunidade PHP de São Paulo, tive apenas metade da sala cheia, mas o feedback das pessoas que assitiram a palestra foi bastante positivo e fiquei muito satisfeito.
Os slides da palestra seguem abaixo, e o código apresentado está disponível aqui.
Quem tiver interesse sobre o assunto, deixo algumas referências:
O nome soa estranho, mas computação em nuvem é a tradução do termo “Cloud Computing” que vem rondando o vale do Silício há algum tempo e é um conceito que assusta gigantes do mundo do PC como a Microsoft e abre espaço para milhões de pequenas empresas na Web – as startups.
A idéia da computação em nuvem apresenta uma nova maneira de organização do mundo digital, que deixa de ser “PCcêntrico” e passa a ser “WEBcêntrico”, já que a tal nuvem é a própria Web, com os softwares deixando de ser produtos e se tornando serviços.
Dessa maneira, seus dados, documentos e ferramentas estariam hospedados em grandes servidores na Web e você acessaria tudo através do navegador, que seria uma espécie de cliente universal e assim você teria acesso aos seus arquivos a partir de qualquer computador no mundo e também exigiria menos dos PCs o que possibilitaria a produção de máquinas ainda mais baratas.
E o software como serviço abole de vez com as licenças e softwares de prateleira, pois você não precisa mais instalar nada, apenas paga-se uma taxa para usar um serviço online por um determinado tempo e no caso de serviços gratuitos, alguém está pagando para você: OS ANUNCIANTES.
Isso já vem acontecendo aos poucos com a oferta de serviços na Web de suítes de escritório e ferramentas de edição de imagem, entre outros e a tendência é que nas máquinas só estejam instalados softwares básicos.
Mas por quê a Microsoft deve se preocupar?
A política da Microsoft de vender software na caixinha fica obsoleta com essa novidade, e os usuários costumavam optar pelos MS Windows pelo enorme leque de opções de softwares compatível com ele. Porém se a idéia da computação em nuvem se concretizar, as aplicações se tornam independentes de plataforma e qualquer pessoa em qualquer sistema operacional que tenha um browser que implemente razoavelmente os padrões web W3C, como o excelente Mozilla Firefox, poderá ter acesso às tais aplicações, e essa é mais uma chance que o Linux tem de decolar.
E o que ainda falta?
Na minha humilde opinião ainda existe um gap que precisa ser considerado: o gargalo da rede. As aplicações Web estão conseguindo um nível de responsividade muito alto, mas para se equiparar aos potentes computadores modernos rodando aplicações stand-alone ainda há um caminho árduo a ser percorrido e não acho que seja algo que é feito da noite para o dia, mas sim algo gradual e relativamente lento, como realmente vem acontecendo.
A dica do dia é: http://browsershots.org, um site onde você pode obter o screenshot do seu site nos mais diversos browsers em diferentes versões e SO’s. Realmente muito bacana!
Update: E para pegar um shot da pagina completa, tem esse serviço web bem bacana
Com o aumento da complexidade de recursos dos sites na Web, o termo Webmaster entra cada vez mais em extinção.
Antigamente, quando tudo era mais simples e feio, com sites em HTML estático e cheio de GIFs piscantes, era comum ter um cara que era responsável por tudo, o webmaster.
Mas agora é cada vez mais difícil ter conhecimento suficiente para ser um bom designer e bom programador, eu me atrevo a dizer que seja impossível. E vou justificar…
As duas áreas podem ser extremamente profundas, design não é só fazer efeitos legais no Photoshop, nem programação é apenas fazer um CRUD em drag’n'drop Net dot Net
Um profissional de design precisa ter conhecimentos teóricos na área, saber criar conceitos, prezar pela usabilidade, ergonomia, sem esquecer da beleza e do conforto do usuário com cores e formas adequadas, e isso requer estudo, não é só questão de ter um “bom gosto”. Fora que muitas vezes a arte que é mostrada no site de uma empresa é a continuação de toda uma campanha que ocorre também fora do “cybermundo”.
E um profissional de desenvolvimento de software precisa conhecer algoritmos, padrões de projetos, tecnologias diversas, técnicas de otimização de performance, segurança, etc.
Existem pseudo-profissionais que se auto-intitulam web designers e programadores, e eu sinceramente não acredito nisso. Um programador pode até escolher um formato bacaninha pra mostrar sua informação e tal, mas está longe de ser um designer profissional, e um designer pode até colocar um reloginho em JavaScript mas também está longe de ser um programador.
São mundos bem diferentes com profissionais de perfis diferentes que se juntam na Web, e para que essa junção seja mais harmoniosa, existe um cara que é híbrido, é o programador de interfaces, caras que sacam um pouco de cá e um pouco de lá e que trabalham na equipe para fazer com que as coisas encaixem mais perfeitamente, pois nem sempre um designer vai saber XHTML, CSS, e etc. Em muitos casos ele sabe criar e desenhar, o programador de interfaces que se vira para adaptar a arte dele para o mundo da Web e interagir com o sistema que é criado pela equipe de programação. Mas também há casos que designers desempenham essa função e há outros em que o programador o faz, cada caso é um caso… mas ainda não existe profissional completo que cuide de tudo, e se faz não é profissional ou não faz bem feito como deveria.
P.S.: Quero avisar aos poucos, porém queridos, leitores desse blog que meu aniversário é domingo, e caso queiram presentear esse que vos escreve, sintam-se a vontade! 
Aqui vai um endereço que talvez possa lhe ajudar: http://feliperibeiro.com/wishlist
Um post (antigo, mas) interessante sobre as cores usadas nos sites mais “famosos” dos últimos tempos:
http://www.modernlifeisrubbish.co.uk/article/web-2.0-colour-palette
Com toda essa moda de SEO, Web 2.0 e etc, os desenvolvedores estão se interessando em melhorar o que é mostrado para o usuário até na URL, pois isso é bom para a indexação nos sistemas de busca – adiciona palavras-chave na url – e deixa mais entendível para quem usa o site.
Com mod_rewrite você faz um mapeamento de como as URLs são exibidas, e a que endereço elas realmente apontam, por exemplo:
Você tem uma parte do seu site que lista usuários por localidade e a URL pra essa página é www.exemplo.com.br/usuarios.php?pais=Brasil&estado=PB&cidade=Campina Grande, se você usa o mod_rewrite você pode fazer com que essa página seja aberta através da URL www.exemplo.com.br/usuarios/Brasil/PB/Campina Grande, que deixa bem mais elegante e melhor de ser indexado pelos sistemas de busca, que não costumam indexar páginas com muitos parâmetros passados por GET. (Normalmente também tem dificuldade em indexar documentos em diretórios num nível muito abaixo da raíz, mas isso é menos crítico).
E a mágica funciona assim:
1 – Certifique-se que o mod_rewrite está habilitado no seu Apache.
Uma maneira simples de fazer isso é com <? phpinfo(); ?> e procurando na parte que mostra os módulos do Apache.
2 – Crie um arquivo .htaccess na raíz do seu site.
3 – Escreva as regras no seu .htaccess:
RewriteEngine on
RewriteRule usuarios/(.*)/(.*)/(.*)$ usuarios.php?pais=$1&estado=$2&cidade=$3 [L]
(Idealmente a RewriteRule fica numa linha só, a quebra foi feita aí por motivos de formatação do blog)
Aí eu estou dizendo para o apache redirecionar qualquer request que vem para /usuarios/XPTO/FOO/BAR para /usuarios.php?pais=XPTO&estado=FOO&cidade=BAR, e onde eu coloquei o (.*) pode ser qualquer regex.
Você pode escrever quantas RewriteRule quiser no seu .htaccess e o Apache vai usar a que primeiro casar com a situação, então é bom estar ligado nessa ordem de precedência, pois se você colocar algo como:
RewriteRule usuarios/(.*)$ usuarios.php?pais=$1 [L]
RewriteRule usuarios/(.*)/(.*)/(.*)$ usuarios.php?pais=$1&estado=$2&cidade=$3 [L]
Vai ter problemas, pois nunca vai entrar no segundo caso, já que o (.*) significa “qualquer caracter, 0 ou mais vezes”, então a / entra nesse bolo, e vc vai ser redirecionado para usuarios.php?pais=Brasil/PB/Campina Grande. Então é bom ter cuidado para usar as Regex corretas e a ordem correta.
Vantagens de se usar mod_rewrite:
1 – Caso você não queira, não precisa expor qual tecnologia você está usando (ocultando a extensão .php, .psp, .pl, .py ou seja lá o que for);
2 – As URLs ficam mais legíveis e relevantes para usuários e search bots;
3 – Você pode fazer uma “gambiarra” para deixar informações relevantes na URL mesmo que não precise delas na sua página, por exemplo: você tem uma loja, e tudo que você precisa para abrir os detalhes de um produto é o id dele: produto.php?id=123456, mas para deixar a url mais bacana e ser indexada melhor você cria a regra:
RewriteRule produto/(.*)/(.*)$ produto.php?id=$2 [L]
e usa essa URL com: www.exemplo.com.br/produto/NOMEDOPRODUTO/ID e o sistema só pega o id ($2), daí ficaria algo como: www.exemplo.com.br/produto/Nintendo Wii/123456
Desvantagens de se usar mod_rewrite:
1 – Você precisa ter um cuidado re-dobrado quando passar strings com caracteres especiais como o &. Pois o .htaccess redireciona pra o seu script, o PHP no caso, e o PHP vai entender o & não como parte da sua string, mas como o separador de parâmetros do GET.
2 – Não sei se em sites de muito tráfego e muitas regras, isso pode interferir (mesmo que muito pouco) na performance, pelo fato do Apache precisar ler e testar todas as regex na url. (também não sei se é feito assim, mas acredito que sim)
Minha experiência com mod_rewrite foi pouca, talvez eu tenha falado bobagem, e se eu tiver, por favor, corrijam-me nos comentários!
Até umas duas semanas atrás meu blog era retornado na quinta posição quando se realizava a busca por felipe ribeiro. Apliquei algumas técnicas de SEO – Search Engine Optimization, e agora estou em primeiro! 
As técnicas principais do SEO são:
1 – HTML bem formatado: Tags aplicadas corretamente indicam a relevância de um texto. Se o texto está entre as tags <title> e certamente ele será a “chave” da página. Um texto entre as tags <h>, também será mais importante do que textos em parágrafos (<p>), texto em negrito e itálico também demonstram um certo destaque. Então um html bem feito é essencial.
2 – META tags: Essas tags também dizem ao spider dos search engines informações sobre o que há no seu site, como keywords e description e foi mexendo nas keywords que consegui melhorar a posição do meu site, organizei melhor as coisas e dei relevância ao que era relevante!
3 – Links: Consiga links para o seu site, os spiders percorrem links pela web e quanto mais links houverem para o seu site, mais “pontos” de popularidade você terá e isso influencia na relevância do seu site para outras pessoas.
4 – Cadastro em Diretórios: Existem sistemas de buscas que não são baseados em spiders, mas em cadastros feitos manualmente, um dos principais é o Open Directory Project (www.dmoz.org), cadastrar seu site nesses diretórios é um bom negócio por alguns motivos, primeiro porque de qualquer maneira aumenta a quantidade de referências para o seu site, e também o Google leva muito em conta os sites cadastrados nesse projeto.
5 – Conteúdo bem escrito: Se você escreve bem, terá as palavras chave com bastante destaque no texto, e essa “densidade” da palavra no seu texto mostra o quanto ela é importante. Por isso que se eu quero aparecer bem na busca por felipe ribeiro, esse é um termo que precisa aparecer!
Essas são algumas das coisas que podem ser feitas para incrementar a popularidade do seu site, mas existem outras como links patrocinados, que não tentei então não posso comentar.
Clique para ver maior…
