Ruby on Rails Tutorial
railstutorial.org
railstutorial.org
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.
Still use the generators. It sets up the model, the tests and fixtures all in one command. It's a productivity win for me.
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 see so many people just skip Ruby fundamentals and go straight into Rails, or worse... they think that Rails is... Ruby.
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.
For those who don't know -- and I guess there are always new people -- this is probably the most famous Rails tutorial on the web.
It has the following impressive attributes:
1. Free
2. Goes through a good process
a. Backs up code to Git
b. Tests the code
c. Deploys it to Heroku
Other paid tutorials are often versions of this one.
(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.)
I even bought the complete pack with the videos after reading just to show my appreciation to Hartl.
At least it was an easy A.
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".
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.
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.
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.
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
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...
To me, thats not a bug its a feature.
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.
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'
Here is a single file rails boot, that includes downloading the gems and running a test.
https://github.com/rails/rails/blob/master/guides/bug_report...
Way too hard to really get going, but maybe it's an OK patience screener.
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.
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?
Cannot speak about amount of junior/entry level jobs out there but in NYC Rails jobs are plentiful.
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.
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)
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.
Mostly JS frontends are just for annoying grumpy oldtimers like us here at HN.
Seriously: unless you have a serious good reason for depending on JS in the frontend then keep it to progressive enhancements: autocomplete etc.
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.
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:
version: "2"
services:
www:
image: "nginx:1.10.1"
restart: "always"
volumes:
- "./node/dist:/usr/share/nginx/html/dist"
- "./nginx/default.conf:/etc/nginx/conf.d/default.conf"
ports:
- "8080:80"
links:
- "app:app"
- "api:api"
container_name: "react-rails_www"
app:
build:
context: "."
dockerfile: "Dockerfile-node"
image: "username/react-redux:0.0.1"
volumes:
- "./node:/home/app/src"
ports:
- "3001"
container_name: "react-rails_app"
command: "npm start"
db:
image: "postgres"
container_name: "react-rails_db"
api:
build:
context: "."
dockerfile: "Dockerfile-rails"
command: "bundle exec rails s -p 3000 -b '0.0.0.0'"
volumes:
- "./rails:/home/app/src"
ports:
- "3000"
depends_on:
- "db"
container_name: "react-rails_api"
server {
listen 80;
server_name localhost;
charset utf-8;
location /dist {
alias /usr/share/nginx/html/dist;
}
location /api {
proxy_pass http://api:3000;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
}
location / {
proxy_pass http://app:3001;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
}
}
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.
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.
From the website:
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.
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?
Another resource would be GoRails. Some of the videos require a membership though.
All the best!
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!
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.
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.