Rails 6.0
weblog.rubyonrails.org
weblog.rubyonrails.org
https://news.learnenough.com/ruby-on-rails-6
You can join the Learn Enough/Rails Tutorial email list to receive a notification when it’s ready:
Along with many, many other things, this tutorial taught me the basics of TDD, which for me was the big unlock, keeping me out of the debugger for every little thing.
Many thanks, Michael.
Good job rails team!
===
Edit: P.S. - Thanks rails community too! Was super simple to build thanks to the vibrant community...
- Corporate SSO via devise + omniauth
- CSV uploads (activerecord-import gem)
- pagination (will_paginate gem)
- external API integration
- DB seeding
- audit logging on edited/created data (audited gem)
- wizards (wicked gem)
- etc, etc.
Here some links:
- https://github.com/octokit/octokit.rb
- https://github.com/stripe/stripe-ruby
Depending on how you set up your app, you should look into organizing your external services like this: https://www.engineyard.com/blog/keeping-your-rails-controlle...
0: https://github.com/omniauth/omniauth/wiki/List-of-Strategies
While Vue works, I miss the productivity of having a single server app to maintain, instead of two. I'm considering moving back to Rails only, with the aid of some library like Unpoly for the nice ajax unobtrusive javascript helpers.
Congrats on the release, and thanks for helping to keep alive the model of server-rendered apps, while everyone else appears to be moving to SPAs.
Sure, clients load "faster" if you mean they don't actually load everything. Apples to oranges.
If a page needs to make 5 DB queries to present a bunch of data, those 5 DB queries will be faster on the server than from the browser. So will parsing the response and transforming it into HTML.
Or do infinite scrolling and only load 10 rows from the DB, where you would have to render more rows to be usable if you didn't have infinite scrolling.
Been doing Rails for the past year coming from a C# and ColdFusion background. God I love what you can accomplish in a short amount of time with Rails.
ColdFusion became a nightmare since there is NOTHING for it any more.
C#, though awesome, is just too verbose.
Rails and Ruby are a God send.
Oh I totally missed his reply in this thread https://news.ycombinator.com/item?id=20718729 (currently at the top)
GoRails (https://www.youtube.com/channel/UCIQmhQxCvLHRr3Beku77tww)
Drifting Ruby (https://www.youtube.com/channel/UCxJaNyXCQw0mghY0hA1wA9w)
Railscasts Reloaded (https://www.youtube.com/user/RailscastsReloaded)
If you already understand MVC (for example if you’ve worked with .NET’s MVC offering) reading rails guides will serve you very well.
Yes, learn anything else other than Rails or Ruby. It was never good, just well promoted. I haven't checked on it recently, and I'm sure there are improvements, but there are so many better options today (e.g., .NET, Python, Node), it's hard to see a good reason to take up Ruby or Rails.
That said we use a Rails admin backend to mange all aspects of the stock and categories. We sync up to Woocommerce with the API and ActiveJob.
This really isn't anything ground breaking, it's using the right tools for the right areas to bring things together.
The clients LOVE it.
Congrats for shipping, and to many good years to come!
[1] https://edgeguides.rubyonrails.org/active_record_multiple_da...
You can even build an SPA using the MVC pattern. I think nullwasamistake's comment was misusing buzzwords, and they were rather comparing server-rendered apps vs client-side SPAs.
Even if you can stretch the definition to fit, is it still useful to organize your code along those terms instead of what's natural in the new ecosystem? (data source resolvers, type schemas, queries/mutations)
We use gRPC web, so backend is a bunch of RPC endpoints. Front end is regular SPA.
This has worked great for us because it reduces backend to "shipping objects" instead of all the bs you normally have to deal with in HTTP.
With gRPC there's no use for rails, or any HTTP server framework. As far as I can tell, this is the future of web endpoints, so rails will die out.
That'll suck. Hope your company doesn't use Github.
Hell, Facebook basically invented reactive Javascript and they still have loading bars everywhere, broken content sections, and requires a full reload every now and again to get content to show. Reddit is even worse. Those are two major implementations of SPAs and they're both horribly broken.
It's nothing to do with if Javascript is enabled in your browser. If Facebook and Reddit, two of the most popular sites on the Internet, can't get SPA right, I'm blaming the technology.
Congrats to the Rails team on this release and for continuing to plug away after all these years.
A new release contradicts the latter, not the former.
Don't get me wrong, Python is a great language. And Django is a great framework. There's lots of good languages and Frameworks.
But Rails has the right magic of incredibly stable tooling, a huge community, and tons of documentation & guides written for beginners. It definitely has a unique (and valuable) place in the world / businesses.
Will it ever hit critical mass?
> In fact, GitHub, Shopify, and Basecamp, as well as plenty of other companies and applications, have been running the pre-release version of Rails 6 for months and months in production.
Test suites are nice and all but nothing beats having tons of real world production workloads thrown at something to really test it and iron out a good developer API. There's just a massive amount of confidence you have that you won't be the one having to pioneer some weird edge case bug.
Can someone list at least 1 other popular web framework that has multiple individual sites pushing billions of page views through it before it hits a stable release?
I think Cookpad wants to test Rails Pre-Release in the future as well, that is a site possibly bigger than Github. I wonder if Apple Music is still on Rails.
There's just a huge amount of goodness in being able to piggy back off a bunch of sites' engineering teams to ensure by the time you use a release, it's been through so much testing.
I really never got that feeling from any other framework. I wish Phoenix had more success stories like that.
The same app that I learned with is now a full fledged startup, with thousands of future doctors using it, and one of our DB tables has nearly 1m objects.
Kudos to the rails team, really. I know a lot of titles and headlines talk about "is Rails dead?" and this should put it to rest. It might not be the most cutting edge technology, but it's proven.
>config.active_record.database_selector = 2.seconds
Rails provides a way to make sure that at-least for first two seconds after the write operation, read requests are handled by the write instance. This assumes that your read replica will get updated within 2 seconds with the live data.
How cool is that
Why not keep dependent operations within the same transaction? If that would be done by rails from the start then I could just easily split read/write through pgpool.
https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b81...
My only complaint with v6 is that we didn't take the opportunity to make a clean break from the Asset Pipeline. I know that there are gems that would break etc. Luckily, the process moving CSS to Webpacker is made easy via this document.
Tips!
If you're using Sass, make sure you switch from sass-rails to sassc-rails.
Stimulus is an awesome solution for your JS needs. Don't even think about React again until you've at least considered the power of a well-cached backend fronted by a Stimulus + Turbolinks solution.
Try to get an early handle on the multiple ways that import can be used in your JS files. There are three different forms and they all have subtleties that can bite you:
import 'library'
import { x, y, z } from 'library'
import * as Library from 'library'
If your JS has require() directives, convert them to import directives. import is the future.
Finally, don't ever let anyone shame you out of using jQuery. jQuery rocks and is an incredibly powerful tool that still brings superpowers to the table. Anyone who suggests it's simply "bad" is not bringing good arguments to the table. (But when things get hairy, take a good look at Stimulus!)
A lot of web apps in Debian are depending on Ruby on Rails 5. Right now, I'm making their transition for 6.0.0 with its RC1 [1]. So glad to meet its stable release now.
Rails continues to win in the productivity category.
A system which does this has been a part of Rails for a _very_ long time, and Zietwerk is an upgrade to it by a longtime Rails contributor that fixes some of the previous downsides and gotchas.
Ruby classes usually need to explicitly require the other classes and modules which they use. Rails implemented a different way to achieve requiring dependencies using a method called "const_missing" which requires the missing dependent when it is not found in the known constant list.
The problem with this is that if your classes and modules do not adhere to a strict arrangement within your source code directories then Rails can sometimes not find the file you are looking for, or worse find the wrong file.
Since "require" has an effect on the loaded constant namespace, the order of requiring dependencies can make a difference in the presence of bugs related to which code has been required.
There's more information here: https://github.com/fxn/zeitwerk#motivation
As a frontend designer, I'd been hoping for some mention of faster SASS/SCSS compiling, but it looks like it's the same asset pipeline for that. Can anyone recommend a current resource for decreasing compile times?
I love designing in a Rails app, but my non-Rails projects all seem to inject CSS changes into the browser almost instantaneously, whereas with Rails there's often a wait of up to 10 seconds. The lag is pretty disruptive to the design workflow. I'm pretty new to Rails so any tips on what I might be doing wrong would be appreciated :)
I also run an instance of bin/webpack-dev-server which handles all of my dev-time Sass pushing needs.
One thing I'm a little sad about is the decision to continue using sprockets (aka Asset Pipeline) for CSS and images. My understanding is that a lot of gems would break if they changed but I can't help feel an opportunity was lost to bite the bullet and do the big switch all at once. I guarantee you that it's coming.
Luckily, I can say that switching to using Webpack for CSS is very doable. The best instructions are here: https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b81...
Active Storage still needs work [2], ( I really wish paperclip had stayed a little longer ), but the update should really be good enough for general purpose usage.
And hopefully someday Action Cable would really work without switching over to Any Cable, the latency are way too high.
And I heard Stimulus 2.0 [3] is coming too.
And with Github and Shopify taking more hands on approach in development, Rail's future is brighter than ever.
[1] https://github.com/rails/rails/pull/32313
Are they both talking about the same thing, or I am missing something?
https://edgeguides.rubyonrails.org/active_record_multiple_da...
In short, to do this feature family properly and in an opinionated, predictable way means that you have to cover a number of non-trivial cases. Multiple primaries and their replicas is just the beginning:
- automatic connection switching on a per-model basis
- Automatic swapping between the primary and replica depending on the HTTP verb and recent writes
- Rails tasks for creating, dropping, migrating, and interacting with the multiple databases
Sharding, cross-cluster joins and load balancing replicas are coming soon.
I think what's important here is that every site over a certain scale previously needed to implement their own take on this, and there were a lot of thorny edge cases, race conditions and heisenbugs to do so. It's kind of like the old chestnut that if you find yourself writing original crypto code, you're probably doing it very wrong.
The fact that any project can uncomment a few lines and get all of this for free is properly awesome.
Thank to all Rails community to build this exciting project
Zawinski's Law “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
--- Action Mailbox routes incoming emails to controller-like mailboxes for processing in Rails. It ships with ingresses for Amazon SES, Mailgun, Mandrill, Postmark, and SendGrid. You can also handle inbound mails directly via the built-in Exim, Postfix, and Qmail ingresses. The foundational work on Action Mailbox was done by George Claghorn and yours truly.
I can build my own Gmail in an hour!
Ruby - the language - is the one released usually on Christmas.
Has anyone else thought the same?
Any tools to work around this?
I hope framework maintainers of other language community should also get inspired by these features.
I was happy to se new Rails notification from newreleases.io today.