Tag Archives: Ruby on Rails

Mentoria com o Lucas Renan

by

“If you want to really learn something, try teaching it to someone else.” – Chad Fowler

E se você pudesse ser um profissional excepcional aprendendo como se estivesse trabalhando em uma empresa de forma rápida e prática?

No livro The Passionate Programmer, Chad Fowler apresenta dicas valiosas de como ter uma carreira excepcional no mundo do desenvolvimento de software. Dois dos capítulos são: “find a mentor” e “be a mentor”. Com base na recomendação do Chad, estou lançando hoje um novo serviço de mentoria.

Paixão pelo ensino

Através de um processo de coaching, acabei descobrindo minha paixão pelo ensino. Na mesma época do coaching (2011) eu e alguns amigos fundamos o GURU Sorocaba. Desde então venho organizando meetups, ministrando cursos e fazendo apresentações. E no começo do ano passei 6 semanas dando aulas na Polônia.

Por que mentoria?

A forma de ensino tradicional com aulas sendo ministradas por um professor para vários alunos, impossibilita que o professor tenha uma abordagem diferenciada para cada perfil de aluno, comprometendo o resultado do ensino como um todo.

É muito comum os profissionais e estudantes de tecnologia buscarem cursos específicos para aprenderem uma nova tecnologia ou se aprofundarem em determinado assunto.

Através da mentoria, conseguimos ter uma abordagem customizada de acordo com o perfil de cada mentee. Também não nos prendemos a um único assunto. Imaginando que o mentee queira aprender desenvolvimento web, podemos começar do basico e ir até o deploy, cobrindo todas as áreas para o desenvolvimento de um projeto real.

Como funciona?

O mentee define os assuntos que quer aprender e o mentor estima a quantidade de horas necessárias. Basicamente o mentee escolhe a grade e carga horária, seguindo um fluxo de escopo aberto, de maneira que semanalmente podemos replanejar o escopo da mentoria.

A mentoria pode ocorrer on-line ou presencial (São Paulo, Sorocaba e região).

Quais assuntos?

Fica a critério do mentee, algumas sugestões são:
Desenvolvimento de software: ruby, ruby on rails, html, css, javascript, mysql, couchdb, mongodb, git, orientação a objetos, scrum, xp, etc. Como fazer apresentações: design, storytelling. Carreira, liderança, inglês ou o que mais o mentee acreditar que eu possa ser um bom mentor.

Sobre o mentor

Eu venho trabalhando com desenvolvimento web nos últimos sete anos. Já trabalhei com php, .net e nos últimos tempos com ruby. Atualmente trabalho como desenvolvedor para a nu, um estúdio de design gráfico de São Paulo.

Sou coordenador de intercâmbios profissionais da área de TI na AIESEC Sorocaba.

Estudei na FATEC Sorocaba e atualmente sou aluno do mestrado em ciência da computação da UFSCar Sorocaba.

Para quem se destina?

A mentoria é focada em estudantes e profissionais, de forma individual. Para grupos ou empresas, entre em contato que podemos planejar algo também :)

Contato
Quer dar um upgrade na sua carreira? Entre em contato através do e-mail: contato@lucasrenan.com

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

Bugs que o sistema apresentou no fim do sprint

by

Ano passado meu último post foi “Erros que cometi nesse sprint”, tratava-se de alguns erros que tinha cometido em um projeto, principalmente por não ouvir as pessoas. Outra vez vou contar um pouco da experiência que eu tive e que está totalmente relacionada aos princípios ágeis.

A grosso modo, o princípio básico das metodologias ágeis de desenvolvimento de software é: entregar software de qualidade e funcional o mais rápido possível para garantir o ROI (retorno sobre investimento). Esse é um assunto que já se tornou clichê no mundo do desenvolvimento de software, porém no dia a dia de um projeto seguir esse princípio não é tão fácil como parece. Então, seguindo essa linha de pensamento, quando vamos iniciar um sprint devemos priorizar quais tarefas serão executadas primeiro afim de entregar o quanto antes as funcionalidades que tem mais valor (ROI).

Muitas vezes o objetivo principal do projeto não fica claro em um primeiro momento, no caso o projeto tratava-se de um loja virtual de cursos, porém esse conceito só ficou realmente claro para a equipe depois que o projeto foi “finalizado”. Isso foi um grande problema, eu particularmente acabei me concentrando em vários detalhes que não estavam diretamente relacionados com o objetivo principal, ou seja, o usuário poder comprar e se matricular em um curso.

Depois do “fim” do projeto foram encontrados vários bugzinhos no sistema e várias coisas que não tinham sido implementadas ou que poderiam ser melhoradas. Eu fiquei encarregado de arrumar esses bugs para então o site ser finalmente concluído e entrar em produção. No fim da segunda semana que estava arrumando os erros percebemos que o processo de compra de um curso simplesmente não estava funcionando…

É aí que PAGAMOS O PREÇO por NÃO ser ÁGEIS

Não entregamos software funcionando incrementalmente, fizemos incrementalmente, mas não entregamos, dessa forma é muito mais difícil descobrir bugs e possíveis mudanças. Adiar mudanças significa aumentar o custo delas. E o pior é entregar software que não cumpre com seu principal objetivo.

Se o software apresenta muitos bugs e precisa de muitas correções, você estará perdendo dinheiro, afinal o cliente não vai pagar para arrumar erros de desenvolvimento.

Poderíamos ficar procurando N motivos para dizer o porque cometemos erros (acharíamos vários e achamos), principalmente pelo projeto ser de escopo fechado, mas era melhor salvar o projeto, não acha? =p

Salve o projeto, seja ÁGIL

Utilizando três técnicas ágeis, conseguimos em poucos dias, corrigir os bugs e tornar o sistema totalmente funcional.

– Testes Automatizados
– Programação em Par
– Refatoração

O sistema tinha/tem testes automatizados, isso nos proporcionou fazer uma refatoração no código programando em par, com a segurança de que não iríamos quebrar outras partes do sistema. Dessa forma conseguimos rapidamente corrigir os bugs e o processo de compra, tornando o sistema totalmente funcional.

E você? está utilizando desenvolvimento ágil nos seus projetos?

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