Learning Rails 5

Foreword

I came to Rails in 2010. At the time I was doing contract work as a QA engineer in Raleigh, NC. Previous to this I was an out of work software tester. After following my wife to Asheville, NC for a university teaching position I decided I wanted to move from software testing to development work. Asheville is a small market and finding work was tough, so Raleigh was one of my only options. At the time Rails was at version 2.x. Though I was only testing, not developing Rails apps, the learning curve was steep. The process of putting all the pieces of a Rails App in place (GIT, Bundler, Gems, Gemfiles, RVM) was daunting to say the least. “Drinking from a fire hose” was the term we used. I was living and working in Raleigh during the week, and going home to be with my wife on the weekend. This living arrangement gave me lots of time to explore this new framework. I wrote test scripts during the day, and spent my evenings working through Rails tutorials. I owe a debt of gratitude to many of the engineers I worked with on the Entitlement Services team at Red Hat. Specifically, Brenton Leanhardt for his patience and mentoring in learning Ruby and Linux. At the time Rails was only about 5 years old and there were still questions of whether or not Rails was enterprise ready. Those questions have since fallen by the wayside, and Rails is now considered a full-fledged enterprise development platform. Rails is no longer a second-class citizen to Java or PHP, and is arguably at the top of the web framework pecking order.

I began teaching Rails in the Fall of 2014 at Asheville-Buncombe Technical College. By far the biggest hurdle I find my students are faced with in getting started with Rails is setting up the Rails development environment. To begin with Rails is not very Windows friendly. Unless you own a Mac or are a Linux guru you are already a second-class citizen in the Rails world (see “In Defense of Windows” in Chapter 1). But, be encouraged. Microsoft is taking steps to make the Rails experience better. That being said, if you want the full Rails development experience you must still own a Mac or use some flavor of Linux. After this, your challenges are not over. Generally, you want to install some kind of version control for Ruby (RVM or RBENV), along with any number of system level packages for Rails. I say all this not to scare you, but to prepare you. Getting your development environment set up can be daunting, but I promise you, it will be worth it. Think of it as a right of passage for Rails development. Once your environment is properly set up you seldom have to revisit it in any sophisticated way, or if you do, you can usually correct whatever problem you are having pretty quickly.

Finally, I want to encourage you to learn Rails, and assure you that you will benefit from this book even if you do not go on to become a Rails developer. I can say this with confidence because Rails has become the gold standard for Model-View-Controller (MVC) architecture in web development. In addition to the general MVC structure, Rails has also created a workflow around migrations, dev ops tasks, REST, GIT, and community support. For all these reasons, even if you do not go on to do great things in Rails, you will encounter some if not all of these challenges in whatever web development platform you choose to work in. By exposing yourself to Rails and its solutions to these challenges you will learn best practices that can be applied to other frameworks and workflows.

J. Mark Locklear