I like the why behind Matestack:
Implementing two separate systems (backend-api, frontend-app) is a pain: Two different code bases, two repositories to maintain, two different deployment schedules, two test environments, two everything… Being a small dev team, we decided not to adopt this modern web development complexity and decided to create… Matestack!
If you have 30 minutes and want an easy button to learn all about it, Jonas Jabari gave a talk on it at Ruby Unconf 2019.
I’m not a big fan of Intercom-style chat widgets, but with how many of them I see out there I might literally be the only person in that camp. That being said, if you’re on the market for (what looks like) a bare bones implementation of that functionality that you can keep 100% 1st party, maybe give Chatwoot a try.
If I had to pick one engineering team to write up how they make (and keep) Rails running fast, it’d be Shopify’s. What a treat!
Part of Shopify’s success with Ruby on Rails is an emphasis on writing fast code. But, how do you really write fast code? Largely, that’s context sensitive to the problem you’re trying to solve. Let’s talk about a few ways to start writing faster code in Active Record, Rails, and Ruby.
Eileen Uchitelle shared the backstory of how they have GitHub running on Rails 6.0 just 1.5 weeks after its final release. 👏
As soon as we finished the Rails 5.2 upgrade last year, we started upgrading our application to Rails 6.0. Instead of waiting for the final release, we’d upgrade every week by pulling in the latest changes from Rails master and run all of our tests against that new version. This allowed us to find regressions quickly and early—often finding regressions in Rails master just hours after they were introduced. Upgrading weekly made it easy to find where these regressions were introduced since we were bisecting Rails with only a week’s worth of commits instead of more than a year of commits.
Shopify’s engineering team has been doing some serious engineering on their codebase:
Shopify is one of the largest Ruby on Rails codebases in existence. It has been worked on for over a decade by more than a thousand developers. It encapsulates a lot of diverse functionality from billing merchants, managing 3rd party developer apps, updating products, handling shipping and so on. It was initially built as a monolith, meaning that all of these distinct functionalities were built into the same codebase with no boundaries between them. For many years this architecture worked for us, but eventually, we reached a point where the downsides of the monolith were outweighing the benefits. We had a choice to make about how to proceed.
Click through for a breakdown of the benefits/drawbacks of monoliths and what they build to address the drawbacks without losing the benefits.
Discover the lesser-known parts of the next major framework upgrade, appealing to mature applications that have been around for a while. Instead of focusing on “greatest hits,” we will walk you through B-sides and rarities that make this new release enjoyable in subtler ways.
What B-sides and rarities are Vladimir speaking of?
While the most-advertised Rails 6 features like Action Mailbox and Action Text steal all the spotlight, it is unlikely that a real-life Rails application that has been around for a while will benefit from the ease of building WYSIWYG text editors right after the upgrade.
At the same time, less flashy features like multiple databases support or parallel testing can bring immediate gains to your productivity—and Rails 6 has enough of those to offer if you know where to look.
A web UI for managing your app’s cache, inspired by Sidekiq’s web UI.
I know Rails isn’t universally beloved by developers, and I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again.
There’s a false dichotomy here. You don’t have to give up React to write server-templated web-apps. That being said, I understand what he’s trying to say.
However, I do think that in the transition to the modern web stack (something like React / nodejs / graphql / etc), we’ve unsolved some of what tools like Rails made easy 10 years ago - and I don’t think it needs to be that way.
This post is less a love song to Rails as it is a pitch for the value of unified frameworks in web development.
DHH announced on the Ruby on Rails blog the details behind Action Mailbox, the second brand new framework coming to Rails 6 (the first was Action Text). Action Mailbox routes incoming emails to controller-like mailboxes for processing in Rails.
The framework was, like Action Text and Active Storage, extracted from Basecamp 3. We’ve been using a related approach to route everything from forwarded emails to email replies to messages and discussions. After extracting the ideas into Action Mailbox, we reintegrated the framework into Basecamp, and we’ve been running the code we’re sharing today for over a month in production.
Jerod is joined by Andrew Nesbitt and Ben Nickolls to talk Octobox, their open source web app that helps you manage your GitHub notifications. They discuss how Octobox came to be, why open source maintainers love it, the experiments they’re doing with pricing and business models, and how Octobox can continue to thrive despite GitHub’s renewed interest in improving notifications.
DHH announces Action Text, a big new feature coming to Rails 6:
It’s an integration between the Trix editor, Active Storage-backed file and image processing, and a text-processing flow that ties it all together. With Action Text, you really shouldn’t ever have to impoverish your users with a vanilla textarea ever again!
I’m a bit torn on this. On one hand, Trix is a good tool and many (most?) web apps need rich text editing at some point in their lifespan. On the other hand, it’s difficult to build general purpose features like this that span both the front and back ends of the stack.
Rails 6 is a ways away (with betas starting in early 2019), so we’ll have to wait and see. Regardless of whether this particular feature pans out, it’s great to see the Rails team continue to innovate and try new things.
In total the project took a year and a half to upgrade from Rails 3.2 to Rails 5.2. Along the way we took time to clean up technical debt and improve the overall codebase while doing the upgrade. Below we’ll talk about how we upgraded Rails, lessons we learned and whether we’d do it again.
Congrats to Eileen and the team on this massive effort! Click through to read how they did it and the lessons the learned along the way.
Looks-wise, this is an exact design clone too. Hope that doesn’t get anyone who uses this “as is” in any trouble with the real Medium.
This project is a fork of a Medium clone which began as Ken Hibino’s personal side project to learn Rails and React. I upgraded and refactored parts of the Rails app and integrated Dante2 wysiwyg editor.
If you’re looking for commentary around the project or Rails, check Hacker News.
Too long to read? No, but here’s the tldr from Tomas Valent…
I would choose “Ruby on Rails” as my primary technology again even in 2018.
Rails is not obsolete, Ruby is not dying. They are more awesome then ever before.
We talk with Ben Halpern the founder and webmaster of dev.to — a community for developers to talk about software. Last Wednesday they open sourced the codebase of the dev.to platform, so we wanted to talk through all the details with Ben. We talked through the backstory, how Ben realized this could become a business, how the team was formed, their motivations for open sourcing it and why they didn’t open source it from the start, the technical stack, and their vision for the future of the site.
I use Pry (a runtime developer console) all the time and I still learned a few tricks from this post. Here’s a doozy for working in Rails apps:
show-routes, which does what the name implies, and also takes a
-Gflag for grepping. No more starting up a new shell to execute
rake routes | grep loginand wait for it to boot up Rails just to give us the routes on the side!
This is the one and only tool that i miss when working with Elixir and Phoenix. Yes, I know there’s
IEX.pry built in, but it doesn’t offer as smooth a workflow as Ruby’s pry. Maybe someday…
Nice post by our friends at Rollbar:
We looked at our database of thousands of projects and found the top 10 errors in Ruby on Rails projects. We’re going to show you what causes them and how to prevent them from happening. If you avoid these “gotchas,” it’ll make you a better developer.
I know many of these like the back of my hand. 🤣…😭
The main purpose of the tool is to allow developers to quickly mock API endpoints that for many possible reasons they can’t reach at a specific time.
Create endpoints which you can then assign static or dynamic responses, cause delays, timeouts. et cetera. Set it up natively or via Docker. 🐳
Derek Prior on Ruby 2.5’s
I write Ruby daily, but I had no idea
yield_self was a thing. In this post, Derek takes us through a real-world use case for it. I agree that the final code is more readable than where it started. Good stuff 👌
Follow along with DHH as he explores the Basecamp 3 codebase to uncover areas of the code that can be improved one way or another. This is as close as it gets to pair programming with David as he examines the code and ways he might improve it.
Great list, and I agree with many of Vladimir’s points. However, I have to admit that Ecto’s take on preloading still bugs me after years of use.
I find myself doing the preload dance all over the place even when I’m well aware of the performance issues around N+1 queries. I thought I’d get used to it over time, but it still irks me every time I see an
A project after my own heart:
🗝 Add authentication to your Rails app without all the icky-ness of passwords
We’ve been password-free on Changelog.com for awhile now. It’s not without drawbacks, but you can definitely sleep better knowing that even a database breach can’t compromise your users’ passwords. Because there aren’t any.
Mike Perham is back for his 4th appearance to talk about his new project Faktory, a new background job system that’s aiming to bring the best practices developed over the last five years in Sidekiq to every programming language. We catch up with Mike on the continued success and model of Sidekiq, the future of background jobs, his thoughts on RocksDB in Faktory vs BoltDB, Redis, or SQLite, how he plans to support Sidekiq for the next 10 years, and his thoughts on Faktory being a SaaS option in the future.