Does anyone else find Rails difficult?

I've used Codecademy Rails (would not recommend), Codeschool's Rails, now I'm watching a YouTube Rails tutorial by Derek Banas and I just don't get it. I've watched Ruby tutorial videos and done Ruby Codecademy, it's somewhat similar to Python, which was one of my first languages, so I understand it and have built a couple little projects with Ruby. However, I don't understand Rails. I don't understand Routes or when/why to use colons or @ or #, etc. I am somewhat new to programming overall, I started Python about 4 years ago but only really started taking programming seriously this year. I am currently studying Java for uni, and I know enough PHP, JavaScript/jQuery, Python and Ruby to get around. I picked up The Rails 4 Way and Ruby on Rails Tutorial by Michael Hartl but I am wondering if I should just stop Rails for the time being and concentrate on my major (cyber-security) and other web development aspects/programming languages. I am learning Ruby & Rails for [The Odin Project](http://www.theodinproject.com/) because I would like to maybe be a professional programmer one day, have a wider array of marketable skills after graduation, and I am just a computer geek and would like to always learn more. Any input, success stories, encouragement, study materials or suggestions?

 

**TL;DR:** I am a Rails n00b, I don't get it and I'm discouraged/overwhelmed by it. Looking for study materials, success stories, encouragement or suggestions.

3 thoughts on “Does anyone else find Rails difficult?”

  1. 1. Have you ever used an MVC framework before?
    2. How much Ruby code have you actually written?
    3. What have you tried to do thus far in an actual Rails project?

    You said you wanted encouragement and suggestions, so here is my rant:

    I just try to build stuff. I play a lot of pool and one of the best guys I’ve played with told me something like this: _”you could spend 20 years watching every video, reading every book, and understanding every aspect of math and physics until you understand and can explain the game perfectly, but if someone who spends those 20 years in a room alone with a pool table, without videos or books, and without knowing any math or physics, you will spend the rest of your life trying to beat them.”_

    I try to build stuff and I fail because I don’t know things, and when I fail I know what I am trying to do (and sometimes have an error message), and I go straight to google. I google shit _like crazy_. At the end of a 2 or 3 hour session I usually have so many Chrome tabs open that I can’t read the text on any of them. I google so much that google automatically gives me a captcha a few times a day because it thinks I am a bot. I google, I look for code that is relevant to what I’m doing (usually Ruby/Rails documentation, StackOverFlow, etc) and eventually I find it.

    When I find the information, I don’t try to understand the entire gem I’m using, or the entire class or module. I try to understand the bare minimum to get the few lines I’m currently working on to run. I look for a comment confirming it works (if it’s documentation I know it works), and I go straight back to my code and shove it in there.

    I don’t try to make it pretty. I just force it in until I get results, then I make it look good, but don’t waste time trying to make it look good. Just good enough for me to *feel* good about it. Having pride translates to more momentum, but trying to write code you can have pride in almost never happens at the same time as trying to get the code to work. Sandi Metz calls this “Shameless green + refactor” which translates to “make it work no matter how ugly, then when it works (and in practice, when you have tests written to ensure it still works), make it pretty.

    The single biggest piece of advice I can give you is this: Do not try to reach a point of understanding and confidence so you can then use Rails. Instead, just use Rails, and fail miserably, and get pissed, and hit brick walls, have minor victories, and fail some more but less miserably, and break a mouse, and have some more victories, and read some documentation and then read some more, and fail less and less.

    Don’t approach Rails with hopes – charge at Rails with brute force and determination. Don’t go watch videos or read tutorials. Decide what you want to build and try to build it. The first thing you need to do will become obvious, and when it does, google it, read documentation, and watch videos about that specific thing, and then get it to work. When, at the end of the day, you can’t figure something out and you are defeated, reflect on all of the shit you know this evening that you didn’t know this morning – that is what’s important.

    Focus on small tasks. Don’t think about the whole project unless you have to. Don’t even think about the whole feature unless you are breaking it down into pieces. Organize those pieces so the first thing you do is what the other pieces rely on. All of my projects, even huge ones, start like this:

    1. Get a new rails project going
    2. view an empty home page.

    When those things work, I still call them victories, and I open the terminal, and I make commits. Do whatever you can to keep your sanity intact. If you are working on a project by yourself, make your commits fun:

    d6e55fe heck yes new rails project
    14c5778 omg home controller and routes OK I’M DONE

    Get in the habit on making small commits. Very small. Small enough that another programmer could look at the changes and understand it in less than a minute. This keeps you from getting overwhelmed when working on something. You can only have so much in your head at once, and having many small victories over the course of a day rather than a few over the course of a week means you gain momentum, you gain confidence, you stay focused, and you don’t try to work on too many things at once.

    Who cares if it’s a Todo app, or an app to organize and categories your favorite streaming videos, or an app to randomize cat pictures: **build something**, and if you don’t know what you are going to build, don’t even think about code until you do know, and try to make it something useful to you or something that solves one of your problems – after all, that’s where the best products come from.

    Much love. Much luck. Happy building.

    Reply
  2. >I don’t understand Routes or when/why to use colons or @ or #, etc.

    `@variable` is an instance variable and most commonly used to assign a value in a controller that can be used in the view.

    If I assign `@hello = “hello”` in hello_controller.rb under the index method, then in my views/hello/index.html.erb I can have access to this variable. We most commonly use this to return a resource or collection of a resource associated with a CRUD method.

    Colons are used for a Symbol. These are treated as immutable strings. You’ll often see them used for hash keys. One thing that can get confusing quickly with that case is there are two different syntaxes available now for assigning. You may have seen

    `:thing => “something else”`.

    That’s the older “hashrocket” syntax. Now days it’s becoming more common to use the newer json-like syntax which would look like this:

    `thing: “some thing”`

    Anyway, you will often see symbols put to use for certain built-in rails tools, like validations, or routes. I assume they are used due to lower memory usage and because they are meant to be immutable. You will often see params and model attributes in the controller being represented as symbols.

    `#` is for comments. Anything after `#` on a line is a comment and not returned or evaluated.

    Reply
  3. Ive been doing rails for almost 3 years and I *still* don’t understand why somethings are a :symbol => and other things are not. No fucking clue.

    Reply

Leave a Comment