To start wrapping things up, I have some final knowledge I'd like to impart that I hope will serve to help you avoid some small part of the frustration I've had to endure.

People are rude

This seems like a strange place to start for an advice section, but I consider this foundational to finding answers:

People, especially those on the Internet, can be rude.

Don't let this bother you.

If you've ever visited any kind of online forum, you'll have certainly seen some poor n00b, completely unable to even properly articulate their question, then verbally abused at length by the very people who could help. All because they said "Linux" when they meant "GNU/Linux". ...or some other such nonsense.

Now, like any decent programmer, I myself believe that it is important to be knowledgeable and be able to correctly refer to the tools and concepts one works with, but how on earth is someone supposed to come about that knowledge if they must already have it to perfectly ask the question that will provide an answer for them?

Spoiler: they can't.

Besides having a tough skin, I recommend thoroughly googling around for a pre-existing answer before you yourself bother asking and, of course, check the stackoverflow.com. I don't believe that Stack Overflow completely solves the problem of people being rude, but they sure are doing a great job of trying.

The Unknown

No one knows everything. So, by extension, I don't know everything, and you don't know everything.

And that's okay.

It's not okay to lie about your abilities or what you know, but I'm a big proponent of making promises based on what you know you will be able to do, rather than what you can do, in order to push your limits.

Not knowing seems generally frowned upon in our society, but luckily we live in a world with Google and we can quietly fill in our knowledge gaps alone if we so choose. If that won't suffice, formulate a question that shows what you do know about your problem, then specify exactly what you don't. People often respond surprisingly well to this.

Relatedly, failure gets a bad rap too. Failure is inevitable and dealing with it is a necessary skill. As a speaker at my college graduation told my class: "Get comfortable with being uncomfortable."

Reading Errors

Errors in Ruby, and by extension Rails, are usually quite helpful, but can also be unnecessarily verbose.

irb(main):001:0> foo bar
NameError: undefined local variable or method `bar' for main:Object
  from (irb):1
  from /home/brad/.rvm/gems/ruby-1.9.3-p194/gems/railties-3.2.8/lib/rails/commands/console.rb:47:in `start'
  from /home/brad/.rvm/gems/ruby-1.9.3-p194/gems/railties-3.2.8/lib/rails/commands/console.rb:8:in `start'
  from /home/brad/.rvm/gems/ruby-1.9.3-p194/gems/railties-3.2.8/lib/rails/commands.rb:41:in `'
  from ./script/rails:6:in `require'
  from ./script/rails:6:in `
'

So, here, we get a pretty lucid error message:

NameError: undefined local variable or method 'bar' for main:Object

But if this wasn't useful to us, we could derive from the error trace that, starting from the bottom, the flow of logic started in ./script/rails, moved to /home/brad/.rvm/gems/..., and ended up throwing an error in (irb):1.

We know it threw the error, because it's at the very top of the error trace.

Furthermore, we even get line numbers in all of the lines above as well as method names in most.

With as much logic that is brought together to make Rails work, the error traces in Rails are usually much, much longer.

The key to using these is, of course, to first look at the error message.

If that doesn't help, look through the trace for files that you created.

If all else fails, look at the rest of the trace and see if a Gem might be causing the problem. If so, find the Gem on GitHub and search for related issues. If you don't find one you can try submitting one of your own.

This probably all seems incredibly obvious, but I personally didn't do so well with error traces at first.

Misspellings

Another thing that might sound incredibly obvious: check for misspellings.

Completely obvious, right?

Yeah, but I recently did a $ rails generate model Authetication ... and then couldn't figure out why I was getting an error when I tried to do a Authentication.create(...).

Can you spot the problem?

If you didn't notice the missing "n" in "Authentication" in the generator, you had the same problem I did.

Except that it wasn't your fault, because I'm the dope who typed it.

In short: misspellings don't compile. You have been warned.

What you did last

To continue the obvious advice parade: when something breaks, always think about the last thing you did. ...and the second to last. ...and third to last.

Chances are that might just be what's blowing up your application.

"Undo" and git checkout are a couple tools that will help you get back to a workable state.

Scoping, Pathing, and Nesting

Scoping, pathing, and nesting are another set of things to consider when running into an error. Though different, within each of these concepts leaves room for us to make the mistake of thinking we are somewhere that we can access something, when we actually can't.

"Method not defined? It's right here, I just defined it!" -> You did, but it's out of scope.

"Why isn't this route pointing to the FooBarsControllers?" -> It is, but you're not using the nested route.

"Okay, seriously, why is this hash empty? I just dumped a ton of stuff in here." -> Well, you actually put your ton of stuff in its parent.

A classic example of this in Rails for me is looking for something like a chapter_id in params[:mark][:chapter_id] where I want it to be, then realizing (ten minutes later) that it's actually being passed in as a nested route and will therefore be in params[:chapter_id]. Derp.

When you run into these kinds of frustrations, double check where you are and where you think you put what you're missing.

Refactoring

Most of the time you'll find yourself writing something and come to realize that you're repeating some task over and over. Don't worry, this is how it's supposed to be.

You shouldn't think too far ahead to try to solve these problems when they don't yet exist, just refactor when you see that you need to.

Focus on building things, but improve efficiency and organization when you have the chance.

Trouble starting out

And finally, if you're having trouble starting out, it never hurts to read more books, blogs, and source code, or to watch more screencasts. This kind of passive learning can be helpful to give you the breadth of knowledge you need to pull ahead.

That said, we only really learn to make things by making things, so I encourage you to just write code. Find a problem, or even invent one, then try to solve it.

It's awfully hard to learn how to make something if you never make anything.

If you're solving a problem just for you, don't worry if you do it quickly, poorly, or inefficiently, just try to solve it.

One of my favorite little Ruby projects was writing a script to fix the timestamps on subtitle files to adjust for the removal of commercial breaks. I'm sure not everyone has this problem, but it was a problem for me and I solved it. ...sloppily.

And if you can't think up a problem of your own, find someone else's code and try to copy it yourself from memory. Rest assured, you won't be able to recall it all from memory, but in trying to do so you'll run up against the limits of your active knowledge and that will make you realize what you don't know, what you can't do. Once you're stuck, cheat, and then strike back out your own again.

You can even do the same thing over and over. Repetition helps, and it counts as forward progress.

So read and watch and copy and learn, but whatever you do be sure that you make something.

And, most importantly, know that you can.


Afterword

The Very Next Step

Stop what you're doing right now and immediately go work your way through the Ruby Koans.

Yes, stop reading this! I'll meet you back here when you're done!

There, now you've worked with Ruby!

More Next Steps

Simply writing code is probably the best thing you can make a habit of doing early on, so if you have a problem you're dying to solve, try solving it!

Additionally, reading source from well-known projects is also a great idea.

And, of course, reading more about specific topics is a good idea too. I recommend picking one topic and focusing on getting to know it better.

But, as you are now well aware, there's a lot out there yet to learn. Feel free to pick and choose as you like, but if you don't know where to start, I'd recommend reading up more thoroughly on HTML/CSS/JS, Ruby, and Rails.

I have some specific book recommendations listed below but I encourage you to skim the table of contents of each before buying to make sure they have enough new material to be useful to you.

First, for in-browser langauges:

Then, some books pertaining to Ruby, Rails, and testing:

Feel free to pick out books on your own, but I can personally vouch for the quality of the five Ruby/Rails books above.

As a general rule though, most everything from O'Reilly Media or The Pragmatic Bookshelf will be worth your money.

But if you don't want to rush right out and get more books, check out the resources page for plenty of places to turn to online for continued learning.

In fact, a terrific place to start would be this video, which kicks off Crockford on JavaScript with a fascinating look at the history of computing.

What did you think?

Well, that does it for now.

Thank you so much for reading, I sincerely hope you found the book to be insightful.

If you enjoyed the book or have any suggestions, I would greatly appreciate it if you would let me know by way of the feedback form below. Don't feel obligated to write a lot, or anything at all, but I would love to hear from you.

I also welcome suggestions of terms and concepts to add to the book. If you go out into The Great Big Internet and run across something that you wish had been covered here, please let me know and I'll try to fit it somewhere in the book.

Oh, and just for fun, please let me know what your favorite topic in the book was! Mine would have to be metaprogramming in Ruby, but I also love the simple universality of JSON.

And if you end up using the knowledge from this book to start an app, a career, whatever, please come back and let me know! I'd love love to hear that my book is making a difference in people's lives.

Thanks again and best of luck out there!

@forkbobomb


Feedback


I'd like the opportunity to use any positive feedback from above as a customer testimonial on the home and about pages, but I understand if you would like to opt out.


Resources