In data-heavy systems, databases are at the core of system design goals and tradeoffs. Even though it is impossible to ignore how databases work, the problems that application developers foresee and experience will often be just the tip of the iceberg.
I usually download the staging or production database in order to test the migration locally. This enables getting migration errors before the deployment. However, I regularly screw up the database with some silly mistake in migration, which requires recreating the database.
Ruby on Rails has some built-in solutions to guarantee GDPR compliance. It is not ideal though. I made some effort to make the framework more complaint.
Anxiety related to deploys is the single largest source of technical debt in many, many orgs. Technical debt, lest we forget, is not the same as “bad code”. Tech debt hurts your people.
Remember all the cases when you were thinking, “Maybe I need to reload this object?” It indicates that your objects are interconnected, and you cannot reason about your code with confidence. Instead, you just guess.
As a Ruby developer you probably use tools like Sidekiq that rely on concurrency. But would you know how to *build* your own sidekiq, or add concurrency to an existing app? This article will open Ruby's concurrency toolbox and show you how each tool works.