Highly recommended, this tutorial got many people (myself included) started on Rails. The parent link is to the free-online version, but I do suggest folks who have benefitted from this give back to Michael by spending on the paid version:
I like that it doesn't use the CLI. I've always wondered who uses code generators. My sense is that experienced developers do not. And that novice developers are better off cutting and pasting. I personally loathe code generators which is one of the reasons I've never gotten in to Rails (I know I can do it without but seemingly all the instruction uses it).
Been doing rails for 3 years and web dev for 8. Scaffold generators are terrible but model generators save time on boilerplate code and give me most of what I want. Test libraries can hook into this process as well saving further time. Rails has plenty of drawbacks but I see some of the CLI capabilities as a strength IMHO.
It's the model generators that especially give me pause. I like to noodle around with my fields before putting them in place. I love designing my models in code.
this is an classic for rails. countless entrepreneur/developers i know have used this as their first 0 to production guide for their first real (shipped, launched, live etc) software projects.
I say it's an excellent intro to someone with maybe some academic programming experience to get into web app development. it gives you the kick starter development plan you need to make a Twitter, db, grub hub, air bnb type startup alone or with a small team.
and... he keeps it up to date! with impeccable detail!
I don't know. I just did a Rails backend. Feel like I couldn't have written more than 100 lines of ruby in the whole thing. Not sure its that important.
I don't understand. Why would they need to know Ruby fist? These arent people looking to become devs. They're looking to limp something along until it takes off or dies. There's no need know Ruby for that.
In fact I'd go so far as to say that trying to learn Ruby first is doing yourself a disservice. Just dive right in.
I credit Mr. Hartl's tutorial many years ago with my decision to take Rails seriously and find a job where I got to work with it every day. I appreciated the framework, but it often seemed "too cute" or "too magical" for my C++-based tastes. His tutorial provided a sober introduction to pragmatic work with the framework that continues to influence my day job to this day.
(Apologies for never actually buying the book after working through the HTML version and loving it–I'll be sure to purchase a copy this month.)
One of the best beginner programming books. I was never really confident in programming until I worked through this book. It taught me so much; proper usage of git, persistence using a database, using a programming language that isn't verbose to the point of being confusing, TDD, and most importantly how to think through problems and think about the incremental design of new features. I purchased the hard copy of this book, but I'm amazed that it's always been free online!
I defy anyone to point me to a more complete treatment of a modern development environment. Hartl's work is ridiculously good. Almost wish I were still using RoR...
I put out a course a few years ago after being dissatisfied with the state of free Rails content http://schneems.com/ut-rails/. I got amazing feedback from those who took it, but while the quality of response was good, my SEO wasn't and so not a lot of people saw it. I never revised the course. The exercises are all out of date (still in Rails 3.2) but most of the videos hold up.
When I was trying to learn Rails, what differentiated Michael's book everything else I came across was his eagerness to not just show _what_ to do but also explain _why_ you're doing it. This is always my suggestion for anyone who is trying to get into Rails.
This is the book that finally led me to abandon Law and become a developer. It finally "clicked" after reading this book and, later, taking the Pragmatic Programmers Rails & Ruby courses.
I even bought the complete pack with the videos after reading just to show my appreciation to Hartl.
You know, I'll probably be bammed for saying this, but reading through this very well-made tutorial gave me the opposite reaction.
I am glad I learned and still use PHP and not RoR.
IMHO, there are way too many black-boxes and unnecessary abstractions for such a simple pattern as MVC, which is really nothing more then connecting HTML views to database fields view URI routes.
I recently struggled through my first Ionic mobile app, and all the prebuilt, "auto-magical" tooling stacks and opinionation I see in the tutorial leaves a sour taste in my mouth ie
gem 'rails', '5.0.0'
gem 'puma', '3.4.0'
gem 'sass-rails', '5.0.6'
gem 'uglifier', '3.0.0'
gem 'coffee-rails', '4.2.1'
gem 'jquery-rails', '4.1.1'
gem 'turbolinks', '5.0.0'
gem 'jbuilder', '2.4.1'
group :development, :test do
gem 'sqlite3', '1.3.11'
gem 'byebug', '9.0.0', platform: :mri
end
group :development do
gem 'web-console', '3.1.1'
gem 'listen', '3.0.8'
gem 'spring', '1.7.2'
gem 'spring-watcher-listen', '2.0.0'
end
group :production do
gem 'pg', '0.18.4'
end
All this for a "toy-app"?
Call me old-school (and I am I suppose, altho I feel I make an hell of an effort keeping up to date), but I cut my programming teeth in C and always respected the very limited but powerful instruction set that language implements, and I, over the years now, respect PHP for creating very powerful constructs (like its magical array handling) but also keeping some C-like simplicity at its core.
Yes of course PHP has its idiosyncratic issues, but I still feel that one of the primary reasons it's so disrespected, I'm very sorry to say, is the snob factor thrown off by serious motherfucking programmers whom seem to feel that the simplicity and power of the language lowers the bar so low that it allows the "unwashed" into the room or something...
No. With that stack you can build business and make money. Not a toy app.
That being said, if you were doing a toy app then you would take out PG. You don't need all the dev gems they just make your life easier / faster startup. If you come from php then you like to make your life hard, so webconsole and byebug are out. Your doing a toy app so you don't need turbolinks, coffescript, or Sass. It's a toy so what does it matter if a person downloads 3MB of javascript. Take out uglifier. You're not doing an API so jbuilder is gone.
This is the new Gemfile.
gem 'rails', '5.0.0'
gem 'sqlite3', '1.3.11'
People make Rails out to be some magical monster that know one knows what is going on. It's just Ruby at the end of the day.
Here is a single file rails boot, that includes downloading the gems and running a test.
That's an unfortunate viewpoint. The point of higher level languages is to provide abstractions. To say PHP is just the right combo of not too high level enough but not too low level is some kind of mental gymnastics to justify its existence. The same argument could be made for using C over PHP.
Also, consider that some languages' ecosystems have preferences for smaller vs larger standard libraries. Clearly most of the dependencies you listed are not actually required; they're made to be stripped out if you're not using them. It's disingenious to state that those are the minumum needed for a toy app.
Most of those are optional libraries and rails does a hell of a lot more than a base install of PHP. PHP is also only "simple" if you ignore the god awful language semantics and inconsistencies of both the language itself and the standard libraries.
First, Rails is not intended for toy-app. You can build it but RoR is production ready apps. So the stack you get reflect that.
Also, you can drop like half of those gems if you do not need them.
And finaly, if you are going to do any non-trivial app in PHP you will either reinvent similar libs yourself, or you will use Symfony, Laravel, etc. and get a comparable bunch of dependencies with Composer.
The other day on my way to the airport, I had an Uber driver in Portland who was telling me that he was just about to start a lengthy coding bootcamp in JavaScript and PHP. Not Node, just front-end JS. And Rails was one of the options, but he opted to do PHP with a focus on Drupal.
Kind of blew me away. I know Rails seems to have waned relative to when coding bootcamps first became big, but I had thought PHP was well past its attractiveness for new developers, despite the number of PHP systems that need maintaining in the real world.
This is probably not the popular opinion in this crowd BUT PHP is still the most used back-end language on the web. It has also come a long way since it's early days. Modern PHP is actually decent to work in and learning it will keep you gainfully employed in most areas outside the Bay Area.
For back-end, Python & PHP are still my go to choices. Both are stable, have tons of libraries, have good frameworks and allow you to get stuff done quickly.
While I would've also chosen Rails, the truth is that there's plenty more PHP jobs out there, even in cities like Portland so he'll be fine either way.
There are far more PHP and Java jobs for entry level devs in Portland. Since we don't have very many startups the tech jobs are mostly at financial institutions and non-tech companies.
PHP has a lot less "magic" in it, so using it will force you to learn a lot of concepts and conventions that Rails takes care of for you (which can have its negatives).
Nonsense. It makes great sense to compare some languages to some frameworks, for some purposes.
Yes, PHP is a language, and Ruby is a language. PHP does a lot more than that. A default install of PHP + Apache has routing logic, and HTTP parsing (what populates all those superglobals like $_POST?), it has templating (I'm sure ERB came up with all of its syntax independently), etc etc. In the Ruby ecosystem, you those are responsibilities of a "framework". Indeed, no one would argue that Sinatra is not a framework, but I'm not aware of any features of Sinatra that aren't already delivered by PHP out of the box.
If your goal is to build an artificial and incoherent taxonomy of "languages" vs "frameworks", then yes it's very clear that PHP and Rails are different types of things.
If your goal is to actually build web sites, comparing Ruby+Rails (which you might write as "Rails", since it implies the "+Ruby part) to PHP is a very reasonable thing to do. I think it's utterly clear that the GP was comparing "making a web app with PHP" to "making a web app with Ruby and RoR".
Please, tell me more about that routing logic built-in in PHP.
How does your HTTP parsing deal with Accept:? Does it populate $_PATCH and $_DELETE too? You are aware, that ERB is not the part of Rails and comes as standard library with Ruby? As does CGI module, so you get that "HTTP parsing" as well.
Yes, I was using the terms interchangeably - my bad. Still, Rails has a lot more conventions and magic than Laravel (I don't know about Symfony). Compared to Laravel, you have to deal with a lot less configuration to get up and running. That's what makes it such an attractive choice for beginners: you can work on developing features right away without having to fiddle with stuff. I say this as someone who has used both.
That's a fair point, but I don't think the whole class would've just been Rails. We would've talked about Ruby programming a bit too (the book does as well).
Here's why I think learning Rails would be good for undergrads: You get exposed to patterns like MVC and stuff like server vs client, requests, basic auth/security in a format that is practical and presents itself to fast iteration and quick feedback. I'd much rather learn MVC through Rails than the extremely dull and slow Java GUI apps we did in school.
I think the magicness of Rails is overrated for a beginner. A lot of people like to tinker with low level stuff, but in my experience in college most students wanted to build stuff. Having them build their own routing/template/controllers/etc or whatever would've been less interesting than just learning the high level concepts with Rails first.
As an added benefit, having some experience with Rails would've helped some students get internships.
Love this tutorial. Michael is one of the best teachers I've encountered. It's such a great tutorial that I hesitate to ask, but I'm not the biggest fan of the Cloud9 IDE stuff that was added in the later versions, though. Anyone else?
The whole "setup your environment" phase is tricky for someone new especially if you're on Windows and probably caused a lot of people to stop reading before they even touched a line of Ruby code.
I'm an experienced dev and I've abandoned many weekend projects because setup was way too complicated. I'm currently working through the tutorial to learn RoR and I did skip the cloud9 setup and use CLI, but I wouldn't recommended it for beginners because for them its important to get quick wins before running into problems.
For someone new, I agree the setup is daunting. It was almost comical that "hello world" took 10 pages.
I think the tutorial could really use an explanation of what a web app is (a bunch of files in a particular structure that the special server knows how to handle) and why we need all the setup to handle it. Then it should explain what actions, controllers, and routes are and what they do, instead of just introducing the terms without meanings. It wasn't until the exercises suggested changing the route to a different action that it clicked for me.
BTW, I think that "goodbye world" is a horrible example to use.
Beginner question, having heard rails is not a hot thing anymore and SPAs being the new hot stuff, where do you guys draw the line between a SPA and a server rendered web app? I can see the extreme side cases, the highly interactive web app vs content-heavy-but-not-that interactive web app.
But for example, github doesn't have complex interactions and is not content heavy (in the walls of text sense) but its doing just fine as a non-SPA and users seem to like it the way it is.
Would a site like github benefit much from being a SPA instead of being server side rendered with some JS on the top?
> Would a site like github benefit much from being a SPA instead of being server side rendered with some JS on the top?
I don't think so. Perhaps there could be some areas they could make the UI richer (say a dynamic code viewer that doesn't require page refreshes, etc)
However, bring it back to the beginning of your comment:
> having heard rails is not a hot thing anymore and SPAs being the new hot stuff
Github doesn't need to be a SPA, nor do most apps. I think many decisions are being made because it's "hot", but generally that's a very poor reason to choose something. (Though to be fair, there's probably many Rails apps that were built in Rails for that very reason)
SPAs carry an entirely new set of concerns. For months, I couldn't order a very important medication online from CVS because their specialty pharmacy site, written in Angular, was busted. I eventually figured out how to make it work by executing Javascript directly in the inspector.
I don't have any feelings myself at all about whether everyone should learn to code, but I'm pretty sure I'm going to remember this anecdote next time someone brings it up.
You can have an SPA and still use Rails. Rails would just serve JSON instead of the HTML. Your JavaScript frontend would use that JSON to display stuff and handle actions. Plenty of companies do this.
Cannot speak about amount of junior/entry level jobs out there but in NYC Rails jobs are plentiful.
Are there any recent, up-to-date and comprehensive tutorials that show how to use React with Rails while following the conventions of both frameworks? Every tutorial I've seen focuses on either one, but I haven't found one that focuses on both.
There's a reason why you don't see specific Rails+React tutorials - since they're just communicating with each other other JSON, Rails doesn't need to know or care that it's React, Angular, or whatever on the other end.
The reverse is true for React, it doesn't care where the data's coming from.
You'd simply want to look for a Rails tutorial that focuses on building an API using Rails.
It's probably slightly easier to learn React first IMHO.
Yeah, I actually know both Rails and React, and have built stuff with them separately. I understand they would talk to each other using JSON and don't need to be "aware" of each other.
The main thing that I find confusing is the build/deployment process of a Rails application that uses React as the front-end. For example, let's say that I develop a Rails/React app and want to deploy it. Do I run webpack first to transpile the React app to "regular" JavaScript, then git commit, then push to Heroku? Or does Heroku do that for me? Also, how does the Rails asset pipeline come into play? Any special configurations? Etc.
If you're going down the road of a React based SPA on top of a Rails API (and I'd question hard if you'll really benefit from that) do yourself a favour and just treat them as entirely separate applications. The backend deploys as you'll be used to with Rails, and the front-end can be built locally and then pushed to anywhere that'll serve some static HTML.
^^^ This. Unless you're building a CMS with a large and complicated administration UI, an SPA is probably overkill and will needlessly complicate your development process.
>>If you're going down the road of a React based SPA on top of a Rails API (and I'd question hard if you'll really benefit from that)
Why would you question it? At least my understanding is that there would be a noticeable performance benefit, since building HTML views on the server can contribute 150-300 ms to the overall responsiveness (or so I've read). I feel like React views would be a lot snappier.
Done right yes, it will feel a bit snappier, and you can integrate offline support without a huge amount of extra complexity on top of your SPA.
Sadly the trade-off currently is that your frontend is going to be far more complex to build than if you just rendered some HTML from Rails. You end up needing to duplicate your model layer in the frontend, debugging is harder because now the bugs are on the client side, which you have no access to after the fact, and integration testing becomes a very real challenge.
These are all surmountable problems, but they're not trivial, and in my opinion they're not worth it for a few hundred ms of response time, especially when you can get close to the speed ups offered with some judicious use of caching, Turbolinks, and a thin layer of JavaScript in the places it makes most sense.
Webpack and the asset pipeline overlap in responsibility, so you probably want to stick with one or the other. There may be some edge cases that I don't know about where you might want functionality from both, though.
I personally use webpack and transpile/bundle all the javascript and styles into a `build` directory that gets served by nginx.
For my side projects, I use a really simple express server with a single handler for all routes that pre-renders the react app and sends it down to the client for rehydration. After that, the client takes over and sends requests directly to the api server (rails in this case). Your boilerplate setup is an nginx reverse proxy that forwards all requests to /api/* to the rails server, and everything else goes to the express server.
For easy reproduction, you can use a docker cluster with a configuration something like this:
My sense is that SPAs are for unidirectional information architectures: click on something, then click on something in that something, and so on, ever forward.
They almost always fail in some way upon use of the back-button (e.g. both Twitter and FB, among many others). The endless page pattern always either doesn't back-button to the right place or uses a smelly hack to re-paginate the endless page.
This is only my opinion so I would love to hear others input too. I think SPA apps are really good for mobile heavy services. Heavy web services such as github or most CRUD SaaS services are fine as a web app. You can still use front-end frameworks such as React or Angular with a Ruby on Rails back-end. Oftentimes that is overkill though for a basic CRUD SaaS app.
Softcover is a new publishing platform based on the production system and business model used by the Ruby on Rails Tutorial by Michael Hartl. Using Softcover, authors can build multi-format ebooks (HTML, EPUB, MOBI, and PDF) from common source files, optionally bundle them with media like screencast videos, and publish them to Softcover’s integrated sales platform with a single command.
I converted http://www.cfenginetutorial.org from AsiiDoc to SoftCover -- the HTML build time plummeted from over a minute to just a second or two. Wow! And it looks better than it ever did.
I recently joined a company that's built on Rails. I previously was most comfortable with Python/Django. There's lots of code to crib from, and I've picked up the basics pretty quickly.
That said, I've been looking for Rails tutorials/resources that are geared toward someone with decent experience with other languages/frameworks. Would y'all recommend this book, or is this more of "learn to code with Ruby on Rails"? If not this, any other resources that fit the bill?
For someone who already knows how to program and just wants to learn Rails, the official guides[1] are top notch and a great way to learn the framework without having to read a whole book
Just a quick personal anecdote for a different perspective:
When I wanted to learn Rails as a developer getting into web dev, I read the Rails Tutorial relatively quickly and did the major exercises. I thought it was well worth the time and would have bought a print copy to reference/scribble in if it had been released in a timely manner.
After that I got the Rails 4 Way, which I still refer to from time to time. It makes a pretty good reference or topical reader once you're more familiar with rails. It is more a book on how things are put together and why, as compared to 'this is how to do X step by step.' I imagine there will be a new edition for rails 5 soon. This would probably be my first recommendation for you coming from Django.
I didn't find the official documentation to be all that helpful until after I had finished that reading and understood the rails system a little better. Now I use the documentation a lot more. The rails source I occasionally refer to, but it is rather painful to read if you're not deeply entrenched in the ruby/rails metaprogramming idioms.
I also have a copy of Agile Web Development with Rails 4, and I never open it anymore. I tried to get through it, but I find it a rather poor book. It is very light on details, or just content in general. Personally don't think it's worth the time or money.
Obviously I like reference books, I find writing in margins and physically flipping pages helps me learn. YMMV!
I would also recommend the documentation. However, if you're really looking for a good book, Agile Web Development With Rails is great. I would hold off on getting it until the new one comes out, which will include all the new features of Rails 5. You shouldn't have a difficult time with it since you do have prior experience with different technologies.
Another resource would be GoRails. Some of the videos require a membership though.
Since you've posted a few comments with this same sentiment a few times in this thread; can you expand on why you feel people would need to learn Ruby before getting started with Rails?
Also if you'd have taken a few seconds to open the link to the book and skim through the opening paragraphs you might have read this sentence:
> There are no formal prerequisites to this book, and the Ruby on Rails Tutorial contains integrated tutorials not only for Rails, but also for the underlying Ruby language, the default Rails testing framework (minitest), the Unix command line, HTML, CSS, a small amount of JavaScript, and even a little SQL.
I kind of agree with GP sentiment for two reasons:
1. Nowadays I mostly advice newcomers to start with sinatra instead of rails, because rails keeps growing in scope and the surface to cover is huge
2. Lots of things rails does might seem magical if you don't know ruby
Don't get me wrong, rails is still bread and butter of myself and other rubyists, but for a newcomer to start with rails is a somewhat strange/scary thing to do.
I am slowly transitioning from Ruby/Rails web dev to Clojure web dev and the process is pretty sweet :) And I don't think there will be any less demand for Rails jobs in the near future, because books/vides like railstutorial exist, to attract the sheep ;) Just kidding, I think such books are great.
https://www.railstutorial.org/#pricing
No affiliation at all, just want to encourage support to a resource that has been a net-positive to our ecosystem.