In professional software development, the adage is “If it hasn’t been tested, it doesn’t work.” It’s easy to write some code that I believe does what I want… it might even pass a few smoke tests. But if it hasn’t been examined with some rigor, it is worthless. Time and time again test suites proved their value by exposing problems in my code. With their help I knew what I need to fix to make things better.
Yet with all this importance, testing techniques and methodologies are rarely covered – or even mentioned – in most curriculum on software development. This is why I was most surprised to find the section Testing Rails Applications on the list of RailsGuides.
I’m still too much of a Rails beginner to understand all of the information in the lesson, so I would definitely have to come back later, but it is enough for me to get a rough idea of the capabilities of the built-in testing framework.
I was most amused to see that the built-in creation scripts for Rails models and controllers would create the test scripts at the same time it created the code. A not-so-subtle reminder for the developer to go and write some tests. At this point, the source code files and the test files are both sitting empty and ready to go. We could start writing the source code – but we could have just as easily started writing the test files first.
Write the test, see it fail, write the code, see it pass.
At least that’s the theory of test-driven development. I don’t know if I’ll approach Rails development in this manner, but I do appreciate how Rails removes so much of the barriers to entry.
As I enter the world of web development, I’m very wary of the security pitfalls of the domain. It is a completely different set of security threats than what I used to worry about. Different attack vectors that need to be defended against or mitigated with different techniques.
I had known about the Open Web Application Security Project (OWASP) but I can’t say I’ve reached proficiency understanding all the concepts there. At this point I can articulate most of the concepts listed in the OWASP Top 10 list. If I come across a description of an attack using one of these top 10 techniques, I can follow along with the description.
But that is far far short of the skill level where I can spot the security issues ahead of time. That is yet to come. With expectations set suitably low, I went through the Securing Rails Applications RailGuide to see how much I can understand. And surprisingly… quite a lot! Whoever wrote this guide was able to explain a lot of these issues in a way I can understand. I really appreciate the effort they put into breaking the problems down.
With every exploit, the guide also describes some mitigation for Rails applications. Not knowing a whole lot about Rails just yet, most of the mitigation descriptions made little sense. So while I understood more than I thought I would, I’d still have to come back again.
Right now I have no confidence that I can tell a secure Rails app from an insecure one. There’s a whole lot of very clever people trying to find ways to break security boundaries. Whenever I read about an exploit, I usually end up shaking my head “I never would have thought to try that.”
Since there’s no way to guard against a problem you never thought of, I need to build up my web programming toolbox. I want to get from “I never would have thought to try that” to “ah, that’s a clever thing to try” to “no problem, I’m pretty sure I’ve taken care of it.”
One step at a time.
It is my opinion that RailGuides’ Getting Started with Rails is a far superior educational resource than the Codecademy class on Rails which I did not care for at all.
The only thing I can say in favor of the Codecademy edition is the completely browser-based Codecademy learning environment. To run through the Codecademy
tutorial mystery show, one only needs a browser. RailGuide has no patience to set up a virtual machine for you. It wants the reader to set up their own fully functional Ruby environment to follow along. (Don’t worry, instructions are right up front in Section 1.) If people are just surveying the technology, this may be more than they are willing to do. But those who are serious about getting their hands dirty will want it anyway, so I didn’t see that as a barrier.
Getting Started with Rails does a far better job of describing what Rails is, what it does, and the components that the students will be activating in the lesson. It explained the directory structure. It explained the relationship of the view and the model and the controller. It explained how the database relates to the model. On and on, tons of info I failed to get out of Codecademy.
The best part was when the class went into partial forms. (Codecademy didn’t cover the topic at all.) First the student did it the hard way, then the student is instructed on how to clean up after themselves and simplify the structure with partials. See the original – then work the magic yourself – makes for superior comprehension.
Ruby on Rails is a big complex machine and there’s still lots to learn. Like routing… the link_to routes are still magic to me. But I feel like I have a solid foundation now, which I didn’t feel before.
Onward to more Rails adventures…
The Ruby language site lists some resources for beginners in their Documentation section. Most of them followed the usual pattern of online language courses, but the Ruby Koans stood out. It is a language lesson by the way of test-driven development. The entire course is in the form of a single Ruby program full of test cases (280-ish when I downloaded it) that all fail. The job of the Ruby student is to look at the test case, understand what the test requires, modify the test case so that it succeeds, and proceed to the next one.
The very first test case is simple – true versus false. Then it progressively built up from there. Data types, flow control, object hierarchy, the works. While this covers much of the same ground as the Codecademy course I took a few days ago, the presentation and the format kept me engaged in a way the Codecademy course did not.
One reason was that it’s possible to “fast forward” through sections I understood: The test cases are all there in Ruby source files. So once I understood the concept covered by one test case, I can continue editing the similar test cases and have them all passing in one batch instead of one case at a time. In contrast to something like Codecademy where, even if I understood the concept, I still had click through the pages one at a time.
Bonus: after I finish the lessons, I have a bunch of Ruby files exercising various Ruby concepts that I can go back and look at for reference. It is much faster to scan through a Ruby file than it is to click through a Codecademy lesson.
This Ruby Koans approach to learning Ruby might not work with everybody, but I loved it.
(*) As long as you are running some flavor of Unix.
Ruby has a reputation for being difficult to set up. Looking at the setup documentation, I can see where that reputation came from. I suspect most of the reputation I heard came from Windows users, since that’s the camp I’ve historically been in. Windows users aren’t used to being treated as afterthoughts… and the Ruby community certainly does treat Windows as a second-class citizen. Most information applied to various flavors of Unix. Random aside: This surprisingly included the very-remotely-Unix-based Mac OS X. Mac instructions are more about ‘updating’ and I eventually figured out that recent versions of Mac OS X included Ruby. (An older version recognized to be stable but out of date.)
Back to Windows: Everything I found can be summed up as “Eh… look at this forum post, some people had good luck with XYZ. But you’re on your own, pal.”
After reviewing my options, I decided my first steps to the Ruby world would be:
- Ignore all the Windows
- On my Windows development computer, install Ubuntu in a Hyper-V Virtual Machine.
- Inside the VM, follow the directions for installing Ruby on Ubuntu via RVM
RVM (Ruby Version Manager) is an utility some Ruby users wrote to help them keep the various Ruby versions straight. The fact this even exists and considered necessary is a little disquieting. Ruby users have to use something like RVM to switch versions around to match the version of whatever they need to get done that day. This implies that backwards compatibility is not exactly a strength of Ruby. (Possibly not even a design goal…)
I spent most of my professional career to date worrying about backwards compatibility day and night. This is a very different world. I’m not sure I’ll like it here, but I’m sure going to give it a try.
This class rushes through the basics of setting up a Rails app without explaining the bulk of what happened. This is not itself a bad thing: it let me see that Rails has a large surface area of machinery, pre-built components that can be put to work quickly.
But the majority of the course is of the “type this and look at the results” without much explanation of what I just typed and why. Example: After writing a few lines of Ruby code, the student is instructed to go into the command prompt and type “rake db:migrate” followed by “rake db:seed” before instructed to marvel at the result of the magic.
What did that do? The class didn’t really say beyond “made database”. Afterwards I went back and dig into the documentation to come up with a guess at what’s going on:
The lines of code turned out to be a way to define schema for a database table. After the schema is updated, the table itself is migrated from the previous schema to the new schema. In this case there is no existing table, so ‘migrate’ creates a new empty one. Then “db:seed” inserts some information pre-generated by the Codecademy course author into the just-created database so it is not empty.
And “rake”, which I had inferred to be some kind of database tool, is actually a general task running tool like “make” for C. I got the wrong impression since all I saw were database tasks.
That’s one example, there were many others. With this lack of explanation I’m sure I have quite a few misconceived notions on how Rails apps are built. Heck, what I described above with ‘db:migrate’ etc. might be wrong! I’ll learn my errors in due course.
If it was titled “Interactive demo of Ruby on Rails” I would be satisfied with what I got, but I don’t think it deserves the title “Learn Ruby on Rails” when actual learning has been left as an exercise for the student.
Upside: Despite being the last in the list of language skill courses, the Codecademy “Learn Ruby” course does not assume the student knows anything about programming. It will start at the very beginning with variables, functions, flow control, etc.
Downside: If you already know basic programming concepts, the first few sections will be a complete bore as it teaches the concept of variables, function, flow control, etc. The only reason to put up with any of it is to learn the Ruby syntax for these basic concepts.
Fortunately, the class doesn’t take terribly long before getting into the interesting stuff. Like how Ruby’s basic data types have a lot more tools attached to them than other languages I’ve seen. All kinds of ways to traverse an array. The crazy number of things built in for various string manipulation. Things that, in other languages, a programmer would have to get from utility libraries outside of the language base.
That said, I’m not sure I see how these differences explain the enthusiasm I read from some Ruby champions. At the basic level covered in the Codecademy class, it doesn’t seem significantly different from any of the other object-oriented programming languages out there. Yes, it has a lot of built-in capabilities for common operations, but is that really enough to get people excited?
I haven’t seen the debugging facilities (or lack thereof) for Ruby. I’m also wary of the reputation Ruby has for being difficult to get up and running on a computer. Inside the Codecademy learning environment, it’s already set up. Getting it up and running on your own has been repeatedly warned as a nontrivial process.
No matter, I wasn’t learning Ruby for the sake of learning a new language. I was learning it as a foundation to build on learning a non-basic-library: Ruby on Rails.
It’s fun trying to bring an old DOS game into the web world, and now I’m getting to the point where I think it makes sense to do part of the work on the server side.
I went into some Node.js classes earlier, mostly because I wanted to learn about NPM. But Node.js isn’t the right tool for every job. Specifically, it isn’t a tool I can use if I want to host with shared hosting services – the power of Node.js conflicts with the constraints to make sure everybody plays nice on a shared web host server. (Specifically those on Dreamhost, where I have my domains registered.)
So… time to learn something that I can use to put on a Dreamhost shared web server and visible to the world. The bullet point on their sales pitch says “Perl, Python, and Rails”. I already know I don’t particularly care for Perl. It is a very terse and concise language that I find to be unnecessarily difficult to debug. Python is supposed to be a more human-readable language, and I don’t know much about Rails at all.
In the spirit of adventure, time to roll the Codecademy courses on Ruby, followed by Rails, to see if I can use it for the server-side work of my little personal project. Either I learn how to do what I want, or I learn enough about Ruby & Rails to be able to articulate how it does not suit me.