I remember starting to use PHP in 1998, when I began browsing the web at home. It’s been quite a long time ago, it was like magic added on top of HTML, or maybe in the background 🙂
PHP was really thought to live in the web environment, and as such, it has plenty of helpers and ways to make that task easy. You can include partials and compose a modular website in less than 5 minutes. It was so easy that a huge community was born, growing to be one of the biggest nowadays in the web development field.
I sticked with plain PHP until 2008, when I faced an old project which I needed to rebuild in a modular way. Why should I invent a new way to modularize it? There were some frameworks on the market, so I chose the most complete I could find: Symfony. It had a steep learning curve, but once I got used to it, it felt natural to me.
I was happy to migrate to Symfony2 when it came out in 2011. It was rewritten from scratch changing the philosophy: it changed the magic for explicit commands. I had the feeling that it migrated its inspiration from Ruby on Rails to Django, maybe because Fabien Potencier loves Python.
So, another steep learning curve. This time, while many things felt better, other seemed unnecessarily complex. I had the sensation that the framework forced to follow design patterns to do simple things. That was a wall that was constantly on my way. I was thinking more about the tool rather than the app I was building.
One day I decided to look for some alternative, and since I was tired of PHP, I wanted to look for a different language. When I was in University, I learned Ruby in an elective course. Why not taking a look at Ruby on Rails? It was used by Twitter, so it had to be a good tool.
I was impressed with all the resources and the community that I found. There were tons of free tutorials, screencasts and the best of all: gems. In my opinion, the most negative thing PHP and its frameworks had was the poor support for plugins. Many of them were out of date, incomplete, or very basic. Ruby on Rails had tons of well supported mature plugins (called gems). They are hosted in Rubygems, but I find The Ruby Toolbox to have a better categorization. Whatever you need for your project, it’s probably already developed in a gem. And to manage the versioning of all these gems easily, you can use Bundler. I was understanding where did Composer come from. It’s amazing how fast you can build your application thanks to this huge help from the community. So it was an easy decision for me to switch to Ruby on Rails.
But since everything changes, I wanted to learn as fast as I could. I started to overview the official guide, and when I finished I started to follow the fantastic Ruby on Rails tutorial, which teaches to build a Twitter clone.
When using PHP, I tried to test my applications mainly with PHPUnit, but I felt so alone when I was having problems. Nobody here was testing PHP applications, in any company I was (and I worked in many). It was totally different with Ruby, because almost everyone tests applications. Better or worse, but they do. So many resources are available, and of course a bunch of good tools. Even Ruby itself has a built-in testing framework supporting unit testing, specs, mocks and even benchmarks. Impressive and very convenient.
My next steps were very pleasant when I found Code School and Railscasts. The first one offers learning while practicing in the browser, while the second one offers very practical and to-the-point screencasts about almost anything you could need.
This was my refreshing switch to Ruby. How was yours? 🙂