Gustavo Dutra » reuso

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 =)

Como usar Adapter Pattern com python

Gustavo Dutra — Mon, 05 Jan 2009 00:45:44 +0000

Olá! Dando continuidade ao post anterior, sobre Decorator Pattern. Mostrarei neste post aqui um exemplo de como e porquê usar o Adapter Pattern. Qualquer dúvida, comente!

O que é Adapter Pattern?

Bom, imaginemos aqueles cartões de memória de máquina fotográfica. Existem de várias tamanhos, micro, pequenos, grandes, gigantes. Seria realmente uma merda se uma máquina fotográfica suportasse somente 1 tamanho, por isso foi inventada aqueles… adivinhem… adaptadores que permitem que micros e pequenos caibam em grande, por exemplo. Todos tem a mesma finalidade, porém, têm tamanhos diferentes.Para isso serve o Adapter Pattern, para resolver justamente esse tipo de problema.

Quando se fala em abstração, geralmente se fala em Adapter Pattern, justamente por isso, porque ele te permite, com um mesmo objeto, fazer ações diferentes com uma finalidade em comum.

Para entendermos melhor, pensemos no caso de abstração de banco de dados. A sintaxe de cada um é diferente, porém têm as mesmas claúsulas. Alguns permitem transações, outros não. Pois esta é uma situação perfeita para o Adapter Pattern. Mas seria muito complexo explicar utilizando ela como exemplo, logo, fiz um exemplo em python que vai ajudar.

class ShapeAbstract(object):
 
	def countCorner(self):
		return self.corners
 
	def __str__(self):
		return self.name
 
	def area(self): abstract
 
class SquareShape(ShapeAbstract):
	def __init__(self, x, y=None):
		self.corners = 4
		self.name = 'Square'
		if (x is not None):
			self.l = x
 
	def area(self):
		return self.l*self.l
 
class TriangleShape(ShapeAbstract):
	def __init__(self, x, y):
		self.corners = 3
		self.name = 'Triangle'
		self.x = x
		self.y = y
 
	def area(self):
		return ((self.x*self.y)/2)

Bom, Tudo começa na nossa classe abstrata ShapeAbstract. Ela é a classe que vai servir de base para todos as formas que vamos calcular a área. Temos a classe SquareShape que representa um quadrado (jura? :/). O construtor da classe, __init__, recebe 2 valores: altura e a largura. Visto que é um quadrado, todos os lados são iguais, não é necessário passar a altura, ficamos somente com a largura. O que difere do triângulo, cujas medidas são base e altura. A nomenclatura não importa, no caso, vamos utilizar no máximo 2 medidas.

Nosso adapter é simplório, caso houvesse a necessidade de calcular a área de um trapésio, seria necessário mais um parâmetro, afinal, a fórmula é: ((base maior + base menor) / 2 * altura). Isso é facilmente implantado utilizando apenas mais um parâmetro no __init__, porque o que realmente queremos é fazer com que o método area() nos retorne a área.

import Shapes
 
class Shape(object):
 
	def setAdapter(self, Adapter):
		self.Adapter = Adapter
 
	def countCorner(self):
		return self.Adapter.countCorner()
 
	def area(self):
		return self.Adapter.area()
 
	def __str__(self):
		return self.Adapter.__str__();
 
	def newShape(ShapeAdapter):
		shape = Shape()
		shape.setAdapter(ShapeAdapter)
		return shape
 
	newShape = staticmethod(newShape)
 
if __name__ == '__main__':
	shape = Shape.newShape(Shapes.SquareShape(5))
	print shape
	print shape.countCorner()
	print shape.area()
        #Imprime:
        #Square
        #4
        #25
 
	shape = Shape.newShape(Shapes.TriangleShape(5,6))
	print shape
	print shape.countCorner()
	print shape.area()
        #Imprime:
        #Triangle
        #3
        #15

Nesta “aplicação principal” vemos a real classe adaptativa: Shape. Ela recebe a instância da classe e executa os métodos dela. Parece bobo ter uma classe que executa o método de outra classe, mas é fundamental para o reuso e a famosa abstração.

Vejam que elas se comportam diferentes. Claro, são formas diferentes! Áreas diferentes! Número de cantos diferentes! E nomes direfentes!

Agora fica fácil ver esse exemplo abstraindo, por exemplo, um banco de dados? Pense que a classe Shape seja Database, TriangleShape seja MySQLDatabase e SquareShape seja MSSQLDatabase, o método area() seja o método setLimit().

shape = Database(MySQLDatabase())
print shape.setLimit(5);
#Imprimi: LIMIT 5
shape = Database(MSSQLDatabase())
print shape.setLimit(5);
#Imprimi: TOP 5

Usando Adapter para 3rd part

Uma das minhas sugestões de uso do Adapter Pattern é com integração de código de terceiros. Vamos supor que você tenha 3 bibliotecas que geram gráficos: X, Y e Z. A bilioteca X é muito boa, mas não tem gráficos em pizza, que na Y tem. Mas a Z, por sua vez, tem gráficos em pizza em 3d. Vamos analizar a situação:

A responsabilidade é a mesma: gerar um gráfico.
Independente do tipo de gráfico (com barras, pizza, etc), todas elas vão receber os mesmos tipos de dados.
Cada biblioteca tem seus próprios métodos, com nomes diferentes, mas para as mesma finalidade

Não parece um lugar perfeito para se utilizar o Adapter Pattern? Ora, vamos fazer um pequeno esboço:

graph = GraphAdapter()
graph.setData(([20,30,10],[15,25,35]))
graph.desenhaGrafico(GRAFICOS.BARRA)
graph.desenhaGrafico(GRAFICOS.PIZZA)
graph.desenhaGrafico(GRAFICOS.PIZZA3D)

Observem que não utilizei a instância de uma classe como adapter, utilizei constantes que vão determinar, na hora de desenhar o gráfico, o tipo dele. Se for BARRA, faz justamente como a biblioteca X exige, usando a API dela. O mesmo para PIZZA (Y) e PIZZA3D (Z). Pronto! Você, utilizando patterns, terá seu próprio modo de gerar gráficos, mesmo que com bibliotecas diferentes! Comentem e até a próxima!

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é?