Paulo Souza

Eu acho impressionante a quantidade de pessoas que falam de WEB 2.0 sem ao menos entender o real conceito para o seu uso.

A internet é livre e tudo que hoje é feito foi pensado tempos atrás por programadores, mas não eram levadas a sério por seus gestores. Isso mesmo, a realidade é nua e crua.

Integrações com usuário, interatividade e outros diversos motivos de se vender um site 2.0 hoje nada mais é do que aproveitamento de idéias de pessoas que pensavam na revolução mas a sua equipe comercial não via com bons olhos. Afinal, nos tempos idos o cliente é isso ou aquilo, conservador, metódico e tudo mais que se possa imaginar para transformar o cara no mestre da formalidade.

Na boa, esquece esse papo de WEB 2.0, pois isto tudo nada mais é que marketing hoje em dia.

Os clientes sempre puderam pedir para que o cliente interagisse mais, que o seu site fosse mais dinâmico e tudo mais que se tem direito, mas sempre foi mal assessorado. Isto sim é verdade.

Com o desenvolver da internet e suas inúmeras “versões”, se é que podemos dizer assim, foram inclusas diversas metodologias de navegação e usabilidade que são um pouco antigas e apenas não eram utilizadas ou ainda não são implementadas por muitos. Com vocês, as famosas “urls amigáveis”.
Muitos já sofreram ou ainda sofrem com sistemas que usam no seu dia-a-dia quando escutam perguntas do tipo :

- Me passa o link?

A primeira coisas que pensamos sem piscar é justamente pensar na url que era apresentada no momento da sua navegação, que muito chamou a sua atenção mas é quase impossível lembrar o caminho exposto no campo de url do seu browser por completo, pois no máximo só passa pela nossa cabeça na maioria dessas situações o maldito endereço do site. Aí vem a sua resposta…

- Eu vou mandar para o seu email por que agora eu não lembro o endereço completo.

Que mico! Você falou sobre o conteúdo da url, disse que “X” coisa era excepcional, que “Y” coisa falava muito bem sobre tal assunto e tudo mais, mas na hora de permitir que o seu amigo pudesse visualizar justamente aquilo que tanto te impressionou, tudo desanda. E ele ali com o palm, celular, laptop ou um simples papel para anotar e nada, restando apenas ter que esperar pelo email.
As urls amigáveis são recursos disponíveis por alguns servidores e tratadas por aplicações que foram pensadas para tal ação.
Servidores web como o Nginx, Lighttpd e Apache possuem um recurso conhecido rewrite engine.
Os módulos que permitem rewrite em servidores web visam construir supostas rotas visuais para tratamento de diferentes páginas e redirecionamentos, tratando os diversos segmentos da página visitada como parâmetros para a construção de uma página específica.
Vamos logo para um exemplo presente no cotidiano de pessoas que utilizam o Orkut. Afinal, quantas vezes você mesmo já não tentou lembrar de alguma página que te chamou atenção neste site?
Atualmente, quando entramos na página de alguma comunidade temos um caminho montado na url da seguinte forma:

http://www.orkut.com.br/Main#Community.aspx?cmm=44916570

Lendo a url acima fica fácil de entender que este caminho é de alguma comunidade apenas pelo “Community.aspx”, mas e para lembrar do parâmetro passado pela variável que vem a seguir? O que será que significa o “Main#”?
Agora vamos para uma idéia mais simples, imaginando o mesmo sistema em um servidor onde ambos foram pensados para se ter urls amigáveis.

http://www.orkut.com.br/community/main/perfects-do-orkut

Impressionante a diferença, não? Vai dizer que assim não ficou mais fácil de responder a pergunta que o seu amigo te fez aí em cima?
Com esta estrutura temos 3 diferentes segmentos na nossa url, onde:

1. community = área que estamos no site
2. main = a página principal da área “community”
3. perfects-do-orkut = o parâmetro esperado para montar a página principal da área que estamos navegando

O site que serviu de base para o exemplo, apesar de ser desenvolvido em uma linguagem desenvolvida pela Microsoft e conseqüentemente está funcionando em um servidor Windows, nada impede que seja repensada e sua estrutura para ser alterada, pois dizem por aí que existe um módulo para rewrite de url’s em servidores IIS. Eu não levo fé, mas se realmente existir seria interessante se o Google, como atual administrador do Orkut, pudesse pensar um pouco sobre isto.
Logo abaixo você poderá ler um pouco mais sobre urls amigáveis e entender melhor sobre o seu funcionamento e vantagens que se pode ter no desenvolvimento de sistemas com essa estrutura, agregando além de valor ao seu desenvolvimento, uma melhor posição em sistemas de busca e um melhor estudo para debug do seu código.

1. Servidores
   1. Nginx
   2. Lighttpd
   3. Apache
2. Apache Mod_Rewrite
3. Urls amigáveis

Até a próxima!

O assunto é chato e tem um ponto de vista muito pessoal e vai depender de quem ler esta publicação a sua correta interpretação ou familiariadade com alguns fatos.
Quando desenvolvemos um sistema, precisamos pensar na base daquilo a que ele se propõe, mas não vejo isto ocorrer com naturalidade e precisão.
A base de qualquer sistema sempre vai existir manipulação de dados, mas você saberia me dizer em um sistema que já teve ou ainda tem a sua participação como isso foi feito? Será que foi feito?
Quando pensamos em sistemas WEB, muitas vezes nos tornamos muito infelizes e descontentes com o nosso trabalho com tantas coisas que aparecem todos os dias para serem alteradas, canceladas ou testadas antes mesmo de serem finalizadas.
Eu não conheço nenhum desenvolvedor que nunca tenha passado por isso, pois na verdade vivenciamos sempre exatamente a mesma coisa, seja no trabalho ou como freelancer, lembrando que como freelancer você ainda tem quase sempre a opção de estar auxiliando melhor aquele que te contratou, mas em quase toda empresa recebemos remessa “X” por email com prazos “Y” de entrega. Se dá para entregar eu não sei, mas é isso que eles querem e é isso que deve ser feito.
Com o tempo aprendi a me proteger sobre pedidos absurdos ou jamais antes imaginados de uma forma bem simples e objetiva, exigindo a documentação formal de tudo que está sendo pedido, os seus propósitos e a relevância do seu uso.
Quando temos um pedido documentado, temos esperança de estar um pouco mais seguros do que faremos e nos preservando de ter um retrabalho chato que na maioria das vezes vai acabar te consumindo, consumo este que vai da sua energia até a compra de medicamentos.
Não custa nada e é super importante para o trabalho de qualquer um pegar um papel e uma caneta e com uma idéia na cabeça desenhar tudo aquilo que vamos precisar, ao menos para saber por onde começar.

O texto abaixo é uma tradução que fiz pelo Google Translate e adaptado por causa de alguns probleminhas na sua tradução. Espero que seja de grande ajuda.
O intuito desta publicação visa ajudar aos inúmeros blogueiros e pessoas que trabalham com sites que necessitam melhorar a sua performance, já que o nosso querido WordPress, mesmo sendo poderoso, tem uma performance muito baixa.
O plugin foi idealizado para trabalhar com o Apache, mas servidores como Nginx e Lighttpd podem ser configurados para aceitar as regras determinadas no arquivo .htaccess.

WP Super Cache
Colaboradores: donncha
Palavras-chave: performance, caching, wp-cache
Testado até: 2.5.1
Tag Estável: 0.6.4
Exige pelo menos: 2.2

Este é um rápido CACHE ENGINE para WordPress, que produz arquivos HTML estáticos.

Descrição
Este plugin gera arquivos HTML estáticos a partir de um sistema WordPress. Depois que um arquivo html é gerado o servidor irá servir este arquivo na frente da execução de funções ou consultas ao banco.
No entanto, uma vez que um usuário deixar um comentário, o plugin irá servir apenas arquivos HTML estáticos para:

1. Os usuários não logados
2. Os usuários que não tenham deixado um comentário
3. Ou usuários que não tenham visto qualquer publicação com senha

A boa notícia é que provavelmente mais de 99% de seus visitantes não realizam qualquer uma das opções expostas acima! E aqueles usuários que não visualizam os arquivos estáticos irão se beneficiar porque eles verão o cache de arquivos e seu servidor não será tão movimentado como antes. Este plugin deve ajudar o seu servidor a lidar com uma primeira página digg.com ou outra aparição no site da rede social.
Como este plugin é baseado no antigo WP-Cache, você pode desligar o SUPER CACHE para htmls estáticos. O cache ainda será realizado, mas a cada pedido, será necessário carregar o PHP novamente. Em circunstâncias normais, ele não é assim tão mau, mas se o seu servidor está com um load ruim ou se está enfrentando tráfego pesado, você pode correr sérios apuros.
Os arquivos do SUPER CACHE serão servidos mais rapidamente do que o PHP em cache de arquivos gerados, por isso há muito pouca razão para não utilizar este recurso.

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Veja a página do WP Super Cache para mais informações.
O changelog é um bom lugar para começar se você quer saber o que mudou desde o último download do plugin.