A word of introduction: this year, I’m planning actively work on learning some new languages and skills, rather than just learning things as I need them for a particular project. My plan is to spend 30 days on each technology, taking about an hour to work on the skill and then about half an hour to write about what I learned.
If you have questions, feel free to comment, but keep in mind that these series are primarily for my own learning, and by no means will I be an expert at any of them by the end of the 30 days.
The rest of this series can be found here.
Why Ruby on Rails?
Quite a few job postings I’ve seen around the internet require Ruby on Rails experience, and I’ve heard a number of people talking about it, specifically in the context of web apps. Most of my development work to this point has been HTML/CSS/PHP/JS, with some other supporting technologies (SCSS, Grunt, etc.).
I chose Ruby on Rails as the first technology this year because it’s fairly well out of my familiar comfort zone; I’m more familiar with dynamic websites based on WordPress, but have almost no experience with building or supporting web app-type products.
Since I had no familiarity with Ruby on Rails, I started working through this guide on their website and found it very helpful. I’ll try not to recreate the guide as it’s there for all to see, but rather add some notes and thoughts of my own as I worked through it.
Note: I may use the abbreviation “RoR” from here on out.
First, here are the software versions I had on my computer:
- Ruby 2.3.0p0
- SQLite 220.127.116.11
- Rails 4.2.51 (fresh install [I didn’t think to check what, if any, version came bundled with OS X]; it took about 5 minutes)
Setting the Application Home Page
Pretty straightforward here.
Resources and Routes
Looking at the examples in
routes.rb, I can start to see the flexibility offered by RoR:
- Regular routes: much like a flat HTML file or a WordPress post/page
- Named routes: can perform actions? I’ll find out eventually
- Resource routes with options, sub-resources, concerns, namespaces: tremendous flexibility
After adding a new resource to
config/routes.rb and running
bin/rake routes, there are a bunch of new routes automatically created—similar adding a new WordPress custom post type and letting WP handle all the form logic:
Prefix Verb URI Pattern Controller#Action welcome_index GET /welcome/index(.:format) welcome#index articles GET /articles(.:format) articles#index POST /articles(.:format) articles#create new_article GET /articles/new(.:format) articles#new edit_article GET /articles/:id/edit(.:format) articles#edit article GET /articles/:id(.:format) articles#show PATCH /articles/:id(.:format) articles#update PUT /articles/:id(.:format) articles#update DELETE /articles/:id(.:format) articles#destroy root GET /welcome#index
Again, fairly straightforward as long as I took the time to read through and not try to skip ahead.
One note: the term “hash” was a bit confusing at first; I typcially think of a #hastag or a MD5 hash like
f561b3482204d6e490cd5938affd90bf. Reading the getting started doc, the hash initially looks somewhat like an array; technically, it’s an associative array where any object type can be the key rather than just an integer.
Another interesting thing: looking at the source code on the form, it includes a built-in authenticity_token, which I imagine is much like WP’s nonces for security sake.
Migrations and reversible database actions: pretty cool concept. I shudder to think of trying to set up a manual reversible migration in WP-land myself…
Validation—at least this simple validation—seems pretty simple to implement. Much easier than using PHP to check
$_POST for submitted parameters and fill in the appropriate fields…
I made it up through 5.10 Adding Some Validation but had to fix one thing that was bugging me; on the articles index view, the site was showing a list of all articles with their title and text and I’d added links to the homepage and for adding a new article, but there were no links to the individual articles. I had to fix that, so found the
to_s method to convert the article ID to a string so it could be concatenated with the articles path, and all was good.
Final code for the day is on GitHub.
- No semicolons at line endings (like PHP and JS) is throwing me off slightly
- I like how the erroring line of code shows up in the browser (unlike PHP’s error_log file you have to chase down)
<%=: didn’t notice the difference at first and had some syntax errors because of it
For now, I don’t want to deal with setting up the app in two places at once, so won’t have a publicly-available copy of the project. Eventually I probably will, but all the code is on GitHub.