GARTZ http://gartz.com.br Desenvolvimento, TI e outras coisas nerds Fri, 11 Apr 2014 18:35:10 +0000 pt-BR hourly 1 http://wordpress.org/?v=3.8.2 KohanaCV, curriculum em PHP http://gartz.com.br/kohanacv-curriculum-em-php/ http://gartz.com.br/kohanacv-curriculum-em-php/#comments Sun, 09 Mar 2014 02:30:45 +0000 http://gartz.com.br/?p=363 Em 2008 eu senti a necessidade de fazer um novo Curriculum, afinal eu estava ingressando no mundo dos empregos com carteira assinada. Em algumas horas converti um curriculum que tinha feito no Libre Office para HTML, em seguida para facilitar a manutenção e mesmo poder fazer algo com Kohana Framework 3.x fiz um pequeno aplicativo que até hoje uso como CV online.

Desde então o link http://curriculum.gartz.com.br está disponível e já me rendeu alguns contatos de empresas brasileiras e do mundo a fora.

Na época eu hospedava meus sites em um servidor que eu fazia leasing, neste tinha também todo um sistema integrado com Redmine e git (via gitolite), onde eu hospedava os meus projetos privados ou aqueles que eu ainda não queria liberar o código pois achava que eram muito incompletos para expor no github.

Hoje eu estou com 2 servidores, um para os sites, que ficam no Brasil, pela empresa Kinghost e outro que é um VPS no EUA fornecido pela Hivelocity. Mas nunca mais re-fiz minha estrutura com Redmine e gitolite, agora o servidor no EUA cuida de um CDN, projetos em nodejs como o Damas Online baseado no DraghtsJS e outras micro-tarefas.

Bom, espero que este código ajude outros programadores que querem se expor para o mundo de forma independente de linkedin.

]]>
http://gartz.com.br/kohanacv-curriculum-em-php/feed/ 0
Como adicionar Google Analitcs em um repositório do Github ou email http://gartz.com.br/como-adicionar-google-analitcs-em-um-repositorio-do-github-ou-email/ http://gartz.com.br/como-adicionar-google-analitcs-em-um-repositorio-do-github-ou-email/#comments Mon, 03 Mar 2014 04:49:06 +0000 http://gartz.com.br/?p=364 Você publicou um projeto no Github ou enviou um email em massa e agora não tem a menor ideia se outras pessoas estão acessando ou não? Se você usa Google Analytics seus problemas acabaram, com projeto ga-beacon você poderá ter uma visão (limitada) de quem está acessando seus projetos e emails de forma muito simples!

Sobre o projeto

O Google Analytics Beacon (ga-beacon) é um projeto criado Ilya Grigorik, funcionário da Google, tem como foco permitir que o Google Analytics possa funcionar em locais onde você não tem como colocar um Javascript no código fonte.

Claro que o uso desta ferramenta limita o rastreamento de acesso, porém é muito interessante para tirar você do escuro total e ver se seus projetos no github ou emails estão sendo visitados.

O projeto ga-beacon tem seu código fonte aberto, então se você quiser montar seu próprio servidor e não utilizar o oficial hospedado no Google App Engine.

Esta matéria vai limitar-se a lhe ajudar a usar o servidor já disponível.

Você vai precisar de

… uma conta no Google Analytics, se você não fez ainda, este é um bom momento.

Então você precisa criar uma “Propriedade“, Pra isso use a Administrador, crie sua Conta e uma Propriedade.

Criando nova proripedade no GA

Criando nova proripedade no GA

Se você está confuso, basta clicar na lista abaixo do nome e em “Criar nova (conta ou propriedade)“.

Repare que suas propriedades tem um ID, por exemplo: UA-12345678-9.

E só isso já te permite utilizar o ga-beacon.

Uma dica, na hora de criar a Propriedade, crie por exemplo como “Github Projects” ou “Projetos do Github”, caso seja pra monitorar emails, você pode criar uma propriedade “Mass mails” ou “Emails em massa”, o nome serve para organizar as suas estatísticas. Mas durante as configurações você poderá identificar a página de origem do acesso, caso tenha vários projetos, pra não precisar criar uma propriedade por projeto.

Instruções de uso

Como já foi dito, o ga-beacon vai adicionar a possibilidade de adicionar uma imagem com uma URL qual vai fazer a tarefa de registrar o acesso na sua conta do Google Analytics. E para isso a imagem vai ter um endereço personalizado.

  • https://ga-beacon.appspot.com/UA-XXXXX-X/seu-repositorio/pagina
  • UA-XXXXX-X deverá ser seu ID de rastreamento do Google Analytics
  • seu-repositorio/pagina é uma identificação que vai aparecer nos seus relatórios como página visitada, se está colocando no github, vai ficar normalmente como seu-repositorio/readme ou seu-repositorio/pagina-da-wiki

Exemplo pra usar o rastreador em um arquivo de Markdown:

[![Analytics](https://ga-beacon.appspot.com/UA-XXXXX-X/seu-repositorio/pagina)](https://github.com/igrigorik/ga-beacon)

Ou pra RDoc:

{<img src="https://ga-beacon.appspot.com/UA-XXXXX-X/seu-repositorio/pagina" />}[https://github.com/igrigorik/ga-beacon]

Você ainda pode não adicionar a imagem do badge incluindo no fim da URL o parametro ?pixel

Exemplo:

<img src="https://ga-beacon.appspot.com/UA-XXXXX-X/seu-repositorio/pagina?pixel" />

Conclusão

É muito simples e útil esta ferramenta pra monitorar os acessos dos seus projetos, em questão de minutos você poderá configurar e começar a monitorar.

Eu acho muito legal manter o link no badge para o projeto original, de forma incentivar e informar as pessoas que acessam seus projetos, para que eles também possam um dia passar a usar a ferramenta, boas ideias devem ser reconhecidas e compartilhadas.

E usando isso me lembrei de que a alguns anos atras eu utilizei um recurso parecido para descobrir dados de quem acessava meu falecido Orkut, colocando uma imagem em um servidor remoto e que no caso do Orkut você podia adicionar a referencia remota da imagem e quem acessava baixava a imagem do seu servidor, por fim acabava fornecendo o IP e mais alguns dados vindos pela requisição do browser. Muito parecido com o que esta ferramenta faz para informar seu Google Analytics de quem e quando alguém está acessando sua página. Nostalgias a parte, espero que gostem da ferramenta.

]]>
http://gartz.com.br/como-adicionar-google-analitcs-em-um-repositorio-do-github-ou-email/feed/ 0
Instalando Cloud9 local com suporte a RunJS no Linux http://gartz.com.br/instalando-cloud9-local-com-suporte-a-runjs-no-linux/ http://gartz.com.br/instalando-cloud9-local-com-suporte-a-runjs-no-linux/#comments Mon, 23 Sep 2013 00:31:48 +0000 http://gartz.com.br/?p=336 Cloude9 é uma ferramenta muito boa pra desenvolvimento, tanto para se ter em casa, quanto em um servidor da empresa para trabalho em equipe. Porém quando vamos instalar ele, costumamos passar por um pouco de dor de cabeça, portanto, hoje vou ajudar quem tem interesse em montar seu servidor doméstico de Cloud9 no linux.

ISATNeste “tutorial” explicarei como instalar seu próprio servidor, vou dar algumas dicas de customização e por fim como iniciar seu servidor com workbranch. A partir disso, você pode montar outras aplicações como scripts de inicialização dos seus projetos, ou como o projeto ISAT que eu fiz na Cianet, o qual os desenvolvedores podem, através de um arquivo JSON, identificar quais servidores/porta de Cloud9 querem iniciar. Por fim, ainda é possível colocar um reverse-proxy em nginx (por exemplo) com DNS interno na sua rede para colocar o nome dos seus desenvolvedores apontando para seus ambientes. Mas neste tutorial vou explicar a parte do Cloud9 apenas.

A foto  direita é um exemplo de como ficou no projeto ISAT a inicialização dos serviços. Você pode continuar deste tutorial e fazer seu próprio projeto para ter o ambiente de desenvolvimento remoto da forma que melhor lhe satisfazer.

Eu não sei se é possível instalar o Cloud9 no Windows, eu nunca tentei e espero que nunca ninguém faça um pedido desses pra mim. Então vamos nos ater ao Linux e esse tutorial serve para qualquer distro de linux que você esteja usando.

Não será necessário ter o Node.js instalado no seu Linux, mas se você já tem, não se preocupe, este tutorial vai ensinar como instalar uma versão independente que rode apenas para o Cloud9 e RunJS sem criar conflitos com a versão que você tem instalada.

Projetos que você vai precisar

Ainda será necessário ter instalado o GCC e é claro o GIT, os outros eu vou ensinar a instalar durante o tutorial.

Instalando o GCC e GIT:

# Distros baseadas em Red Hat yum install git gcc -y # Distros baseadas em Debian apt-get install git gcc -y

Instalando Cloud9

Neste exemplo vou instalar o Cloud9 direto na pasta home do meu usuário, Vai ficar assim:

cd ~/ git clone https://github.com/ajaxorg/cloud9.git cd cloud9

Para continuar vamos precisar do Node na versão 0.8.x, até o Cloud9 v2.0.93 era necessário a versão 0.8.x por causa do node-waf que deixou de existir nas versões >= 0.9.x do Node

Instalando Node 8x

Considerando que você ainda está na pasta do Cloud9, é aqui mesmo que vamos clonar o Node, para deixar mais claro vamos chamar a pasta de Node8, assim ficará mais fácil de lembrar de não compilar versões posteriores a 8 aqui.

git clone https://github.com/joyent/node.git node8 cd node8 git checkout v0.8 ./configure --prefix=~/cloud9/node8 make make install

É bom ressaltar que estou considerando a instalação na sua pasta de usuário, dentro da pasta do cloud9, se você instalou em um local diferente, altere o “–prefix=” como desejar.

No make install, não vai ser necessário ser root, pois você está instalando apenas para o seu usuário.

Instalando dependencias do Cloud9

Voltando a pasta do cloud9, devemos instalar suas dependencias usando o node8:

cd ~/cloud9 PATH=./node8/bin:$PATH npm install

Para testar se sua instalação funcionou, na pasta do cloud9 digite:

./node8/bin/node server.js

cloud9-console-initSe abrir o servidor em localhost na porta 3131 (http://localhost:3131) e seu console exibir algo igual a imagem a direita, é porque foi instalado corretamente e está funcionando. Caso contrário, ele vai disparar alguma mensagem de erro durante a inicialização ou quando você tentar abrir pelo browser o endereço. Nestes casos você pode tentar descobrir qual é o erro e corrigi-lo ou simplismente recomeçar o processo todo.

Instalando RunJS

O RunJS é uma ferramenta que foi feita pela própria equipe do Cloud9 e é usada internamente para manter os serviços das instancias do cloud9 rodando mesmo quando dão algum erro e este faz a aplicação parar. No caso o runjs vai reiniciar a aplicação com os parametros iniciais sempre que ela parar por qualquer motivo que não seja um kill via runjs.

Sabendo disso vamos instalar o runjs, até a versão 2.0.93 o runjs ficava na pasta node_modules/runjs porém não existe referencia pra ele no arquivo package.json, então ele não é instalado automáticamente.

Por causa disso, eu decidi que era melhor não instalar este na pasta “correta” mas sim utiliza-lo fora do node_modules, pois ele não é um modulo oficial e também porque na branch master do cloud9 eles removeram o link simbolico pro runjs (não sei porque).

Então vamos colocar o runjs direto dentro da pasta do cloud9, como fizemos com o node8, dentro da pasta do cloud9 seguem os comandos:

cd ~/cloud9 git clone https://github.com/c9/runjs.git

Apesar do README do runjs recomendar o uso da versão estável, estou usando a Master, pois funcionou direitinho, mas não acabou ai, temos agora que compilar o arquivo watcher.

cd runjs gcc watcher.c -o watcher -v chmod 0550 watcher

runjs-ok

Por fim teste o seu runjs, se estiver tudo OK, ele simplismente vai dizer que não há processos rodando.

./runjs

Quando você não compila o watcher, ele tenta compilar, mas é normal ele não achar o GCC no seu enviroment e falhar. E outra coisa que acontece as vezes a permissão do CHMOD estar errada e o watcher não consegui acessar os processos, se você seguir do jeito que eu expliquei provavalmente não passará por essas dificuldades.

Iniciando o seu Cloud9 com o runjs

Agora que você tem o cloud9 e o runjs funcionando, você precisa inicia-lo usando o runjs, se você usar a versão do seu nodejs e essa não for mais nova que 0.8 isso poderia ser uma dor de cabeça, então vou ajuda-lo a modificar os arquivos necessários pra usar o runjs.

Pra começar vamos vamos criar o link simbólico (ou alterar caso exista) pro runjs na pasta bin:

cd ~/cloud9/bin rm run.js ln -s ../runjs/runjs run.js

No arquivo “runjs.sh” na mesma pasta, vamos remover o comando como super usuário na linha 7:

  1. sudo bin/run.js panic

Ficará:

  1. bin/run.js panic

Agora vamos mudar o run.js para executar usando o seu node8 em vez do node global, editando este arquivo na sua primeira linha:

  1. #!/usr/bin/env node

Ficará (substitua usuario pelo nome de usuário, uma dica é ir na pasta do node8 e escrever pwd pra saber o endereço completo dela):

  1. #!/usr/bin/env /home/usuario/cloud9/node8/bin/node

Vamos testar, tente executar com runjs agora:

cd ~/cloud9/bin ./runjs.sh

Se funcionou seu cloud9 estará novamente funcionando (lembre de fechar aquela instancia de teste antes de fazer isso).

Você pode monitorar o que está acontecendo com seu Cloud9 com seguinte comando (ainda na mesma pasta):

./run.js tail c9

Se quiser fechar seu Cloud9 execute:

./run.js kill c9

Para abrir em uma outra pasta de projeto, você pode especificar o parametro -w, como no exemplo:

./runjs.sh -w ~/meu_projeto

BONUS: Resolvendo bug com Sessionid

Esse bug é muito conhecido e comentado, mas o pessoal que desenvolve o Cloud9 não da muita atenção pra ele, até porque é um problema de um plugin chamado connect.archect

Este plugin tem algum problema que faz ele não conseguir sobrescrever ou ler arquivos na pasta .session que ele mesmo gera, então ele dispara o erro e é bem chatinho, pois quando acontece você tem que dar refresh no browser e se ele fica se repetindo, da vontade de desistir da IDE…

Então pra resolver esse bug que é relacionado a sistema de arquivos, da pra configurar pra o Cloud9 usar o gerenciamente de sessões na memória.

No arquivo “config/default.js” mais ou menos entre as linhas 160 e 180 tem este código:

  1.    {
  2.         packagePath: "./connect.session.file",
  3.         sessionsPath: __dirname + "/../.sessions",
  4.         maxAge: 7 * 24 * 60 * 60 * 1000
  5.     },

Substituindo file por memory, você passa a usar a memória no lugar do sistema de arquivos:

  1.    {
  2.         packagePath: "./connect.session.memory",
  3.         sessionsPath: __dirname + "/../.sessions",
  4.         maxAge: 7 * 24 * 60 * 60 * 1000
  5.     },

Problema resolvido!

]]>
http://gartz.com.br/instalando-cloud9-local-com-suporte-a-runjs-no-linux/feed/ 1
HTML5 + Bomberman = Bombermine http://gartz.com.br/html5-bomberman-bombermine/ http://gartz.com.br/html5-bomberman-bombermine/#comments Sat, 02 Mar 2013 12:32:23 +0000 http://gartz.com.br/?p=315 Um pessoal teve uma ideia brilhante, que foi juntar as possibilidades do HTML5 com o famoso game dos anos 80 Bomberman e o resultado pode ser visto no site www.bombermine.com que irá rodar em qualquer browser moderno.

Dando uma olhada no código fonte do projeto, pude ver alguns detalhes interessantes, como o uso de WebSockets, renderização com WebGL, técnicas de qualidade de código usando jshint e várias libs conhecidas:

  • jQuery 1.9.x – Compatibilidade cross-browser
  • Moment.js – Manipulação de datas
  • Underscore.js – Kit de utilitários para Array, Objects e outros
  • AngularJS – Framework com Model, Template, Controllers, Routes e outros recursos

Apesar do site não ostentar muitas informações, no código é possível reparar apontamentos a outro domínio com sufixo .ru o que indica que o pessoal que produziu esse game é Russo, apesar da latência, cerca de 330ms aqui para o Brasil, o jogo continua sendo muito divertido de se jogar e a sensação de lag, apesar de perceptível, não chega a incomodar.

A organização dos arquivos é bacana, o projeto ainda não está com todo seu código minificado, então quem quiser dar uma olhada no client-side do projeto, é um bom momento. Ainda mais porque ele está bem organizado, eles evitam bastante utilização de globais encapsulando seus códigos em funções auto-executáveis, a unica propriedade adicionada ao global é uma chamada “game”, que segue as premissas do AngularJS.

O “core” do jogo foi feito com GWT, está em um arquivo minificado e otimizado. Como seu nome indica, ele não permite cache, pois o jogo vem sendo constantemente atualizado e provavelmente seus autores também não querem que este resida no computador dos usuários.

Em contato com o responsável pelo projeto por email, eles dizem reconhecer uma grande comunidade brasileira acessando o jogo e já tem planos para servidores no Brasil.

]]>
http://gartz.com.br/html5-bomberman-bombermine/feed/ 1
Hatters gonna hate http://gartz.com.br/hatters-gonna-hate/ http://gartz.com.br/hatters-gonna-hate/#comments Tue, 19 Feb 2013 03:53:06 +0000 http://gartz.com.br/?p=292 Bill Gates vs Steve Jobs… Ou nenhum?!?

 

]]>
http://gartz.com.br/hatters-gonna-hate/feed/ 1
Browser modernos, plugins, extensões e segurança http://gartz.com.br/browser-modernos-plugins-extensoes-e-seguranca/ http://gartz.com.br/browser-modernos-plugins-extensoes-e-seguranca/#comments Mon, 18 Feb 2013 01:38:14 +0000 http://gartz.com.br/?p=274 Browsers modernos com suporte a uma infinidade de plugins e extensões que comprometem a segurança do usuário, seria um bom momento para uma API genérica para podermos ter mais controle sobre esses terceiros rodando junto do nosso web app?

Não é de hoje que os Browsers dão suporte a uma infinidade de plugins e extensões. Em dado momento, os browsers começaram a se integrar com softwares de terceiros, para dar suporte as tecnologias não nativas no DOM, tínhamos os Java Applets, Shockwave, logo veio o Flash e com o passar do tempo, surgiram novas possibilidades, barras customizadas, botões, plugins que liam o DOM e alteravam em tempo real para personalizar sites e permitir funcionalidades como integração com gerenciadores de download que permitiam continuar o download mesmo caso este fosse interrompido.

Com tanta novidade boa, também surgiram as ruins. Sites que instalavam seus plugins sem pedir permissão para usuário, plugins que vinham com programas terceiros que mudavam a forma como o browser funcionava e a coisa foi piorando, virus, trojans, worms e todo tipo de malware.

O Google Chrome quando saiu, não tinha suporte a plugins e extensões, queriam HTML5 puro, mas isso não deu muito certo, logo tiveram que adicionar suporte a Flash, Java Applets e todos outros, tentaram melhorar o Flash embutindo-o de forma gerenciar via sandbox para contornar possíveis falhas, não foram soluções práticas, acabaram adicionando API’s para que desenvolvedores pudessem adicionar e remover plugins, como já existia no Firefox e no Internet Explorer, porém tentaram fornecer o máximo de segurança, e nessa corrida de gato e rato, as melhores soluções não costumam durar muito tempo sem que brechas sejam encontradas e exploradas.

Inovando novamente o Chrome colocou extensões de código aberto dos desenvolvedores em “sandbox” com recursos limitados que em teoria não poderiam afetar o usuário, mas isso não é uma verdade absoluta apesar dos esforços, contanto com melhorias na segurança que o artificio trouxe pro Chrome, o Firefox seguiu o mesmo caminho e ainda hoje em ambos você pode vir instalar extensões que vão encher suas páginas de propagandas de terceiros e monitorar sua navegação sem você ser avisado.

Fazendo uma busca rápida sobre “falha de segurança java”, ou mesmo flash, serão páginas e mais páginas de notícias dizendo que você está em risco. Vão lhe ensinar a desativar o Java, ou Flash do seu browser e se você usa algum site de banco brasileiro, vai precisar do Java ativo para poder acessar.

Não espero que os bancos desativem a necessidade do Java no browser, pessoalmente acho uma péssima solução usá-lo, mas parece que para bancos a internet ainda é um campo muito obscuro, cheio de obstáculos e periculosidades pouco compreendidas por seus analistas e engenheiros de sistema. E ai eles utilizam o recurso que te coloca em risco, para te assegurar de que ninguém vai roubar sua senha ou manipular o site deles de forma invisível ao usuário.

A W3C e as restrições no Javascript tentam lhe proteger ao máximo, não permitindo que sites de diferentes domínios sejam manipulados, criando restrições no carregamento de scripts e outras tarefas. É possível até se listar os plugins disponíveis no browser usando API “navigator.plugins” disponível nos browsers modernos.

Mas já está na hora de podermos fazer mais que listar plugins, deveriam colocar na mão dos desenvolvedores a possibilidade de bloquear/desativar plugins. Afinal, no meu site eu não uso flash, java ou plugins de vídeo que não sejam h264 ou webm, então se algum desses plugins estiver ativo no meu site em quanto o usuário navega, isso é uma anomalia. Para dar mais segurança ao meu usuário, eu gostaria de poder desativa-los.

E eu disse que você não pode de um domínio manipular em um frame ou window código de outro site, mas se for uma extensão no seu browser, ai pode sim. E isso é um problema, pois as extensões são permissivas o suficiente pra se esconder parte delas em códigos externos (sites) que podem conter malwares onde na validação feita pelas empresas na hora de colocar essas extensões disponíveis como seguras em seus sites (Mozilla plugins, Chrome Store, etc) passam como seguras, porém o desenvolvedor pode torna-las inseguras a qualquer momento.

Hoje o seu browser já pede permissão para que o site possa deixar a tela em fullscreen, ainda é um rascunho da API do HTML5, mas uma boa maneira de proteger o usuário de sites maliciosos. Que tal pedir permissão para usar certos plugins e extensões caso o site tenha um “black list” que gostaria de impedir acesso dos mesmos, deixando claro pro usuário o risco que ele está correndo ao usar esses recursos.

Uma janela dizendo “Este site solicita sua permissão para desativar os seguintes recursos: (uma lista com os plugins e extensões)”, lista contendo todos plugins e extensões que foram registrados como desnecessários ou nocivos ao site pelo próprio desenvolvedor.

Desta maneira, se o usuário estiver com seu Java Applet infectado, ou uma extensão do browser já conhecida como problemática pelo site, estas serão informadas ao usuário na hora do acesso, podendo seletivamente para o site serem desativadas na sessão ou permanentemente. Tornando a navegação do usuário mais segura e possivelmente mais agradável no site.

Quanto a ativação e uso dos plugins, acho interessante a maneira que os browsers já fazem, com questão de permitir que o usuário escolha a forma com que esses plugins poderão ser requisitadas pelo site. O que falta realmente é uma API para bloquear plugins e extensões indesejáveis.

Será que poderíamos ajudar a proteger nossos visitantes leigos, que não sabem sequer o que é ou que faz os Java Applets e o Flash?

Espero que essa ideia seja transmitida adiante, lapidada e quem sabe um dia nos desenvolvedores possamos ter mais autonomia na hora de proteger nossos visitantes.

Pra finalizar, lembro que anti-virus também usam de plugins e extensões de forma extremamente intrusiva para proteger seus usuários, até onde uma API com tal controle em mãos do usuário tornaria outras ferramentas de proteção ineficazes? Como usuário de Linux, não vejo isso como um obstáculo, mas acho que pra quem usa Windows pode se tornar quem sabe mais um problema.

Notícias relacionadas

19/02/2013 - Extensão para Chrome rouba “Likes” do Facebook para cibercriminosos

20/02/2013 - Este site inocente causou os ataques à Apple e ao Facebook

22/02/2013 – Apple também foi hackeada devido a falha no Java

]]>
http://gartz.com.br/browser-modernos-plugins-extensoes-e-seguranca/feed/ 1
Testes de desempenho para Javascript com jsPerf http://gartz.com.br/testes-de-desempenho-para-javascript-com-jsperf/ http://gartz.com.br/testes-de-desempenho-para-javascript-com-jsperf/#comments Sun, 10 Feb 2013 16:00:53 +0000 http://gartz.com.br/?p=127 Na hora de desenvolver um projeto em Javascript, é importante ter em mente o objetivo do mesmo, o foco e a forma que ele deverá se comportar no futuro.

Quando falamos de alto desempenho em Javascript, não estamos apenas falando de trabalhar com bons algoritmos, devido às possibilidades diferentes de implementação que a linguagem permite, também estamos falando de padrões de código.

Uma ferramenta muito útil nos dias de hoje é o jsPerf que permite fazer benchmarks (testes de desempenho) com diferentes implementações e browsers. A ferramenta é incompatível com alguns browsers, então se você está trabalhando com um dispositivo móvel ou uma compilação antiga do webkit, é provável que você não consiga usar todos recursos da ferramenta.

Navegando pela lista de testes do jsPerf é possível achar vários testes interessantes. E mesmo assim sempre me deparo com testes terrivelmente mal construídos, acontece por descuido, mas também por falta de conhecimento de como utilizar a ferramenta, pode-se até afirmar que a maioria dos testes estão quebrados e foi isso que me motivou a escrever este artigo. Quero ajudar aqueles pretendem extrair o melhor de seus códigos e aprender com as possibilidades que o Javascript lhes propicia.

Qual o melhor algoritmo afinal?

É uma questão muito difícil de responder, vai depender do browser, do motor que vai processar, pré-processar, pré-otimizar/pré-compilar antes de processar seu código e por fim ainda dependerá do hardware utilizado e em alguns casos mais raros, da forma em que este prioriza I/O (Interfaces humanas, bases de dados, DOM, temporizadores, Workers, XHR e por ai vai).

Aí vem a pergunta, se é tão complicado avaliar, então tanto faz? Não!

Na hora de escolher seu algoritmo tenha foco. Se um browser tiver muito desempenho em determinada opção e outros podem até ser piores, porém são resultados aceitáveis, opte pela opção do browser que te deu melhor desempenho. É possível, e provável, que com a corrida dos browsers os outros venham aprimorar seus motores para igualar-se.

Quando os browsers destoarem muito os resultados, escolha a média, sempre tendendo aos motores mais novos.

Quando teste for inconclusivo

Neste caso, escolha a melhor escrita, evite escrever códigos muito complexos para ganhar apenas um pouquinho de desempenho, quando uma escrita mais legível poderia ser suficiente para um desempenho aceitável.

Criando testes

Vamos falar dos campos do jsPerf. E logo quando você entra no site, este lhe pede nome, email e url. É opcional, mas é uma ótima maneira de encontrar novamente seus testes.

Os testes dos usuários ficam em http://jsperf.com/browse/usuario onde usuário é seu nome, removendo caracteres não alfanumérico e substituindo espaço por hífen. No meu caso (Gabriel R. Giannattasio): http://jsperf.com/browse/gabriel-r-giannattasio

Mas nada mais importante que um bom titulo e descrição para que você e outros desenvolvedores possam se beneficiar dos seus testes.

Preparando código

Existe diferença entre o campo para HTML e o campo para configuração (setup) dos testes.

jsPerf: JavaScript performance playgroundNo primeiro campo é o local onde você deve colocar seu HTML, neste campo você deve preparar o DOM para durante os testes ser validado, inspecionado e alterado (quando alterar, use corretamente os campos setup e teardown, falaremos deles mais tarde), também é um ótimo (e indicado) local pra você carregar bibliotecas como jQuery, Prototype, entre outras, como indica nos botões que irão lhe auxiliar nessa tarefa. Os outros campos não são indicados pra isso.

Se você criou sua própria biblioteca, use o campo HTML para inseri-la.

Usarei como exemplo o underscore.js, que tem seu código fonte hospedado no github. 

underscore-min-raw

Para isso vou usar o arquivo underscore-min.js, que neste caso já é minificado e o mais indicado para testes. Com o link do raw, é simples colar este na área do HTML, veja o seguinte código:

  1. <script src="//raw.github.com/documentcloud/underscore/master/underscore-min.js"></script>

Nota-se que não tem “http” ou “https” no inicio, apenas “//”, se o servidor oferecer o arquivo pelos 2 protocolos, você não vai precisar especificar.

Posso colar o código da minha biblioteca dentro do tag script?

Pode, mas não é legal. Fica ilegível, você não fornece a fonte de origem do código, em pouco tempo é provável que se torne um teste obsoleto.

Posso preparar meu código de teste dentro de uma tag script?

Não, olhe este teste e sua revisão. Na revisão o código que prepara os testes foi movido de dentro do tag SCRIPT no campo HTML para campo setup de forma correta. No próprio comentário Mathias Bynens explica que “isto evita pesquisa de escopo pela variável, então os testes que usam estas variáveis não são penalizados. Tornando o teste mais preciso”.

Então eu devo colocar minha biblioteca no campo “setup”?

Leve em consideração que isso vai encher o escopo do seu teste com as variáveis que sua biblioteca expõe, deixará o campo cheio de código (boa parte apenas poluindo seu ambiente de teste). Fazendo como no exemplo anterior e após o carregamento no setup referenciando apenas o que você irá de fato usar no seu teste, você terá um teste limpo e bem direcionado ao seu objetivo.

O que colocar no campo “setup”?

Como já explicado, o campo setup vai construir o escopo de execução do seu teste. Então se o seu foco é testar uma operação de comparação de variáveis por exemplo, as variáveis devem estar declaradas no campo setup e nos testes apenas devem existir os códigos que deverão ser comparados.

Neste teste, por exemplo, coloquei a implementação dos algoritmos (minha biblioteca) no campo HTML dentro do tag SCRIPT. No pré-teste (campo setup) clonei as arrays que foram preparadas de forma aleatórias no meu campo HTML, para todas as arrays testadas sejam iguais durante os testes. Na segunda revisão do teste resolvi ver qual dos algoritmos era mais rápido no geral (realizando de pequenas a grandes operações) e neste caso o resultado mudou, onde o mySort é expressivamente melhor em arrays pequenas, o newSort em média quando temos arrays grandes, se torna mais eficiente.

O que fazer com campo teardown?

Se você já fez pesquisas com jsPerf, deve ter reparado que o teardown é muito pouco, quase nada utilizado. Basicamente ele será executado logo após o seu teste (pós-teste) e não vai influenciar no tempo do seu teste.

O teardown poderia redefinir suas variáveis para o valor original, mas isso é mais indicado para ser feito no campo setup.

Este recurso é mais utilizado quando você abre uma conexão e quer garantir que esta foi fechada após seu teste. Por exemplo, quando testando XHR, eventos assíncronos, API externa que necessita de algum pós comando, esses tipos de coisas. Logo falaremos mais de testes assíncronos.

Campo preparation code, cadê?

Se você ouviu falar, ou viu em versões antigas o campo “Preparation code”, bom, ele não existe mais por uma boa causa: o campo HTML é um ótimo lugar pra você preparar o código da sua execução, era um campo redundante, onde ele apenas adicionava um tag SCRIPT ao campo HTML com conteúdo que você colocou.

Manipulando DOM

Não esqueça que quando for manipular o DOM, você deve restaurar o mesmo para seu estado original, podendo ser feito tanto no campo setup quanto no campo teardown. Neste exemplo você verá que o teardown irá remover todo HTML do elemento “container” após cada teste, fazendo com que todos testes sejam idênticos ao serem executados.

Testes assíncronos

O jsPerf tem suporte a testes assíncronos, mas vamos deixar bem claro aqui: não faça testes síncronos em casos que são assíncronos.

Vejamos um teste comparando função lenta com uma rápida dentro de um setTimeout:

setTimeout vs. setInterval · jsPerf

Se você não está habituado com testes unitários, deve estar se perguntando “Como assim?!? O segundo teste claramente demora muito mais, como pode ser avaliado como mais rápido?”. Isso é um comportamento bem estranho, por dois motivos, o teste está errado, deveria ser assíncrono e o outro, é que os dois resultados deveriam ser iguais, pois neste caso o que está sendo testado é o método setTimeout em ambos os casos, independente do seu callback (função passada no primeiro argumento do setTimeout).

Explicarei esta questão do enfileiramento de tarefas do Javascript em outra matéria, voltando aos testes assíncronos.

Então para testar uma função assíncrona, no local onde esta deveria executar seu callback final que indica o fim da operação em teste, você deve inserir o trecho de código:

deferred.resolve();

Simples assim, como vemos neste teste do método setTimeout que diferente do primeiro está correto.

Corrigindo o primeiro teste, teríamos um teste, que resultaria em algo semelhante a isto:

setTimeout vs. setInterval · jsPerf

Exemplo prático seria com AJAX, utilizando a biblioteca jQuery:

  1. $.ajax('url_query_testar', {
  2.   complete: function () {
  3.     deferred.resolve();
  4.   },
  5.   async: true
  6. });

Neste suposto teste que uso apenas para exemplificar, eu iria avaliar o tempo da requisição completa, não estaria testando desempenho do javascript, sim da latência do XHR, se eu colocar o defferd.resolve() no sucesso e esquecer de fazê-lo no erro, se um dos testes a requisição XHR falhar por algum motivo, o teste ficará aguardando o deferred.resolve() resultando em erro, pois nunca será executado.

Aleatoriedades não devem ser testadas

Quando você inserir um valor aleatório no campo setup ou no seu teste, como Math.random(), é provável que seu resultado será aleatório.

Mas as vezes é necessário usar valores aleatórios, em um exemplo anterior aqui mesmo há um teste que faz uso do Math.random().

Quando for necessário, defina os valores gerados aleatórios no campo HTML, salve-os em alguma variável para utilizar durante o teste. E no setup do seu teste, faça um clone do valor original (caso seja alterado durante o teste) e utilize a variável clonada no teste. Desta maneira você garante que os valores aleatórios serão gerados antes de começar os testes e todos os testes serão feitos com o mesmo grupo de valores preparados.

Fidelidade nos resultados

Vamos falar de alguns procedimentos para obter fidelidade nos resultados. Você pode simplesmente abrir uma nova aba e sair testando, mas isso não garante que seu resultado será fiel a realidade.

Neste teste por exemplo, eu prejudiquei os resultados do meu Chrome quando estava fazendo os testes. Abri uma nova aba e testei, o resultado demonstrou corretamente à proporção quanto a diferença de execução entre os casos, porém o desempenho ficou quase que pela metade do browser Arora, que utiliza JSC, sem Nitro (habilitado por padrão nas compilações em 64 bits do webkit no browser Safari e em sua versão para OS-X e iOS, gera grandes ganhos de desempenho utilizando JSC).

Ao fechar o browser, iniciá-lo sem abas e apenas executar o teste, houve diferença no resultado, agora este estava com resultados melhores do que o Arora, porém o gráfico continuou mostrando muito menos desempenho que o Firefox e Opera, o que é em parte uma falácia, pois os últimos resultados tiveram desempenho similares, pouquíssimo inferior ao do Opera. Isso acontece porque o jsPerf gera gráficos baseado nas médias dos resultados e não apenas no último resultado. Então como tenho 3 resultados ruins e depois 3 resultados bons, o gráfico está mostrando a média entre estes, que é algo entre o Arora e Opera.

Faça testes em ambiente controlado

Para obter melhores resultados no Chrome, utilize o flag para testes de desempenho e faça o teste ao abrir o browser, sem que outras janelas/abas tenham sido executadas. O seguinte flag irá expor a API chrome.Interval que permite uma avaliação mais precisa de tempo.

# linux
$ google-chrome --enable-benchmarking
# windows
chrome.exe --enable-benchmarking

Um teste não é o suficiente

Execute o teste mais de uma vez, para ter certeza que o resultado é válido, o uso de recursos do seu sistema operacional pode interferir no resultado do teste, então uma bateria de 3 testes irá lhe fornecer informações mais confiável.

Não mexa na barra de rolagem

Quando os testes estão sendo realizados, o jsPerf irá usar análises de tempo com a maior precisão possível, se você redimensiona o browser, ou mexer na barra de rolagem, isso causará disparo de eventos no DOM, que vão tornar seus testes menos precisos.

Devo usar uma VM pra fazer os testes?

Se quer testar browsers que não rodam nativos no seu sistema operacional, sim, você deve usar VM, isso vai facilitar sua vida, mas não precisa exagerar, criando uma VM para isolar totalmente seu teste, esse tipo de perfeição não trás grandes benefícios.

Dicas

Para testes ainda mais elaborados, você pode utilizar a API do Benchmark.js. Mas cuidado com as armadilhas, como a deste exemplo, onde o autor usou o this.count no setup e toda vez que alguém executar o teste, o contador vai incrementar e o resultado será cada vez pior.

Para executar os testes sem precisar clicar no botão “run”, adicione a URL #run e este vai executar os testes assim que a página estiver pronta para. Exemplo: http://jsperf.com/document-getelementbyid/2#run

Testes no Internet Explorer antes da versão 9, podem exibir caixas de diálogo com avisos quando estiver executando testes, isso acontece porque o IE até a versão 8 limitava os scripts a 5 milhões de instruções, o que hoje em dia é um valor trivial para se processar no Javascript. Por sorte a Microsoft fez uma correção que está disponível neste link.

É possível “exportar” os resultados clicando na imagem “Browserscope” e você ainda pode customizar a saída com a API do mesmo.document.getElementById() · jsPerfGostou? Quer contribuir ou ver se o jsPerf está sendo desenvolvido? Ele é openSource e seu código fonte está disponível no github.

Resumo

  • Utilize corretamente os campos HTML, setup e teardown;
  • Use o mínimo de código necessário dentro de cada campo de teste;
  • Tenha certeza que os métodos usados para teste estão comparando a mesma coisa (foco);
  • Se os métodos não estiverem comparando a mesma coisa, mencione isso na descrição;
  • Evite colar o código inteiro de sua biblioteca no campo HTML;
  • Jamais coloque o código da sua biblioteca no setup, se colocar no teste, tenha em mente que você vai testar o tempo de carregamento da biblioteca contra outras bibliotecas;
  • Valide seu código para garantir que você está testando o que você realmente quer testar;
  • Quando for reutilizar variáveis entre testes, redefina-as no setup ou teardown;
  • Limpe/prepare o DOM quando for utilizá-lo entre testes;
  • Não faça testes assíncronos como se fossem síncronos;
  • Não adicione aleatoriedades no seu teste;
  • Quando testes não forem conclusivos com o melhor algoritmo use o mais simples ou de melhor leitura;
  • Faça testes em ambiente controlado;
  • Faça mais de um teste para ter certeza.

Curiosidades

Cookies ou localStorage? No caso do jsPerf, localStorage, assim evita trafego desnecessário no protocolo HTTP.

Mas porque não salvar o rascunho de seus testes no localStorage? Afinal, se der problema posso perder todo meu trabalho.

Simples, isso afetaria testes que envolvem localStorage, então o mínimo de uso melhor, apenas os dados do usuário e só. E se você for testar localStorage, no setup, recomendo que apague os campos do jsPerf, para um teste fiel.

Referências

]]>
http://gartz.com.br/testes-de-desempenho-para-javascript-com-jsperf/feed/ 0
O que é um CDN e porque criar ou usar http://gartz.com.br/o-que-e-um-cdn-e-porque-criar-ou-usar/ http://gartz.com.br/o-que-e-um-cdn-e-porque-criar-ou-usar/#comments Mon, 04 Feb 2013 22:02:51 +0000 http://gartz.com.br/?p=64 Conhecendo um pouco da história do CDN com artigo do wikipedia:

“Content Delivery Network (CDN ou Rede de Fornecimento de Conteúdo) é um termo criado em fins da década de 1990 para descrever um sistema de computadores interligados em rede através da Internet, que cooperam de modo transparente para fornecer conteúdo (particularmente grandes conteúdos de mídia) a usuários finais.”

Fonte: http://pt.wikipedia.org/wiki/Content_Delivery_Network

Quando se fala de servidor de mídia, estamos falando de imagens, vídeos, músicas, arquivos comprimidos, flash, até Javascript e CSS. Repare que o conteúdo de um CDN normalmente são arquivos estáticos, que podem facilmente ser replicados, vamos falar mais disso logo, logo.

Porque usar um CDN?

No Brasil, essa não é uma resposta particularmente complexa, normalmente esse artifício melhora o desempenho do seu site. Existem CDN’s conhecidos como da Google, Microsoft, Amazon, que são comum quando se trata de frameworks em Javascript, conhecidas como jQuery, ExtJS e outras.

Se quando você instalou jQuery no seu site copiou este código abaixo, você é um usuário de CDN, e está usando o da Google para seu jQuery, o que é recomendado pelos desenvolvedores do jquery.

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script>

Devo usar um CDN já existente?

Quando se utiliza o CDN, o client que está acessando seu site irá baixar o arquivo de um servidor diferente do seu, o que implica em algumas vantagens e desvantagens:

Vantagens:

  • Download feito em paralelo;
  • O navegador pode já ter o arquivo em cache (se o usuário esteve em outro site que utiliza o mesmo CDN);
  • Não irá consumir o trafego do seu servidor;
  • CDN’s como do Google, Microsoft e Amazon, costumam ter ótima latência e taxa de transferência;
  • CDN’s grandes tem menos chance de ser infectados com malwares;

Desvantagens:

  • Você não tem controle sobre o conteúdo do arquivo quando referencia um servidor remoto;
  • Se o CDN tirar o arquivo do ar ou estiver indisponível (manutenção), isso vai impactar no seu site;
  • Usar um CDN não confiável poderá tornar seu site perigoso para os usuários que visitam;

E isso nos leva a próxima pergunta…

Porque criar um CDN próprio?

Então voltamos ao caso “Brasil” onde temos servidores caros. Sim, normalmente taxa de transferência  espaço de armazenamento, limites mensal de trafego entre outros, todos são caros.

Um exemplo são as VPS, vamos comparar alguns países, com disponibilidade de recursos bem simples, como 1GB ram, 50GB storage e 1 núcleo de 2ghz:

País Taxa Limite mensal Custo Latência*
Brasil 2mbps ilimitado R$ 80.00 ~20ms
Brasil 10mbps ilimitado** R$ 300.00 ~20ms
EUA 100mbps 2000GB R$ 15.00 ~170ms
EUA 100mbps 3000GB R$ 60.00 ~160ms
EUA 100mbps ilimitado R$ 120.00 ~160ms
Europa 100mbps ilimitado R$ 60.00 ~230ms

Fonte:

* Latência deve variar dependendo da região onde você estiver do Brasil.

** Ilimitado no Brasil sempre vem com poréns, se você fizer uso muito alto da banda, irá ter problemas.

E não estou levando consideração encargos com IP’s extra, backups e outros que no Brasil costuma chegar a ser 10 vezes mais caro que nos outros países.

Criando seu próprio CDN, você pode balancear esse cálculo sem perder desempenho. Por exemplo, pode ter 2mbps no Brasil para o seu site, e os arquivos dinâmicos, porém arquivos estáticos com mais de 150KB, pode hospedá-los em um CDN no exterior, desta maneira o site irá carregar rápido e quando usuário tentar baixar uma imagem de alta definição, ou um arquivo compactado, vídeo, audio, ou um Flash pesado, estes estarão em um servidor que vai levar um pouco mais de tempo para iniciar a entrega, mas assim que começar o download, além de poder ser mais rápido, não aplicará grandes encargos financeiros na hospedagem.

Usabilidade

Uma das coisas que torna mais lento o carregamento de um site, é o início do carregamento, isso é, quando usuário digita o endereço do site, e a página demora a aparecer pela primeira vez.

Depois que ela carregou o browser vai começar a carregar os conteúdos linkados a página, sejam CSS, JS, imagens. Se a página demorar para carregar, e seus arquivos dependentes também, a usabilidade estará comprometida e se torna irritante a navegação.

Porém se a página carregou rápido, arquivos como css, js e pequenas imagens (iconização por exemplo) ficaram disponíveis de imediato, quando o browser estiver baixando outras imagens maiores, vídeos, músicas e conteúdos extras, isso não será tão perceptível ao usuário, ainda mais, que tendo a página inicial carregada, várias desses conteúdos maiores irão carregar em paralelo.

Servidor de alta latência

Um exemplo é, se você tem um site em um servidor que tem 200ms de latência, em teoria é que seu site carregue no mínimo em 400ms (estamos retirando ai o tempo de processamento do html, js e outros que afetam o browser), mas normalmente será uma vez para carregar o arquivo principal e uma segunda vez para carregar os arquivos linkados, se no CSS houver link para imagens então estas irão levar 600ms até serem carregadas.

Bom, meio segundo para carregar uma página seria razoável  mas não estamos contando os tempos anexos de processamento. E se você clicar em 3 links para navegar nessa página, você vai ficar frustrado, pois vai ver que é um tempo extremamente alto em dias que 10ms no carregamento faz diferença na experiencia do usuário.

Servidor de baixa latência

No mundo ideal você teria 20ms para carregar seus arquivos, o que resultaria em 40ms para página e 60ms com as imagens, mas como vimos, no Brasil isso é caro, o que pode acontecer é que quando for carregar suas imagens, poucos clientes consumam toda banda do seu site e de 20ms ele passe para mais de 1000ms, uma vez que vai ter que balancear a entrega dos arquivos.

Servidores de baixa e alta latência distribuindos

Quando hospedamos o site no Brasil e fazermos um CDN no exterior, vamos supor que no brasil a entrega seja de 20ms e no exterior de 200ms, colocando apenas as imagens referenciadas no CSS no CDN.

O site irá carregar em 40ms, nesse ponto o usuário já pode interagir com links e navegar, as imagens vão levar mais 200ms para chegar, mas vamos esperar até o final, temos um site que carregou por completo em cerca de 240ms.

Vantagens e desvantagens, qual custo?

CDN é uma solução de baixo custo, mantendo desempenho em quase 3 vezes mais rápido que hospedando seu site completamente no exterior. Apesar de ser 4 vezes mais lento que hospedar totalmente no Brasil, você tem uma economia de 4 à 10 vezes no valor da hospedagem, tendo como adicional uma banda de trafego até 10 vezes maior.

Análise de trafego aplicada

Para analise de arquivos HAR foi usada ferramenta Har Viewer 2.0.15

Agradecimentos

Agradeço ao Gian Carlos Salvati (Grupos Internet), que contribuiu com a indicação do Volume Drive, servidor utilizado para CDN da mesma. Ao Sérgio Surkamp, pelas idéias e ajuda na correção do texto. E não menos importante, a Renata Laurente, que fez a revisão ortográfica.

Próxima matéria pretendo explicar como montar e configurar um servidor de CDN simples, para uma infra-estrutura de pequeno porte, mas que quer honrar com velocidade de entrega dos seu(s) site(s).

]]>
http://gartz.com.br/o-que-e-um-cdn-e-porque-criar-ou-usar/feed/ 2
Loucura http://gartz.com.br/loucura/ http://gartz.com.br/loucura/#comments Tue, 14 Aug 2012 23:42:24 +0000 http://gartz.com.br/?p=46 O esquecimento, a mudança sem alterações. A vida é muito estranha quando a lógica é ineficaz, desconsiderada e distorcida pelos outros. Repetidamente perseguida e errada por momentos de presunção.
Rostos sem expressão, não identificando o que de fato há no coração, a visão que perece enquanto não mais reconhece aqueles que por tempo lhe perseguem.
A vida definha enquanto há felicidade, pelo carinho e o amor de alguém sem destino. O raciocínio que está sempre em conflito, a ética que não passa de moral em um contexto ficcional.
A aceitação de um desconhecimento que nos atrai orgulha e leva à depressão, o tempo que nos julga e enfraquece no momento em que falamos.
Certo e errado, a relação entre como deveríamos e como agimos, não impede de que a confiança que temos nos outros nos protejam das maldades e dos vícios de uma sociedade corrompida pela ganância.
A tristeza de machucar a quem nos importa simultâneo à frieza com quem se sente ameaçado por palavras, se escondendo em sombras distorcidas de uma realidade imposta, rigorosa, mesquinha e preconceituosa.

]]>
http://gartz.com.br/loucura/feed/ 5
Assassino Virtual http://gartz.com.br/assassino-virtual/ http://gartz.com.br/assassino-virtual/#comments Thu, 05 Apr 2012 23:23:22 +0000 http://gartz.com.br/?p=42 Estou dirigindo para casa e tenho apenas uma certeza, eu a amo. Passamos um final de semana maravilhoso, eu e ela.

No momento a noite é minha única companheira, assim como ela foi neste final de semana, foi muito bom. Quase como estar sozinho e não se preocupar com nada, ela gosta tanto de mim que parece fazer parte do meu corpo a todo o momento, como se me completasse.

Eu nunca precisei dela e ela nunca precisou de mim. Não temos quase nada em comum, mas nos completamos juntos. Sem motivos, sem necessidades. Apenas faz bem estarmos juntos.

É uma certa loucura estarmos juntos, ela é, pelo menos, seis anos mais nova que eu, sinto em certos momentos sua insegurança, se sente insegura por me amar tanto, mas mal sabe ela que eu a amo da mesma maneira.

Talvez seja melhor assim, nem tudo deve se dizer, apenas demonstrar. As palavras assim como são fortes para as pessoas que as ouvem, enfraquecem aquelas que as pronunciam. E além do mais, os olhos refletem a verdade daqueles que podem sentir.

Hoje a estrada está vazia, já estou a pelo menos cento e sessenta quilômetros por hora. Normal em uma estrada como esta, mas há pessoas que defendem que o limite que as placas impõem deve ser obedecido.

Bom senso. É necessário apenas bom senso para definir o certo do errado. Sim. Sem por os outros em risco, respeito é muito importante. Mas no meu caso, gosto de viver a vida.

Amanhã é segunda-feira, volto para empresa e fico boa parte do dia fazendo algo que eu tenho facilidade, não que eu goste ou deixe de gostar, mas não é algo que me dificulta, pelo contrario, permite que eu alcance minhas ambições.

Intensidade. Quando não estou trabalhando, estou levando a minha vida da forma mais intensa possível. Estou apaixonado, estou muito apaixonado. Se estivesse com ódio, estaria com muito ódio, se estivesse ansioso, estaria muito ansioso.

Eu acho isso perfeito, há quem diga que a vida deve ser dosada. É porque já não conseguem sentir a vida, tem tanto medo da morte que fazem de nada para serem vivos e não morrerem, mas já esqueceram que de nada vale a vida daqueles que não podem vivê-las.

Serei um eterno exagerado, que exista um dia aqueles que compreendam a vida ao extremo.

Estou cansado, muito cansado, chegarei logo em casa, espero que ela aproveite sua semana, artistas precisam de inspiração. Usei toda minha energia a cada dia que passou e cada manhã que acordei, acordei com toda energia e um pouco mais.

Um dia, não havia nada para fazer e nesse dia tentei não pensar, quis me sentir como alguém que guarda suas energias para o dia seguinte. No dia seguinte acordei tão cansado que quis guardar minhas energias para outro dia. E por um momento refleti, do que vale me guardar para amanhã, olhar pra trás e ver um monte de dias me guardando para o dia que vou deixar de viver.

Melhor viver em quanto estou vivo. Sim, estou muito apaixonado. Preciso chegar, quero viver a minha vida de amanhã.

]]>
http://gartz.com.br/assassino-virtual/feed/ 0