Ruby, Drupal and a tadpole's swimlane

Entering the pond

As a tadpole in the Metal Toad pond, I had my fair share of anxiety in my first few weeks as a developer but from day one every member of the team made me feel welcome and has always been there to help.There is a strong sense of camaraderie that crosses over into our work ethic and collaboration. We all take pride in the work we do and that became apparent to me right away in my first few weeks here. I feel like I am part of more than just a development team, I feel like I am part of an extended family. I can't imagine being more set up for success than I am right now. It's a great and motivating feeling!

One of the things I picked up early on is that there are a lot of moving parts to this well oiled machine and a polyglotic eye goes a long way in creating a mind map of each tool's place in the stack. This has been instrumental in helping me to determine where/when to call on certain dev tools, how to look at a problem through the right lens, and how to come up with the right questions when I get stuck.

As someone coming from a Ruby on Rails stack, adapting to a content management system has not been a straight forward transition. However, there is always more than one way to view a situation. This has caused me to engage in a lot of introspection on these two subjects and as to what the differences are between Rails with its Model View Controller approach versus Drupal and its Content Management System process. I thought some of you out there that are new to development like myself may have been pondering the same thing and so I thought it would be fun to share my thoughts on the subject.

The right tool for the job

In order to compare the two, let's take a look at 3 things: frameworks, database communication, and testing. I will start by noting that while Rails is a framework, Drupal is built around one (Drupal Core). PHP gets a performance boost from Drupal and Ruby gets one from Rails. This might not mean much at first glance but there really are some notable differences that I found as I learned (and continue to learn) more about the two. Like many things, it is important to know what tool to use for the job. With Drupal you can easily hit the ground running with a website, users, polymorphic relationships and many other things right out of the box thanks to Drupal's Entity API, whereas with Rails you start with nothing and have to code these things together. So, with all this out of the box, Drupal seems like a perfect solution but that mainly depends on the job and which side of the table you are sitting on.

For instance, if you are a client who would like to easily and fluidly update and review your content without having to phone someone in the IT department every time you want to make content updates here or there, Drupal can be very useful as it comes not only with the aforementioned attributes but it also comes with a full featured, easy to use web interface and many useful menus, selectors, etc to get you in and out of edits with ease and with the confidence that you made that change without completely crashing your entire infrastructure due to a misplaced comma or a missing semi colon (happens to the best of us).

On the flip side of this, Ruby on Rails does for the developer what Drupal does for the client in a sense because it was created with ease of use for the developer as its number one priority. Unlike other high level computing languages, Ruby was written specifically for developers as opposed to a language made for the perspective of a computer. It makes coding very intuitive and fast by capitalizing on Ruby gems and other tools to help automate processes while still giving a lot of flexibility for a dev to make surgical adjustments. Although intuitiveness is a sliding scale opinion on a dev by dev basis, the general consensus from my observations is that Ruby caters to the developer as a priority. Also, the Model View Controller approach Ruby utilizes, compliments this approach by making it very clear how data is communicated from the browser to the router, from the router to the controller, and from the controller to the model (this last step goes back and forth between the two in order to pull the correct info from the view to send back to the browser). Some may find other approaches better, I find this analogous to Mac vs PC in that it depends on what you learned using and what you are most familiar/comfortable with.

Common Ground

Rails uses ActiveRecord (ORM) which can be somewhat compared with the Drupal Entity API (query builder). There are opinions both ways on which is better when it comes to the subject of scalability but in my limited knowledge, I would simply note that regardless of the language you're using, at a certain high-volume point you will run into the similar issues. That point will almost always require architectural changes and query builders tend to be difficult to maintain since the code is custom and anyone other than the query builder may have difficulty ascertaining the full scope of what is going on. ActiveRecord provides an object-oriented interface to an application's database making it quick and painless to make changes to a database on the fly. Its place in the MVC pertains to the model. Drupal has Database API (DBTNG) that has a similar developer friendly, object oriented approach to communicating with databases.

Testing, do it!

With testing, we use Behat and I admittedly have somewhat of an uncomfortable relationship with it because I first learned about testing from the TDD approach. On the one hand, like our Drupal user interface, I love how client friendly our testing suite is by utilizing human-readable syntax. Like our Chief Development Strategist pointed out to me the other day, in an ideal situation, the client's user stories would be the Behat scenarios and steps themselves. That is the goal at least. This is an area where I am definitely getting interesting exposure because there are unique differences between TDD (RSpec) and BDD (Behat). Behat tests look for certain things to show up after triggering a specific action whereas with RSpec (and Capybara/FactoryGirl) you create a test that simulates the experience that the method you need to write is supposed to accomplish, then you write the method to make the test pass knowing that once that test passes your code is solid. There is still much I need to learn about Behat but the new perspective on testing in general is a real eye opener. Both approaches seem effective in their own way but this is an area I would certainly like to learn more about. For example, does one approach contribute to a faster workflow, over the other?

Conclusion

From what I have experienced at Metal Toad so far and from what I know from my previous exposure to Rails, you can build very powerful things with both PHP/Drupal and Ruby/Rails and this leaves me with the conclusion that the most important thing to know is what tool is best for the specific job. Working here at Metal Toad with awesome exposure to great technologies and a super supportive, genuine, and refreshingly humorous team, I am getting a great mentorship, making friends, and getting a well rounded dev experience. There is no other place I'd rather be.