Pesquisar este blog

quarta-feira, 17 de fevereiro de 2010

Por que o CleverCSS é legal e como você pode ser também!

Senhores, hoje a postagem é sobre gerador de código CSS. Não me refiro aos editores gráficos poderosos que algumas empresas como a Adobe fornecem. Nosso foco hoje é o CleverCSS, uma biblioteca escrita em python que permite gerar código CSS de forma rápida e bastante maleável.

A grade idéia do CleverCSS é possibilitar a codificação de arquivos CSS fazendo uso fruto das facilidades de linguagens de programação, como funções e variáveis. Por exemplo, já pensou ser capaz de mudar todo o esquema de cores de seu site mudando apenas uma variável de um arquivo em formato CleverCSS?

A forma como isso tudo é feito também é bastante interessante. O CCSS se utiliza de uma DSL (domain specific language) bastante semelhante ao próprio css onde você pode definir suas regras de estilo, variáveis e funções (macros). Essa DSL, como não poderia deixar de ser, tem sua estrutura semelhante a uma mistura de python com CSS. Do python, foi retirada a identação, que serve para definir os blocos de regras de estilo, substituindo os usuáis caracteres de chave.

Do CSS foi retirado quase todo o resto. Vejamos uma regra simples, escrita em formato clevercss:
variavel = red
a:
    color: $variavel
    &:hover:
        color: $variavel.brighten()
Na primeira linha, temos a definição da variável variavel que irá guardar o valor de red, que já é definido (igual seria no css puro). Em seguida, temos a declaração do conjunto de regras para tags a. Nessa declaração, utilizamos a identação para definir o bloco com as regras, ou seja, tudo que estiver abaixo de a e dentro de sua identação será aplicado a a.

As regras definidas foram:
  • Todo elemento a deve ter a cor armazenada em $variavel ($ dá acesso ao conteúdo de variavel).
  • Ao ocorrer o evento hover (meta seletores), a cor da variável deve ser $variavel, só que mais clara (a macro brighten devolve a cor armazenada na variável 20% mais clara).
Caso você tivesse um site grande que usasse um padrão de cores composto por duas ou três cores, o exemplo acima poderia lhe ser bastante útil pois você poderia utilizar com diferentes graus de claridade baseados no esquema do site sem ter que escrever as cores toda vez.

Além do brighten, outro método interessante é o darken, que permite obter o valor da cor da variável escurecido em 20%. Ambos os métodos aceitam como argumento o grau de clareamento ou escurecimento da cor. Caso você queira que variável seja clareada em 10%, você escreveria: $variavel.brighten(10).

Um detalhe importante é que, código em formato CleverCSS não pode ser utilizado diretamente nos seus arquivos HTML. Eles devem ser primeiro convertidos para o formato CSS antes de serem utilizados. Para isso, você pode codificar seu próprio script de conversão, pode usar uma variação deste script, disponível no site do pocoo:




Ou pode utilizar o seguinte snippet:



Outros exemplos, tipos e macros são possíveis e estão definidos na DSL. Para uma referência mais completa, veja: http://sandbox.pocoo.org/clevercss/. 
Abraço senhores! 

sexta-feira, 5 de fevereiro de 2010

Como tornar seu projeto django mais rápido!

Hoje a postagem é direcionada para quem já sabe django e quer melhorar o desempenho de uma aplicação sua. Existem diversas formas de se melhorar o desempenho geral de uma aplicação Django, entretanto, vou falar de duas técnicas bastante simples e eficazes. 

Quando se fala em melhorar o desempenho de uma aplicação, desenvolvedores com background em outras linguagens e frameworks logo pensam em adicionar cache e "melhorar o sql" das consultas. Em Django, esta não é uma forma eficiente de fazer as coisas. 

O fato de nem todo site necessitar de cache e do cache, às vezes, não poder ser usado, por possibilitar retornar dados previamente carregados quando a última informação do banco deve ser mostrada sempre, são argumentos pertinentes contra o uso de cache. Quanto a melhorar o SQL, em Django, que possui um ORM poderoso, responsável por cuidar de todo o SQL gerado, esse se torna uma melhoria que muitas vezes terá impacto imperceptível. Se você não estiver bastante conciente sobre os acessos mais comuns ao seu site e sobre a complexidade de suas querys, outras formas mais simples de melhoramento podem ser adicionadas ao seu projeto.

Evite usar locals()

No Django, normalmente, cada view é uma função responsável por receber uma requisição e retornar uma resposta adequada. A forma mais usual de retornar essas respostas é através da função render_to_response, que se encarrega de carregar o arquivo com o template Django, populá-lo com os dados de um dicionário e retorná-lo utilizando o mimetype adequado. O problema aqui está na forma como o render_to_response pode ser usado.  Vejamos a assinatura do método:
render_to_response(template[, dictionary][, context_instance][, mimetype])
Assinatura simples, com poucos argumentos. template é o nome do arquivo (html, por exemplo) que será renderizado, enquanto dictionary é um dicionário com todas as variáveis que serão disponibilizadas no template. O problema ocorre quando, para o argumento dictionary, é usado o resultado do método locals(), que retorna todas as variáveis locais. Isso ocasiona que, ao invés de usar apenas as variáveis pertinentes na renderização do template, tudo que estiver como variável local também será fornecido como argumento, tornando a busca de valores das variáveis menos eficiente e diminuindo a qualidade do código. Então, primeira regra, não use o locals no render_to_response. 

Utilize o middleware Gzip

A utilização do middleware Gzip é uma das formas mais fáceis e rápidas de melhorar o desempenho geral de um projeto django. A integração deste middleware no seu projeto fará com que os dados enviados ao navegador do usuário sejam compactados com gzip antes de ser enviados. Isso permite diminuir o tráfico geral de dados consideravelmente. Como adicionar o middleware gzip a um projeto é muito fácil, ele é a melhor forma de melhorar o desempenho de um projeto rápidamente. 

Para adicioná-lo a um projeto, edite o arquivo settings.py adicionado:

'django.middleware.gzip.GZipMiddleware',

ao seu dicionário MIDDLEWARE_CLASSES.

Além destas duas dicas simples, outras formas de melhorar o desempenho do seu site são:
  • utilizar o wsgi em detrimento ao mod_python
  • servir o conteúdo estático do seu site diretamente pelo servidor
  • não utilizar o método len() em querysets sem necessidade
Bem senhores, é isso. Espero ter ajudado. Abraço e comentem!

quinta-feira, 28 de janeiro de 2010

Adicionando robots.txt no seu projeto Django

O robots.txt é um arquivo na raíz do seu site que informa os robôs da internet (as maquininhas responsáveis por indexar seu site em sistemas como o do google ou yahoo) o que pode ou não ser indexado. Ele é particularmente interessante ao se trabalhar em ambientes de teste disponíveis na internet ou quando não se quer alguma página específica disponível a todos. 

Em miúdos, o robots.txt é bastante útil, entretanto, sua integração ótima no Django é um pouco cabeluda. "Por quê?" Você perguntaria. Muito simples meu caro Watson, projetos Django, normalmente, utilizam uma pasta especial para servir todo o seu conteúdo estático, e essa pasta especial, normalmente, é acessada por um caminho ou path diferente da raíz. Isso quer dizer que quando um robô indexador procura o robots.txt em meusite.com/robots.txt, ele não o achará, pois o mesmo está, provavelmente, em media/robots.txt.

Para resolver esse problema, existe uma série de abordagens, como criar uma view que sirva o arquivo, por exemplo. Uma abordagem mais interessante e eficiente é utilizar o mod_rewrite do Apache nesse trabalho. O código ficaria assim:
RewriteEngine On
RewriteRule ^robots\.txt$ /media/robots.txt [L] 
(contribuição de Dave Dash)
"/media/" no caso, é o caminho para os arquivos estáticos do seu site. Estou postando essa solução (simples para quem conhece Apache) porque achei bem interessante e me tomou alguns minutos de pesquisa.

No mais, é isso. Abraço a todos!

terça-feira, 26 de janeiro de 2010

Django Snippets - Soluções em Django

Senhores, hoje a postagem será de utilidade pública. Resolvi falar sobre esse excelente (com ressalvas) repositório de códigos para Django, prontos para serem usados.


Para quem não sabe, o Django é um excelente framework de desenvolvimento para web com python. Ele te permite criar aplicações seguras e robustas em pouco tempo. Mesmo o Django sendo "super cool", seu código é bastante enxuto, de várias maneiras. Os desenvolvedores escolheram por adicionar "pouca" coisa ao código padrão do framework, permitindo que houvesse poucas dependências. Assim, se você quer algo diferente, você tem que fazer. "Você" entre aspas! Caso você conheça o django snippets, poderá utilizar soluções bastante interessantes desenvolvidas por diversas pessoas de todo o mundo.

O funcionamento do django snippets é bem simples, existe o site de snippets onde as pessoas vão e postam suas soluções, que são tornadas públicas. Caso alguém encontre um problema na sua solução, elas podem, por exemplo, sugerir uma mudança. Infelizmente, o site não permite buscas das formas usuais. Basicamente, se você quer procurar um snippet, você deve usar o google ou procurar, página por página, na lista de snippets disponível.

Como exemplo de snippets legais que você pode usar tem o snippet de recaptcha que te permite adicionar um captcha a um formulário de busca, por exemplo, sem grandes problemas. snippet

Ou código legal é este que te permite criar objetos de paginação que tornam bastante fácil criar o Look&Feel do digg no seu site. Eu, particularmente, o utilizado no django-forumbr.

Existe uma infinidade de outros snippets que podem lhe agradar. Sugiro doar 15minutos do seu tempo, um dia desses, para averiguar o repositório do Django Snippets. No mais, é isso. Abração, senhores!

segunda-feira, 25 de janeiro de 2010

Comemorando meus dois seguidores!

Hoje descobri que tenho exatos dois seguidores no meu blog, fato que achei "O MÁXIMO"! Rrsrs sinal que o blog está saindo do limbo. Para comemorar, resolvi fazer essa postagem e nela, não falar do que costumo falar: programação, baixo e comida. Hoje vou mostrar uma conversa antiga minha, que tive com meu amigo Nícolas Alcântara, onde discutimos alguns aspectos do movimento bastante falado esses últimos tempos, o movimento EMO.


Durante nossa discussão, uma metáfora poderosíssima foi construída, para classificar as pessoas de acordo com os seus sentimentos por cocô. Nada muito pretencioso, é claro. No mais, espero que gostem!

Uma análise musical com "Fezes pra que te quero".

Hehe, no mais, o compinha Victor Sobreira resolveu me dar uma aula de rails esse domingo, lá no Shopping Aldeota. Ruby ainda sux, mas agora eu aprendi um pouco mais do comportamento do Rails. Vou poder criticar com mais base ainda! Buahahahahá!

sábado, 26 de dezembro de 2009

Dolphin, Lua, Ruby, Natal e um pombo safado!



Essas duas últimas semanas foram de muitas novidades e emoções! Natal, estudo de Ruby (falo disso já!), Lua e teve também um episódio envolvendo uma limonada e uma ave mal educada. Nada extremamente interessante, entretanto, o caso do Dolphin, o emulador de GameCube, pode agradar uma galera.

Já falei aqui sobre emulador de Playstation, Sega Saturno e NDS para Ubuntu. Todos muito bons e rápidos. Excelentes projetos. Hoje, apresentado pelo meu amigo, gostaria de apresentá-los ao emulador de GameCube Dolphin. Alguns já devem ter ouvido falar do mesmo, outros devem pensar que este emulador foi descontinuado, mas eis a realidade: Ele existe, continua em desenvolvimento e, de quebra, funciona tanto no linux quando no windows. Isso foi uma grande supresa agradável para mim, pois alguns emuladores só funcionam em Windows, por exemplo, o que é bastante frustrante. Tem um emulador escrito em Java, o JPCPS, que não tem versão atual para Linux.


Bem, choramingos à parte, vamos ao Dolphin. Ele é bastante rápido, tem uma lista de compatibilidade muito boa e instala super fácil em sistemas baseados em Debian, como o Ubuntu. Para instalá-lo no Ubuntu, basta o comando abaixo, no terminal:

# sudo apt-get install subversion scons g++ wx2.8-headers libwxbase2.8-0 libwxbase2.8-dbg libwxbase2.8-dev libwxgtk2.8-0 libwxgtk2.8-dbg libwxgtk2.8-dev libsdl1.2-dev nvidia-cg-toolkit libxxf86vm1-dbg libxxf86vm-dev libxext6-dbg libxext-dev libglew1.5-dev libcairo2-dbg libcairo2-dev libao2 libao-dev libbluetooth-dev libreadline5-dev && svn checkout http://dolphin-emu.googlecode.com/svn/trunk/ dolphin-emu-read-only && cd dolphin-emu-read-only && scons flavor=release

Tudo bem que é um comandozão grande com cara de mal, mas ele funciona muito bem e não requer muita "ação" do usuário. Basicamente, ele baixa e instala as dependências da aplicação e, em seguida, baixa a versão do sistema de versão e a compila. Nisso, um arquivo chamado RunMe estará disponível na pasta dolphin-emu-read-only/Binary/Linux Execute o dito cujo e seja feliz!

No site, tive a impressão que uma placa nvidia moderninha é uma boa escolha para rodar o aplicativo, em conjunto com um bom processador. Quem testar e quiser deixar um comentário do seu hardware, eu agradeço.

Além desse meu texto informativo altamente útil para o curso e progresso da humanidade, isso é um blog, correto? Falar um pouquinho do meu dia-a-dia também, para deixar as coisas mais interessantes.


Seguinte, esses últimos dias, o caro Rafael Cruz, um dos defensores de Ruby aqui no Ceará, fez a caridade de me emprestar um livro sobre Ruby: Conhecimento e Linguagem, do Eustáquio, para estudar. O livro é bom e tudo, mas, quanto mais eu lia, mas eu via que não gostava de Ruby. Linguagem confusa, cheia de símbolos e de estruturas desnecessárias. Para quem vem do Python e já sofreu com Perl, com certeza deve achar a sintaxe muito desgostosa. Até meu background de java chiou com o Ruby.


Nisso, o Rafael sempre me dizia "Dê mais um dia para o ruby. Estude mais um dia". E eu estudava mais um dia. No segundo dia: "Estude mais dois dias", e eu estudava mais dois dias. Quando essa conta chegou na primeira semana, foi demais para mim! Meu sensor de dor disparou e eu tive que largar essa linguagem malévola. Rsrsrs, acho que agora, só programo em Ruby forçado.


De qualquer maneira, durante meus dolorosos estudos de ruby, em meu tempo livre, fui estudar Lua, que eu já conhecia de vista, mas nunca tinha parado para aprender. E quão boa foi a experiência! Ao contrário de ruby, que mais parece uma linguagem frankstein, Lua é super bonitinho e conciso. Tudo bem que a orientação a objetos em Lua não é lá uma Gisele Büdchen, mas tirando isso, ela tem qualidades em relação a outras linguagens. A primeira qualidade dela é ser brasileria. E por que isso é uma qualidade? Pq o que é da terrinha é mais gostoso, é claro =D. Segundo, ela te permite interagir fácilmente com outras linguagens, inclusive C. Terceiro, ela está fazendo muito sucesso com os gringos, ou seja, daqui a algum tempo, ela "chega" por aqui bombando. Sinal que vai valer a pena saber programar com a bichinha. E...bem, muitas qualidades. Para finalizar, eu gostei do fato de ela ter um interpretador interativo embutido, que nem o Python e ter uma sintaxe clara, sem muito frufru (Ruby, aprende!).


Para quem não sabe, Lua também pode ser usado com o Ginga, que é o middleware de interatividade do padrão brasileiro. Como a outra linguagem fácilmente utilizada com o Ginga é Java, acredito que Lua é uma opção bastante atraente. Quem quiser ver Lua funcionando de verdade, pode baixar a "Engine" de jogos do Lua löve, que é muito bonita.


Ufa! Que postagem grande! Falta só falar do pombo...Ave danada, viu? Algumas pessoas chamam esse bicho de "rato voador". Dia desses eu tive certeza do motivo. Em mais uma de minhas mirabolantes noites de insônia, saio eu, de manhãzinha, 6hrs, à procura de uma merciaria aberta, disposta a me vender alguns limões. Seis quarteirões depois, descubro que está tudo fechado. Excelente. Voltando de minha empreitada mal sucedida, triste e desiludido, sabendo que não terei minha limonada, eis que sinto a cagada em meu braço. Olho para cima, e lá está, o pombo, com a cara mais sínica. Tudo bem que o bicho é irracional e tudo, mas eu acho que o pombo fez de propósito. Só tinha ele lá no fio do poste, e o maldito ainda me acertou. Ele fez mira. Não pode ser coincidência, um negócio desses...

É por coisas como essa que eu digo: NÃO ALIMENTEM OS POMBOS! Esse ato pode se voltar contra vocês! Vocês podem levar uma cagada enquanto procuram limões!

É isso. Boas festas de fim de ano, negada ö/!

domingo, 29 de novembro de 2009

Mootools Vs JQuery

Quem desenvolve para web nos últimos anos, com certeza sentiu a necessidade de aprender algum framework javascript para agilizar seu trabalho ou mesmo possibilitar criar efeitos mais complexos com menos esforço. Nessa empreitada, o cidadão vai se deparar com uma série de opções das mais variadas, como ExtJs, Prototype, Dojo e outros.

Dentre esta gama de opções, escolhi como meu framework principal o Mootools que é bastante prático e poderoso. O problema é que, na minha região, esse não é lá um framework muito utilizado. O mercado costuma ser dominado por uma tecnologia ou outra, enquanto as "outras" convivem timidamente, em seu nicho. No meu caso, o framework que está "na boca do povo" aqui é o JQuery, outra opção muito popular, internet a fora.

Nisso, sempre ocorrem aquelas discussões sobre qual o seu framework predileto ou por que pessoa tal escolhe framework tal. Aqui, normalmente essas discussões envolvem o JQuery, e no meu caso, o barraco é mais ou menos no estilo Mootools Vs JQuery. Hoje, ocorreu algo assim, em pequenas proporções, quando comentei meu desgosto com a sintaxe do JQuery em relação à sintaxe do MooTools no twitter.

Disseram que a sintaxe do Mootools é "mais feia" que a do JQuery e que o primeiro era "javeiro". Tudo bem que sintaxe bonita e feia é questão de gosto, mas o adjetivo "javeiro" que foi definido pelo interlocutor como prolixo já não é. Ele faz referência a alguma coisa (Java, no caso) e representa uma característica teoricamente perjorativa.

Mediante tudo isso, me sinto compelido a contribuir com meus dois centavos. Vou justificar porque vejo a sintaxe do Mootools como sendo mais clara e "bonita" que a do JQuery, por fim, vou colocar alguns exemplos de código para ver se o adjetivo "javeiro" realmente procede.

Primeiro, quem já parou para ler a documentação do JQuery? Ver os métodos e classes disponíveis? Galera normalmente só olha o que vai precisar neh? Então vou fazer uma análise sobre trechos de código que se usa normalmente.

Vejamos alguns exemplos de como selecionar elementos com JQuery e Mootools:



Bem, não vou me estender muito neste artigo, mas acho que foi possível mostrar alguns pontos que mostram que o adjetivo javeiro, talvez tenha sido mal empregado pelo meu colega. De qualquer forma, quaisquer observações ou erros no código, favor, não deixem de informar. Abraço a todos!