Image Image Image Image Image
Scroll to Top

Topo

Rails

SWX Labs 05 – Projeto 14 Bis

Em 10, fev 2014 | Sem Comentários | Em Blog, Cloud Computing, Código, Destaques, Rails, Ruby, Sistemas, SWX Labs | Por Mike Lopes

BisOn

No SWX Labs 05 Mike, Ighor, Tássio e principalmente Vinicius , falam sobre o principal projeto em curso na SWX, o 14 BIS.

Saiba a proposta do projeto, como ele surgiu, conseguiu financiamento e está sendo desenvolvido. Além disso, conheça uma história que fala sobre empreendedorismo e dedicação, e o saiba um pouco mais do dia a dia de uma Startup e de como executar um projeto de software.

Ouça o podcast clicando no play, se preferir faça o download

Links

Assine o feed do nosso podcast e não perca nenhum episódio: http://feeds.feedburner.com/SWXLabs

Se preferir, também estamos no Itunes Store

Gostou? Não gostou? Erramos algo? Sua opinião é muito importante para nós, por isso deixe seu comentário ou envie email para mike@swx.com.br

Temas abordados:

  • O que é o 14 BIS

    • Definição

    • CIO Market

    • Vantagens

  • Histórico

    • Surgimento da SWX

    • Insight: Problemas de instalação e manutenção de software para pequenas e médias empresas

    • Inspiração: Loja de aplicativos (Google Play e Apple Store)

    • Solução: Loja de aplicativos que automatiza a instalação de softwares

    • Histórico do desenvolvimento do 14 BIS

  • Processo de desenvolvimento do 14 BIS

    • Seleção de desenvolvedores

    • Andamento do desenvolvimento dos módulos

    • Importância da parceria com a Universidade Federal de Sergipe

  • 14 BIS na prática

    • Como funciona para comprador e fornecedor de software

    • Diferenciais competitivos

  • O futuro do 14 BIS

    • Consolidação dos grupos de projeto

    • Aumento das opções de infraestrutura de nuvem

    • Transformação do CIO Market em plataforma (plataforma como serviço)

 

 

 

Tags | , , , , , ,

22

jan
2014

Sem Comentários

Em Blog
Código
Rails
Ruby

Por Mike Lopes

Model em Ruby on Rails – Parte 02

Em 22, jan 2014 | Sem Comentários | Em Blog, Código, Rails, Ruby | Por Mike Lopes

* Por João Paulo

Veja a parte 01

ruby-on-rails

Um model é uma classe que herda da classe ActiveRecord::Base e está associada a uma tabela.

O arquivo do model possui o nome da tabela em minúsculo no singular (“nomedatabela.rb”) e a classe o nome em CamelCase (“class NomeDaTabela”).

É possível criar o model manualmente, porém o Rails possui um generate que cria o model, o migration e a tabela dinamicamente. Funciona no seguinte formato:

rails g model <Model> <Campo1>:tipo <Campo2>:tipo <Campon>:tipo

 ex.: A tabela “produtos”, gerada anteriormente, poderia ser gerada da seguinte forma: será gerada a tabela, o model e a migration pra ela.

rails g model Produto name:string

 Nota: Caso a tabela já tenha sido criada, é necessário adicionar o parâmetro “–force” no generate para reexecutar a migration.

 _mvc

Para acessar um campo pelo controller é necessário criar os métodos que irão ler e escrever o campo, por exemplo, para um campo “nome” ser lido, tem que ser criado o método “nome” e para gravar deverá ser criado o método “nome=”.

class table1 < ActiveRecord::Base

def nome

self[:nome]

end

def nome=(novoNome)

self[:nome] = novoNome

end

end

 

 Nota: É possível usar attr_accessor, attr_reader e attr_writer.

 Para definir um relacionamento no model é necessário chamar o método com o nome do relacionamento (belongs_to, has_one, has_many, …) e o nome na tabela. Esse relacionamento será feito a partir do id. Ex.:

class table1 < ActiveRecord::Base

belongs_to :table2

end

 

relacionará o campo “table2_id” da “table1” com o campo “id” da “table2”.

 Relacionamentos:

  • belongs_to (pertence à): Define que um registro de um model está ligado a um registro de outro model e pertence a ele numa relação “um pra um”, por exemplo, em  uma tabela com reitores e outra com universidades, “um reitor pertence a uma universidade”, assim a tabela “universidade” deverá ter um campo “reitor_id”.
  • has_one (“contém”): Define que um registro model contém outro de outro model numa relação “um pra um” (o contrário de belongs_to), no exemplo do belongs_to, temos que uma “universidade contém um reitor”.
  • has_many (“contém muitos”): Define que um registro de um model contém muitos registros de outro model. Por exemplo, um cliente pode ir a uma loja comprar vários produtos, assim à relação será “cliente contém muitos produtos”, logo a tabela “produtos_vendidos” terá um campo “cliente_id”.
  • has_and_belongs_to_many (“contém e pertence a vários”): Define que vários registros de um model está associado a vários de outro model. Por exemplo, em um sistema de vendas, existe uma tabela “pedidos” que associa vários registros da tabela “produtos” a um da tabela “cliente”, pois um cliente compra vários produtos; porém, também associa vários da tabela “clientes” a um da tabela “produtos”, pois um produto é comprado por vários clientes.

 

Validações:

 Em um model é necessário validar se os dados são válidos antes de salvar no banco de dados, para validar é necessário definir o método no formato:

“validates :<campo>, <validação>”.

 ex.: O campo “nome” da tabela “table1” será obrigatório.

class table1 < ActiveRecord::Base

validates :nome, presence: true

end

Existem vários helpers para validação, como, por exemplo, garantir que apenas números são esperados:

class table1 < ActiveRecord::Base

validates :value, numerically: true

end

Para mais helpers acesse: http://edgeguides.rubyonrails.org/active_record_validations.html#validation-helpers

É possível definir mensagens para caso ocorra um erro na validação, ou seja, para quando um valor passado não estiver de acordo com a validação:

class table1 < ActiveRecord::Base

validates :nome, presence: true, :message => “O nome é obrigatório.”

end

É possível definir a validação para uma determinada ação (create, update, …):

class table1 < ActiveRecord::Base

validates :nome, presence: true, on: :update

end

 

Validações por métodos customizados:

class table1 < ActiveRecord::Base

validate :método, on: :create

 

def metodo

if (campo1 > 10)

erros.add(:value_error, “O número tem que ser maior que 10”)

end

end

 

Informações sobre validações: http://edgeguides.rubyonrails.org/active_record_validations.html#validation-helpers

Documentação completa: http://api.rubyonrails.org/

* João Paulo é estudante de Computação e estagiário da SWX

Tags | , , , ,

15

jan
2014

Sem Comentários

Em Código
Rails
Ruby

Por Mike Lopes

Model em Ruby on Rails – Parte 01

Em 15, jan 2014 | Sem Comentários | Em Código, Rails, Ruby | Por Mike Lopes

Por João Paulo*
ruby-on-rails

O model é o componente da arquitetura de software MVC que faz a comunicação com o banco de dados (acessar e editar o banco de dados), ou seja, é no model que ficam as regras de negócio. O Rails conta com uma biblioteca para o desenvolvimento dos models de forma rápida, segura e organizada, essa biblioteca é chamada de ActiveRecord. No Rails, o model faz referências a uma tabela no banco, logo se existir um model, existe uma tabela associada a ele (essa é a ideia básica, mas não uma regra, pois é possível ter um model não associado a uma tabela).

É possível criar uma tabela manualmente, porém para alterá-la é necessário alterar manualmente em cada máquina que estiver o projeto, o que torna um processo trabalhoso, então, com o objetivo de  resolver esse problema, o Rails possui o ActiveRecord::Migrations que uma classe do ActiveRecord que define a tabela de forma que cada alteração seja facilmente enviada a todas as máquinas com o projeto. O modelo abaixo é de uma migration (nome dado a classe que herda de ActiveRecord::Migrations) em que é criada uma tabela chamada “produtos” e um campo “nome”:

ActiveRecord

class CreateProductos < ActiveRecord::Migration
	def change
		create table :produtos do |t|
			t.string :nome
		end
	end
end

O método change suporta:

  • add_column

  • add_index

  • add_reference

  • add_timestamps

  • create_table

  • create_join_table

  • drop_table (must supply a block)

  • drop_join_table (must supply a block)

  • remove_timestamps

  • rename_column

  • rename_index

  • remove_reference

  • rename_table

As migrations ficam salvas como: db/migrate/<timestamp>_<migration>.rb.

O comando “rake db:migrate” executa, no console, as migrations que ainda não foram executadas.

Para mais informações sobre migrations: http://guides.rubyonrails.org/migrations.html

É possível gerar, de forma dinâmica, uma migration a partir do console.

Abaixo estão apresentados alguns comandos:

Criar tabela:

rails g migration Create<Tabela> < campo1>:tipo <campo2>:tipo <campon>:tipo

Ex.: será criada uma migration chamada “CreateProducts” com o nome “products”:

rails g migration CreateProducts name:string

Adicionar coluna em uma tabela (depois da tabela ter sido criada):

rails g migration Add<Coluna>To<Tabela> <nome_da_coluna>:tipo

Ex.: será criada uma migration “AddRefToProducts” que acrescentará uma coluna chamada “ref” a tabela “products”:

rails g migration AddRefToProducts ref:string

Nota: é possível usar “rails generate…” ou simplesmente “rails g…”, pois eles são equivalentes.

Para mais informações sobre o rails generate acesse: http://guides.rubyonrails.org/migrations.html#creating-a-migration

* João Paulo é estudante de Computação e estagiário da SWX

Tags | , ,

Enciclopédia do Heroku

Em 23, ago 2012 | Sem Comentários | Em Arquitetura, Cloud Computing, Rails | Por Vinicius AC

Fonte: AkitaOnRails

Atualização 05/06: Depois que escrevi este artigo, encontrei um outro muito bom que recomendo a leitura por ter mais detalhes para complementar. O artigo se chamaHeroku isn’t for Idiots

Se você quer lançar uma aplicação Rails rapidamente, não existe melhor solução do que o Heroku. Para quem não conhece, o Heroku é um Paas (Platform as a Service) que roda sobre o Amazon EC2 (que é um IaaS ou Infrastructure as a Service). O Heroku automatiza a criação de uma nova máquina virtual (volátil! isso é importante) e configura todo o ambiente para rodar Ruby.

O Heroku usa uma unidade de máquina virtual chamada “Dyno”, a grosso modo, considere um Dyno como uma máquina virtual “pequena” com 4 cores e até 512Mb de RAMsem swap file e sem suporte a persistência de arquivos (não faça uploads diretamente no diretório public/uploads ou algo assim, sempre configure para mandar para a Amazon S3, aprenda como neste tutorial). Configurar um novo ambiente é simples, o próprio Heroku tem uma boa documentação ensinando como e recomendo ler antes de continuar.

Subir uma única dyno usando um banco de dados compartilhado PostgreSQL é de graça, o que é excelente para testar sua aplicação. Obviamente apenas um único dyno é pouco para qualquer aplicação séria lançada em produção para o público.

O Heroku fornece “stacks” padrão que é o perfil pré-configurado de um dyno para uma determinada plataforma. Para Ruby e Rails a mais atual (na data de publicação deste post) é a Celadon Cedar, a anterior era a Badious Bamboo portanto se encontrar um tutorial qualquer de Heroku por aí, cheque sobre qual stack estamos falando, só use se for para Cedar.

Concorrência num Dyno

A primeira coisa que me chamou a atenção é que a configuração recomendada é executar uma aplicação Ruby usando o servidor Thin. Pense no Thin como uma evolução do venerado Mongrel mas que suporta executar Eventmachine internamente. Na prática é um Mongrel melhorado, o que significa que cada Dyno, por padrão, não suporta mais do que 1 única execução concorrente (não confundir com “requisições por segundo”!! Muita gente erra isso. Um único processo com uma única execução concorrente pode executar várias requisições por segundo, basta cada requisição demorar menos de 1 segundo).

Executar múltiplos Thins poderia ser possível mas se queremos mais processos rodando simultaneamente para responder mais requisições ao mesmo tempo, a melhor opção é usar Unicorn. Leiam a documentação para aprender as peculiaridades do Unicorn, na prática pense nele como um controlador de processos Ruby. O melhor tutorial para usar Unicorn no Heroku continua sendo o do Michael van Rooijen. Não vou repetir tudo que ele disse, mas as partes importantes são:

Substituir a gem thin pela unicorn na sua Gemfile:

group :production, :staging do
  gem 'unicorn'
  ...
end

Em seguida precisamos declarar quantos processos do Unicorn queremos de cada vez, então crie um arquivo config/unicorn.rb com o seguinte:

worker_processes 4 # amount of unicorn workers to spin up
timeout 50         # restarts workers that hang for 30 seconds

Leiam atentamente o post original do Michael, ele explica alguns benchmarks que ele fez para determinar a quantidade ótima de workers de Unicorn e o ideal é entre 3 e 4 processos. A informação não-oficial que eu tenho é que cada dyno tem até 4 CPUs, o que justifica esse número de processos. Mais do que isso, chequem sempre quanto de memória cada processo consome (ferramentas como NewRelic ajudam nisso) pois a somatória precisa ser menor que 512Mb ou você terá problemas.

Finalmente, a stack Cedar permite configurar perfis de dynos num arquivo chamado Procfile que fica na raíz do seu projeto. Para que a dyno levante com Unicorn coloque o seguinte:

web: bundle exec unicorn -p $PORT -c ./config/unicorn.rb

Continue aqui: http://www.akitaonrails.com/2012/04/20/heroku-tips-enciclopedia-do-heroku?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+AkitaOnRails+%28Akita+On+Rails%29#.UDYbXdZlT3w

Tags | , , ,

10

abr
2012

Sem Comentários

Em Blog
Rails
Ruby

Por Allison

Puma, novo servidor web para Ruby, é disponibilizado

Em 10, abr 2012 | Sem Comentários | Em Blog, Rails, Ruby | Por Allison

Fonte: IMasters

Com informações de The H

A especialista em Ruby on Rails Platform-as-a-Service, Engine Yard, divulgou um novo servidor web para Ruby, que recebeu o nome de Puma. De acordo com seus desenvolvedores, o Puma foi criado como uma alternativa para WEBrick e Mongrel, e foi construído para ter melhor desempenho e para lidar com concorrência.

A novidade trabalha com qualquer aplicativo que suporte a interface Rack, além de processar requisições usando o Ragel, uma extensão otimizada em C, que oferece rápida análise do protocolo HTTP 1.1, atrás do qual oferece a solicitação em uma thread a partir de uma pool de threads. O Puma foi feito para ser um servidor “go-to” para Rubinius, e também trabalha com JRuby and Ruby MRI.

Mais informações sobre o Puma, incluindo um guia e benchmarks, podem ser encontrados no site do projeto e neste link. O código fonte do novo servidor web está hospedado no GitHub.

Tags | , , ,

10

abr
2012

Sem Comentários

Em Blog
CSS
Rails
Ruby

Por Allison

Como gerar gráficos no Rails com o CSS Graphs

Em 10, abr 2012 | Sem Comentários | Em Blog, CSS, Rails, Ruby | Por Allison

Fonte: Samuel Vinicius/IMasters

Post Original http://nubyonrails.com/pages/css_graphs

O CSS Graphs é um bom plugin para quem deseja gerar gráficos no Ruby on Rails usando apenas CSS. Para quem ainda tem alguma dúvida, veja como utilizá-lo:

Instalação

./script/plugin install http://topfunky.net/svn/plugins/css_graphs

Como usar

Para usá-lo, o seguinte código basta:

<%= bar_graph  [ ['Rails', 24],
                    ['Open', 9],
                    ['Css', 81],
                    ['Gráficos', 57],
                    ['Samuel', 42]] %>

Ou:

<%= complex_bar_graph  [ ['Rails', 24],
                  ['Open', 9],
                  ['Css', 81],
                  ['Gráficos', 57],
                  ['Samuel', 42]]%>

Tags | , , , ,

30

mar
2012

Sem Comentários

Em Blog
Rails
Ruby

Por Allison

Segundo release candidate do Ruby on Rails 3.2.3 é lançado

Em 30, mar 2012 | Sem Comentários | Em Blog, Rails, Ruby | Por Allison

Fonte: IMasters

A equipe de desenvolvimento do Ruby on Rails anunciou hoje a chegada do segundo release candidate da versão 3.2.3.

O Rails 3.2.3 trouxe uma nova opção que permite que o usuário controle o comportamento de formulários remotos relacionados à geração authenticity_token. Aqueles que querem fragmentar seus formulários em cache verão que o token de autenticação também serão também serão armazenados em cache, o que não é aceitável. Entretanto, se esses formulários forem usados apenas com Ajax, é possível desabilitar a geração de token, porque ela será buscada com a meta tag.

Com a versão 3.2.3, há a opção de parar de gerar authenticity_token em formulários remotos, configurando config.action_view.embed_authenticity_token_in_remote_forms = false. Essa ação vai impedir o envio desses formulários com o javascript desabilitado. Caso a opção de não gerar o token em formulários remotos seja escolhida por padrão, é possível ainda explicitar :authenticity_token => true ao gerar o formulário para contornar essa configuração.

A opção padrão é true, o que significa que aplicativos já existentes não são afetados.

O RC inclui essa mudança no authenticity_token e duas correções para bugs. Caso não haja maiores impedimentos, a versão final deve ser liberada amanhã.

Detalhes sobre as mudanças que a nova versão traz podem ser encontrados no anúncio de lançamento.

Tags | , ,

30

jan
2012

Sem Comentários

Em Blog
Rails
Ruby

Por Allison

Ruby on Rails 3.2.0 é liberado

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

Com informações de BR-Linux

Fonte: IMasters

A versão 3.2.0 do framework Ruby On Rails foi liberada, e ela será a última a suportar o Ruby 1.8.7, já que a próxima versão do Rails (4.0) exigirá o Ruby 1.9.3.

O Ruby on Rails 3.2.0 traz três grandes novidades. Uma delas é um modo de desenvolvimento sensivelmente mais rápido. Inspirado pelo Active Reload, o Rails recarrega classes apenas quando o arquivo é alterado. O ganho de desempenho é dramático em grandes aplicações. O Route recognition também ficou mais rápido graças a um novo motor (engine) Journey.

Além disso, a nova versão traz uma nova funcionalidade que detalha as consultas geradas pelo ARel, bastando definir um método de detalhe em ActiveRecord::Relation. Por exemplo, é possível rodar algo como ‘puts Person.active.limit(5).explain’, e a consulta ARel é explicada. Isso permite checar índices e realizar otimizações.

A outra grande novidade é o Tagged Logging. Ao executar uma aplicação multi-usuário, é de grande ajuda conseguir filtrar o log por quem fez o quê. O TaggedLogging em Active Support ajuda a fazer isso ao marcar linhas de código com sub-domínios, ids de requisições, e qualquer coisa para ajudar a debugar a aplicação.

Mais informações sobre o Ruby on Rails 3.2.0 podem ser encontradas nas notas de lançamento.

Tags | , , , ,

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

dez
2011

Sem Comentários

Em Blog
Rails
Ruby

Por Allison

DataTables com RubyOnRails

Em 25, dez 2011 | Sem Comentários | Em Blog, Rails, Ruby | Por Allison

Introdução

Para quem não conhece ou não tem muita experiência com a utilização de plugins para Javascript, vamos mostrar a implementação básica do plugin para jQuery: o chamado DataTables.

DataTables é um plugin para jQuery que proporciona uma interação maior com a tabela do HTML. Em grossas palavras, ele transforma sua tabela em um componente mais útil adicionando como por exemplo: paginação e campo de busca.

Visão Geral

  • O artigo se baseia no exemplo disponível no github.
  • Para quem não está familiarizado, estou utilizando a gem HAML, que é apenas uma forma diferente de escrever HTML. Isso não irá interferir em nada a não ser o modo de escrever o HTML mesmo.
  • Estou considerando que você já tenha conhecimento de projetos RubyOnRails e que seu projeto já esteja utilizando o jQuery. Isso é estritamente necessário para que funcione o DataTables.

Obtendo o DataTables

O primeiro passo é fazer o download do plugin e adicionarmos ele em nossa aplicação. Basta clicar aqui para fazer o download.

Descompactando arquivos úteis

Após descompactar, voce irá notar que ele tem vários arquivos e nem todos serão úteis para nossa aplicação. Precisaremos apenas dos arquivos que se encontram no diretório media.

Copie este diretório para dentro do diretório javascripts da sua aplicação e renomeie para datatables.

Incluindo arquivos

Agora já temos os arquivos necessários para utilizar o DataTables. Porém, precisamos fazer a inclusão desses arquivos em nosso projeto.

Lembrando que devemos incluir os arquivos Javascript e os arquivos de CSS.

#css
= stylesheet_link_tag "/javascripts/datatables/css/demo_table.css"
#javascripts
= javascript_include_tag "datatables/js/jquery.dataTables.min.js"

Criando uma tabela

Sua tabela não pode ser criada de qualquer jeito. O DataTables necessita que sua tabela esteja conforme o exemplo abaixo.

%table.example
%thead
%tr
%th Id
%th Name
%tbody
%tr
%td 1
%td "Carro"
%tr
%td 2
%td "Moto"

Uma observação: é necessário que sua tabela possua as tags <thead> e <tbody>

Transformando a tabela em DataTables

Feito isso, agora vamos apenas chamar o método do DataTables que irá transformar a nossa tabela. Basicamente é pegarmos a tabela e chamarmos o método dataTable(). Deverá ficar similar ao exemplo abaixo:

-content_for :javascript do
:javascript
$("table.example").dataTable();

Pronto, já temos o DataTables funcionando. Muito simples. Ele possui melhores personalizações que você poderá ver no projeto de examplo que criei. O que foi dito acima é apenas o básico.

Informações sobre o exemplo

O exemplo que se encontra no meu github possui as seguintes características:

Ruby 1.9.2-p290
Rails 3.0.10
haml 3.1.2
jquery-rails 1.0.13
sqlite3
ffaker 1.8.1

Fonte: Adriano Todao/IMasters

Tags | , , , ,