And, finally, then it doesn't matter whether your host OS is windows or ubuntu; use which you feel most comfortable with.
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.
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.
When I get more experience in Rails though, I'll probably switch over to using a Mac.
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!
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.
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.
http://api.rubyonrails.org/classes/ActiveModel/MassAssignmen...
grep attr_accessible app/models/*rb
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.
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.
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...
I've noticed usually the better someone can draw on paper, their web design reflects the same.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
Based on your experience, how do you think learning materials/tutorials could be improved for people learning from scratch?
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.
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.
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.
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.
Your site looks really nice, and now you've got the ability to do design AND program, which is a combo that isn't too common.
Best of luck with your site....
For instance at the "type 2 + 6" question, if I type 2+6 it freezes. If type 2 + 6 it's fine.
Running OSX Lion and Google Chrome.
Dave