Live data from Hacker News

Ruby on Rails Tutorial

railstutorial.org

71–80 of 82 posts

Re: Ruby on Rails Tutorial

#71
post #59

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

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

Rails guy here of 10+ years (started before 1.0).

Still use the generators. It sets up the model, the tests and fixtures all in one command. It's a productivity win for me.

Re: Ruby on Rails Tutorial

#72
post #17
post #3

I'll always be upset that my college web development class got changed from following this tutorial to early 2000s PHP without a database.

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 Ioni…

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.

Re: Ruby on Rails Tutorial

#73

I am surprised this hasn't been submitted dozens of times in the past. 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.

Seriously! Going through comments it appears that this is legendary tutorial on rails. This should've appeared more than once on hackernews.

Re: Ruby on Rails Tutorial

#74

Earlier quoted context omitted.

What does GP stand for in this context? I keep seeing it on HN and figured out what it means, but what do the actual letters stand for?

Grandparent. As in your comment is my parent comment, and your parent comment would be my grandparent, and so on.

Makes sense, thanks. I've seen 'OP' (original post/poster) enough times that I thought it was a variant on that and couldn't make sense of it.

Re: Ruby on Rails Tutorial

#75

I am surprised this hasn't been submitted dozens of times in the past. 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.

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

Re: Ruby on Rails Tutorial

#76
post #62

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.

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.

Re: Ruby on Rails Tutorial

#77
post #58

Earlier quoted context omitted.

PHP can be compared to Ruby. Rails can be compared to Symfony or Laravel. It makes little sense to compare a language to a framework though.

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…

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.

Re: Ruby on Rails Tutorial

#78
post #59

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

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.

Re: Ruby on Rails Tutorial

#79
I just want to put a plug in for @mhartl's Softcover (https://www.softcover.io/)

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.

Re: Ruby on Rails Tutorial

#80

Earlier quoted context omitted.

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.

Ah, gotcha. Thanks, that makes sense. >>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…

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.

Post reply on HN