Tag Archives: ruby

Quem disse que aprender ruby seria fácil?

by

Semana passada vi que o Renato Molina compartilhou um post muito interessante: “Ruby rocks and Java sucks?“. É claro que o post se trata da velha história, não existe bala de prata, use a melhor ferramenta para o determinado tipo de problema. Particularmente eu gosto muito de ruby <3 e tenho a felicidade de utilizar ruby para resolver boa parte dos meus problemas.

É claro, você vai achar um milhão de posts pela internet sobre como ruby é elegante, como ruby on rails é produtivo, como a sintaxe é mais limpa que a do Java e etc. Isso tudo é verdade, porém isso não significa que programar em ruby seja fácil.

Outro dia desses estava conversando com o Guilherme Vinícius sobre o trabalho que estamos realizando com o GURU Sorocaba. Nos últimos 12 meses realizamos um dojo, algumas palestras, alguns cursos e também encontros com palestrantes de altíssimo nivel.
Todo esse trabalho tem sido muito gratificante e válido, estamos conseguindo movimentar uma comunidade em torno do ruby aqui em Sorocaba. Muitas pessoas estão se conhecendo e evoluindo muito (inclusive nós mesmos). Porém, confesso que esperava um pouco mais de resultado. Gostaria de ver mais negócios surgindo, mais pessoas trabalhando com ruby, mais projetos sendo criados com ruby on rails e principalmente mais pessoas programando em ruby.

Em maio, durante a SeCOT da UFScar Sorocaba, conversei bastante com o Fabio Akita e um dos assuntos foi o mercado de trabalho. Sempre vejo nos noticiários matérias falando sobre a falta de bons profissionais no segmento de tecnologia de informação, de como estamos com um gap imenso de programadores. Está extremamente difícil encontrar bons programadores ruby, até mesmo desenvolvedores que tem pouca experiência com rails estão empregados devido a escassez de desenvolvedores.

Se ruby é simples, se ruby on rails é tão produtivo, se tantas pessoas gostam de ruby, por que há essa falta de bons programadores no mercado?

Eu me fiz essa pergunta durante vários dias. A conclusão que cheguei é bem simples: programar é uma arte complexa, difícil e que exige muito esforço. Sem dúvida que ruby é uma linguagem simples e que o rails nos ajuda a ser muito produtivos, mas isso não significa que é fácil. E no fundo isso vale para outras tecnologias como java por exemplo. Um programador não se torna bom do dia para a noite, sem um determinado esforço. Você tem que buscar a excelência a cada dia.

Ou seja, você precisa sair da sua zona de conforto! Acordar cedo no fim de semana e ir nos encontros, investir uma grana para ir nos eventos, ler vários artigos na internet, ler livros técnicos, fazer cursos e o principal: programar, programar e programar.

Mas não se preocupe, se quiser ser só mais um na média, as fábricas de software também estão contratando =p

CouchRest Model Slug

by

This is the first time that I blog in english, so please correct me if I write something wrong. Suggestions are welcome too =)

CouchDB automatically generates UUIDs if none are provided. Usually, it’s recommended because some things like replication. However, we can do better for users. UUIDs are ugly, then we can create friendly urls.
CouchRest Model Slug is a simple gem to generate better urls using CouchRest Model in an easy way. I created this gem based on Mongoid Slug.

Getting Started

Add to Gemfile

gem "couchrest_model_slug", "~> 0.0.2"

A simple example

class Post < CouchRest::Model::Base   
  include CouchRest::Model::Slug   

  property :title   
  property :text   

  slug :title 
end

Querying

 
p = Post.create(:title => "CouchDB Time To Relax")
p.to_param # => "couchdb-time-to-relax"

Post.find("couchdb-time-to-relax") # =>#<Post slug: "couchdb-time-to-relax", title: "CouchDB...

CouchRest Model Slug was made to work with or without slugged value, then it uses the id to keep things running with no problems.

Post.create(:text => "post without slug") # => #<Post slug: "", title: nil, text: "post with no slug", _id: "9fdfdd090897680de59091c8c98ff064"...

Post.find("9fdfdd090897680de59091c8c98ff064") # => #<Post slug: "", title: nil, text: "post with no slug", _id: "9fdfdd090897680de59091c8c98ff064"...

See the github page for more information https://github.com/lucasrenan/couchrest-model-slug

Vaga desenvolvedor Ruby on Rails

by

Galera, já faz quase um ano que estou trabalhando para a nu design e nós estamos contratando programadores ruby \0/

A nu é um estúdio de design gráfico de São Paulo, com um trabalho forte em web. O estúdio é consagrado pelo bom desenho e por ter uma pesquisa permanente, também na área do desenvolvimento. Informal e descontraído –porém extremamente profissional e produtivo– o estúdio mantém uma equipe de ponta que trabalha duro (apenas durante a semana!) para entregar o próximo projeto sempre melhor que o anterior.

desenvolvedor ruby on rails

requisitos

– experiência em ruby
– testes automatizados
– xhtml / css
– javascript / jquery

diferenciais

– mongodb
– rspec (tdd e bdd)
– práticas ágeis (scrum e xp)
– nginx e passenger

é seu perfil? envie seu cv e usuário do github para contrata@nudesign.com.br

Sinatra – Uma DSL Ruby

by

Quem não está muito ligado na comunidade Ruby talvez só tenha ouvido falar sobre o Rails. É claro que o Rails é o framework mais famoso de Ruby e vem ajudando a alavancar o crescimento da linguagem, porém existem outros frameworks e DSLs em Ruby. Uma DSL muito boa é o Sinatra. O Sinatra é uma DSL para se criar aplicações web de maneira rápida e com o mínimo de esforço. (eu aprendi a utilizá-lo com o Anderson Leite da Caelum)

O Sinatra possui algumas diferenças com relação ao Rails como por exemplo, não segue o padrão MVC. Seu uso é recomendado para resolver problemas pequenos e é realmente bem fácil utilizá-lo.

Vamos supor que você precise fazer algo simples como criar uma listagem qualquer ou qualquer outra coisa simples não compensando o desenvolvimento em Rails. (hoje eu precisei criar um sitemap com alguns dados da minha aplicação, bem simples, algo que não seria necessário agregar ao escopo da minha aplicação Rails).

Antes de começar é necessário instalar o Sinatra

sudo gem install sinatra

Vou utilizar também o MySQL e o Data Mapper como ORM

sudo gem install dm-core
sudo gem install dm-mysql-adapter

Supondo então que quero fazer uma simples consulta em uma tabela posteriormente criada e com dados cadastrados.
Crie o arquivo my_sinatra.rb com seu editor preferido

require 'rubygems'
require 'sinatra'
require 'dm-core'

#conexao com mysql
DataMapper.setup(:default, "mysql://user:pass@localhost/database")

#classe qualquer
class Product
  include DataMapper::Resource

  property :id, Serial
  property :name, String
  property :status, String

  def self.active
    all(:status => "A")
  end
end

#listando produtos ativos
get '/' do
  @products = Product.active 
  erb :index
end

#utilizando SQL diretamente
get '/sql' do
  @products =  repository(:default).adapter.select("SELECT * FROM produtos WHERE status = 'A'")
  @products.collect{|p| p.id.to_s + " "}
end

Crie também uma pasta chamada views e o arquivo index.erb

<% @products.each do |p| %>
  <%= p.name %><br />
<%  end %>

Para startar a aplicação

ruby my_sinatra.rb

O Sinatra roda na porta 4567 (http://localhost:4567/)
Repare que as urls são definidas no início do bloco: get ‘/’ do…

Para complementar o post, recomendo a leitura:
http://www.sinatrarb.com/intro
http://datamapper.org/getting-started

CakePHP vs Ruby on Rails

by

O CakePHP é um framework para desenvolvimento rápido de aplicações em PHP. Baseado no Ruby on Rails, segue o paradigma da convenção sobre configuração. Usa design patterns como MVC e ORM, reduz os custos de desenvolvimento e ajuda os desenvolvedores a escreverem menos código.

Apesar de ser um bom framework e ser baseado no Rails, a principal diferença que faz o Rails mais vantajoso (fora o nível da comunidade ruby ser maior que o nível da comunidade php) é a própria sintaxe do Ruby em relação ao PHP. Eu particularmente recomendo fortemente o desenvolvimento em PHP utilizando o CakePHP, mas na minha opinião nada supera o Rails.

Abaixo segue um exemplo de uma consulta (inner join) entre dois modelos (Agencia e Cidade que possuem um relacionamento has_and_belongs_to_many) para uma consulta em que devem ser listadas as cidades (distintamente) que possuem relacionamento com agências ordenadas pelo nome:

O SQL esperado

SELECT cidades.id, cidades.nome FROM `cidades` INNER JOIN agencias_cidades ON (`agencias_cidades`.`cidade_id` = `cidades`.`id`) GROUP BY `cidades`.`id` ORDER BY `cidades`.`nome` ASC

Um possível exemplo no CakePHP (no controller agencias)

function index() {

        $cidades = $this->Agencia->Cidade->find('all', array(
            'recursive' => 0,
            'fields' => array('Cidade.id, Cidade.nome'),
            'joins' => array(array(
                'table' => 'agencias_cidades',
                'type' => 'INNER',
                'conditions' => array('agencias_cidades.cidade_id = Cidade.id')
            )),
            'order' => array('Cidade.nome'),
            'group' => array('Cidade.id')
        ));
        
        $this->set('cidades', $cidades);
}

Um possível exemplo no Ruby on Rails (no controller agencias)

def index
	@cidades = Cidade.all :select => "cidades.id, cidades.nome",
        :joins => "INNER JOIN agencias_cidades ON (`agencias_cidades`.`cidade_id` = `cidades`.`id`)",                          
        : order => "cidades.nome",
        :group => "cidades.id"
end

Esse é um exemplo bem simples, porém fica nítido a simplicidade do código, mesmo sem levar em consideração que no Rails bastaria uma linha em cada modelo para definir o relacionamento, enquanto que no Cake seria necessário mais linhas.

Recommend Me

Por que as empresas perdem bons desenvolvedores?

by

A “implantação” do sistema neoliberal no Brasil (e em outros lugares do mundo) contribuiu para o aumento da competitividade entre as empresas e também entre os profissionais. A busca por uma melhor qualificação profissional se tornou constante, devido ao fato de que as empresas passaram a exigir profissionais com alto nível de conhecimento técnico e a concorrência cada vez mais acirrada.

Não é preciso ter muito conhecimento de economia ou política para se perceber que o capitalismo é um sistema que não tem como objetivo favorecer o trabalhador. Com todos os problemas do mundo, muitas pessoas se sujeitam a péssimas condições de trabalho para garantir o sustento de suas famílias.

O desenvolvimento de software é uma tarefa criativa que exige profissionais com alto grau de conhecimento técnico. Não é uma tarefa braçal, isso quer dizer que o desenvolvedor tem seu capital intelectual como instrumento de trabalho.
Devido a tamanha complexidade das tarefas, é muito difícil encontrar bons profissionais (desenvolvedores, programadores, analistas, engenheiros etc) comparado a outras áreas profissionais em que o mercado já possui certa saturação de mão de obra.
Isso faz com que o profissional de tecnologia da informação seja um pouco menos desvalorizado.

Algumas empresas (principalmente as pequenas) sofrem grande impacto quando um bom desenvolvedor recebe uma boa proposta de trabalho e troca de emprego (já presenciei essa situação algumas vezes). Para minimizar esse problema as empresas estão investindo (não que elas sejam legais, o problema é o custo gerado).

Fiz uma pequena lista com os principais motivos (ao meu ver) que levam um desenvolvedor a mudar de trabalho:

- Salário
O motivo mais óbvio e comum. Quando uma outra empresa oferece salário mais alto, é improvável que o profissional recuse a proposta, caso a empresa atual não ofereça uma boa contra proposta.
É incrível como as empresas “tem mania” de achar que conseguem realizar um trabalho de qualidade contratando apenas estagiários (para pagar menos).

- Desafios
Um programador vive de desafios (não confunda com “buxas”). Passar o mês inteiro fazendo formulários não é tarefa que motive a maioria dos desenvolvedores web. Se o profissional não sentir que seu trabalho é “diferente”, é útil, é legal, ele não vai se sentir motivado a continuar.
Existe grande diferença em trabalhar “estilo produção” fazendo meia dúzia de pequenos sites por mês e cuidar de uma aplicação de alta disponibilidade com milhares de acessos por hora.
Cabe a empresa proporcionar novos desafios a sua equipe (pois em outras empresas existem vários).

- Tecnologia
Um fator interessante, que muitas vezes as empresas não enxergam, é a tecnologia utilizada para desenvolvimento. Se o programador apoia o software livre, ele não vai gostar (vai odiar) programar em .NET por exemplo, assim como um desenvolvedor Rails não gosta muito de Java por exemplo. (sei que dizem que devemos ser poliglotas, mas isso é só um detalhe =p)

- Equipe e chefe
Ponto crucial que pode levar o profissional até a se demitir da empresa. Um bom desenvolvedor não gosta de trabalhar com desenvolvedores medíocres, ele quer trabalhar ao lado de outros bons profissionais.
Também não suporta a idéia do chefe mala que faz pressão, não ajuda e só “passa buxa”.
Esse problema se agrava, quando o desenvolvedor é contratado como estagiário a certo tempo e já adquiriu certa experiência que o faz não depender do emprego para aprender mais.

- Ambiente de trabalho
Outro fator fundamental é o ambiente, o local de trabalho precisa ser bom, ter ar condicionado, ter comida a disposição, cadeira confortável, o mais importante um PC (ou MAC) de qualidade.
O calor irrita e tira a concentração, isso faz com que a produtividade diminua.
Como diria o velho ditado “saco vazio não para em pé”, a empresa tem que fornecer comida como bolachas, frutas, suco, etc. Comida fornece energia para o programador ser mais produtivo.
Talvez o que mais faça um programador ficar irritado, é quando o computador é lento, quando demora “meia hora” para compilar o software ou carregar a IDE.

- Flexibilidade de horários
Algumas empresas insistem em achar que desenvolver software é como fabricar uma peça ou montar um carro. Desenvolver software NÃO É PRODUÇÃO!
Não adianta fazer com que seu colaborador “bata cartão” as 8h da manha em ponto e não saia antes das 18h. Estamos lidando com humanos e não com máquinas, o dia que a pessoa está com problemas ou não está motivada, a baixa na produtividade é inevitável.
O colaborador não deve se sentir em uma prisão, em que não pode ir 5min no “bar da esquina” comprar um refrigerente.