Rails 5.2 | Hacker News Reader

Rails 5.2

weblog.rubyonrails.org

151 pointsmoeamaya37 comments

Say what you will about Rails, I find it hard not to love, despite having dealt with a couple of large Rails codebases that were woefully out of date and/or ridden with technical debt from programmers who were either unaware of or were compelled to do things against “the Rails way.”

I’ve investigated several alternatives that offer significant advantages over Rails, like static type checking or simplicity or security or performance, but I still suspect that I would turn to Rails if I were to start my own web company or any non-trivial web app or API I intended to keep around for a while.

I love Rails, but for me, it’s missing the Daniel Kehoe style generators. As a web app developer, I don’t want to configure omniauth, capybara, Twitter bootstrap, rspec.

Add that ability to the command line like:

rails new Blog —configure bootstrap capybara rspec omniauth=github

And then it automatically shows up. I get a landing page where I can login with github and get a skeleton spec directory where I can just start adding tests. And I can start using bootstrap css classes in my erb templates and they just work.

I love Daniel Kehoe’s work (Rails Apps) and I’m surprised it’s not being incorporated into Rails. His work makes Rails even more approachable and I think Rails is missing Daniel’s little gem.

https://github.com/RailsApps/rails-composer

I love that style. Does anyone know if there's anything similar for React/Redux? An alternative to using large boilerplates and having to customize it ...

create-react-app has some basic generators, but I don't know if their system is extensible in the same way that rails' is.

Currently ending year one of my new startup which is being built on top of rails. It continues to be a remarkably great platform upon which to build a real sustainable business.

Thank you to all the contributors who have contributed so far to this release and to all those who will test it prior to GA.

As usual, Rails is impresive framework and this update addresses and eases pains (file uploads) and streamlines work (redis and cacheing).

Most people unfortunatelly are stuck with old codebases and will have to wait before they can use something shiny like this in daily work.

Last few years, majority of my work in Rails is upgrading older apps to current, for security mostly.

Really great update, congrats DHH and the team.

It's amazing how many apps for which this is true. I've spent more time in Rails land upgrading older microservices to latest rails. It's pretty crappy work actually.

I too have spent a ton of time doing this. It's a product of Rails architecture and the prevailing design philosophies in the Rails community.

I am fine with it, I do this as a service for other companies who's developers are too busy with feature work.

Being "too busy with feature work" is exactly the mindset that forces us to spend months and months of developer time every couple of years to upgrade Rails and an ever growing list of other gem dependencies.

It is hard for managers to organize developers and to uphold for good practices. That is why I created a service so people would not feel guilty, just hire us and we take care of things for you. :)

Nice for you. Not so nice for the companies wasting their money on paying you. Yeah, managing software teams is hard. But paying contractors every year to upgrade Rails is malpractice. Can you honestly say that you are capable of going into these legacy systems with thousands of lines of code and upgrading all of their gems, including Rails, without causing regressions? Maybe for a small project your approach is okay but it doesn't scale.

If you know rails well and keep current, upgrading is perfectly straightforward, if uninspiring, work.

It's a janitorial service of sorts, and it's totally appropriate for some corps to contract it out. It allows the developers with the best knowledge of the business to focus on that, where value is created. Regressions are mitigated by a strong culture of testing.

I've spent many months upgrading legacy Rails services. One particular project was upgrading several microservices from Rails 3.1 to Rails 4. The projects made use of Rspec, Test::Unit, and Capybara. There were unit tests, integration tests, and UI tests. There were over 5000 specs in total. The project also used many gems in production to accomplish its tasks. When you are forced to uprgrade: the testing frameworks themselves, the ORM, the web framework, static asset building tools, libraries for managing file uploads, map rendering, etc, all in one go, it's nearly impossible to get it 100% right. We upgraded minor versions one by one. We read the Rails release notes and any gems that had them. Every time we bumped a Rails version we broke thousands of tests. Even after months of meticulous work we had only managed to upgrade 3 of the 4 services up to Rails 4.0, with another stuck on 3.2. Is it possible to work this way? Sure. But it's insane and costly when you let it get this bad. I've yet to work on a large Rails project on a team that outsources their upgrades where upgrading was "perfectly straight forward". It sounds like you work for a company that actually cleans house. A company like that has no need to hire OP.

Just wondering how much of this upgrade pain is Rails-specific? How about Spring, Play and Django? What's so different about Rails?

I ran into such serious issues with Django and Django-CMS that we were unable to upgrade a Django 1.7 app to 1.8 without a ton of work and the possibility of data corruption. "Kitchen sink" frameworks like the ones mentioned above often lead to issues like this. I don't use Play framework any more when writing Scala. That being said, Rails truly was the pioneer for this type of web application programming. Many of the other frameworks are just copy cats.

Yes, I had a feeling Rails was getting singled-out unfairly. There's nothing about Rails which is more monolithic than, say, Spring, Django, Play or Laravel.

I actually went through that several times. It is not easy and requires specific expertise, like you said. Sometimes it makes sense to refactor parts. Microservices are not the only way to refactor. I like Trailblazer for example who for bigger codebases adds another layer of discipline.

Put another way: If you're always outsourcing work like upgrading Rails versions so that your devs can focus on "features" they will never learn which design decisions they are making are extremely costly in the long run. Like, hmm, maybe I shouldn't include 4 gems just to build and test my JavaScript. Or, hmm, maybe I shouldn't write this code in a way that leaks ORM details. Testing culture is great. But it is not an antidote for kicking-the-can-down-the-road culture.

That I can agree with. I've been using rails since version 0.9, and my predisposition is to use as few gems as possible.

Managed properly, rails and ecosystem churn is manageable. Managed poorly, it becomes reasonable to bring in an expert to repair your neglect.

But it's definitely true that rails culture doesn't make itself easy to manage.

I think you are very narrow minded here. It takes considerable cost to hire developers if you have code debt and the kind you get are quite different. It is really not something that is wasteful, quite the contrary.

Also, I have yet to meet a team that has all the developers it wants, with all the expertise they desire. Maybe FB and Google, most other places need to focus their talent on what will bring best value.

It actually makes more sense on bigger codebases then on smaller.

They would get much more value out of their team if they took the time to help them to be proper software developers. Companies these days do not focus nearly enough on mentorship and continuing education. Instead they hire a team, treat them like code monkeys, then pay big bucks to expensive contractors to do big upgrades and rewrites.

I agree with you completely, they spend a ton of time to hire you, only to ignore you the second you say yes :), or give you completely innapropriate working conditions. So all your expertise you were so happy to get and bring to the table, can't use it.

Are you hiring?

:) Not at the moment, but feel free to connect /w.

Have to say it again: I love Rails. Thanks guys.

Active Storage looks amazing.

Just 4 comments in 2hrs? Hallmark of a mature technology.

Active Storage looks nice, and perfect timing for me, I'm looking to add generic file blobs to my toy project in Rails pretty soon.

Rails introduced me to software development. From the beginning I felt really comfortable in Rails, and that's part of what gave me the confidence to switch careers.

I don't write Ruby for a living anymore, but I am super appreciative of all the things the Rails team has done.

This is a pretty good update from the looks of it. Maybe I shouldn't be surprised by the low votes and comments? I did expect more though.

It seems that Rails for some reason completely falled out of grace. Which is a shame. When you do Rails, you are supposed to uphold to a ton of good practices, that are for most part missing from Javascript world.

Elixir is not big enough to have all good Rails people.

Yeah. Bit sad how much Ruby and Rails have fallen from graces. I'm fine with Python so not all bad with wanting something nicer than JS, I just have a kinship with Ruby.

Rails is amazing! :)

What's coming in 6.0? If this is 5.2 It seems something much bigger is in the work.

Yay Rails! Kudos to the whole core team for the continued work on the platform.

Great to see Rails chugging along and focusing

Kudos guys!

Reply on news.ycombinator.com