How I Learned Enough Ruby On Rails In 12 Weeks To Launch Freelancify

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 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.

Using MacPorts to install ImageMagick was hell. But when I used HomeBrew, it was like night and day.

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.

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.

Good luck!