The other thing I want to add is how much 'else' I learned while running through Michael Hartl's tutorial.
Despite many years making websites, I really had no clue about basic http methods — get, put, post, etc — and in fact, I didn't even realize what they were. The other huge, huge thing for me was finally figuring out what REST is all about.
Basically, the web runs on those few basic http methods, and using the REST approach spells that out for you and cements it in your head.
I had an awesome jump-up-and-down moment when it finally clicked.
I get really annoyed when there is an element that follows me down the page as I scroll. It's really distracting. I get even more annoyed when I have to set up an adblock rule to make it go away.
Please, designers, stop doing this (and stop doing menu bars with the same behavior). There's not much on your site that is important enough that I need it to follow me everywhere.
Congrats on the launch. I think I speak for everyone on HN when I say, you're going about this the right way: learn enough to build applications for yourself, whether or not you're going to be a code committer over the long term.
Can I give you some quick advice? Don't take this the wrong way: Rails makes it easy to learn enough to be dangerous in 12 weeks. Some quick hits on obvious things you should look over in your application to ensure it isn't overtly insecure:
* Every model class should have an "attr_accessible" statement, and the attributes you expose through it should be minimal. A very common misconception: "the things in attr_accessible are the only attributes users can set". Not so! The things in attr_accessible are the only attributes users can set automatically, through mass assignment. You can expose things that aren't in attr_accessible by manually settings them with assignment statements. Assume anything that's in an "attr_accessible" list, and every attribute of a model without attr_accessible, can and will be set to the most hostile possible value, like "role=admin".
* Rails programming intros have a bad habit of introducing ActiveRecord finders in the context of the model class object --- in other words, "Post.find(params[:id])". This is exactly the wrong way to do it; it's so bad that you can literally generate a list of vulnerabilities on Rails projects by grepping app/controllers for "[A-Z][a-z]+]\.find". Instead, make sure all your finders work via associations, like "@current_user.posts.find(params[:id])".
* Use a popular plugin for file uploads. Rails doesn't do much of anything to defend against file upload/download vulnerabilities. If I was building a public-facing Rails application, I'd do whatever I could to keep the filesystem namespace out of my requests --- storing all files on Amazon S3 without explicitly storing them in temp files is a good way to do this.
* Don't enable the old-style wildcard route ("/:controller/:action/:id) or any of its variants ("/posts/:action/:id :controller => :posts); whether you declare methods "public" or "private" in a controller should have nothing to do with whether they're exposed to attackers.
* Have a "PreauthController" that inherits from "ApplicationController" and disables the is-logged-in check; in other words, every controller, particularly every controller generated by "rails generate", should be post-authentication by default. Set up the before_filter that checks for a valid user session right there in ApplicationController, then "turn it off" for the LoginController by having it inherit from PreauthController.
Similarly: if you can get away with not having an AdminController at all --- run a totally separate Rails app for admin that requires a VPN to get to --- do that; otherwise, have an abstract AdminOnlyController class with no methods in it that does nothing but set up a before_filter to check for admin privileges, and have every admin-only controller inherit from it.
* Pretend the backtic operator (the one that executes Unix commands) doesn't exist.
You may do all of these things already (in which case, good for you! you learned more in 12 weeks than a lot of Rails developers do in years). I just called them out because (a) not doing them will be tremendously painful down the road (individual XSS slipups are annoying but unlikely to kill you, but vulnerabilities that allow people to dump your whole database are something else) and (b) they are so easy to fix.
Teaching good security practices was one goal of the Ruby on Rails Tutorial (a resource mentioned in the OP). It uses attr_accessible for every model and uses find-through-association (emphasizing the security implications of both), and it most assuredly does not use the /:controller/:action/:id pattern or backticks. It punts image upload over to Gravatar, and recommends Paperclip for those who need custom uploads.
Having a PreauthController definitely sounds like a good idea, but it might be a bit obscure for beginning developers. I'll consider it for inclusion as an exercise in one of the chapters covering authorization, or maybe I'll include it in more advanced Rails Tutorial material down the road. Thanks for the tip.
All I can say is, I looked under the hood at the application we're talking about and thought these might be useful suggestions. Particularly attr_accessible.
I've found a lot of Rails apps over the last couple years that were diligent about having an attr_accessible in every model, but not diligent about what went in the attr_accessible. Following the Rails idiom, they were doing all their attribute assignment through update-style params[:model] model[foo] model[bar] stuff, and attr_accessible "breaks" that.
The Rails tutorial is good (and ambitious) --- just know, this stuff trips up solid, experienced Rails developers all the time.
When I was starting out, every tutorial seemed to assume that I even knew what "mass assignment" implied. Creating a bunch of bad things at once? Changing a lot of existing things in a bad way at once like their creator_id so a bad guy could access them?
I think "mass assignment" and "attr_accessible" in tutorials should always link to the API documentation[1] that explains the implications and the tools at your disposal + example code.
Worse still, I started off with Beginning Rails 3 by Apress, and it makes only one obscure reference to attr_accessible, and not in the context of security, doesn't mention mass assignment at all, and has no chapter on even basic security. Beginners need to learn this stuff early, so Apress' oversight is unforgivable. mhartl OTOH is to be applauded.
Those are awesome pointers - there should be a tool that you could upload all your applications files to, the tool would scan all the files for these errors and return a report on vulnerabilities found and instructions on correcting. Maybe this already exists? I am a beginner programmer as well, making my way through Rails Tutorial (chapter 10) and Learn Ruby the Hard Way (exercise 35) and Codecademy Code year.
Thank you for this. I will have to look into a few off that list and implement them. All the models does have attr_accessible. Using CarrierWave for uploads.
I think it might be worth your time to double check your attr_accessibles. Just:
grep attr_accessible app/models/*rb
Everything that comes up on that list, you should be comfortable with users giving any value they want to; that's what attr_accessible (effectively, not literally) means: "I give up any control of how these attributes will be set".
Fantastic post. Thanks so much for it. I decided to really dig into Ruby on Rails after Christmas this year, after thinking/talking about it for years. I was thrilled to hear that you really had no programming background—I think a lot of us are in this boat.
I watched the Lynda.com videos on Ruby, and the one on Ruby on Rails (both from Kevin Skoglund). I just watched enough of both to get fairly overwhelmed and confused, then moved on to Michael Hartl's site. Things started to click much better there—that's the best Rails resource I've seen to date.
Still though, After really digging in over the evenings and two weekends, that nagging feeling started to set in—am I actually going to 'get' this? Am I wasting my time? Is this going to take years? Will I ever get past layouts/partials? Should I just go learn PHP / Javascript / iOS / something else?
Did you feel like giving up? Or question the purpose/wisdom of learning Ruby and Rails?
I started actively teaching myself Rails in Dec 2010 after dabbling with it off and on for years. Went in blindly like most of us do. The uneasiness of the aloofness was eased by the fact that I was learning every day and dangerously productive with what I did know.
Didn't finally grok what REST actually was until last month. It also took me months to finally understand what exactly "mass assignment" meant and what `attr_accessible` is actually protecting against. http://api.rubyonrails.org/classes/ActiveModel/MassAssignmen...
I feel like every little thing I learn just makes it easier to predict how other things work and gives me more wherewithal to dig in and learn how they work. I also finally started just reading the dang API for once which is incredibly documented compared to what it was many years ago when I first encountered Rails.
Stick with it and actively pursue the things you don't understand. reddit.com/r/ruby, r/rails, stackoverflow, HN comments, and irc.freenode.net's #rubyonrails have been huge helps. In fact, I just started hanging out on #rubyonrails while I'm getting work done. If I don't have a question of my own, I learn even more trying to answer other questions. And I found that #rubyonrails is the best place to ask "why is it this way" because it's too meta for stackoverflow and sometimes all you need is a succinct explanation for something to click.
Yes, it was the hardest/easiest thing to learn I've ever experienced. Sometimes I was jumping out of my chair and then other times throwing things against the wall.
Plenty of times I wanted to just give up.. during those points; I'd step back and go take a break, go for a walk, do something.. other than think.
Programming is hard because it's full-time blitz mode thinking. I felt the front part of my brain (is that where all the programming juice is held?) hurt often in the beginning.
Do you have an actual product you want to work on?
> Do you have an actual product you want to work on?
Having a real product to build, even if its just to help yourself and not the world is key. It gets you out of the tutorials (which you need to do) and into finding out the main problems you have to solve to get something live.
And once you've got something live, you've built your mental framework that you can "hang" everything else you learn on.
Couldn't agree more. The urge and desire to start learning was constantly squashed by the daunting task at hand. Once my ideas began to coalesce into something coherent, the passion and interest superseded the difficulty or fear I'd never "get it".
You're 100% right about having something specific to work on. Going through tutorials doen't commit you to anything, and hence never compels you to keep going when things get tough.
The place where I stopped with Michael Hartl's tutorial was on the authentication chapter. I found that whole salt thing completely confusing. Later, I heard about Devise (and others), I thought—Ok, so I'll never actually need to know how to do this—but that's not true. Right on the Github page it says that Devise is complicated and not for beginners. In fact, I'm pretty sure it links back to Michael Hartl's article as an 'easy' way to implement authentication!
That's when I packed it in right there!
Thanks for the advice and for taking the time to write this stuff down. Your freelance site looks amazing for 12 weeks work. Great stuff.
I'd like to add to this simply because I had a very similar experience but with PHP.
There were definitely times when I was extremely frustrated and wanted to give up. There were a couple times when I had 5+ hour sessions and got nowhere, then I'd come back the next day to realize it was a stupid mistake.
One thing I can't stress enough (and James has been saying it too), if you don't have a final site, product, or app in mind you're probably going to get bored and walk away for good. I tried to learn C++ a while back and gave up because I didn't have anything in mind and the boring repetitive exercises lead to nothing in the end.
"then I'd come back the next day to realize it was a stupid" I couldn't agree with that more!! Come back and you find out all you had to do was restart the 'Rails Server' or simply mis-spelled something.
I have done the exact same thing as you, saltcod. I have been reading on Ruby on Rails for the past 4 months prior to December. After the new year hit, I told myself that this is the year I fully understand and learn Ruby on Rails to the point of putting out a product. I had started the Rails Tutorial by Michael then stopped, probably from confusion or disinterest. I watched/read many other tutorials that are around.
I have also signed up as of Jan. 11th with a monthly Lynda subscription just to watch the Kevin Skoglund tutorials on there, I have probably 4 hours of tutorials left. I skipped much of the environment setup since I have that down. This tutorial so far has helped me to understand a lot of concepts. I hope to revisit Michael Hartl's Rails Tutorial and fully complete it with TDD and all.
If you ever need a kick in the ass shoot me an email.
I will probably do a write up on my experience learning RoR after I get something built. Like the OP, coming from HTML & CSS & Some database background.
Great write up. I experienced a similar adventure in learning PHP over the past couple months and I completely agree that the first few weeks are by far the hardest.
Late last summer a friend and I came up with a great idea but we lacked the programming skills to create it ourselves. I knew a bit of HTML, a touch of c++ , and PLC ladder logic programming(huge help, right?). It wasn't until around October that I realized we were getting nowhere. I decided enough was enough and I was going to learn how to program. I spent an entire weekend reading and trying out zend's PHP 101 for beginners. Three months later and I had created a user authentication system with messaging, friends lists, administrative rights, and all sorts of other goodies. I was working a full time job so I did this with my spare time.
Your site looks great by the way. Keep up the good work.
During the initial learning phase I wasn't as enthralled because who cares what $this->someFunction($variable) means? I'd say I put in around an hour per day for the first month and then once I got the hang of it, probably 2-4 hours per day after that. I made sure to take off programming at least one day per week so I wouldn't get burned out considering I was working full time too.
So, I'd estimate around 150-160 hours. I should've kept track. I plan on learning ruby later on this year and I'll be sure to keep a record of that.
James, this is in response to what you said to my last comment. The reply button wasn't showing.
Anyway, that 150-160 hours was to the point where I was comfortable enough to sit down and code away. I'm still working on the system and I'm still learning a lot. I'd also like to become a lot better with css/jquery. I know the basics and not much more. A guy on my team is a front end whiz so I don't have to worry about cramming that into my head right now.
Hey James, very inspiring read. I've been following your story and progress on the fastlane forum and glad to see that you had a successful launch! I've also been learning to program myself but my language of choice was python and django for framework. You are right that it takes some time to get through that initial learning curve but once you reach that first stage and figure out how to get past everytime you get stuck, it gets pretty exciting and fun. Congrats and best of luck to you!!
Any advice for getting started for someone without a Mac? I remember once trying to learn and immediately stalling out during setup (lame, I know). I have WinXP & Ubuntu, and would like to take a stab at this again no matter how stupid I feel about not even being to able to install the damn stuff to start with.
My advice is to do your development using a Virtual Machine--ideally running the same OS as what your production web server will eventually be running. This gives you the freedom to screw around with your app and server configuration, knowing you can easily roll back to an older version. And it also gives you more confidence that your app will deploy cleanly to your production server and not get hung up on some subtle difference between e.g. Ubuntu and Red Hat.
And, finally, then it doesn't matter whether your host OS is windows or ubuntu; use which you feel most comfortable with.
The Ubuntu and Mac setups should be pretty similar. It will be easier for you to get help developing through Ubuntu than XP. Stackoverflow/IRC are your friends when you run into trouble.
Another thing to look into would be Vagrant (http://vagrantup.com/). You can have all your ruby/rails specific dependencies in a Virtualbox VM and not worry about setting it up in your host OS. It also has the added benefit of easily tearing down the instance if you manage to mess up. There's a learning curve to it, especially when setting up chef recipes, so for starters you could just bake everything into the image
I don't want to sound blunt, but I found the installation process of ruby/python/git on windows to be more painful than necessary. (Last time I tried) It might make sense to try it on Ubuntu as it should be very similar to a mac environment. Good Luck!
Python? Really? There's nothing you need to do after running the installer. It sets up the path and everything. Most of the popular python libraries that require a binary component have windows installers as well.
Ruby is a bit more understandable, if you don't get DevKit (or if DevKit can't compile something) working with gems can be frustrating. And setting up Git on Windows with an SSH key has been awful in the past.
RailsInstaller takes a lot of the pain out of setup, though.
http://railsinstaller.org/ makes it really easy on Windows, though you might find that some of the gems don't work properly.
Another option would be to use something like Vagrant, which gives you a VirtualBox server that's mapped to your local filesystem. So you use the editors you're used to but you have a fairly solid server running the code. If you search around for "vagrant rails" you'll find several pre-built images, along with a RailsCast that explains how it all fits together.
Use Mac Leopard, and don't switch from 32 bit to 64 bit - you're gonna get a massive headache getting all those gems you need to install. Also if you're considering doing anything to do with image processing, consider NOT using Mac. Installing stuff like PIL and ImageMagick can be hell
I'm going through the rails tutorial on arch linux and I haven't run into any issues. Definitely use ubuntu, I think it'd be pretty painful on windows.
I had a look at it too, and from a design standpoint it looks very nice. I am not sure about your choices for project budget. For example, this description was posted for bids:
Need Drupal developer to: - do PSD/HTML to Drupal theme for one new section on the existing site. - Do additional module programming. - fix issues/error on the site - Make the entire site work
With a stated budget of $100--$300. I mean come on, that's ridiculously naive on the part of the person who posted. If you could give bid-seekers some guidelines on what to reasonably expect, e.g. some examples of what a budget of $100-$300 might buy, it would help people get qualified bids.
Thank you! Without getting too much into technics in the beginning, and getting the person to get something up to feel accomplished, gain confidence.
I think that's what gets most people. That initial learning curve takes a lot reassurance that they can do it; but if they hit a wall and it takes more than 7-8 hours to get around it, a lot just quit all together.
By far, the most thorough and best written resource I used was the Rails Tutorial from Michael Hartl.
thanks james and commenters saltcod and tmh88j for saying that the first few weeks are the hardest. I'm banging away at the google python exercises and nearly crying. knowing that other people are going through this headache too gives me a bit of confidence to truck through.
Once you get through the basics, think of a couple small programs to write to test out your new skills and you'll be sure to encounter new problem. Some of the first programs I wrote in PHP included sorting and ordering a list of numbers and letters that were entered, a pig latin converter, and then to get the hang of MySQL, I created some simple database entries.
For the first month I was constantly referencing other code online to figure out how to create my programs. After a while I found myself looking less and less at existing code and I was able to simply type away.
I started working on my first non-trivial application and having no test suite started hurting me within a few days. Inconsistencies between my local and Heroku environments just feel like whack-a-mole with no easy insights into where along the commit line they broke. `git push heroku` feels blind as I cross my fingers.
Now I'm in the process of applying tests retroactively which is even more painful. I'm doing this "retro-TDD" process of breaking my app and writing tests until they go green when I fix my app.
I suppose this is a necessary journey to actually practicing TDD.
hey danneu,
Unfortunately no. The logic for the cucumber tests are written out, so if another coder took a look at the .features, they'd be able to figure out what the app needs to do. But as far as the tests working if I cmd 'cucumber'; they would all fail as they aren't defined yet.
The main reason for this was, me and Josh were actually going to only do Freelancify for a week or two without testing, then scrap it and re-do it again BDD test driven.
I ended up putting so much work into it in the weeks, that starting over from scratch would be a huge time-killer. One of the next things on the to-do is to go back and make these cucumber tests work.
Josh and I are probably also going to start on another small app so I can do BDD first, then code.
As someone with programming background, I actually wish there are more stories on the opposite direction (programmer who gets kickass awesome in UI design (HTML + CSS)).
I think that the complexity of CSS compatibility (what browser supports what not... even there are minor quirks between Firefox & Chrome, not just IE.. don't get me started on IE7 & 8 either), it is very easy to raise a white flag and say "that is it..I am going back to deal with backend only tasks, nothing that consumer will see on the surface).
Perhaps, OP already has a knack for UI design (as he/she mentioned in the post that he/she is a UI designer by trade before Ruby), so kudos for getting a nice grip on Rails. As for me, I wish I can master the UI design etc.
I sort of built my skills in unison (had an interest in both programming and design since I was a kid), but my career has tended towards the development side, so I guess you could say that I am a programmer by trade that picked up design on the side. Whether or not I am "kickass" is subjective, but people seem generally happy with my work.
The biggest challenge I find is that people do not take designer programmers seriously. Those who do just enough programming to support their interfaces seem to be respected, but as soon as I dive in writing some low level component in C, as an example, my design skills are immediately discounted, it seems.
Programming is design, in my opinion. The way you structure your code, getting the indents and spacings just right to be pleasing to the eye, are the exact same skills you need when you're shifting pixels in photoshop. Thinking about how the next programmer will interpret the meaning of your code is the same skill you need when thinking about how a user will use your interface. I feel the only thing limiting a programmer from becoming a good designer is practice.
I have the opposite background, but similar anecdotes. Spent all of high school and college in various art or design-focused curriculum and degrees. Inevitably ended up taking a few dev courses, but was only marginally interested. My first job after college was as a web designer in a software shop where I quickly realized that "real-world" programming mixed aesthetics and creativity with logic and really hard problems, was immediately hooked and started absorbing everything (even SICP!) in my quest to become a better developer.
Like yours, my left-brain intuitively sees patterns and (un)readabilty in code, beauty in simplicity, and has empathy for users/novices. My right-brain solves the problems, connects the top to the bottom, and is cold-and-calculating about the inner-workings.
It's also my experience, that if you are design-forward people discount your programming skills (all the more reason to prove them wrong) and if you are development-forward people discount your creative side ("oh, I _totally_ trust your opinion, but just to be on the safe side....").
IMHO Diversity of skills gives you insight into your work and the world around you. Even if you are not a natural you still gain new perspective. Hell, even knowing that you aren't any good is half the battle! I am good at _executing_ other people's ideas, and intuitively knowing what looks good - but struggle coming up with an original _truly unique_ artwork from scratch. On the other hand, Give me an empty vim buffer...
CSS and HTML and compatibility has nothing to do with UI design. Someone who does CSS and HTML would be a "frontend developer", a "ui designer" is someone who designs. The roles can be combined, but if you were to say "I am a UI Designer" that wouldn't mean you deal with CSS and HTML.
Arguably, until traditional software developers are able to grok these distinctions, you're not going to see many of them "crossing over" to design work.
I think it has a lot more to do with memorization of all the little quirks on what works on what browser and what doesn't.
With languages like C#/Ruby/PHP/JavaScript, I find that I can soak up that knowledge better than HTML/CSS, because I find it consistent and organized (...not too sure about PHP's quirky API naming conventions). For CSS, it just seems like there is a myriad of tricks you gain through out the years, and I guess it just takes more effort to get good at it.
Exactly. Programming is logical. Styling isn't. Knowing that `margin: 0 auto;` centers elements in CSS isn't a left-brain, right-brain thing. It's just something unintuitive that you accept until you stumble upon the New Way of doing it.
jekyll on S3 is a pretty killer combo for a cheap blog that scales infinitely and automatically. You'll probably like it, especially since you're a ruby guy.
Despite many years making websites, I really had no clue about basic http methods — get, put, post, etc — and in fact, I didn't even realize what they were. The other huge, huge thing for me was finally figuring out what REST is all about.
Basically, the web runs on those few basic http methods, and using the REST approach spells that out for you and cements it in your head.
I had an awesome jump-up-and-down moment when it finally clicked.