A while back, Joe Sondow posted a great thread on Mastodon that is a perfect example of why you should split a complex job up into several individual ones. Basically, Worf was experiencing an error that caused Riker to post more than he should have.
In two previous posts, I explored the custom elements part of Web Components, concluding that the lifecycle callbacks provide value beyond rolling your own. I want to look at the other two parts of Web Components, which are the Shadow DOM and the <template> tag. These provide a templating mechanism that doesn’t work like any other web application templating environment and is incredibly limiting to the point I must be just not understanding.
Feedback from my previous post on Web Components was that
the lifecycle callback methods like connectedCallback are actually what makes custom elements useful. After exploring this
more, I can see why and want to demonstrate.
Jeremy Jung had me on his podcast during RubyConf this past week. It was a great conversation. We talk about choosing technology, Go vs Ruby, moving from Heroku to AWS and more!
People saying that “Web Components are having a moment” should look at the difference between Web Components and just using the browser’s API. They are almost identical, so much so that I’m struggling to understand the point of Web Components at all.
Let’s take Jim Neilsen’s user avatar example and compare his implementation to one that doesn’t use Web Components. This will help us understand why there is so much client-side framework churn.
If you have been waiting to get a whole ton of Ruby books, including “Sustainable Web Development with Ruby on Rails”, there is a Rails Humble Bundle available now!
Performing a resilient operation on bulk data can be challenging, especially if the operation relies on a third party. You can safely do this by fanning out the work to idempotent background jobs that operate on only one piece of data at a time. Those jobs can retry independently as needed, making the entire operation more easy to manage. This post will show an example of how that works and why you might want to use this pattern.
If you want to know how to sustainably manage background jobs in your Rails app, you should be using Sidekiq, and you should by my book, Ruby on Rails Background Jobs with Sidekiq. $9.99, ebook only, a scant 70 pages.
Since 2011, I’ve been responsible for apps that had a lot of background jobs, and I’ve been on-call for those apps. Believe me when I tell you, you don’t want to learn how to write idempotent jobs, create self-healing retriable processes, or manage queues that way. It takes too long and its too stressful. Just read the book I wish I had back then.
To effectively use any abstraction, you must—eventually—have a solid understanding of what it’s abstracting. I’m calling this the Katz Conjecture because Yehuda Katz made this statement in a conference talk (that I cannot find and hope actually existed). The conjecture has two implications: any abstraction that doesn’t sufficiently simplify what it’s abstracting makes everything worse, and any abstraction you don’t understand is a risk to your project.
This week, I’m on Robby Russel’s “Maintainable” podcast, talking about Sustainable Rails, testing, Angular JS, expertise and agile aphorisms. This is the intro and a reference to the link, as well as a quote: