Archive for the 'Ferramentas' Category

Fatos sobre Erlang

Compilação de alguns pontos relevantes sobre Erlang, feita por Odracir:

  • Linguagem de programação de propósito geral, com ambiente de execução (runtime environment) implementado numa máquina virtual;
  • Possui suporte “embutido” para concorrência, distribuição, e tolerência à falhas.
  • É “Open-Source”, distribuído através da licença “ERLANG PUBLIC LICENSE“, que é essencialmente a Mozilla (Netscape) Public Licence, porém com algumas poucas modificações para torna-la compatível com a legislação Sueca.
  • É escrito em C, e é  portável para diversas plataformas.
  • Muito escalável!  Sua máquina virtual é responsável pela criação de “processos leves” de forma  rápida e barata, tanto em termos de utilização de recursos de CPU como de memória. Em outras linguagens de programação, normalmente estes serviços são delegados para o sistema operacional, o que limita  o número máximo de processos simultâneos permitidos.
  • Para modelar um sistema um Erlang nós usamos: “COP – Concurrency Oriented Programming”.
  • Não existe estado compartilhado…
  • Variáveis podem ser atribuídas apenas uma única vez. (Single assignment variables)
  • Os processos se comunicam entre si através do envio de mensagens (cópias imutáveis) assíncronas.
  • Tipicamente um código escrito em Erlang faz uso dos diversos núcleos disponíveis nas CPUs modernas, praticamente sem codificação adicional. Testes mostram que clusters com 16 máquinas executam um programa 14,55 vezes mais rápido do que o mesmo programa sendo executado numa única máquina, sem codificação adicional ou específica para isto!
  • Permite a interoperabilidade com C,C++, Java, Ruby, Python, Perl, etc …
  • Estudos mostram que para um mesmo projeto, o código Erlang é de 4 à 10 vezes menor que seu equivalente escrito em C++.
  • Possui a biblioteca  OTP (Open Telecom Platform).
  • Em situações extremas de “carga”, um sistema Erlang tende a degradar seu desempenho, mas não para de funcionar.

Histórico no Admin do Django

A funcionalidade de geração automática (de qualidade) de uma área de administração em projetos Django foi talvez a grande responsável por eu preferir esse framework ao Turbogears (junto com o fato do Turbogears ser na verdade uma federação de pequenos projetos). Pode parecer bobo, mas desenvolver uma área de admin bem feita é custoso, e ter uma versão básica bem feita de graça pode ser um grande diferencial na hora de construir algo novo.

Dentre as várias funções interessantes oferecidas por este admin, o histórico de operações sobre os objetos merece destaque:  cada ação efetuada sobre todo e qualquer objeto através do admin é gravada em uma tabela de histórico gerada automaticamente (data, usuário, objeto modificado, natureza da modificação), que pode ser visualizada em uma tabela web.

Infelizmente, este histórico é gerado automaticamente apenas para ações efetuadas através do admin. Recentemente, tive a necessidade de gravar o histórico de operações efetuadas por tarefas em background no SigaSeuTime (envio de anúncios comerciais para o Twitter), que me permitissem controlar de forma unificada e centralizada o bom funcionamento do sistema.

Pesquisando um pouco, descobri como fazer isso de forma simples com um código pequeno, que vou reproduzir abaixo:

from django.contrib.admin.models import LogEntry
from django.contrib.contenttypes.models import ContentType

def gravahistorico(objeto, mensagem, usuario): LogEntry.objects.logaction( userid         = usuario.id, contenttypeid = ContentType.objects.getformodel(objeto).pk, objectid       = objeto.pk, objectrepr     = mensagem, # Message you want to show in admin action list changemessage  = mensagem, # I used same action_flag     = 4 )

Chamando este código, ações sobre um objeto serão gravadas na tabela de histórico, e poderão ser vista na área de administração do Django. Simples e extremamente útil.

Pro Git

Semana passada eu estava buscando material de referência para algumas configurações do Git e achei um livro muito bom, chamado Pro Git. O livro foi escrito por Scott Chacon e publicado pela Apress. Como o livro foi publicado sob a licença do Creative Commons, está aberto para traduções e até mesmo adaptações.

No verdadeiro espírito de eating your own dog food, o autor do livro colocou o código-fonte do livro no GitHub e qualquer pessoa pode fazer um fork, para fazer modificações no material. Vi que a tradução para pt_br foi iniciada, mas ainda estava tímida. Ato contínuo, fiz um fork do projeto e comecei a fazer a tradução.

A minha idéia é completar a tradução e colocar aqui no site, em uma seção separada. Obviamente, não é algo que vai ficar pronto em uma semana, ainda mais se eu fizer sozinho. Então, fica a dica: se você quer aprender a mexer com o Git, ajudar a fazer a tradução do livro enquanto usa o Git é o casamento perfeito entre teoria e prática.

Ferramentas de busca

Outro dia, num almoço com outros alunos de pós-graduação do Instituto de Computação da Unicamp, estávamos conversando sobre ferramentas de busca e o que elas fazem bem ou mal para nós.

Na verdade a conversa começou porque uma professora tinha pedido a mim para procurar o número de artigos que referenciavam três artigos que eu estava estudando. Esta é uma métrica bastante utilizada no meio científico para ver quão bom um artigo é. Quanto mais referências um artigo tem em um menor espaço de tempo indica quão mais importante para o meio acadêmico de uma forma geral são as idéias defendidas naquele artigo.

Para fazer esta busca, a professora sugeriu que utilizássemos uma ferramenta de busca desenvolvida especificamente para este propósito: o Citeseer. Basicamente o que esta ferramenta faz é buscar numa base de dados as informações sobre um artigo e as referências cruzadas que outros artigos catalogados na mesma base de dados tem com este artigo buscado. Fiz uma busca para os três artigos que eram meu foco e… nada. Não me lembro exatamente dos resultados, mas acho que um nem foi encontrado e os outros dois, apesar de terem sido encontrados, não eram referenciados por ninguém.

O problema, neste caso, era que eu estava trabalhando com artigos muito novos, publicados no final do ano passado. Como o Citeseer, se não me engano, nem utiliza uma base de dados própria, não havia tido tempo suficiente para esta base de dados, que é alimentada com dados de algumas das principais organizações de pesquisa do mundo (no caso de computação, por exemplo, ACM e IEEE), fosse devidamente atualizada pelos diversos intermediários até chegar ao pessoal do Citeseer.

Tentei, então, o CiteseerX, uma versão nova da engine do Citeseer que ainda está na versão beta. Sem sucesso também.

A minha última tentativa foi, então, o Google Scholar. Bom, ele pelo menos conseguiu identificar os meus artigos (provando mais uma vez que o Google realmente consegue indexar algumas coisas bem rápido). Mas ainda assim meus artigos não eram referenciados. Tudo bem. Eles eram novos e isso era de se esperar.

Mas ai, no meio disto tudo, veio à tona três perguntas interessantes: você já usou outra ferramenta de busca que não o Google? Se sim, quando e porque você mudou para o Google? Será que um dia vamos parar de usar o Google?

Muita gente que eu conheço sempre usou o Google. Acho que estas pessoas teriam ainda mais dificuldades de mudar de ferramenta de busca um dia, eventualmente, se isto acontecesse.

Bem, este não é o meu caso. E toda esta conversa que tivemos me fez lembrar de quando comecei a usar a Internet. Este ano faz quinze anos (nem eu imaginava que já era tanto tempo). Em 1994, a World Wide Web estava engatinhando ainda. As ferramentas de busca, idem.

Na verdade, em 1994 não existia nenhuma ferramenta de busca que merecesse este nome para falar a verdade. Naquela época, eu e muitos outros colecionávamos os endereços que achávamos mais interessantes. Eu tinha uma planilha que chegou a ter cerca de 200 endereços catalogados e divididos em categorias. Nesta época eu já via a necessidade de ter uma ferramenta de busca (que fosse uma busca na minha planilha), mas eu não tinha conhecimento técnico para fazer isto — infezlimente; se tivesse, talvez eu estaria milhionário hoje.

O fato é que, naquela época, agrupar endereços em diretórios era tudo o que dava para ser feito. Foi assim que nasceu, também em 1994, o “Jerry and David’s Guide to the World Wide Web”, que, ainda naquele ano passou a se chamar “Yet Another Hierarchical Officious Oracle” ou, simplesmente, Yahoo!. Mais da história inicial do Yahoo! pode ser encontrada aqui.

Eu não tive o prazer de acessar o site inicial de Jerry and David pelo meu navegador Mosaic (primeiro navegador existente e predecessor do Netscape 1.0). Mas a versão inicial do Yahoo! eu usei. Era o melhor que se tinha na época. Andei procurando no Internet Archive uma versão do site inicial do Yahoo!, onde só existia a estrutura de diretórios e nenhuma ferramenta de busca ainda. Mas nem mesmo o Internet Archive indexava páginas há tanto tempo atrás. A primeira home page do Yahoo! que existe lá é de outrubro 1996. Clique aqui para dar uma olhada (até os links funcionam! :) ). Nela existe a famosa estrutura de diretórios do início do Yahoo! (que deve existir até hoje) e uma ferramenta de busca (talvez a primeira da qual eu me lembre).

Eu parei de usar o Yahoo!, se não me engano, pouco antes de entrar na faculdade, em 1999. Naquela época já existia uma ferramenta de busca chamada AltaVista que conseguia atingir diversos sites que, aparentemente, não eram visitados ou corretamente classificados pelo Yahoo!. Como dizia o próprio slogan do AltaVista, ele era “The most powerful and useful guide to the Net”. O AltaVista ainda existe. Hoje ele é parte do Yahoo!, que, se não me falha a memória, em um determinado ponto no tempo comprou a engine do AltaVista para utilizar em suas próprias buscas. Eu, no entanto, não voltei a usar o Yahoo! como ferramenta de busca.

Até que, já lá para o meio do meu tempo de faculdade, muitas pessoas vinham me falar do Google. Com o tempo, as buscas que eu fazia no AltaVista já não pareciam tanto satisfatórias. E, quando eu, insatisfeito, ia até o Google e repetia a mesma busca, ele me retornava resultados melhores. Com o tempo, fui largando o AltaVista e passei a usar somente o Google.

Como já comecei a usar o Google quando ele era uma ferramenta estável, usei o Internet Archive para buscar as primeiras versões da página do Google. É interessante notar que a primeira página registrada para o Google no Internet Archive (que, neste caso, deve ser a primeira página deles mesmo) não era tão diferente da atual e o nome Google aparecia com um ponto de exclamação no final  (“Google!”)… será que isto tinha alguma coisa a ver com o então maior site de busca do momento “Yahoo!”? :) Yahoo!, inclusive, para o qual o engine criado por Larry Page e  Sergey Brin (fundadores do Google) foi oferecido e rejeitado, o que levou à criação do Google. Mas isto é outra história…

Bom, o fato é que o tempo foi passando e hoje o Google, para mim, está agregado em rotinas automáticas no meu computador. Para falar a verdade, não acesso mais a ferramenta de busca pela página web do Google já faz muito tempo. Uso apenas o plug-in de busca para o Firefox ou o Google Desktop para fazer isso. Com isto, fica cada vez mais difícil a mudança para outra ferramenta de busca, na minha opinião, pois tudo já está pronto e funcionando assim.

No entanto, isto não quer dizer que não existam outras opções. Ano passado foi lançado o Cuil (leia-se “cool”), um site de busca criado por ex-funcionários do Google. O grande diferencial do Cuil seria a não utilização da popularidade de uma página como item preponderante no cálculo de relevância da página, o que pode ser bem interessante em alguns casos, especialmente quando se busca conhecimento e não simplesmente popularidade. No entanto, eles mesmo adimitiam na época que não era necessário apenas uma boa ferramenta de busca: o maior trabalho estaria em quebrar a inércia dos usuários (a minha, por exemplo, como descrevi no parágrafo anterior, é bem alta).

Outra que sempre tentou desbancar o Google foi a Microsoft. Ano passado ela tentou comprar o Yahoo!. Não deu certo. Este ano ela lançou o Bing, sua nova ferramenta de busca. Apesar do visual mais bacana que o do Google (na minha opinião) e de ele vir embutido em vários produtos da Microsoft, isto não foi suficiente para mudar a inércia do usuário.

Sinceramente, eu acho que a única maneira de quebrar esta inércia do usuário em relação às ferramentas de busca que ele usa é criar algo que o Google ainda não oferece (não me pergunte o que… se eu soubesse não estaria escrevendo este post, mas sim implementando esta idéia :P ). Ou fornecer ferramentas de busca que retornem resultados mais aprimorados que os do Google em campos nos quais o Google talvez não seja satisfatório. Eu listaria como dois campos em que o Google está longe de ser satisfatório em relação às buscas, na minha opinião, as buscas por imagens e por vídeos. O “Santo Graal” nestas áreas, por mim, seria conseguir fazer busca não pelos textos das páginas em que as figuras ou os vídeos aparecem, mas sim fazer busca pelo significado das imagens e dos vídeos mesmo. Algo que eu acho que a computação ainda está um pouco longe de conseguir fazer de forma automática e eficiente.

“Jerry and David’s Guide to the World Wide Web”

“Jerry and David’s Guide to the World Wide Web”

Desenvolvendo O Eclipse – construindo seu primeiro plug-in

Escutamos muito as pessoas falarem em desenvolvimento no Eclipse, utilizando esta ferramenta poderosa como plataforma de desenvolvimento. Para mim o Eclipse é a melhor plataforma de desenvolvimento genérica na qual eu já trabalhei. E, certamente, é uma das melhores plataformas de desenvolvimento para Java (para mim A melhor) e C/C++ (com certeza não A melhor) que eu já usei.

Opiniões pessoais a parte, eu passei três anos, de 2006 a 2008, não apenas utilizando o Eclipse como plataforma de desenvolvimento mas também como produto final do meu trabalho. Ou seja, eu não só desenvolvi no Eclipse. Eu desenvolvi O Eclipse.

Muitas pessoas escutam falar que o Eclipse é uma plataforma extensível. Afinal de contas, se fosse diferente, certamente não teríamos os incontáveis plug-ins para Eclipse que adicionam inúmeras funcionalidades interessantes. O que talvez nem todo mundo saiba é que extender o Eclipse é muito fácil! E talvez por não saberem disso, acabam achando que é algo difícil e não se aventuram por este mundo interessante.

O melhor de tudo é que para extender o Eclipse a única coisa que você precisa é do própio Eclipse! Ou seja, a melhor ferramenta para desenvolver o Eclipse é o próprio Eclipse.

Neste artigo vou abordar o passo-a-passo de como criar um plug-in simples para o Eclipse.

Primeiramente, alguns conceitos. O Eclipse possui o que chamamos de pontos de extensão (extension points). Estes são arquivos XML que possuem configurações que definem possíveis extensões do Eclipse. A plataforma básica já fornece uma série de pontos de extensão que podem ser facilmente utilizados para extender as funcionalidades já disponíveis (por exemplo, neste mini-tutorial iremos criar um novo menu com uma ação específica). À medida em que você for ganhando mais traquejo na implementação de pontos de extensão, você vai naturalmente notar a necessidade de você mesmo criar seus próprios pontos de extensão a partir de coisas que você extendeu anteriormente da plataforma básica (espero falar disso em um post futuro).

Mas vamos ao que interessa a este tutorial. Para começar você vai precisar ter instalado uma máquina virtual Java. Sugiro as da IBM ou da Sun, já que elas funcionam muito bem com o Eclipse. Um aviso aos usuários de Linux: as máquinas virtuais que veem com as distros (GCJ ou iced-tea) em geral não funcionam corretamente e possuem bugs em funcionalidades básicas, tornando difícil ou impossível rodar o Eclipse com elas. Se você já roda o Eclipse como plataforma de desenvolvimento você certamente já possui uma máquina virtual Java instalada.

Depois é necessário instalar o Eclipse SDK. Outro aviso aos usuários Linux: também não recomendo os empacotamentos de Eclipse SDK que vem com as distros. Em geral são ligeiramentes diferentes em relação ao Eclipse distribuído pela Eclipse.org e, muitas vezes, possuem bugs que não existem na versão original.

Quando usado como plataforma de desenvolvimento para Java ou C/C++ não é necessário ter o Eclipse SDK instalado. Basta o runtime do Eclipse. Para instalar o Eclipse SDK basta certificar-se de que você baixou o pacote com o nome Eclipse SDK do site Eclipse.org ou que você tenha instalado a feature “Eclipse Project SDK” através do Update Manager do Eclipse runtime.

Bom, feito isso, siga os seguintes passos:

1) Crie um novo projeto de desenvolvimento de Plug-In para Eclipse.

1.1) Clique no menu File -> New -> Project….

1.2) Selecione a opção Plug-in Development -> Plug-in Project na janela que se abrir e clique no botão “Next”.

1.3) Dê um nome para seu projeto, por exemplo org.eclipse.test e clique no botão “Next”.

1.4) Clique no botão “Next” no próximo passo do Wizard, chamado de “Content”.

1.5) No passo de escolha de Templates, selecione o template “Hello, World”. Clique no botão “Next”.

1.6) No último passo do wizard, não altere nada e clique no botão “Finish”.

2) O Eclipse irá perguntar se você deseja alterar a Perspectiva atual para a Perspectiva de desenvolvimento de plug-ins. Clique em “Yes”.

3) O Eclipse abrirá o editor no arquivo MANIFEST.MF. Este arquivo define as características de seu plug-in como, por exemplo, de quais outros plug-ins ele depende, quais pacotes ele exporta, quais extension points ele extende, quais extension points ele provê e outras configurações. Não vou me ater a este arquivo pois ele não será realmente importante para o desenvolvimento deste caso simples.

4) Utilizando este Template “Hello, World”, você verá que o Eclipse criou uma pasta src/org.eclipse.test.actions com uma classe SampleAction.java. Abra esta classe no editor dando um duplo clique no arquivo.

5) Esta classe possui um método public void run(IAction action) que define qual ação será executada ao se clicar no menu que estamos criando. No caso deste template, a ação executada é bem simples: abre-se uma janela com uma mensagem de “Hello, Eclipse world”.

6) Para ver seu plug-in em ação numa instância de Eclipse não é necessário instalá-lo, ainda. O Eclipse provê uma funcionalidade através da qual, de dentro do Eclipse, você pode lançar um novo Eclipse que carregará os plug-ins que você está desenvolvendo no seu workspace. Para fazer isto você terá que “executar” seu plug-in de maneira semelhante ao que você já faz para suas aplicações Java ou C/C++.

6.1) Clique no menu Run -> Run Configurations….

6.2) Dê dois cliques em “Eclipse application” no lado esquerdo da janela que se abrir. O Eclipse criará um novo launcher para aplicação Eclipse que, por padrão, a incluirá os plug-ins que estão no seu workspace.

6.3) Clique no botão “Run”.

7) Um novo Eclipse será executado. Note que nele aparecerá um menu novo, que não existia na instância anterior de Eclipse, com o nome “Sample Menu”. Clique em Sample Menu -> Sample Action.

8) Uma janela será aberta com a frase que você definiu na classe SampleAction.java.

Parabéns! Você acaba de criar um plug-in para Eclipse ao extender o extension point que permite a adição de novas opções de menu ao Eclipse.

Um tutorial semelhante a este pode ser acessado de dentro do próprio Eclipse através das “Cheat Sheets” providas pelo Eclipse SDK. Clique em Help -> Cheat Sheets… e depois selecione a opção Plug-in Development -> Creating an Eclipse Plug-in na janela que se abrir. Selecione “Create a plug-in” na view que se abrir e siga os passos descritos na tela. Este tutorial, apesar de estar em inglês, possui uma quantidade bem legal de informações sobre como criar plug-ins para Eclipse com links explicando vários conceitos relacionados. Vale a pena!

Scala: faz barba, cabelo e bigode

Aprender Scala está na minha TODO list faz um bom tempo. Finalmente tive algum tempo umas semanas atrás pra dar uma olhada na linguagem. A motivação veio de diversas fontes. No laboratório onde trabalho nós estamos tendendo à usar Scala nos nossos desenvolvimentos futuros, devido a integração de elementos funcionais que facilitam a implementação de algumas partes do código; a minha pesquisa usa uma boa pitada de linguagens específicas de domínio (domain specific languages, DSLs) e Scala parece adequada para o desenvolvimento de embedded DSLs (por exemplo, veja essa DSL para SWT em Scala); e finalmente, tivemos uma palestra sobre tagless interpreters, que haviam sido implementados em Haskell e OCaml, e eu queria ver como implementar um interpretador de cálculo lambda em Scala.

Bem, não importa se você não sabe o que são tagless interpreters ou se não se importa com lambda calculus, o foco desse post é outro. Quando comecei a aprender Scala, eu vi que a linguagem realmente faz jus ao nome (Scala vem de SCAlable LAnguage, e o objetivo era ter uma linguagem que serve pra fazer desde pequenos scripts até grandes aplicações enterprise). Basta olhar a lista de features da linguagem que você percebe que Scala faz barba, cabelo e bigode!

Como não faz sentido discorrer sobre todas as features de Scala (isso merece um livro), eu vou me concentrar em duas pequenas coisas que deixam qualquer programador Java com inveja: Local Type Inference e Traits.

Local Type Inference (Inferência Local de Tipos)

Quantas vezes eu odiei ter que escrever tipos redundantes em Java (que já expliquei em alguns comentários anteriores). Imagine um método que devolve uma lista inicializada com um inteiro (é um exemplo estúpido, mas é só pra mostrar type inference in action). public List<Integer> getList() { List<Integer> list = new ArrayList<Integer>(); list.add(0); return list; }

Scala é staticamente tipada, o que significa que todos os tipos tem que ser verificados pelo compilador. Mas o compilador de Scala tenta ao máximo inferir o tipo que você está indicando. Você só precisa escrever o tipo se o compilador não conseguir determinar qual é o tipo correto. O mesmo código em Scala ficaria mais ou menos assim (Note que sou bem novato em Scala, então me perdoe se existem soluções mais elegantes): def getList() = 0 :: Nil

O código ficou pequeno não somente por inferência de tipos, mas vamos ver como que inferência ajudou (o que segue é como eu imagino o compilador pensando). Primeiro o compilador infere que Nil é uma lista vazia, então pode ter qualquer tipo. O “::” é na verdade uma chamada de método (o add) na lista Nil, passando zero (0) como parâmetro (em Scala, métodos que iniciam com “:” fazem bind à direita, então Nil – que é uma case class de List – é quem recebe o método). O compilador vê que 0 é um Int (o equivalente de Integer e int em Scala), então o resultado de chamar add em Nil é uma lista de inteiros (ou List[Int]). Finalmente, o compilador vê que essa lista é retornada pelo método, então o tipo do método é List[Int].

Com isso, ao invés de escrever o tipo de lista em 3 lugares diferentes, você não precisou escrever em lugar algum, pois o tipo foi inferido do conteúdo e essa informação foi propagada. Note que se a lista estivesse vazia, você teria que escrever pelo menos 1 vez qual é o tipo (pois não tem como inferir do conteúdo), mas é melhor que 3 vezes!

Traits

Traits são basicamente interfaces com implementação. Já é sabido faz um bom tempo que herança múltipla (multiple inheritance, MI) causa dores de cabeça enormes (o Google, por exemplo, proíbe uso de MI no desenvolvimento interno de aplicações C++). A resposta de Java foi o conceito de interfaces, que te dão um poder parecido com MI (porque uma classe pode estender diversas interfaces, então pode ser usada polimorficamente no lugar de qualquer uma delas), mas muito mais restrito (porque a classe tem que implementar os métodos de todas as interfaces).

Em Scala, as Traits são como interfaces, mas elas podem ser parcialmente implementadas, normalmente com código default. Isso resolve alguns problemas de interfaces. Em Java existem várias interfaces pra receber eventos de GUIs que contém diversos métodos (um pra cada tipo de evento, veja MouseListener por exemplo). Quando você só tá interessado em um tipo de evento (por exemplo, Mouse Pressed), você tem que implementar todos os métodos (normalmente deixando em branco). Se você tiver sorte e sua classe não estende nenhuma outra, você pode usar um dos adapters com implementações em branco (como MouseAdapter), mas não é sempre o caso. Outro caso típico é quando um dos métodos pode ser derivado dos outros, como no exemplo direto do tour de Scala: trait Similarity { def isSimilar(x: Any): Boolean def isNotSimilar(x: Any): Boolean = !isSimilar(x) }

Nesse caso, classes precisam somente implementar isSimilar pois elas já ganham de graça o isNotSimilar. Note que traits, como interfaces, não podem ser instanciadas, e têm que ser adicionadas a classes ou objetos.

E agora?

Eu dei aqui só uma mostra do que Scala tem, e na verdade não cheguei nem perto da parte que eu considero mais importante, que é a junção (bem elegante por sinal) dos paradigmas funcional e orientado a objetos. Inclusive, umas semanas atrás eu fui à uma palestra do Simon Peyton-Jones, que é um dos caras por trás de Haskell. Depois da apresentação eu conversei (por ótimos 2 minutos) com ele sobre Scala e ele se disse feliz que Scala está trazendo linguagens funcionais pra desenvolvedores que estariam presos em OO (tanto por instrução – o que se aprende nas universidades em geral – quanto pelo mercado de trabalho). Eu acho que ele ainda prefere Haskell, mas Scala introduz “desenvolvedores comuns” ao paradigma funcional, sem abdicar de ser prática (não que Haskell não seja, mas o fato de se poder chamar código Java de Scala faz com que a adoção seja bem mais fácil).

O que me pergunto é se “desenvolvedores comuns” vão conseguir entender o que Scala oferece e usar de forma eficiente (isso depois que surgirem “Scala Design Patterns”). Sempre ouço que na indústria o average Joe mal entende Java direito, imagina então Scala. Estaríamos chegando em uma era em que uns poucos desenvolvedores excepcionais, usando linguagens e ferramentas ultra eficientes, seriam capazes de desenvolver “qualquer” sistema e suprir a demanda do mercado? Ou seja, o mercado encolheria em termos de número de programadores, mas os que restarem teriam uma produtividade muito superior?

Não sei. Mas sei que Scala faz barba, cabelo e bigode. E se bobear, tem algum jeito daquele pelinho no fundo da orelha ir junto!

Identificação de charsets

Hoje, para variar, vou falar sobre outra coisa que me incomoda. Aliás, que me incomodava.

Sempre fiquei muito intrigado com um fato que recorrentemente eu presenciava: precisava ler um arquivo de “texto puro” mas, quando abria o arquivo, lá estavam vários caracteres esquisitos ou pontos de interrogação ou qualquer coisa que não deveria estar lá. Ou seja, o programa que eu estava usando não conseguia reconhecer adequadamente o charset do arquivo e, quando tentava mostrar os caracteres usando o charset padrão do programa, um punhado de coisa ficava zuada.

Ficava sempre pensando que alguma coisa idiota devia estar acontecendo, afinal de contas, como um programa não conseguia reconhecer um charset? Tantos anos de evolução na computação e uma coisa simples como esta ainda não funcionava direito? Tentava de várias formas bolar uma solução para isso mas, qualquer coisa que eu pensava, não era uma solução que eu achasse viável. Afinal, a maneira mais fácil de identificar um charset seria colocar uma espécia de meta-dado no arquivo, como é (deveria ser) feito com páginas web (mas nem sempre funciona também por falhas nos programas!). E aí o arquivo deixaria de ser um arquivo de “texto puro”.

Enfim, não tinha uma solução para este “problema” e, pelo jeito, via que ninguém mais tinha, afinal o problema continuava existindo. Mas ele continuava me incomodando de tempos em tempos.

Até que li este texto do Joel. E aquietei meu espírito em relação a este problema. O texto inteiro é bom, especialmente a parte final The Single Most Important Fact About Encodings. E o que resume tudo é esta frase: There Ain’t No Such Thing As Plain Text. Ou, numa tradução livre: “Não existe algo como texto puro”.

Ou seja, tudo aquilo que é mostrado pelo programa que abre arquivos de “texto puro” é simplesmente uma abstração. Esqueça os caracteres. Eles são apenas interpretação dos dados reais binários. Qualquer representação dada a eles é apenas resultado de algum processamento por trás que tenta ou não identificar qual foi o charset usado para criar o arquivo.

Por mais óbvio que isso seja e por mais que eu soubesse disso, é engraçado como eu não ligava este simples fato à minha inquietudade em relação ao processamento de arquivos textos pelos programas.

Feito isso, com a ajuda do Joel, problema resolvido!

Integrando MailMan com servidor SMTP autenticado

Nota para referências futuras minhas e de quem se interessar pelo assunto.

A versão 2.1.12 (e provavelmente anteriores) do Mailman não prevê envio de email através de servidores SMTP que requerem autenticação. Para quem está tentando configurar um servidor de listas e precisa desta funcionalidade, pode ser problemático. Mas obviamente alguma boa alma no ciberespaço resolveu este problema, criando um PATCH. Como eu tive uma certa dificuldade de reencontrar o dito cujo, resolvi compartilhar a informação com vocês.

No diretório de instalação do mailman, abra o arquivo Mailman/Handlers/SMTPDirect.py. Salve uma cópia no mesmo diretório chamada ASMTPDirect.py. Adicione as seguintes linhas no método

__connect(self)
logo abaixo da linha
self.__conn.connect(mmcfg.SMTPHOST, mmcfg.SMTPPORT)


if mm_cfg.SMTP_AUTH:
     self.__conn.login(mm_cfg.SMTP_USERNAME, mm_cfg.SMTP_PASSWORD)

Pronto, já temos um handler de envio de mensagens via SMTP autenticado.

O próximo passo é configurar o sistema para usar este handler. Para isto, abra o arquivo mm_cfg.py, e adicione as seguintes linhas:

SMTPPORT = 25 SMTPHOST = 'smtp.server.com' SMTPUSERNAME = 'seuusuario' SMTPPASSWORD = 'suasenha' DELIVERYMODULE = 'ASMTPDirect' SMTPAUTH = 1

Resolvido!

Python de Bolso

Do site do Portable Python:

“Portable Python is a Python® programming language preconfigured to run directly from a portable device, enabling you to have, at any time, a portable programming environment. One of the most powerful dynamic programming languages that is used in a wide variety of application domains and is used at many companies and institutions around the world (YouTube, Google, NASA, Firaxis Games, etc.).”
Resumindo: leve seu Python em qualquer lugar. Me parece ser útil naquelas situações onde você tem um monte de scripts interessantes de manutenção/análise/diagnóstico e afins, e você precisa mexer em máquinas “peladas” e desconhecidas. Nunca precisei rodar algo em Python em situações emergenciais, mas várias vezes precisei mexer em máquinas com quase nada útil instalado, e sonhava em ter um canivete suiço digital naquele momento.

Foi nessas que eu aprendi a usar minimamente o Vi, que é seguramente o único editor de texto que você com certeza vai encontrar em QUALQUER ambiente UNIX/Linux.

Rapidinha sobre SQLite

SQLite é uma mão na roda para desenvolver pequenos aplicativos que precisem de uma base de dados, mas sem a necessidade de se ter um SGBD parrudo. Roda como biblioteca de um programa, é rápido nas buscas, faz grande parte das operações úteis sobre tabelas.

Ótimo para se trabalhar com Python, e bem útil no desenvolvimento de aplicações web com Django.

Mas em épocas de desenvolvimento, com uma parte do sistema em produção, o fato do SQLite não permitir alterar ou remover colunas de uma tabela é um fator bem limitante. Espero que eles adicionem estas funcionalidades em breve.

Next Page »

Switch to our mobile site