Initial Experience with Ruby on Rails

Ruby on Rails 5

The Adventure Begins

So, I work with PHP at my day job. This doesn’t mean I use any of the cool frameworks like Laravel, or Drupal, or even Wordpress. Nope, my senior dev has spent the better part of ten years refining a custom framework that we build our web applications with. Don’t get me wrong, this framework he’s built is awesome. It follows a design pattern similar to MVC with some unique quirks, and everything follows the Object Relational Model. Let’s face it. If you’re building apps that centralize around data, and you use PHP to do this, your best bet is to handle the massive clusters of arrays as objects. While I love this idea, it is also a core motivator for my choosing to spread out into other OOP languages. You’re looking at my first dive into it.

Default Ruby on Rails welcome screen

Why Ruby on Rails, though?

PHP wasn’t my first language. Ruby wasn’t my first language. Hell, JavaScript wasn’t my first language. Nope, I started way back in the fledgling days of Python. Like, 0.6 alpha days of Python. Everything has moved along quite significantly since then, including JavaScript somewhere along the way becoming a “real” programming language (seriously, wtf?).

I chose Ruby on Rails as I like the structure of Ruby. The inherent nature of the development process removes the necessity for a templating engine as long as you keep following the MVC structure. The code reads nicely; it’s smooth and sleek. It’s not a haggard syntax like JavaScript or PHP. Plus, it’s super fast. Yukihiro Matsumoto really put some thought into Ruby, and for that, I’m eternally grateful. It shows even more so when it comes to developing a rails app simply in the speed of development. Plus you aren’t dealing with these massive, complex SQL queries that you damn near need a degree in data science to understand. I like that.

Initial Impressions

I won’t lie. Setting up the environment was kind of a pain in the ass. First, you have to get RVM working (my choice, I understand there are alternative methods). Then you have to figure out what dependencies you’re missing on the system level. Think Node.js, and PostgreSQL, and this or that. It gets frustrating. Then you run

And what would’ve taken an hour at minimum before is done in a matter of minutes. Need a form?

Rails takes care of it for you. Not only does it provide you the database migration you’ll need to shut up the errors, but it creates all your partials, and creates the associated CSS and CoffeeScript files you’ll need to go along with that fancy little piece you just made. Don’t anticipate anything fancy though, those initial form pages are ugly as sin at first. Gotta love vanilla, unstyled HTML. Regardless of that point, it just f’ing works! And that to me is glorious. The fact that this beautiful method of development even exists sort of makes me resent the old ways of doing things.

Moving Forward

The novelty wears off eventually and you start to get into the groove of things. Your app is slowly coming along, you’re making some decent headway, then you make your first big mistake. A misplaced comma, or a plural object reference where it should be singular. Rails pukes all over itself, throws that ugly red and white error screen and says, “Hey, you. Yeah, I just crushed your confidence and gave you utter confusion.” The biggest problem when learning a new framework like rails is oftentimes you run into errors that others have not. Who’s kidding, this is the case with 95% of programming, the only difference being you don’t know how to decipher the error messages in this new language. Queue the frustration.

This only happened a few times during the development of this app thankfully. For the most part, rails is super clear about where the bug is and even offers some advice from time to time, which is super cool. Much better than one of my favorite error messages in my professional framework, which simply states, “Smarty cannot load file: ‘.tpl’ in ‘index.tpl’.” Basically, that error simply means there’s no reference in the database to the page you’re trying to reach. But when you first see that error, you’re totally lost.

As I built this out I came to realize how much I like rails, yet how foreign its methodology is. It’s still a relatively new framework in comparison to many I’ve worked with but it’s incredibly advanced for its relative youth. I know, some of you are going to scoff at that remark, but let’s face it. PHP is what, 25 years old now? Ruby didn’t start gaining recognition until 2007-ish? My point remains, rails is fresh. Now in comparison to say, Android development, rails is cake. I haven’t hit a null pointer exception yet and for that I am grateful.

Look how clear and understandable that is… PHP can’t touch it.

Conclusion

For a semi-seasoned professional developer, rails is pretty easy to get a grasp of and dive into. For a novice, or hobbyist that has a day job, I could see it being absolutely daunting. I have to say though, I credit much of my success with this app to the instructor at udemy.com that created the awesome guide from which I learned. Check him out, his name is Jordan Hudgens and he created the course Dissecting Ruby on Rails 5. He also runs an instructional company called DevCamp, also worth checking out. I’m stoked to get deeper into rails and incorporate many of the concepts I’ve learned into my own processes, and maybe convince my senior dev to migrate over some day. Agree or disagree, let me know what your thoughts are. More power to you if you’ve transitioned from PHP into such a beautiful language too, would love to hear about your experiences! Till next time, thanks for stopping by and giving this a read.

Originally published at www.thomasjost.com.