Paulo Souza

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.

Com o título desta publicação, acho que seria muita pretensão minha falar de marketing quando na verdade eu trabalho com desenvolvimento. Mas espere que logo você irá entender.
Trabalhei com pessoas de marketing que viram nos famosos “emails marketing” uma possibilidade de aumentar lucros de clientes ou simplesmente ter uma excelente visitação em seu site, mas que esqueciam de uma coisa muito básica nos dias de hoje. O tempo, ou se preferir, a falta de tempo.
Vivemos em um mundo onde se você não está conectado ou não possui uma simples conta de email, está fora do grupo de amigos que falam baboseiras lidas no Orkut ou perde assuntos interessantes que foram lidos na página de algum jornal ou revista. Seja uma simples fofoca ou algo em “real time” que acaba de acontecer na esquina da sua casa e você mesmo nem sonha em saber.
Quando entramos em um site e gostamos das informações nele contidas, é extremamente necessário que tenhamos o poder de um simples formulário onde possamos inserir o nosso email na espera por atualizações, promoções, festas ou seja lá ao que o site se propõe a oferecer. Aí que entra o problema (Dramatic Chipmunk)!
O email marketing deve ser tratado com assuntos pontuais e de breve visualização, pois se você não lê o email que sua própria mãe te enviou com a história do menino amputado que sentou em uma bomba depois de ser baleado oito vezes no peito a queima roupa e sobreviveu depois de um ano internado em um hospital público, só de ver o tamanho do scroll (barra de rolagem) você não vai ler nem o primeiro parágrafo, mesmo que o assunto aparentemente seja do seu interesse.
Quase todos os dias eu recebo emails de sites como o E-panelinha e TImaster que por mais que seja sobre emprego eu nunca consigo ler perto de 1/3 das informações ali contidas, já que chegam muito detalhadas e muitas informações ali expostas não me interessam. Mas como eu posso resolver isto de forma simples e objetiva? A resposta é mais simples ainda…SENDO OBJETIVO!
Se eu recebo um email onde tenho nele 100 propostas de emprego já previamente detalhadas, quando estiver lendo o terceiro link, alguma coisa vai me interromper com certeza, esteja eu precisando de emprego ou não. E se essa suposta interrupção for prolongada, eu nem vou lembrar de terminar de ler depois.
Você dispara email marketing? Se sim, pense nisso. Garanto que esse tipo de decisão vai melhorar a vida da pessoa responsável pelo disparo do email e a sua própria vida, onde você vai deixar de gastar tempo em 100 coisas criativas para pensar em uma única, segmentada e objetiva.
E olha que com 1/2 hora de alguns me ouvindo (no sentido tecnológico da palavra), já estão inclusive dando aula e continuam sem entender metade do que eu acabei de escrever aqui.