Gustavo Dutra » porque

Tchelinux 2009 – Porto Alegre

Gustavo Dutra — Thu, 12 Nov 2009 15:28:29 +0000

Para quem é do Sul, estarei em Porto Alegre no dia 14/11/2009 ministrando duas palestras no evento Tchelinux. A programação tem mais de 60 palestras sobre diversos temas e a entrada é apenas 2kg de alimentos não perecíveis. Aqueles que participarem recebem um atestado de 10h para usar como atividade complementar.

Para mais informações http://www.tchelinux.org/2009. As palestras serão:

VIM-de a mim, produtividade

Uma palestra que mostra maneiras para um edição de texto efetiva e rápida usando o vim.

jQuery – Introdução

Apresenta o porquê do jQuery ser um excelente framework para desenvolvimento rápido com javascript.

Se alguém tiver assistido a alguma palestra, favor dar um feedback!!!

Dicas de como aumentar a produtividade usando autocmd no vim

Gustavo Dutra — Sun, 12 Apr 2009 02:06:11 +0000

Quantas vezes você faz um arquivo que é exatamente igual à um outro arquivo por dia? Quantas vezes você abre um arquivo só para copiar um trecho de código que é utilizado em vários arquivos? Quantas vezes você se vê fazendo a mesma coisa que fez em outro lugar?

E aquela palavra que você sempre escreve errada? Aquela função que você sempre esquece o nome?

Conheça algumas dicas para aumentar a produtividade e diminuir o trabalho dessas coisas rotineiras.

Lista de Abreviaturas

Sabe aquelas palavras que a gente insiste em escrever errado? Principalmente quem trabalha com e-mails, códigos e comentários em outras línguas tem dificuldades com certas palavras. Por exemplo,

vc -> você
q -> que
pq -> porque
nao -> não

Agora a pergunta que não quer calar: Porque não usarmos algo para evitar esse tipo de coisa? Às vezes nem notamos os erros, mas eles estão lá. Mantenha uma lista de abreviaturas no Vim. Cuide dela, adicione novas abreviaturas assim que vierem à sua cabeça. A sintaxe é simples, basta adicionar no seu .vimrc:

"" abbr ERRADO CORRETO, por exemplo:
abbr pq porque
abbr vc você

O Vim ainda possibilita que você crie sintaxes diferentes para arquivos diferentes. Então, seus arquivos .txt podem ter abreviaturas diferentes das de .py. Ou seja, se o nome daquela função python é muito longa ou você insiste em escrevê-la errada, ela merece uma abreviatura, no formato descrito acima (abbr ERRADO CORRETO).

$ mkdir -p ~/.vim/abreviaturas/
$ vim ~/.vim/abreviaturas/txt.vim

Adicione ao txt.vim as abreviaturas utilizadas para arquivos texto. Mesmo que poucas, coloque algumas. Um pouco de disciplina fará com que sua produtividade aumente. Tenha certeza.

Ao seu .vimrc, basta acrescentar:

autocmd BufNewFile,BufRead * source $HOME/.vim/abreviaturas/para_qualquer_linguagem.vim
autocmd BufNewFile,BufRead *.txt source $HOME/.vim/abreviaturas/txt.vim
autocmd BufNewFile,BufRead *.py source $HOME/.vim/abreviaturas/python.vim

O autocmd funciona mais ou menos igual a uma trigger. É um sistema de eventos, basicamente. Ou seja, ao abrir um arquivo novo (BufNewFile) ou um arquivo já existente (BufRead), se o nome do arquivo casar com a expressão (no caso, *, *.txt ou *.py) irá executar o código a seguir.

Vou falar mais sobre o autocmd em outro post, tem muitoooo pano pra manga, hehehe.

Templates de Arquivos

Quando se fala em programação é meio que como na arte. Não só porque programar é uma arte, mas porque nada se cria, tudo se copia. Tudo bem que, hoje em dia, com técnicas de encapsulamento, oop, etc, fica mais difícil. Mas sempre há coisas em comum entre os arquivos. Vamos começar com algo simples.

Template básico para javascript, onde será utilizado jquery.

$(document).onready(function(){
// code here
});

Simples, mas não é um saco ter que escrever isso sempre que abre um arquivo novo? Tome isso como regra: Faça uma, porém apenas uma vez. Não seria mais fácil abrir o arquivo e tcha-ram! Lá está o código que, em 90% dos casos, você irá utilizar?

Esse foi pequeninho, mas imagine um arquivo html. A trabalheira que é copiar todo o caçalho. E se você segue um padrão, pode usar inclusive o css junto. Observe:

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

E o css:

html * {
}
body {
}
#wrapper {
}
        #wrapper #head {
        }
        #wrapper #content {
        }
        #wrapper #footer {
        }

Imagine um designers, aqueles que fazem o psd e depois passam pra xhtml, tendo que copiar isso vezes e vezes para todos os arquivos que ele faz. Faça apenas uma vez e siga o padrão!

Usuários de django, ao criar um model, precisam escrever sempre os imports ? Se são utilizados sempre, porque não criar um template?

Agora você me pergunta, como carregar o template automagicamente no Vim ? Fácil! Utilizando nosso autocmd =). Do mesmo modo que fizemos com as abreviaturas, vamos criar os diretórios:

$ mkdir -p ~/.vim/templates/

Criei lá os arquivos com os templates que você acha útil.

autocmd BufNewFile *.html 0r ~/.vim/templates/html.tpl
autocmd BufNewFile style.css 0r ~/.vim/templates/cssstyle.tpl
autocmd BufNewFile jquery.*.js 0r ~/.vim/templates/jqueryjs.tpl

Agora, abra seu Vim e sinta a magia:

vim index.html style.css jquery.initscript.js

Executando comandos externos

g(un)zip

O manual do Vim tem um exemplo bem interessante, para abrir arquivos gzipados, editá-los, como se nada tivesse acontecido e salvá-lo no formato gzip de novo. Apesar de que aqui, não precisou acrescentar os códigos abaixo, ele já fez automático. Basta adicionar o .vimrc

augroup gzip
  autocmd!
  autocmd BufReadPre,FileReadPre	*.gz set bin
  autocmd BufReadPost,FileReadPost	*.gz '[,']!gunzip
  autocmd BufReadPost,FileReadPost	*.gz set nobin
  autocmd BufReadPost,FileReadPost	*.gz execute ":doautocmd BufReadPost " . expand("%:r")
  autocmd BufWritePost,FileWritePost	*.gz !mv <afile> afile><afile>:r
  autocmd BufWritePost,FileWritePost	*.gz !gzip afile><afile>:r
 
  autocmd FileAppendPre		*.gz !gunzip afile><afile>
  autocmd FileAppendPre		*.gz !mv afile><afile>:r afile><afile>
  autocmd FileAppendPost		*.gz !mv afile><afile> afile><afile>:r
  autocmd FileAppendPost		*.gz !gzip afile><afile>:r
augroup END
afile>

Verificação por erro

Já deve ter acontecido com você: você salva o arquivo e quando vai testar, faltou um ponto e vírgula, ou escrever o nome de uma função errada, ou algo similar… um erro bobo, mas que não deixou seu código ser executado e exige reparo.

Para ajudar contra esse trabalho desnecessário (teste + correção + teste), que pode se repetir inúmeras vezes, você pode usar o autocmd para alertá-lo, utilizando ferramentas externas. Por exemplo:

autocmd BufWritePost *.pl !perl -c %
autocmd BufWritePost *.php !php -l %
autocmd BufWritePost *.java !javac -Xlint %

Use a criativdade

Utilize sua criatividade e seja mais produtivo na SUA rotina. Deixe as coisas serem automatizadas. Para mais eventos do autocmd, :help autocmd. Tem uma lista bem extensa. Leia a documentação e seja feliz =). Crítias, sugestões e CASES são bem vindos nos comentários =)

Por que usar Clean URL’s?

Gustavo Dutra — Sun, 01 Mar 2009 16:02:56 +0000

Olá! Este post é na verdade uma introdução para o próximo. Que trará formas de se trabalhar com Clean URL’s. Este, por sua vez, é mais teórico. Portanto, se você estiver em dúvida se usar ou não, qual os ganhos dela e etc, sinta-se a vontade de ler, comentar e criticar o post abaixo.

Patterns de URLS

A primeira coisa a se pensar ao usar Clean URL’s é a modularização, estruturação ou hierarquisação dos conteúdos do site, para que se possa fazer algo interessante. Precisamos de algo único e que seja facilmente localizável. Afinal, um dos motivos do uso de Clean URL é este: que o conteúdo daquela página seja facilmente localizável (isso inclui memória do usuário, assimilação e, por que não, associação com outros assuntos. Além é claro de convenções, tais como: /about, /contact, etc).

Para blog, é muito interessante que o título de um post vire parte da URL. Ao ver o link, o usuário já sabe sobre o que se trata e o que vai encontrar neste post. Logo, se o vizinho da sua tia puser um link de um post seu no blog dele, torna-se muito mais fácil alguém clicá-lo. Nem sempre o link para o post conterá o título, talvez o link seja um mero ‘clique aqui’. Mas, passando o mouse sobre o link, o usuário vai ler o título do post. Para por o título na URL, existe um termo técnico chamado SLUG, que contém apenas letras, números, hífens e underlines. Por exemplo: ‘/artigo/como-usar-mod_rewrite’ é muito mais prático e óbvio do que um ‘?categoria=article&article_id=5433′.

Para buscadores isso é muito importante também. Note a diferença entre as URL’s do exemplo anterior: para usuários que não tem uma intimidade com Web, ver descrito o nome do título lhe dá muito mais segurança de clicar. Pessoas menos íntimas costumam julgar a periculosidade de uma URL pelo que consta nela. Constando “coisas do diabo” como ‘?id=343&vid=3fdd&hash=54dfsg===v3rgf’ devem ser exorcizadas!

Hierarquisando

Hierarquisar o site, fazer a topologia, mapa do site. Vários termos! Mas para mim, são a mesma coisa. No momento em que refletimos aquelas velhas questões clássicas antes de montar um site:

Qual o público alvo ?
Qual o objetivo ?
O que é preciso ?

Já estamos montando mentalmente uma organização. Vamos pensar no blog deste que vos escreve e responder às perguntas.

Preciso de um blog. Onde eu escrevo posts sobre assuntos que me venham à cabeça para compartilhar um pouco da experiência que tenho e obtive lendo outros blogs, de pessoas que liam outros blogs. Ou seja, quero retribuir o que recebi (está aí o objetivo). Meu público alvo? Justamente aqueles que procuram por informações. Que programam, aprendem e crescem porque são apaixonados por tecnologias.

Agora vamos organizar essas informações:

No blog, além de posts (o que é totalmente indispensável), também deverá haver categorias, tags, etc. Pois o público alvo é um público sedento por informação. O público quer o máximo de informação possível e de forma rápida e simples. Não há tempo para se perder. Por isso se utiliza a categorização e as tags: fazem com que conteúdos relacionados cheguem muito mais rápido àqueles que as procuram.

Portanto é necessário que se consiga uma URL fácil para pesquisas no blog. Por exemplo: http://gustavodutra.com/categoria/GVim já lista todos os posts da categoria GVim. O que possibilita o ‘Joãozinho’ favoritar a dada URL e, sempre que entrar, irá se deparar com posts da dita categoria.

À partir do momento que você junta informações sobre o site, você consegue estruturá-lo de forma com que fique claro e simples para o usuário onde ele está. E mais importante! Sempre coloca nomes em URL’s que tenham algum sentido lógico com o contéudo. Fazendo o contrário, faz com que o site perca credibilidade, tanto para buscadores como para usuários finais. A palavra chave é ‘contextualização’. Uma URL uma vez contextualizada junto ao seu conteúdo, fica mais visível na internet!

Quais são os ganhos reais

Muitos dos ganhos podem parecer bobos. Mas não são. Com URL’s bem definidas:

Aumenta-se a segurança do site
Facilita a manutenção do site
Despreocupaçao com diretórios e nomes de arquivos
Facilita a navegação
Aumenta o pagerank em buscadores
Pode aumentar o número de visitas/page views

Se você se perguntou ‘Como?’, aguarde o próximo post! Obrigado pela atenção, até mais!

O que é? Como e Por quê usar? – Decorator Pattern

Gustavo Dutra — Mon, 29 Dec 2008 01:46:18 +0000

Rá! Acá estou eu para explicar um pouco mais sobre o Decorator pattern, um deles que eu acho pouco usado, mas pode salvar vidas. Tem poder na mão. Alguns podem já ter noção do que seja, mas outros devem estar se perguntando: ‘WTF??’. Então vamos lá:

Decorator Pattern

É um pattern desenvolvido para modificar um determinado objeto (seja modificar alguma coisa já existente ou delegar uma nova responsabilidade) sem a necessidade de extendê-lo. O que é muito bom, assim, o reaproveitamento de código é maior ainda! Enfim, vou tentar dar uma explicada no pattern:

Diagrama de Classes do Decorator Pattern

Abaixo segue o código usado:

class Message {
 
	protected $msg;
 
	public function __construct($msg) {
		$this->setMsg($msg);
	}
 
	public function getMsg() {
		return $this->msg;
	}
 
	public function setMsg($msg) {
		$this->msg = $msg;
	}
 
	public function __toString() {
		return $this->getMsg();
	}
 
}
 
class Success_Message extends Message {
	public function __construct($msg) {
		parent::__construct($msg);
		$msg = new DivClass_Decorator(
			new Li_Decorator(
				$this
			)
			,'success-msg');
		$this->setMsg((String)$msg);
	}
}
 
class Error_Message extends Message {
 
	public function __construct($msg) {
		parent::__construct($msg);
		$newmsg = new DivClass_Decorator(
			new Li_Decorator(
				$this
			)
			,'error-msg');
		$this->setMsg((String)$newmsg);
	}
 
}
 
interface Msg_Decorator_Interface {
	function render(Message $message);
}
 
abstract class Msg_Decorator_Abstract extends Message {
 
	public function __construct(Message $msg) {
		$this->render($msg);
	}
 
}
 
class Li_Decorator extends Msg_Decorator_Abstract implements Msg_Decorator_Interface {
 
	public function render(Message $message) {
		$msg = $message->getMsg();
		$this->setMsg(''. $msg .'
');
	}
 
}
 
class Div_Decorator extends Msg_Decorator_Abstract implements Msg_Decorator_Interface {
 
	public function render(Message $message) {
		$this->setMsg(''. $message->getMsg() .'
');
	}
 
}
 
class DivClass_Decorator extends Msg_Decorator_Abstract implements Msg_Decorator_Interface {
 
	private $class;
 
	public function __construct(Message $msg, $class = null) {
		$this->class = $class;
		parent::__construct($msg);
	}
 
	public function render(Message $message) {
		$this->setMsg('.(null === $this->class?'default-class':$this->class).'">'.$message->getMsg().'
');
	}
 
}

OK! Com o código em mãos, vamos pensar um pouquinho. Tenho uma cacetada de classes, todas fazendo praticamente a mesma coisa. E agora? Calma, Juvenal. Vamos analizar:

Temos a classe Mensagem. Sabemos que ele representa uma mensagem. Métodos básicos para manipularmos a mensagem e um __toString() que irá retornar o valor em string pra classe quando for feito o cast.
Classe Msg_Decorator_Abstract que extende da classe Mensagem. Todos os nossos decoradores, por assim dizer, irão ser filhos desta classe. O exemplo é tão simples que a classe abstrata nem tem métodos abstratos. Mas a idéia é que tenha, caso necessário.
Msg_Decorator_Interface, essa interface obriga os programadores que quiserem criar decorators a escrever o método render(). Que é chamado pela nossa classe Abstract no construtor.
Li_Decorator, Div_Decorator e DivClass_Decorator são exemplos de decorators.

Vamos ver o negócio funcionando? Vamos escrever o seguinte código:

   	print new Div_Decorator(
			new Li_Decorator(
				new Message("Mensagem de teste!")
			)
		);

Irá imprimir



	Mensagem de teste!

Viram? Simples e prático! Claro que o exemplo é bem simples e talvez nem seja tão útil. Mas é só pensar um pouquinho mais que logo surgem exemplos onde se usar o Decorator.

Entender agora fica mais fácil. Apenas comece olhando do meio para a esquerda. Primeiro nós instanciamos a classe Message com o mensagem “Mensagem de teste!”. O método getMsg() retornará exatamente isso: “Mensagem de teste!”. Porém, no momento em que é instanciado o Li_Decorator, ele vai mudar a mensagem usando o método render(), que deve ser implementado na Msg_Decorator_Interface e chamado na Msg_Decorator_Abstract pelo construtor. E assim acontece com o Div_Decorator.

Notem que eu decidi mudar o valor da mensagem usando o setMsg. Eu já li em alguns lugares onde fica armazenada a instância da classe anterior e então o método getMsg seria chamado em forma de cascata, fazendo com que a mensagem original nunca fosse alterada de verdade, e no fim ela é, igual a um método recursivo, retornada decorada e maquiada.

Reutilizando o código

Bom, como eu havia dito no começo, o Observer Pattern nos possibilita o reuso. O exemplo são aquelas duas classes das quais eu não cheguei a falar: Error_Message e Success_Message.

Observem que são simples e, utilizando os Decorators já existentes, mostram uma mensagem personalizada de Erro e de Sucesso! Para utilizá-las, basta usar:

1 2	print new Error_Message("Erro! Você fez algo errado!"); print new Success_Message("Sucesso! Parabéns!");

O que imprimirá:



	Error!




	Sucesso! Parabéns!

Prós

Adiciona flexibilidade ao código.
Facilmente reutilizada.
Ótimo para sistemas que possibilitam o uso de plugins.

Contras

Gera um grande número de arquivos (se for pensar que cada arquivo é uma classe ou vice-versa).
Dependendo da quantidade de classes aloca muita memória.
Ruim para sistemas mais fechados e bitolados ou muito padronizados.

Acho que é isto pessoal. O que acharam? Não é um bixo de sete cabeças, né?