From PHP to Rails (5 meses depois)

Salve pessoal,

A algum tempo decidi migrar do PHP para o Rails e desde então não tenho feito nada relacionado à PHP e me dedicado exclusivamente ao estudo e trabalho com Ruby on Rails. Os motivos eu expliquei bem e quase 6 meses depois eu acho que já posso dar uma explanada boa do que vem sendo meu cotidiano de projetos e experiências com a ferramenta.

Linguagem Ruby

O Ruby é uma linguagem fantástica: o Rails se aproveita muito bem de todas as capacidades e liberdades (as vezes até libertinagens) dela para fazer magia com algumas coisas. É muito impressionante você sair de uma linguagem estritamente movida basicamente à funções e classes para uma linguagem mutiparadigma que te deixa programar de várias formas diferentes.

A adaptação é bem custosa para quem está acostumado com o PHP mas vale muito a pena. Existem coisas como essa abaixo que realmente te deixam feliz.

1
2
3
10.times {
|i| puts i
}

A principalmente dificuldade que acredito que se encontra é realmente essa cara da maioria das coisas do Ruby que se tem que se acostumar a ler e interpretar. Mas depois que se começa a aprender é ótimo.

Gerenciador de pacotes Ruby Gems

Hoje em dia, a maioria das linguagens legais tem seus repositórios de bibliotecas. No PHP usei bastante o PEAR e algumas coisas do PHPClasses. No Ruby extendemos seu poder com o uso de gems e estas tem uma maneira muito legal de rastrear dependências e tudo mais através de um comando muito simplista:

gem install pacote_magico_ou_arquivo_da_gem

Ao contrário do PEAR que exige configurações e alguma coisas que um mortal as vezes não consegue se virar, o comando gem é muito simples e efetivo. Ele com certeza é a coisa mais legal desde o APT-GET. :) Vale avisar que se você seguiu a instalação padrão do rails, ele buscará sempre as coisas do rubygems.org que é o repositório padrão de gems.

O rubygems.org hoje tem trocentas bilhões de gems que ajudam um monte a desenvolver e não re-inventar a roda. :)

A framework Rails

Apesar das trocentas framerworks que temos para o PHP, poucas são realmente maduras como o CodeIgniter (de todas a melhor hoje em dia na minha opinião), CakePHP, Zend, Prado, Symfony e por ai vai. A comunidade Ruby se concentra MUITO em usar e divulgar o Rails, framework que transformou o Ruby num hipe louco de uma hora pra outra.

Todavia, o merecimento é mais que merecido: o Rails desde a versão 2 é uma framework que vai direto ao ponto e permite uma produtividade incrível e se aproveita muito da questão do uso de convenções para ficar ainda mais rápido.

Já trabalhei com frameworks em várias linguagens e posso afirmar que sentir-se à vontade no Rails é uma questão de dias e o vislumbre vem em semanas. Existe CLARO suas “limitações”: entre aspas pois na verdade dentro do escopo de propósito do Rails você as vezes tem que sair das convenções e isso tem seu preço.

A maturidade da framework é outro ponto muito bom: muito conceito e forma de fazer as coisas estão muito bem resolvidas. Ela utiliza uma conjunto muito legal de gems para deixar a framework pronta para subir e meter fogo sem necessitar de bibliotecas adicionais. É instalar, criar o projeto e sair codando e pendurando as gems adicionais SE precisar.

A parte chata (que não é um problema exclusivo dela) é a documentação: existe muita informação pulverizada e espalhada que as vezes você tem que garimpar e testar muito. Ao menos fica o aprendizado no final.

Testes, RSpec e Capybara

O próprio PHP tem uma mania de escrever rápido e ir debugando: conheço pouquíssimas pessoas que trabalham com testes no PHP e a ida para o Rails me deixou ainda mais confiante que sem teste não dá de jeito nenhum. Talvez isso seja mais uma coisa de cultura da comunidade, mas as ferramentas também não ajudam muito.

Um dos pontos que mais me deu desgosto no PHP era a forma precária como as frameworks trabalhavam com testes. Na Giran, tentamos no CakePHP, tentamos no CodeIgniter e já estavamos até fazendo nossos próprios forks e remendos pra conseguir rodar bem os testes unitários, funcionais e de aceitação. Tudo isso com aquela pergunta “Putz cara, será que isso é realmente necessário?”.

O Rails se integra de uma forma perfeita ao RSpec, uma ferramenta brutal de testes, nos permitindo escrever nossos testes de uma forma muito mais legível. A integração feita entre os dois é poderosa o bastante pra tornar a prática de escrever testes uma coisa muito mais natural e legal de ser feita. Isso no PHP estava se tornando algo MUITO dolorido e custoso, coisa que não é nem de longe nosso objetivo ao programar.

Outro lance legal é o Capybara, que permite escrever os testes funcionais bem rápido também. Estamos fazendo coisas nele e gostando dos resultados. É simplesmente impressionante como a cobertura de testes da aplicação está melhor.

Um programador melhor

O mais legal desse tempo é que sem dúvida me tornei um programador melhor. Você começa a ver as coisas com um pouco mais de calma, consegue estudar melhor as aplicações, se preocupa mais com a arquitetura e vem nisso um monte de novas coisas legais para estudar que acabam te levando de volta àquele sentido gostoso de querer saber mais e mais.

Fazia um tempo bom desde que não sentia isso e pensei que que seria algo só no inicio dos estudos do Rails: 5 meses depois cá estou eu lendo mais e mais pra descobrir as sutilezas do Ruby e coisas legais de se fazer no Rails. :)

Então tá tudo perfeito?

Foram 5 meses de muito aprendizado e coisa bacana, mas nesses 5 meses nem tudo foram flores.

  • a adaptação pro Ruby para quem vem de outras linguagens não é muito fácil, embora muito excitante
  • a documentação do Rails não é tão vasta: se rala muito para saber os N jeitos de se resolver as coisas
  • inexiste comunidade Ruby no ES (estamos pensando muito em juntar quem sabe aqui no ES e começar uma)
  • sair da “convenção” do Rails as vezes é bem complexo

E é isso: tem muita coisa nesse meio que vou escrevendo daqui pra frente nas descobertas que for fazendo na Giran com os brothers do time … novos railers que estão devorando livros e livros comigo. :)

Simbora.

Moving to Python/RubyOnRails

Salve people,

Estava com saudades de escrever coisas por aqui bacanas mas estava às avessas com Giran, eventos e tudo mais. É claro que que a desculpa “falta de tempo” não existe quando você está motivado e focado em algo. Continuo motivado com muita coisa, principalmente com o crescimento natural e meio que imposto pela velocidade que as coisas estão acontecendo que pedem cada vez mais uma postura e abordagem que exige muita muita MUITA disciplina.

Mas uma coisa que não me motiva à tempos foi o PHP, não pela linguagem e sim mas todo um entorno que acabavam impactando diretamente na melhoria continua disso.

Frameworks

Larguei o CakePHP pelo CodeIgniter em busca de uma framework mais light e customizável. O CodeIgniter serviu muito bem, mas peca em duas coisas muito importante que era o suporte mais integrado à testes e um ORM bacana. Nem o SimpleTest nem o PHPUnit se mostraram muito bem integrados e o ORM mais bacana que achamos foi o Overzealous DataMapper. São duas boas ferramentas, mas que não atingiram totalmente (e juntas) o objetivo que era ter coisas estáveis pra desenvolver.

A pouco tempo palestrei sobre frameworks, mas acho que tem que melhorar muito até chegar num nível de maturidade legal. Ou seja, isso acaba atrapalhando e muito a questão de trabalhar com todas as ferramentas e técnicas possíveis para o desenvolvimento de aplicações com alto nível de qualidade. Para quem não demanda toda a qualidade que estou/estamos buscando, essas ferramentas são show de bola demais.

Existe uma certa carência de um set de ferramentas que possam trabalhar em conjunto para oferecer a sustentabilidade desejada para um projeto de, digamos, qualidade máxima.

Não estou dizendo que as ferramentas são ruins mas cheguei num ponto em que queria me focar mais no negócio e por isso espero ferramentas que ja estejam maduras o suficiente para que eu possa confiar nelas. Num certo ponto estava me preocupando com questões de estabilidade e funcionamento que eu esperava ja terem sido resolvidas pelos projetos.

Desafio

Por conhecer e programar em PHP a MUITO tempo, cheguei num nível que ou me dedicava ao desenvolvimento de uma ferramenta ou algo mais tenso para manter isso aceso ou partiria para a evangelização da linguagem, o que faço em partes como um dos coordenadores do PHP-ES. Desenvolver um projeto novo é legal, mas prefiro contribuir com os que existem com patchs e o que puder … e desenvolver algo novo deve primar pela idéia em si e não pela tecnologia. E se a idéia é nova, porque não brincar com outra coisa nova?

Mas lá no fundo entrei em loop no que tange aprender mais PHP. E isso, dentro do meu universo pessoal onde mudo e toda hora procuro algo pra fazer, chegou a um ponto que ficou insustentável. Como diria o poeta “Já deu …”.

Comunidade

Acredito que faça dois anos que começamos de fato com os eventos com o PHP-ES e estava tudo indo bem exceto por dois pontos:

  • a falta de mobilização da comunidade em prol de algo que não seja discutir salários e questões banais como sindicalização no forum
  • a falta de interesse do próprio time de coordenação em querer fazer as coisas da melhor maneira, ajudando no dia-a-dia e não apenas não-presencialmente

Não julgo ninguém, mas no fundo fui me sentindo meio que lutando e tentando fazer crescer um Mercado onde as pessoas de certa forma ou não se interessem tanto, enquanto comunidade, ou não estão preocupadas com evolução, isso tanto pessoal quando novamente em comunidade.

Me amarro em fazer eventos e ensinar o pouco que sei sempre, seja por blog, por MSN, em eventos ou o que for mas no caso de eventos é um sentimento meio chato não ver as pessoas se movendo em prol de um objetivo mútuo. Deve ser a idade chegando, mas já havia passado por algo em outras áreas de atuação (fiz muitos eventos de heavy metal que rolavam várias coisas do gênero). Se não existe comunidade, você luta pra fazer crescer uma. Quando já existe e você vê o desinteresse das pessoas, você precisa tomar descisões e a minha vibe é de “estou aqui pra ajudar mas tomar a frente não tão cedo”.

Porque Python/Ruby on Rails?

A escolha do Python e Rails foi a mais natural pois ambas são linguagens de script. Além disso, uma penca de coisas me levaram a escolher essas duas também:

  • comunidade irada
  • frameworks maduras
  • ferramental para testes e tudo mais maduros
  • Orientadas a objeto de verdade
  • Preparadas para o que der e vier

O Python/Django foi uma escolha bacana no sentido de que se pode desenvolver tanto para web quanto para uma pá de outras coisas, até pra iPhone. ;)

O Ruby/Rails foi outra escolha bacana por ser atualmente, sem modismo, uma das (se não a melhor) framework para desenvolvimento web, e que segue “por default” uma filosofia voltada à qualidade e agilidade. Vi várias coisas embasbacantes na QCONSP (vou escrever um post bacana sobre essas coisas) e é motivante ver tanta gente correndo atrás da melhora não apenas da ferramenta mas da comunidade toda em si.

Muitas oportunidades sempre rolaram em relação a desenvolver com elas e acho que chegou a hora de me dedicar a isso com força.

Então PHP nunca mais tio???

Deixar de estudar uma linguagem não é um “nunca mais trabalho com ela” nem coisa do tipo. Tive ótimos feedbacks em relação aos posts de TDD com o Simpletest e pretendo continuar (mas com PHPUnit talvez) com mais algo de Selenium … enfim, coisas mais voltadas à qualidade de código final do PHP do que o desenvolvimento dele em si.

Além de continuar falando sobre PHP em relação à isso, pretendo estar ajudando a comunidade seja como palestras, ajudando os amigos da coordenação com os eventos e todos que ainda puder ajudar ensinando algo porque afinal … eu gostcho!

Enquanto isso, vamos seguindo nossas vidas e seja o que Alah quiser.

Hugs!

Review II WORKSHOP PHP-ES

Salve people,

Tava com saudades aqui do blog. Ae uhaeuhAEae A correria na Giran ultimamente está pra lá de frenética e estou estudando muito pra escrever algumas coisas legais aqui e de relevância.

Rolou hoje o II Workshop PHP-ES na UVV e posso dizer que por um lado foi muito foda e pelo outro um pouco triste.

O que foi muito foda

As palestras foram altamente maneiras. Um review muito bacana do rolou está no blog do Xiquin (http://www.franciscosouza.com.br/2010/08/28/ii-workshop-de-php-do-espirito-santo-foi-show), que palestrou sobre CodeIgniter com o André Tagliati, vulgo Gligli. A palestra dos dois, inclusive, foi muito bacana assim como as palestras do Marcelo Raposo sobre práticas mágicas no MySQL e de PDO com o mestre Almir M3nd3s.

Outro ponto foi a abertura do evento para assuntos fora do eixo técnico para ir para o entorno no mundo PHP, como a plafatorma Moodle com o Lucas Coradini (nunca pensei que um designer botaria banca num evento de programadores hehehhe zuera sacanagem) e a metodologia Scrum com o Paulo Jeveaux e o Makoto Hashimoto. A escolha dos assuntos não poderia ser mais feliz, porque nas contas finais eu achei as duas palestras mais informativas pelo público presente.

Este público presente foi outra surpresa: a imensa maioria era de pessoas do interior do estado, como Cachoeiro, São Mateus e Pinheiros. Isso nos mostrou o quanto de espaço pode-se ter junto a um público que geralmente só tem acesso a informação desse tipo vindo pra cá. Tivemos alguns contatos e esperamos levar eventos de PHP para lá.

O evento transcorreu muito bem e no geral foi muito bacana até mesmo pra mim que fui sob efeito de muitas drogas anti-gripais. O sorteio no final foi um show a parte de integração e diversão com direito até a contribuição de um brinde por parte da platéia (valew Fabiano!).

Por último, o apoio PRA LÁ DE F*DA da UVV e do prof. Vinicius Rosalen, que não apenas nos cedeu toda a estrutura para a realização do evento como ajudou com café e rosquinhas pela manhã e a tarde. E também da Giran, pela mobilização geral do pessoal no preparo de conteúdo, palestras para o evento e apoio incondicional na organização do evento.

O que foi meio triste

Palestrar, terminar slides, organizar evento e tocar evento doente é foda. Aliás, qualquer coisa nessa situação é foda. Queria ter estado melhor mas no final das contas estar doente foi apenas um empecilho. :P

Ter no cast de palestrantes uma galera da Giran foi uma honra pra gente, mas por outro lado mostrou uma coisa que quase inviabilizou o evento: não tivemos NENHUMA palestra submetida pelo grupo de usuários que povoa o fórum. Parece que as pessoas preferem discutir coisas abstratas como sindicato de programadores PHP (sic) que movimentar e dar apoio aos eventos da própria comunidade.

Seguindo a lógica, de 260 pessoas inscritas não tivemos nem a metade que seria o normal. E dos que compareceram uma galera era do interior e poucas pessoas da Grande Vitória. Agora não sabemos se há um desinteresse total das pessoas da Grande Vitória por PHP, se os tópicos das palestras foram mal escolhidos ou simplesmente as pessoas se cadastram por diversão. (risos) Isso trouxe um efeito bacana que é agora nossa vontade real de levar esses eventos para o interior.

Enfim …

Para um evento que esteve no limiar do cancelamento por falta de ânimo com um cenário onde nem palestras haviam para fazer o evento, foi um PUTA evento e que me recorda o feeling que eu tinha quando tocava heavy metal em shows que as vezes só sobravam 5 pessoas na frente do palco: você está ali pelas pessoas que ainda acreditam no ideal e no que você acredita e por elas VALE MUITO A PENA.

Simbora.

PHPzeiro? Adote um Framework! :)

É notável a quantidade de aplicações em PHP que ainda utilizam nosso velho e conhecido modo Macarrônico de programar: dezenas de snippets e blocos de código que trabalham com regras de negócio, apresentação e tudo mais espalhados por N lugares na aplicação.

O PHP Macarrônico é assim

O PHP Macarrônico é assim

Esse método é justificável dentro da PHP até certo ponto: a própria linguagem tem por princípio a simplicidade e velocidade na codificação e resolução de problemas. O próprio Rasmus Lerdorf, criador do PHP, já se mostrou bem contrário aos frameworks atuais pois eles são lentos e não escaláveis, culpa do feeling de  “faz-tudo” que a maioria delas leva no sentido de continuar ostentando a bandeira de “desenvolvimento rápido” da PHP, que muita gente confunde com gambiarras e que transformou a PHP em sinônimo de POG (Programação Orientada à Gambiarras).

Continue…

Mock Objects no SimpleTest

Olá pessoal,

Continuando nossa sequência de artigos sobre o SimpleTest, já aprendemos como fazer testes unitários e agrupa-los para facilitar a execução em lote: agora vamos falar um pouco sobre mock objects.

Até agora, nossos testes unitários se resumiram a testar métodos e funcionalidades que envolviam apenas uma classe como nossa calculadora: tínhamos um método chamado “somar” que fazia parte da própria classe e recebia como parametro de entrada apenas dois inteiros.

A idéia do teste unitário (ou de unidade), como o próprio nome diz, é isolar e testar apenas aquele ponto e funcionalidade do software: então é imprescindível que possamos isolar da melhor maneira apenas a classe/métodos que desejamos testar para que, caso apresente falha, possamos identificar exatamente onde a falha ocorreu.

Mas e quando nossa classe depende de outra(s) classe(s) para fazer um método funcionar ?

Continue…