Posts de ‘Andrews Medina’

[Andrews Medina] Dev In Cachu eu fui!

Wednesday, May 4th, 2011

No dia 30 de abril em Cachoeiro de Itapemirim aconteceu o primeiro Dev In Cachu, um evento com o foco de reunir desenvolvedores do sul do Espírito Santo para compartilhar conhecimentos e experiências.

O evento teve um nível bem legal de palestras, falando sobre ensino 2.0, colaboração e software livre, refactoring, TDD e agilidade com a participação de palestrantes como o Jeveaux e Hackin da Giran, Henrique Bastos, Erich Egert da Caelum entre outros.

Além disso contou com uma ótima infra estrutura e organização, tendo coffe breaks e etc.

Eu tive a honra de participar do evento em uma palestra com o Francisco Souza falando sobre o uso de Python para vários propósitos, já que é uma linguagem multi propósitos.

A idéia da palestra era demonstrar 12 trabalhos usando Python, assim como teve os 12 trabalhos de Hércules, mas, devido ao tempo abordamos apenas 4 trabalhos. Mas, vou deixar esse assunto para um outro post.

Para finalizar, os slides da palestra:

[Andrews Medina] classes “new-style”

Thursday, February 10th, 2011

Estava conversando com um amigo sobre classes “new-style” e percebi que alguns desenvolvedores não sabem a diferença em herdar ou não a classe object ao criar uma classe em Python.

Até a versão 2.1 do Python, o tipo de todas as classes em Python era classobj. E qualquer instancia de uma classe era do tipo instance. Ou seja, todas as instâncias eram independentes de suas classes:



>>> class Foo: pass

>>> type(Foo)
<type ‘classobj’>
>>> foo = Foo()
>>> foo.__class__
<class __main__.Foo at 0×1e4570>
>>> type(foo)
<type ‘instance’>

Na versão 2.2 do Python, foi criado as classes ‘new-style’ que unificam classes e tipos. Onde uma classe não é nada mais que um tipo definido pelo programador:



>>> class Bar(object): pass

>>> type(Bar)
<type ‘type’>
>>> Bar.__class__
<type ‘type’>
>>> bar = Bar()
>>> bar.__class__
<class ‘__main__.Bar’>
>>> type(bar)
<class ‘__main__.Bar’>

Outra característica é que uma classe new-style é do tipo ‘type’ assim como as os tipos primitivos, permitindo a criação de tipos baseados nos tipos primitivos:



>>> type(list)
<type ‘type’>
>>> type(Bar)
<type ‘type’>
>>> class MinhaLista(list): pass

>>> type(MinhaLista)
<type ‘type’>

Para manter questões de compatibilidade, na versão 2 do Python as classes são old-style por padrão, para que uma classe seja new-style ela tem que ser uma classe filha de uma classe new-style, onde object é a base das classes new-style. No Python 3 as classes são new-style por padrão e as classes old-style não existem mais (amém).

As classes new-style tem várias características diferentes das old-style, como é facilmente visto no exemplo abaixo:



>>> dir(Foo)
['__doc__', '__module__']
>>> dir(Bar)
['__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__']

Algumas diferenças são: descriptors, method resolution order e chamada de métodos especiais.

Mais informações sobre classes new-style:

[Andrews Medina] Análise de Código em Python

Monday, January 31st, 2011

Análise (estática) de código é um termo utilizado pela análise feita fora do tempo execução de um código, verificando a sua qualidade.

Há várias formas de analisar um código, a sua sintaxe, verificar a ocorrência de elementos não utilizados, código duplicado e etc.

Vou listar aqui algumas ferramentas de análise de código para python, explicar o uso e instalação de cada uma delas.

pep8

Verificar se o código está seguindo as orientações do pep 8.

Instalação:


[sudo] pip install pep8

Uso:


pep8 /diretorio-do-meu-codigo

pylint

Analisa o código procurando por bugs ou por sinais de baixa qualidade. Como:

  • existência de docstring nos métodos
  • variáveis e atributos não definidos
  • pep8
  • métodos, modulos ou objetos importados não utilizados
  • verifica linhas similares

O pylint atribui uma nota ao seu código de acordo com o resultado do teste.

Instalação:


[sudo] pip install pylint

Uso:


pylint /diretorio-do-meu-modulo-python

pyflakes

Verifica se algum modulo ou objeto importado ou uma variável não estão sendo utilizado. Detecta também variávies não definidos.

Instalação:


[sudo] pip install pyflakes

Uso:


pyflakes /diretorio-do-meu-codigo

clonedigger

O objetivo do clonedigger é detectar códigos semelhantes.

Instalação:


[sudo] pip install clonedigger

Uso:


clonedigger /diretorio-do-meu-codigo

O clonedigger gera um arquivo chamado output.html mostrando todas as duplicações.

Bônus: http://pypants.org/

pypants é um site onde você cadastra seu projeto python e ele analisa a qualidade do seu projeto e da uma nota de acordo com o resultado.

Agora, uma vez como o código analisado, fica mais fácil saber o que refatorar para melhorar a qualidade do mesmo.

[Andrews Medina] Meu ambiente de trabalho em 7 itens

Wednesday, January 26th, 2011

O @franciscosouza me convocou para listar 7 ítens do meu ambiente de trabalho. Então, lá vamos nós…

1) git + github

O git é uma ótima ferramenta para controle de versão, rápido e distribuído. Já o github é mais que um repósitorio para projetos opensource. É uma rede social para desenvolvedores, onde você pode seguir desenvolvedores e projetos. Ele também simplifica e ajuda a desburocratização da colaboração com o software livre, facilitando a colaboração.

2) textmate

O meu editor favorito é o textmate. Ele é simples, tem syntax highlighting e é facil fazer macros e plugins para ele.

3) macbook + mac os

Para mim o macbook e o mac os é a melhor harmonia entre o software e o hardware. =)

O mac os é muito agradável, fácil de usar, não é necessário perder tempo instalando drivers e etc, e é unix o que o torna bem poderoso como ambiente de desenvolvimento.

Ah, e a bateria dura bastante tempo.

4) homebrew, iterm2

Como terminal eu tenho utilizado o iterm2 tenho gostado. E para instalar pacotes utilizo homebrew.

5) pip + virtualenv + virtualenvwrapper

Atualmente utilizo várias linguagens de programação, mas a que mais utilizo (no momento) é Python.

Para desenvolver em Python, utilizo pip para instalação de pacotes, virtualenv e virtualenvwrapper, para trabalhar em ambientes limpos e isolados pro projeto. Fazendo com que um ambiente utilizado pelo projeto X não precise ter instalado as dependências do projeto Y.

6) TeamCity Continuous Integration Server

Para mim um código não testado não existe. E para monitorar meus projetos e saber se seus testes estão passando eu utilizo o TeamCity com um plugin para chrome, que mostra no chrome se o build está passando ou está quebrado.

7) monitor + teclado sem fio + mouse

Junto com o macbook eu utilizo um monitor, um teclado sem fio da apple e um mouse da microsoft.

Passo a bola para:

[Andrews Medina] DSLs em Python

Saturday, December 11th, 2010

introdução

DSL (Domain Specifc Language) é uma linguagem limitada com o objetivo de atender um domínio específico. Ou seja, DSLs são uma forma diferente de programar, onde é criado uma sintaxe que se aproxime mais do domínio do qual ela faz parte.

A linguagem de programação escolhida para construir a DSL afeta totalmente em como será a sintaxe da DSL. Geralmente, linguagens menos burocráticas como ruby são mais utilizadas para construção de DSLs.

Python mesmo sendo dinâmica tem várias burocracias, como endentação obrigatória, monkey patch limitado, que limitam a construção de DSLs, mas por outro lado, Python, tem características que podem ser utilizadas, como: sobrecarga de operadores, decorators e modificação do encoding.

Nesse post eu mostrarei como utilizar essas técnicas para construção de DSLs, e mostrar bibliotecas em Python que já as utilizam.

sobrecarga de operadores

Há duas formas de utilizar a sobrecarga de operadores para construir DSLs. Uma delas é mantendo a função original do operador, mas modificando o domínio em que ele atua, e a outra forma é modificando a função do operador, utilizando ele apenas para facilitar a sintaxe.

Para exemplificar como podemos utilizar um operador, mantendo sua função original, mas modificando seu domínio, vamos analizar o funcionamento o operador de adição (+):

Ele pode ser utilizado para realizar a adição, somando dois números:



>>> 2 + 2
4

Pode ser utilizado para concatenar duas strings:



>>> “andrews” + “medina”
“andrews medina”

Seguindo esse raciocínio poderíamos usar o operador de adição para concatenar duas imagens:



>>> imagem1 + imagem2

Um framework que faz um ótimo uso de sobrecarga de operadores, mantendo sua função é o cocos2d. Ele utiliza operadores para concatenar ações/animações:



>> sprite.do( Reverse(scale) + scale )

A outra forma, de usar operadores é apenas sobrescrevendo ele para usar ele de uma forma que fique ‘visualmente’ agradável, criando assim uma DSL.

Um exemplo de biblioteca que utiliza essa técnica é a should_dsl:



>> 1 |should| equal_to(1)

decorators

Usar decorators para descrever características de uma função, é uma técnica para escrever DSLs, tornando o código mais claro e legível.

Um exemplo, seria construir um decorator para tornar funções assíncronas:



@assync
def funcao():
pass

O uso de decorators é bem comum. Outro caso é utilizar decorators para definir o roteamento de ur utilizado por uma função:



@url(‘foo’)
def foo():
pass

O django utiliza decorators para facilitar a construção de filtros e template tags:



@filter
def hello():
return “hello”

Além do django, o lettuce, web2py, flask utilizam decorators.

modificação do encoding

Uma outra forma mais livre de construir DSLs em Python é utilizando o encoding para modificar a sintaxe do Python.

Essa técnica não é muito comum e eu particularmente não gosto dela, por ela modificar a sintaxe original da linguagem.

Um exemplo de uso dela pode ser visto num projeto criado pelo Fernando Meyer, chamado YETI (https://github.com/fmeyer/yeti):



describe Bowling:
def before_each:
self._bowling = Bowling()

it “should score 0 for gutter game”:
self._bowling.hit(0)
self._bowling.score |should_be.equal_to| 0

Para quem quiser entender mais como funciona o YETI, Meyer escreveu um post sobre isso: http://planeta-globo.com/2009/09/05/writing-a-domain-specific-language-dsl-with-python/

conclusão

Para saber quando usar sobrecarga de operadores, decorators ou criar uma sintaxe diferente na hora de criar uma DSL, lembre-se sempre de torná-la mais simples possível e sempre condizente ao domínio.

[Andrews Medina] Testando tags e filtros customizados no Django

Saturday, September 18th, 2010

O sistema de templates do Django traz nativamente uma grande variedade de tags e filtros, mas, em vários casos é necessário criar tags e filtros customizados.

Criar tags e filtros está bem documentado na documentação oficial do Django, mas, como testar tags e filtros customizados é algo que gera muitas dúvidas em vários desenvolvedores.

Uma forma simples para testar filtros e tags é utilizar a própria Template API do Django para criar e renderizar uma template que utilize um filtro ou tag a ser testado.

Um teste para um filtro ‘reverse’ que inverte uma string, seria da seguinte maneira:



from django.test import TestCase

from django.template import Context, Template

class TestFilter(TestCase):

def test_lower_filter(self):

html = ‘{% load reverse %}’

html += ‘{{ username|reverse }}’

template = Template(html)

context = Context({’username’: ‘ozzy’})

assert ‘yzzo’ == template.render(context)

Assim é possivel fazer TDD no desenvolvimento de filtros e tags sem sofrimento.

[Andrews Medina] Listando branchs remotos e locais com no git

Wednesday, July 28th, 2010

Isso é mais uma anotação, uma dica do que um post.

Mas, para listar branchs remotos e locais no git é só usar o parâmetro ‘-a’ no comando branch:

git branch -a

[Andrews Medina] novo post do andrews

Saturday, July 17th, 2010

quero so ver como vai ser

[Andrews Medina] Testando aplicações django com nose-django.

Tuesday, December 8th, 2009

O nose-django é um plugin para o nose com o objetivo rodar testes de aplicações Django.

Com ele é possível criar testes em uma estrutura de arquivos menos engessada que a estrutura imposta pelo Django, sem perder as funcionalidades de testes do framework como fixtures, client e etc.

Outra vantagem do nose-django é a possibilidade de utilizá-lo em conjunto com outros plugins para o nose como o coverage por exemplo.

Mais informações sobre o projeto: http://www.assembla.com/spaces/nosedjango