Image Image Image Image Image
Scroll to Top

Topo

cpython

05

jan
2012

Sem Comentários

Em Blog
Python
Rails
Ruby

Por Allison

Como Ruby vem ganhando a prefrência do Python para administração de sistemas

Em 05, jan 2012 | Sem Comentários | Em Blog, Python, Rails, Ruby | Por Allison

Há cerca de três anos, eu comprei o livro “Python for Unix and Linux System Administration“, e ele me convenceu de que o Python seria a linguagem padrão de scripts para administradores do sistema Linux no futuro próximo. Eu estava trabalhando no projeto One Laptop Per Child (Um Laptop Por Criança) na época, onde o Python era a linguagem comum. Parecia que o Red Hat estava usando o Python para quase todo novo projeto. Além disso, o Unladen Swallow estava fazendo um progresso rápido. Eu não poderia estar mais errado.

Através de uma combinação de acidente histórico e algumas diferenças de recursos aparentemente pequenas, o Ruby está, inexoravelmente, se tornando a linguagem padrão dominante para a administração do sistema Linux.

Antes de eu ir mais adiante, seus administradores de sistema estão provavelmente gritando “Nós já temos uma linguagem de scripts, Bash!”. Mesmo amando Bash e commandlinefu, o Bash se torna uma obrigação, não uma qualidade quando seu script excede 100 linhas, e um completo pesadelo se você precisa analisar ou dar saída em HTML, CSV, XML, JSON etc.

Acidentes históricos

Em 2004, Luke Kanies falou sobre a construção do Puppet, um sistema de gerenciamento de configuração para melhorar as deficiências que ele via na CFEngine. Do excelente blog On Ruby:

Eu tentei implementar minha ideia em Perl, mas eu simplesmente não conseguia fazer os relacionamentos de classe funcionar (todos atributos e tipos de recursos precisavam ser classes, de acordo com o design na minha cabeça). Isso era quando o Python era o melhor, então eu naturalmente o experimentei, mas o Python simplesmente faz meus olhos sangrarem (e não, não era o espaço em branco, eram coisas como o fato de que `print` era uma instrução em vez de uma função, e `len` era uma função ao invés de um método).

Eu tinha um amigo que tinha ouvido falar que o Ruby era legal, mas não tinha de fato testado. Como eu estava simplesmente à toa na época, pensei em dar uma olhada. Quatro horas depois, nunca tendo visto uma linha de Ruby antes, eu tinha um protótipo funcional.

Dois anos depois, muitos desenvolvedores Puppet sentiram que o Puppet não satisfazia suas necessidades. Eles começaram suas própria ferramenta de configuração de gerenciamento, Chef, largamente inspirada pelo Puppet. A grande diferença entre Puppet e Chef é que Chef utiliza Ruby puro como “receita”, enquanto o Puppet usa sua própria linguagem de configuração baseada no Ruby.

Ambos Puppet e Chef estão sendo adotados rapidamente por grandes empresas, de acordo com a BusinessWeek. Se você ainda não estiver usando Puppet ou Chef, você deve começar a planejar a usá-los no futuro. Seja escolhendo Chef ou Puppet, você terá efetivamente o script da sua infraestrutura em Ruby. Depois de gastar 25% do seu tempo trabalhando com Puppet, você estará muito mais inclinado a escolher o Ruby para sua própria tarefa de scripting.

Projetos populares


Aqui está uma lista não definitiva de projetos sysadmin/devops em ruby

  • puppet
  • chef
  • vagrant
  • mcollective
  • cucumber (behavior-driven testing)
  • capistrano
  • rake (ruby Make)
  • aeolus project/openshift
  • cloud foundry
  • graylog2
  • logstash
  • travis-ci

e em Python:

  • openstack
  • cobbler
  • fabric
  • func
  • buildbot

O que é importante aqui não é o comprimento das respectivas listas, mas a importância dos projetos individuais. Chef, Puppet e Vagrant são os novos martelos e chaves-de-fenda da administração de sistemas. Se você for um administrador de sistema e ainda não está usando essas ferramentas, não se preocupe, você irá, cedo ou tarde.

O Openstack merece uma atenção especial, e é um projeto muito animador, mas ainda está no seu estágio inicial. Ele pode representar um papel importante no seu futuro como administrador do sistema.

Por favor, me notifique de projetos devops significantes que estão faltando nessa lista.

O que um administrador de sistema quer

Aqui estão os recursos em uma linguagem script que um administrador de sistema quer:

  • Um DSL para o problema do domínio
  • Alta produtividade, por exemplo, sintaxe expressiva e concisa
  • Fácil interação com comandos shell
  • Expressões regulares
  • Comandos de linha poderosos

Note que desempenho não está na lista de necessidades. O Ruby é acentuadamente mais lento que o Pyhton, e isso era particularmente verdade para a série 1.8.* do Matz Ruby Interpreter (MRI). No entanto, desempenho simplesmente não é algo crítico para 90% do nosso trabalho como administradores de sistema. Nós nos importamos mais com produtividade do que com desempenho. Legibilidade é legal, mas está um segundo distante de produtividade.

O Python não tem expressões regulares nativamente, provavelmente para melhorar a legibilidade. Ele também limita o número de variáveis globais de alto nível embutidas. De uma perspectiva de design de linguagem, isso é muito mais limpo. Da perspectiva do seu administrador de sistema padrão, treinado na rua, estressado, viciado em VI, é irritante.

Essas variáveis de alto nível também deixam as ONE_LINERS mais concisas. Aqui estão algumas.

$_ last line read from STDIN
$? last exit code from a child process
$stdin reference to stdin
$stderr reference to stdout
$stdout reference to stdout

Aqui está uma sessão IRB para mostrar esses valores em ação.

hitman@hiroko:~/pr$ irb
irb(main):001:0> %x[ ls -a ]
=> ".\n..\nfoo1\nfoo2\nfoo3\n"
irb(main):002:0> puts $?
0
=> nil
irb(main):003:0> %x[ ls xys ]
ls: cannot access xys: No such file or directory
=> ""
irb(main):004:0> puts $?
512
=> nil

“IRB?” você me zomba, “Você terá que arrancar o IPython das minhas mãos mortas geladas.”

Eu adoro o IPython. Eu usei o IPython por mais de quatro anos, e o IRB não tem comparação a ele. Dito isso, os atalhos do Ruby são bastante úteis, o suficiente pra compensar as deficiências do IRB. Existe algo chamado wirble que eu ainda não tentei, mas ele pode deixar o IRB bem mais produtivo.

Aqui está algum código Python para detectar se uma máquina é VMware VM.

# edit: fixed python code tks to kstrauser

import os
  if 'vmware' in os.popen('dmidecode').upper():
    print 'this is a vmware vm'
  else:
    print 'this is not a vmware vm'

Aqui está o mesmo código em Ruby:

`dmidecode`
if $_ ~= /vmware/i
   puts 'this is a vmware vm'
else
   puts 'this is not a vmware vm'

Francamente, esse tipo de código faz meus olhos sangrarem. O exemplo do Python é muito mais legível e mais fácil de manter. Dito isso, muitos dos administradores de sistema iriam gostar de quão conciso é o exemplo do Ruby.

Vamos ver como escrever comandos de linha em ambas as linguagens.

O código imprime as primeiras 10 linhas em um arquivo usando Python.

python -c "import sys; sys.stdout.write(''.join(sys.stdin.readlines()[:10]))" < /path/to/your/file

Aqui está o mesmo código em ruby:

ruby -ne 'puts $_ if $. <= 10 ' < /path/to/your/file

Compare você mesmo essas coleções de oneliners no Python e no Ruby. Se o Ruby te lembra o Perl, seus olhos não te enganam. Em muitas maneiras, ele é o filho querido do Perl e do Smalltalk.

DSLs FTW

Há algum tempo, eu tentei assistir a todas as palestras da Structure and Interpretation of Computing. Todo esse esforço falhou miseravelmente, mas eu me lembro de Harold Abelson dizendo que todo grande programa deveria ter seu próprio DSL interno adequado para o problema de espaço. Isso é debatível devido ao grande mundo da programação, mas eu acredito estar apto para a administração de sistemas. Passamos toda nossa carreira com vários DSLs diferentes. Cada formato de arquivo com configuração diferente é seu próprio DSL.

Se você comparar o rake (Ruby Make) ao código rails, eles parecem muito diferentes, quase linguagens diferentes. Se você comparar o código fabric a uma classe django, eles se parecem muito. Isso é uma força e uma responsabilidade. Não sou nenhum advogado de linguagem, mas parece muito mais fácil criar DSLs (Domain Specific Languages). O Ruby certamente gera DSLs com uma frequência muito maior do que o Python. Nenhuma ferramenta de construção do Python domina o problema de espaço como o rake faz na comunidade Ruby. A maioria dos projetos Python parece usar setup.py para tarefas administrativas, mesmo este não sendo seu objetivo explícito.

Ambos, Puppet e Chef são DSL para administração de sistemas. O Capistrano é uma DSL para deploy de aplicações. Sobrecarga de operadores e os blocos do Ruby facilitam a criação de DSLs.

Em resumo

A maior força do Ruby é sua grande flexibilidade. Existe muita “mágica” no Ruby, e às vezes essa magia é negra. O Python intencionalmente tem o mínimo de mágica. Sua maior força é a capacidade de reforçar as boas práticas através da sua comunidade. Essas práticas tornam o Python bastante legível em vários projetos. Eles garantem alta qualidade de documentação, fazendo sua biblioteca padrão arrasar. Mas o fato é que nós sysadmin precisamos de flexilidade mais do que precisamos de poder ou consistência. Mesmo assim, esses não são os motivos reais pelos quais o Ruby está tomando o lugar do Python.

O Ruby está rapidamente se tornando a linguagem de script para os administradores de sistema porque, em 2004, Luke Kanies olhou para o Python e se sentiu doente (eu tive a reação oposta). Como um administrador de sistema, você ou está ou logo estará usando o Puppet ou o Chef diariamente, gastando muito tempo essencialmente codificando em Ruby. Pessoalmente, eu prefiro em Python, mas estou mudando a escrita dos meus scripts para Ruby porque passo muito tempo no Chef.

Texto original em inglês de Bryan Berry, disponível em http://devopsanywhere.blogspot.com/2011/09/how-ruby-is-beating-python-in-battle.html

Fonte: Bryan Willson Berry/IMasters

Tags | , , , , , ,

25

nov
2011

Sem Comentários

Em Blog

Por Allison

PyPy 1.7: o mais rápido interpretador de Python, ainda mais rápido

Em 25, nov 2011 | Sem Comentários | Em Blog | Por Allison

Foi lançado nesta semana, o PyPy 1.7, nova versão do interpretador da linguagem Python escrito inteiramente em Python. O principal foco desta versão foi o aumento de desempenho de bibliotecas, em relação ao CPython e ao próprio PyPy 1.6.

O PyPy é uma alternativa a outros interpretadores como CPython (o padrão), Jython e IronPython, e de acordo com os diversos benchmarks publicados, o mais rápido entre eles. Segundo os desenvolvedores do projeto, “se alguma implementação for mais lenta que o interpretador CPython, então é um bug”.

A performance excepcional do PyPy se deve principalmente ao seu compilador JIT. O interpretador já é suportado em Linux 32/64, MacOS 32/64, mas o atual release (com JIT) ainda não foi concluído para o Windows.

Algumas funcionalidades estão em fase avançada de desenvolvimento, mas ainda não ficaram prontas para este release:

  • Implementação especializada de listas: Está já em fase de testes a implementação de listas de inteiros/float/string compactadas como um array de arrays, o que deve aumentar a perfomance e reduzir o consumo de memória de algumas aplicações.
  • Duas novas implementações do compilador JIT direcionadas aos processadores PowerPC e ARM

Para conhecer mais sobre o PyPy, fazer o download ou ajudar nos testes da plataforma, visite a página oficial do projeto.

Fonte: Rafael Nunes/InfoQ

Tags | , , , , , , , ,

10

set
2011

Sem Comentários

Em Blog

Por Allison

Python no Visual Studio agora é cidadão de primeira classe

Em 10, set 2011 | Sem Comentários | Em Blog | Por Allison

A Microsoft lançou uma extensão para desenvolvimento em Python no Visual Studio 2010. A ferramenta Python Tools for Visual Studio, de código aberto (licença Apache 2.0), oferece suporte a CPython, IronPython, Jython e PyPy.

Entre as principais funcionalidades do Python Tools, estão recursos avançados de edição de código, como IntelliSense e a localização de referências (Find all Refs), o comando Go to Definition e um navegador de objetos (Object Browser). Há ainda métodos de refatoração, como “Extract Method” e uma janela nativa para REPL (read-eval-print loop). O suporte para depuração, profiling local e remoto, e clusters HPC e MPI são outros destaques. Para desenvolvimento com HPC, é necessário obter o SDK, também gratuito, separadamente.

Após a instalação do Python Tools, são disponibilizados quatro templates de projetos: o mais flexível é o Python Application, em que há a opção de escolher o interpretador/runtime para execução das aplicações; os outros três, todos para o interpretador IronPython, facilitam a criação de aplicações Winforms, Silverlight e WPF.

No mesmo anúncio, a Microsoft informou o lançamento dos pacotes NumPy e SciPy para IronPython e .NET.

Há um bom screencast mostrando como utilizar o Python Tools. A extensão pode ser obtida no site oficial do projeto, no Codeplex.

Fonte: Elemar Jr./InfoQ

Tags | , , , , , ,

25

ago
2011

Sem Comentários

Em Blog

Por Allison

PyPy 1.6 implementa Python 2.7

Em 25, ago 2011 | Sem Comentários | Em Blog | Por Allison

O PyPy anunciou o lançamento da versão 1.6 do seu interpretador Python integrado com rastreamento Just-in-Time (JIT). De acordo com os desenvolvedores, a versão implementa totalmente o Python 2.7.1, além de trazer maior velocidade e melhorias na estabilidade.

Com o codinome “Kickass Panda”, o PyPy 1.6 está 30% mais rápido que a versão anterior e vem com melhorias de desempenho, que incluem maior rapidez no tempo de aquecimento JIT e melhor funcionalidade do Garbage Collector.

A ferramenta web-based JitViewer está incluída para ver quais partes do código foram compiladas utilizando JIT. O módulo de extensão API para CPython, o intérprete padrão C para Python, agora inclui suporte para outras extensões.

Fonte: Under-Linux

Tags | , , , , ,