Assim como a sociedade, a língua é uma entidade viva e está em constante modificação – não se encontra estática em um livro de gramática. A língua tem que estar a serviço da sociedade, e não o contrário. A norma dos cultos, que, hoje, é considerada a padrão, amanhã, pode não o ser mais.

Quer dizer, sendo uma entidade viva, parece que por ela falhar em impor suas regras formais – ou em ter suas regras impostas por pais, professores e sociedade – de tempos em tempos tem seu rigor aliviado e deve se adequar às regras informais, coloquiais, incentivada pela infinidade de momentos em que a expressão se torna mais importante do que suas restrições.

Pensando pelo lado “maldita inclusão digital que nem sabe escrever e já sai escrevendo no Face”, isso é péssimo, mas, pensando no dia-a-dia, quando lemos dezenas de artigos e escrevemos outras dezenas, seja na internet, na redação, ou mesmo mentalmente, vemos que tudo está a favor de uma linguagem flexível e compreensível, tanto para o cidadão de pensamento simples como para um doutor. Isso se repete sempre e dada sua ciclicidade não tão óbvia – a não ser que você tenha lido dezenas de edições de livros de gramática da língua portuguesa – talvez muito do que consumimos e produzimos já fora considerado gramaticalmente errado.

Portanto, pode parecer estranho, mas em um futuro bem próximo – observada a forma como os brasileiros estão escrevendo – as seguintes mudanças na língua portuguesa poderão ser mais aceitas, senão oficializadas:

Desobrigação do R ao final do verbo através da transformação da palavra em oxítona

Vamos lá toma umas cervejas e conversa um pouco

Aceitação do pronome oblíquo “mim” antes de um verbo

Antes eu não conjugava os verbos de forma correta. Agora mim pode conjugar

Flexibilização da concordância nominal

Eu fui comprar uns jogo no Centro

Advérbio de intensidade mais como conjunção adversativa mas

Escrevo assim mais nem ligo

Nesse momento eu penso em… “cruzes!”, mas não importa. Eu estou longe de escrever bem, portanto, longe de ter razão em criticar quem não escreve seguindo todas as normas.

Para isso há várias soluções, dependendo dos requisitos. O HaavokIPC dá conta destes: chamadas síncronas a funções ou métodos de objetos/classes; uso dos dados retornados através de callbacks; uso em parte da aplicação que não exige alta performance. Ele não usa servidores ou conexões, ele executa o binário do PHP e se comunica com ele através de um arquivo serializado ou persistência. Os objetos responsáveis pela persistência e serialização são plugáveis e novos objetos podem ser desenvolvidos sem perda de tempo, apenas respeitando a interface. Por enquanto estão disponíveis os seguintes objetos de persistência, chamados de Drivers: File, Memcache e Shm, que usam, respectivamente, um arquivo, um servidor do memcache ou shared memory de ambientes *nix. Para a serialização, estão disponívels os Serializers Default, que usa as funções serialize e unserialize nativas do PHP e Msgpack, que usa a extensão msgpack.

Ele foi desenvolvido para ser compatível com boa parte das versões de PHP entre 4 e 5.

A documentação ainda não está madura e há muito a se fazer no código em termos de performance e arquitetura, como todo bom projeto experimental.

O código está disponível no GitHub -> HaavokIPC/PHP

Update 25/11/2011
Estou portando o HaavokIPC para Ruby e isso me obrigou a fazer mudanças na arquitetura, a fim de tornar a configuração e a conversa entre front end e back end mais fácil, seja de PHP para PHP, PHP para Ruby ou de Ruby para PHP. Criei um novo repositório para este port, disponível em HaavokIPC/Ruby. Mais pra frente espero portá-lo para outras linguagens.

Update 30/11/2011
O desenvolvimento do HaavokIPC em Ruby está congelado enquanto trabalho no refactoring da versão em PHP, com alterações mais profundas do que simplesmente tornar sua configuração mais flexível.

Mais importa exibir nosso mundinho cada vez mais fechado em uma vitrine mentirosa.

Doentes.

O lucro de empresas que oferecem conteúdo de auto-ajuda do tipo “conquiste uma parceira” ou “envie seu nome e o nome da sua paixão via SMS para BLABLABLA está alto por causa disso: muitos limites, pouca verdade na hora de gostar de uma pessoa.

O cara encontra alguém dentro do critério que faz parte do “senso comum da sociedade”, digamos “alta, magra, loira, olhos azuis” e por medo de perdê-la, acaba colocando uma máscara e a partir daí, só se relaciona com ela usando essa máscara.

Eu sou muito mais viver com quem eu gosto, tendo a certeza que o máximo que me fez escolhê-la foram preferências (que não são opções, escolhas e muito menos obrigações) e não limitações. É isso que faz um relacionamento respirar e ser confortável enquanto durar.

É isso que me faz ser feliz pra caralho com uma morena gordinha de estatura média e olhos castanhos. Se eu não “tive critério” para ficar com ela, que dirá na hora de reparar em outras mulheres.

Critério reduzindo uma gama de possibilidades de ser feliz? Ah, vá.

Cada um merece o ópio que tem, o vício que agradavelmente o consome, que o faz ser único e que dá o direito de ser distante de quaisquer tendências, inclusive as deste texto.

Eu acho que consegui juntar um pouco do que eu reparei que as pessoas que eu conheço gostam e de certa forma pode ser uma homenagem a quem está na minha vida, que já passou ou que um dia irá embora da minha vida. Um passo no leito do rio, certo ou errado, tropeço ou sorte, tem poder de mudar o curso dele para sempre.

Pensando nisso, tive a idéia de criar um userscript – mais um userscript em uns 3 ou 4 anos brincando com JavaScript no Greasemonkey – que esconde as Pages que não me agradam da minha lista de atualizações do Facebook, sem ter que bloquear ninguém ou ficar ocultando uma por uma. O resultado é o Deorkutizador de Facebook e pode ser baixado do meu repositório através daqui:

https://github.com/MendelGusmao/Userscripts/blob/master/deorkutizador_de_faceboo/deorkutizador_de_faceboo.user.js

As instruções de instalação estão no arquivo. Já adianto que é necessário que a extensão Greasemonkey esteja instalada no Firefox. Também coloquei as instruções para a instalação no Chrome, mas ainda não testei nele.

Copiei o código Me baseei neste artigo chamado How to play nicely with jQuery and Greasemonkey que ensina a como usar o jQuery dentro do Greasemonkey. Considero essencial porque o modo como o jQuery faz para acessar os elementos em uma página tornou a tarefa de encontrar aqueles que contém as atualizações incômodas e removê-los muito fácil. O “Deorkutizador de Facebook” possui uma lista de páginas bloqueadas que é atualizada automaticamente conforme eu encontro as páginas. Essa lista está disponível na minha conta do Dropbox e é carregada sempre que o Facebook for aberto e o script estiver ativado.

http://dl.dropbox.com/s/pn104hbhmqs77fu/paginasBloqueadas.js?dl=1

Para garantir transparência, a mesma lista está sincronizada com o GitHub

https://github.com/MendelGusmao/Deorkutizador-de-Facebook/blob/master/paginasBloqueadas.js

Quem for usuário do GitHub poderá fazer pull requests na lista, sugerindo novas páginas a serem bloqueadas e também “forkar” o script e sugerir modificações.

Essa primeira versão só esconde os históricos, então toda vez que o Facebook for aberto, as publicações estarão lá e em instantes serão ocultas. Estou trabalhando em um jeito de fazer o script “clicar” no botão “Ocultar histórico” automaticamente, assim, na próxima vez o histórico incômodo não estará mais lá de verdade. Ainda há alguns bugs, em especial um que eu apelidei de “só pega no tranco”, porque ele carrega os scripts mas não executa a limpeza, então a página tem que ser recarregada para ele funcionar.

O script é seguro, não incomoda ninguém, não acessa seus dados (muito menos sua senha), não interfere com a sua timeline nem com a de seus amigos e também não faz propaganda no seu mural.

Tchau

Neste ponto, um código de 36 KB (XRegExp + parte da aplicação) já está razoávelmente comprimido, mas não o suficiente para um ambiente com muitas requests: advertising.

A solução encontrada foi compressão pelo servidor com GZip. Otimização, aliás, recomendada no post do Sérgio Lopes e não só por ele!

É uma solução muito eficaz para entrega de conteúdo estático. Se utilizada com cache, então, fica lindo. Mas essa opção não se adequava ao caso, já que o JS era “eventualmente estático” e qualquer alteração das regras impactava no conteúdo do JS, seja modificando o tamanho para mais ou menos, mas, sempre modificando o arquivo. Daí a necessidade de não cachear esses arquivos e garantir que toda alteração feita pelo usuário da plataforma seria imediatamente refletida no script.

Então foi decidido: compressão máxima pelo servidor onde os arquivos JS (um para cada site, cada cliente com vários sites) seriam hospedados. Packer  + Gzip nível 9 – compressão de 36 para menos de 4 KB. Incrível! (~4 KB * clientes * sites * milhões) já parece ser um número bem melhor!

Nesse ponto, fiquei incomodado – mesmo sem ter feito qualquer benchmark – sobre como o servidor responderia tendo que efetuar tantas compressões on-the-fly, sem caching e acabei chegando a uma solução muito, mas muito simples e eficaz:

Para conteúdos estáticos e muito requisitados, não deixe o servidor comprimir durante a requisição. Entregue comprimido.

Sim, isso! Armazenar o arquivo já comprimido! O backend já era responsável por obter as regras, concatenar a XRegExp, as regras e o código que faz tudo funcionar; agora também é responsável por comprimir o JS com GZip. Gastar algum tempo de processamento comprimindo 36 KB (ou mais) em 4 KB? Nunca na requisição, só no momento em que uma regra for modificada ou em algum cron job na madrugada executado por garantia.

E o servidor?

A não ser que ele seja instruído a não fazer isso, e manter a compressão habilitada para tudo, ele vai comprimir o que já foi comprimido. Então, aqui está o maior truque disso tudo:  configurar o servidor para caso uma request peça por um arquivo armazenado em determinado diretório, deixe a compressão e envie uma header Content-Encoding: gzip.

E aquele browser que não tem suporte a gzip?

Não pode entregar como gzip. Excepcionalmente, o backend também trata de gerar os scripts somente com a compressão do Packer. Nesse caso, usar cache é importante, porque uma parcela de usuários receberá um arquivo um pouco maior que os outros e é importante não deixar a performance do servidor ser impactada por isso.

Usamos  o Lighttpd e foi muito fácil configurá-lo para agir assim. Para caching, o escolhido foi o Varnish, mas como não fui responsável pela configuração, não posso dar detalhes.

O conceito mais importante dessa parte do post não se aplica ao JS ou ao comportamento da aplicação, mas do servidor. A idéia de entregar conteúdo já comprimido ao invés de utizar compressão on-the-fly se aplica a qualquer tipo de conteúdo que não seja interessante, do ponto de vista da performance, de ser entregue através de métodos específicos de caching. E a conclusão é de que isso não é mais do que um método alternativo de caching.

Considerei a abordagem de usar caching mais forte, separando a XRegExp, com um tempo de cache maior, enquanto as regras e o código ficariam com um tempo menor de cache. Mas aí não seria tão “emocionante” e se por algum motivo a XRegExp não fosse carregada, a aplicação não funcionaria.

Concluído o projeto, me desliguei da empresa com uma proposta mais interessante, deixando uma documentação bastante forte sobre essas idéias. Preciso dar uma olhada nos sites dos clientes para ver se eles já estão utilizando tal aplicação!

Em uma empresa onde trabalhei no ano passado, tive que desenvolver um código JS que usa uma biblioteca adicional, XRegExp, para named capture em expressões regulares. Juntando essa biblioteca e meu código, o tamanho total ficava em cerca de 36 KB – no mínimo, já que o código era modificado por variáveis que o cliente da plataforma poderia configurar. A projeção de hits no servidor solicitando um JS era da ordem de milhões por mês, dado que é uma plataforma de advertising. Considerando que cada site deve incluir esse JS e um cliente tem vários sites: (+36 KB * clientes * sites * milhões): não resulta em um número muito bom.

* Detalhe importante: o JS não é totalmente estático. Caso o cliente da plataforma modificasse uma regra, ela teria que ser imediatamente aplicada ao JS, logo, não poderia ficar muito tempo em cache do usuário. O jeito encontrado foi servir sem cache e com o máximo possível de compressão.

Há 3 anos eu conheci o Packer, um compactador de JavaScript que é bastante utilizado por frameworks JS e módulos de pipelining em frameworks web – detalhe que na época eu o conheci através de um código malicioso e como eu queria saber o que o código estava fazendo, então tive que estudar a forma como ele era compactado e o que significava aquela function(p,a,c,k,e,r) no começo do arquivo. Ele tem muito valor e utilidade em ambientes onde você precisa fazer entrega de conteúdo com eficiência.

Ele não é tão simples como outros códigos que eliminam comentários, espaços, tabs, pontos-e-vírgulas duplicados, quebras de linha, deixando a estrutura básica da linguagem para que o código seja funcional. Ele faz bem mais que isso. Explico agora:

- O Packer parseia seu código JS, fazendo tudo o que eu descrevi ali em cima e também separa cada palavra-chave ou valor, montando um array* de strings.
- Cada palavra armazenada no array possui um índice numérico e esse índice é usado como referência no código que o Packer gera.
- O Packer cria um wrapper, que é a função anônima (p,a,c,k,e,r), responsável por descompactar o código gerado, buscar as referências no array e remontar o código, substituindo as referências pelos valores respectivos, terminando com um eval() para interpretar o código remontado.
- Como as referências são únicas e as strings usadas para descrevê-las são pequenas, muitas vezes usando números de base 62 – dependendo da configuração, o código gerado é bastante econômico e sucinto.

* Este array de strings é na verdade uma string só, com seus valores delimitados por pipes

Vou dar um exemplo bem simples de como o packer vai montar um o código compactado:

function stack_messages(strings) {
var i = 0;
for (i = 0; i < strings.length(); i++) {
var message = “Annoying message #” + i + “: ” + strings[i]“;
alert(message);
}
}

Esse é o “array” de palavras úteis que o Packer gerou após fazer o parsing:

‘|i|var|function|stack_messages|for|length|Annoying|message|alert||’

E gerar o seguinte código:

’3 4(a){2 1=0;5(1=0;1<a.6();1++){2 b=”7 8 #”+1+”: “+a[1]“;9(b)}}’

Não parece, mas esta é a função stack_messages. Ignorando chaves, pontos-e-vírgulas, parênteses e outros símbolos que obviamente não podem ser reduzidos, é possível entender que que: a referência 3 corresponde ao índice 3 no “array”, que quer dizer “function”. A referência de número 4 é “stack_messages”. Isso é só pra começar.

Note algo interessante: palavras que foram utilizadas várias vezes no código, como var, message e i só aparecem uma vez no array. Elas possuem as referências 2, 8 e 1, respectivamente.

’3 4(a){2 1=0;5(1=0;1<a.6();1++){2 b=”7 8 #”+1+”: “+a[1]“;9(b)}}’

Trocando de 1 a 7 caracteres por 1 só. Inteligente demais, não?

* Não entendi o porque da palavra message ter duas referências, 8 e b, mas assim que descobrir, atualizo o post.

Não vou me aprofundar nos detalhes do algoritmo de descompressão do Packer, mas por cima é possível notar que:

- È um algoritmo iterativo: o único código que roda imediatamente é ele e o código desenvolvido por você não vai rodar até que ele tenha iterado o array de palavras úteis e transformado o código traduzido em código válido para ser interpretado com eval(). A velocidade com a qual ele roda depende bastante da velocidade da máquina e do browser de seu cliente.
- Não é bom para códigos pequenos. O overhead causado pela função de descompressão não compensa o trabalho da compressão.
- Concatene todos os arquivos JS que sua página necessita através de um pipeliner antes de comprimir com o Packer. Isso faz com que o tamanho do array de palavras úteis seja menor e centralizado. No caso de frameworks e bibliotecas de terceiros, escolha as versões non-minified e non-packed. O ideal é não judiar do forçar o browser do seu cliente a executar o descompactador do Packer mais de uma vez, seja em cada arquivo, seja em “compressão em cima de compressão”, como um código packed passando novamente pelo Packer.

Nesse ponto, meu código (XRegExp + minha aplicação) já está “minified” com o Packer, mas ainda está pesado para o cenário de milhões de requests. Vou explicar na parte 2 como o servidor foi otimizado para servir arquivos com compressão.

Mas agora quero brincar um pouco com Android e achei que seguir esse pequeno curso do The Code Bakers seria um bom começo. E um dos requisitos, porém, é o uso do Eclipse. Justificável, dada a facilidade do emulador e a minha preguiça de procurar métodos alternativos enquanto estou brincando.

Parece que a última versão do Eclipse disponível no repositório oficial do Ubuntu é a Galileo/3.5. Talvez porque a 3.6 não seja estável nas versões mais recentes do sistema operacional. Fato é que eu não gosto de usar software desatualizado, salvo sobre meu Windows – XP – e um driver da Nvidia cuja última versão fazia o sistema dar memory dumps nas tarefas mais simples.

Alguns sites aconselham a alterar os endereços de repositórios do Eclipse mas não funcionou comigo. A solução foi usar o PPA da Eclipse Team que felizmente voltou a ser atualizado. Mão na massa:

sudo apt-key adv –recv-keys –keyserver keyserver.ubuntu.com 5126890CDCC7AFE0
sudo add-apt-repository ppa:eclipse-team/debian-package
sudo apt-get install libswt-gtk-3.6-java eclipse

Adicionei libswt-gtk-3.6-java à instalação porque o Eclipse não abriu sem essa dependência e o arquivo ~/workspace/.metadata/.log exibia um erro mencionando-a.

Enjoy your new Eclipse!

* Observação: descobri que o Android Development Tools é incompatível com o Eclipse 3.6. Se sua pretensão é usar o ADT, continue com o Eclipse 3.5.

Fico feliz por ter mais uma opção na minha viagem cruzando São Paulo no meu transporte de Guarulhos até a Berrini, onde trabalho, além da ponte ORCA da Vila Madalena/Cidade Universitária e dos trens da Barra Funda/Altino. Da primeira vez foi uma decisão de última hora: na segunda-feira da inauguração da estação Pinheiros, indo da Paraíso para a Vila Madalena, decidi descer na Consolação e logo vi não foi uma boa idéia: era dia de inauguração e na saída principal estavam manifestantes, jornalistas, empresários e políticos  reunidos na porta. Uma muvuca só.

Detalhe importante: as estações são bem fundas. Na Consolação, por exemplo, existem duas esteiras e duas escadas rolantes até a plataforma de embarque. Em Pinheiros são 4 lances de escadas rolantes até a saída principal. Para usar a integração com a estação Pinheiros da CPTM, há mais uma escada rolante até a passarela. Prato cheio para quem curte andar de metrô e no metrô.

A integração entre Pinheiros da CPTM e Pinheiros do Metrô só começa no mês que vem, já que a passarela que liga elas não está pronta, assim, é necessário andar cerca de 400 metros entre as estações, passando pelo entorno do canteiro de obras do que será um terminal de ônibus em 2012 e pagar novamente 2,90 ao passar pela catraca.

É nesse ponto que eu vejo problemas de planejamento. Ainda que a necessidade de pagar nova tarifa seja temporária, eu acho que é ilegal. O governo bem que poderia implantar um esquema similar ao utilizado na ponte ORCA, em que você adquire gratuitamente um cupom que garante que ao chegar na outra estação – em uma van ou microônibus ORCA – você não terá que pagar novamente a tarifa. Oras, era só colocar as máquinas que emitem os cupons entre as estações. A diferença é que não é preciso pegar uma van. Custo irrisório para o governo e um consórcio que entregaram uma obra importante com 10 anos de atraso e claro, garantia do bem estar do cidadão.

Outro ponto que me incomoda é que os novos trens e as plataformas de embarque das estações da linha amarela são minúsculos. Menor do que estas plataformas, só a plataforma da estação Paraíso sentido Vila Prudente. Não sou um especialista, mas acredito que aquilo não tenha sido bem planejado, com números e projeções reais do volume de pessoas que vão utilizar a linha. A falta de espaço faz parecer que a linha só será usada pela “elite” que reside em Pinheiros, Morumbi e Jardins. Soa inapropriado, já que é fato que São Paulo necessita urgentemente de mais linhas de metrô e as novas estações já são inauguradas com uma quantidade considerável de usuários. Lotadas.

Bônus: mapa do metrô de São Paulo para ser visualizado no Google Earth. Linhas atuais do metrô e da CPTM, linhas em projeto e até algumas linhas imaginárias que nossos filhos e netos poderão usar muito bem, se o Governo do Estado de São Paulo trabalhar com um pouco mais de boa vontade: http://migre.me/4Dp34