Coder Legion - Recent posts tagged code-refactoring

From Writing Code to Orchestrating AI: The Delegate-Review-Own Model Every Engineering Lead Needs

Wed, 08 Apr 2026 07:19:10 +0000

There is a paradox sitting at the center of engineering in 2026.

80% of developers are now using AI coding agents in their daily workflows. Productivity gains of 35 to 45% have been documented across organizations that have leaned in. AI-powered testing frameworks are catching 68% of bugs before they even reach production. By every metric, adoption is a runaway success.

And yet trust in AI accuracy has dropped from 40% to 29% year-over-year.

That is not a contradiction. That is the market maturing.

The developers who experienced initial euphoria, shipped AI-generated code without enough scrutiny, and then watched subtle bugs slip through into production: they are the ones driving that trust number down. I have been there. And working through that experience forced me to completely rethink how I structure my relationship with AI coding tools.

What I landed on is something teams are converging on across the industry. The Delegate-Review-Own model.

What "Agentic" Actually Means Now

Twelve months ago, "AI-assisted development" mostly meant smart autocomplete. A tool that finished your function signature, suggested a variable name, maybe drafted a docstring.

That era is over.

In 2026, the leading AI coding tools operate as genuine agents. They do not respond to a single prompt and stop. They run through execution loops: breaking down a task, scaffolding a solution, writing tests, running those tests, reading the failure output, revising the implementation, and iterating until the criteria are met. Tools like Claude Code, Cursor with background agents, and JetBrains Central (launched in March 2026 as an "open system for agentic software development") can now handle hours of work autonomously before ever surfacing a result for your review.

Gartner projects that 40% of enterprise applications will embed AI agents by the end of 2026. That number is not about chatbots in a sidebar. That is agents taking actions inside production systems, writing code, running queries, submitting pull requests.

The question for every engineering lead is no longer "should we use AI tools?" It is "how do we operate in a world where agents are doing significant chunks of the work?"

The Delegate-Review-Own Model

The teams getting this right in 2026 have stopped thinking about AI tools as productivity boosters and started thinking about them as a new tier of the engineering team. Here is the model I have settled on:

┌─────────────────────────────────────────────────────────────┐
│                   DELEGATE - REVIEW - OWN                   │
├───────────────┬─────────────────────────┬───────────────────┤
│   DELEGATE    │        REVIEW           │       OWN         │
│               │                         │                   │
│ Agent handles │  Engineer validates     │ Human accountable │
│ first-pass    │  correctness, risk,     │ for architecture, │
│ execution:    │  alignment, edge cases  │ trade-offs,       │
│               │                         │ outcomes          │
│ - Scaffolding │  Ask: "Would I have     │                   │
│ - Tests       │  written it this way?"  │ Non-delegatable:  │
│ - Boilerplate │  "What did the agent    │ - System design   │
│ - Docs        │  not consider?"         │ - Risk calls      │
│ - First impl  │  "Is there hidden debt  │ - Team judgment   │
│               │  here?"                 │ - Stakeholder     │
│               │                         │  communication    │
└───────────────┴─────────────────────────┴───────────────────┘

Delegate means being intentional about what you hand off. Good candidates: first-draft implementations of well-scoped tickets, test case generation, documentation, boilerplate for new services, refactoring passes for isolated modules. Bad candidates: anything touching security-critical paths without a tight spec, cross-system integration design, or anything where requirements are genuinely ambiguous.

Review is where the model breaks down for most teams. Engineers trained to "code fast and trust the AI" skip review or treat it like a rubber stamp. That is how the 29% trust number gets generated. Effective review in an agentic workflow is different from reviewing a colleague's PR. You are not just checking "does this work?" You are asking: "What assumptions did the agent make that I never specified?" and "What failure modes exist that the agent was not asked to consider?" This requires reading agent output with more skepticism, not less, precisely because the code often looks clean and confident.

Own means the engineer, not the agent, is accountable for what ships. This sounds obvious, but the cultural pressure to externalize blame onto "the AI wrote it" is real on some teams. The role shift from creator to orchestrator does not change who carries responsibility. If anything, that responsibility sharpens: you are now accountable for the quality of your instructions, the rigor of your review, and the integrity of your final approval.

What This Means for How You Lead Your Team

I have made three concrete changes to how I run my team since we adopted this model:

1. Redefine "done" in your definition of ready.
Before any agent-assisted ticket ships, the engineer on point must be able to explain why specific design choices were made, not just that the tests pass. We now explicitly ask this in code review. It surfaces quickly who is reviewing versus rubber-stamping.

2. Separate agent velocity from engineer throughput.
Your sprint velocity will look wildly different when agents are doing first-pass work. That is not a reflection of team performance. I stopped using raw output volume as a signal of individual contribution and shifted to measuring decision quality, architecture coherence, and review depth.

3. Build agent guardrails into your workflow, not just your tools.
We define clear "agent lanes" per project. The agent can operate freely inside those lanes. Outside them, it surfaces a proposal and waits for human decision. This is not slowing the agent down. It is structuring the agent's autonomy so review effort is concentrated where risk is highest.

The Skill That Actually Matters Now

Everyone is talking about "prompt engineering" as the new developer skill. I think that framing is already outdated.

The skill that matters in 2026 is orchestration: how you design the interaction protocols between specialized agents, how you specify constraints and guardrails upfront, how you sequence multi-agent workflows, and how you build review checkpoints that catch what the agent missed without creating so much friction that the productivity gains evaporate.

That is an engineering judgment skill. It requires deep domain knowledge, system intuition, and the ability to anticipate second-order failures. Junior engineers struggle with it not because they lack technical ability but because they do not yet have the accumulated context to know what questions to ask.

This, more than anything, is what makes experienced engineering leads more valuable in 2026 than they were in 2023, not less.

The agents are not replacing judgment. They are raising the floor on execution speed, which means the ceiling for leverage now belongs to the people who bring the clearest thinking to what gets built and why.

The engineers who are thriving right now are the ones who treated the first wave of AI tools as an opportunity to sharpen their review instincts, design cleaner specs, and think harder about system architecture. The ones struggling are the ones who tried to compete with the agents at their own game: raw output speed.

SOLID for Rails Developers, real-life tour (with code)

Thu, 16 Oct 2025 09:47:21 +0000

You’ve heard “keep controllers skinny, models thin” but how? The SOLID principles are a compact set of habits that keep Rails apps change-friendly as they grow. Here’s a practical, with bite-size Rails examples you can use today.

What is SOLID?

Before we jump into code, let’s meet the SOLID squad five principles that save your codebase from chaos, confusion, and late-night debugging sessions.

S ingle Responsibility Principle (SRP): Every class should have one job. Not two. Not three. Just one.
O pen/Closed Principle (OCP): Your code should be open for extension, but closed for modification.
L iskov Substitution Principle (LSP): If your code says it’s a duck, it should quack like a duck.
I nterface Segregation Principle (ISP): Don’t force your classes to implement methods they don’t need.
D ependency Inversion Principle (DIP): Depend on abstractions, not concrete things.

Ready to SOLIDify your Rails code? Let’s go!

A running scenario

Imagine a small trading API for “Tomato” prices:

We fetch intraday PriceTicks.
We compute the best daily gain (buy low, sell high once).
We expose endpoints for analytics.

We’ll use this scenario to illustrate each principle.

S Single Responsibility Principle (SRP)

A class should have one reason to change.

Bad (a God Controller)

class AnalyticsController < ApplicationController
  def show
    date = Date.iso8601(params[:date])
    ticks = PriceTick.where(time: date.all_day).order(:time)
    # validation, parsing, domain logic, formatting… all here 
    min = ticks.first.value_cents
    best = 0
    ticks.drop(1).each do |t|
      best = [best, t.value_cents - min].max
      min = [min, t.value_cents].min
    end
    render json: { date: date, best_gain_cents: best * 100 }
  end
end

Good (split responsibilities)

Query loads just what’s needed
Service computes the gain
Controller orchestrates and renders

app/services/best_gain_calculator.rb:

class BestGainCalculator
  def self.call(ticks, quantity: 100)
    enum = ticks.each
    first = enum.next rescue (return 0)
    min   = first.value_cents
    best  = 0
    enum.each do |t|
      diff = t.value_cents - min
      best = diff if diff > best
      min  = t.value_cents if t.value_cents < min
    end
    best * quantity
  end
end

app/queries/price_ticks_on_day.rb:

class PriceTicksOnDay
  def self.call(date)
    PriceTick.where(time: date.all_day).select(:time, :value_cents).order(:time)
  end
end

app/controllers/api/v1/best_gains_controller.rb

class Api::V1::BestGainsController < ApplicationController
  def show
    ticks = PriceTicksOnDay.call(date)
    render json: { best_gain_cents: BestGainCalculator.call(ticks) }
  end
end

Win: Each class changes for exactly one reason.

O Open/Closed Principle (OCP)

Open for extension, closed for modification. Add behaviors without rewriting stable code.

Real life: new gain strategies without editing the controller

app/services/gain_strategies/base.rb:

module GainStrategies
  class Base
    def call(ticks) = raise NotImplementedError
  end
end

app/services/gain_strategies/single_trade.rb

module GainStrategies
  class SingleTrade < Base
    def call(ticks) = BestGainCalculator.call(ticks)
  end
end

app/services/gain_strategies/multi_trade.rb

module GainStrategies
  class MultiTrade < Base
    def call(ticks)
      # example: sum of all positive deltas
      prev = nil
      profit = 0
      ticks.each do |t|
        if prev
          delta = t.value_cents - prev
          profit += delta if delta.positive?
        end
        prev = t.value_cents
      end
      profit * 100 # quantity stub
    end
  end
end

app/controllers/api/v1/best_gains_controller.rb:

def show
  ticks = PriceTicksOnDay.call(date)

  strategy = params[:mode] == "multi" ? GainStrategies::MultiTrade.new : GainStrategies::SingleTrade.new
  render json: { best_gain_cents: strategy.call(ticks) }
end

Win: Adding WeekOverWeek or TrailingStop strategies doesn’t touch controller code.

L Liskov Substitution Principle (LSP)

Subtypes must be usable wherever their base type is expected.

Real life: STI pitfalls vs composition

If you have PriceTick and you try STI for FxPriceTick < PriceTick but change value_cents semantics (e.g., store pips), substituting FxPriceTick where PriceTick is expected will break calculations.

Better: keep interface and units consistent, or compose.

class PriceTick < ApplicationRecord
  # always expose value in cents
  def value_cents
    super # guaranteed integer cents
  end
end

class FxPriceValue
  def initialize(pips:, pip_value_cents:)
    @pips = pips
    @pip_value_cents = pip_value_cents
  end

  def to_cents = @pips * @pip_value_cents
end

Win: Anything expecting value_cents continues to work.

I Interface Segregation Principle (ISP)

Prefer small, focused interfaces over fat ones. Consumers shouldn’t depend on what they don’t use.

Real life: split service interfaces

Bad:

class ReportService
  def generate_csv_for_day(date); end
  def generate_pdf_for_week(date); end
  def email_pdf_to(user); end
  def email_csv_to(user); end
end

Good:

class CsvReport
  def call(date); end
end

class PdfReport
  def call(week); end
end

class ReportMailer
  def send_pdf(user, pdf); end
  def send_csv(user, csv); end
end

Win: Each client depends on only what it needs; easier to test and swap.

In Rails, ISP often means small POROs instead of piling methods into one “service class.”

D Dependency Inversion Principle (DIP)

Depend on abstractions, not concrete classes.

Real life: inject gateways (HTTP, cache, payments)

app/services/price_sync.rb:

class PriceSync
  def initialize(client: External::PricesClient.new, cache: Rails.cache)
    @client = client
    @cache  = cache
  end

  def call(date)
    @cache.fetch("prices:#{date}", expires_in: 10.minutes) do
      @client.fetch_for(date) # abstraction: responds to `fetch_for`
    end
  end
end

In tests:

fake = Class.new { def fetch_for(date) = [{ time: Time.now, value_cents: 10000 }] }.new
result = PriceSync.new(client: fake, cache: ActiveSupport::Cache::MemoryStore.new).call(Date.today)

Win: Swap implementations without changing business logic. Fewer brittle tests.

Pulling it together: a tiny SOLID checklist

SRP: Does this class change for exactly one reason?
OCP: Can I add a variation without editing existing classes?
LSP: Will any subtype respect the expected inputs/outputs/units?
ISP: Is this interface minimal for its consumer?
DIP: Are external details injected (e.g., clients, storage, time)?

A realistic, SOLID endpoint (end-to-end)

app/controllers/api/v1/best_gains_controller.rb

class Api::V1::BestGainsController < ApplicationController
  def show
    ticks = PriceTicksOnDay.call(date)
    strategy = strategy_for(params[:mode])
    best = strategy.call(ticks)
    return render json: { error: "no valid trades" }, status: :unprocessable_entity if best <= 0
    render json: { date: date, best_gain_cents: best }
  end

  private

  def strategy_for(mode)
    mode == "multi" ? GainStrategies::MultiTrade.new : GainStrategies::SingleTrade.new
  end
end

Everything above respects SOLID:

The controller just orchestrates.
Strategies extend behavior (OCP).
Calculators keep contracts consistent (LSP).
Tiny interfaces (ISP).
Dependencies injected (DIP).

Final thought

Rails gives you speed; SOLID gives you sustainable speed. Start small: extract one PORO today (calculator or query), inject one dependency, and keep your interfaces tiny. Your future self and your teammates will thank you.

Bonus: If SOLID were a superhero team...

SRP: Captain Focus only fights one villain at a time.
OCP: The Extender always ready for new powers, never rewrites their origin story.
LSP: Duckman if it walks like a duck and quacks like a duck, it’s Duckman!
ISP: The Minimalist only carries what’s needed for the mission.
DIP: The Abstractionist never depends on sidekicks, only on the idea of sidekicks.

Now go forth and SOLIDify your Rails app and remember, with great principles comes great maintainability!

What’s Missing With AI-Generated Code? Refactoring

Tue, 23 Sep 2025 07:37:30 +0000

A GitClear study found AI-generated code rife with duplication, indicating productivity gains could disappear amid the growing use of coding assistants.

Last month, GitClear published an analysis of 211 million lines of code in its AI Copilot Code Quality report. One of the key findings is that refactoring signals are crashing while code duplication and churn is increasing. In fact, 2024 is the first year when the introduction of repeated code is greater than refactoring activity.

The trend is attributed to the rise in AI coding assistants, and if it continues, we could be heading toward a software crisis.

The Race To Adopt AI

If you work in software development, someone has told you that “AI won’t replace developers; developers using AI will replace developers who don’t.” The message is clear: either use AI or you’re heading for a career change. More positive messages suggest we could remove toil work — the tasks that require high repetition and little thought.

The recent Stack Overflow State of Development survey found that more than 60% of developers are now using AI as part of their work, and more are planning to do so. The primary motivation for AI adoption is increased productivity. As the GitClear report shows, the dramatic downside of wanting to increase productivity is that you may wind up removing your bicycle chain in order to peddle faster.

In the case of software development, we are now rapidly accelerating the rate of change in our codebases. In 2025, the rate of change is predicted to be almost double the pre-AI (2021) number.

This leap in productivity is likely seen as great news by many, particularly those selling AI. However, we should remember the wisdom of our predecessors. Productivity provides a poor view of knowledge work and has been permanently elusive in its measurement.

“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.” — Peter Drucker, 1963.

Throwing Out Good Practice

Before we became productivity-obsessed, there were some foundational practices that the software industry found to be highly valuable. One of these is refactoring. You build more reliable systems when you continuously revisit your code to keep components loosely coupled and to make sure you define concepts just once. You would keep things together if they changed for the same reason and tease them apart if they had different drivers for change.

My bookshelf creaks beneath the weight of software design literature by Kent Beck, Emily Bache, Martin Fowler, Robert C. Martin, Michael Feathers, Rebecca Parsons, Steve McConnell and more. These books contain lasting techniques and practices that are vital to successful software over the long haul. Coding assistants don’t change the fundamentals of software development.

If we accelerate the rate of change, we must match this by keeping pace with the software’s internal structure. In other words, for this to result in a successful long-term software development strategy, we must be able to refactor at the same pace we change the code.

But the report highlights that this is not currently the case.

Refactoring activity is tracked using a category of change called “moved code.” This is where the fundamental logic remains the same but has been shuffled to improve the code’s design. This includes classic refactoring patterns like “extract method” or “rename variable,” which are typically automated by developer tools to guarantee they are safe refactorings (not to mention the practice of test-driven development should mean your tests would catch any accidental behavioral changes).

Since 2021, the proportion of refactoring changes has plummeted from 24% to below 10%. At the same time, the number of copy/pasted lines of code, or duplication, has increased from below 10% to almost 15%.

The prediction for 2025 is that we will reach a point where refactoring is dead, representing little more than 3% of code changes. Our software will continue for some time before the effects of this become clear.

The Lesson Comes Too Late

I’m reminded of an organization where I successfully replaced a chaotic, fragile process with continuous delivery. The key practices installed were test automation, deployment automation, and a solid monitoring and alerting system. The combination of these tools dramatically improved reliability, and elevated the levels of trust between developers and business stakeholders.

After I left, the team decided that managing test data was an undesirable task. They deleted the database script that ran on test environments to reset data to a known state. For many months, the integration tests still worked, and would have continued to work if nobody had manually changed the test data for the test record configured for integration testing.

Once the test data was spoiled, the team faced a tough choice. They could recreate the test data management script, updating it so it worked with all the database changes they had made. Alternatively, they could delete the failing tests. Under pressure to deliver features (and remain “productive”), the team deleted the tests.

Deleting tests has no immediate impact. The feature continued to work for some time, but errors were eventually introduced, and then became a recurring issue.

This is the problem that arises when you choose productivity over long-term sustainability. It takes a long time to realize there’s damage. When the impact of past decisions is apparent, it can often be too late to mitigate it.

Flying vs. Falling

AI code assistants provide the perfect conditions for parabolic software velocity. Just like the zero-gravity plane flights, which use a parabolic curve to provide a feeling of weightlessness, code assistants make us believe we’re flying when we’re actually following a ballistic trajectory in free fall.

For AI to sustainably increase your productivity, you can’t let it dictate your code quality.

JuggleBee’s Great Leap – Data Migration, ActiveStorage, and Production Readiness (Part 2)

Sun, 24 Aug 2025 10:52:32 +0000

Now that we had a deployable app, I set up a staging server using my new favourite provider, Hetzner (not a sponsor, lol), spun it up, and witnessed a “fully functional” skeleton of JuggleBee. Stage 1 of the migration plan was complete.

Now came the real meat and potatoes of the project — actually hydrating the new app with all of its production data. We’re talking over 50,000 images, countless database records, and security credentials… the works. This is the part where a missed step could mean broken listings, missing files, or downtime. No pressure.

In case you missed Part 1, we covered:

Why I started fresh on Rails 8 instead of doing incremental upgrades.

Migrating core models/controllers/services to modern Rails conventions.

Swapping Sprockets for importmaps and modernizing the JavaScript setup.

Replacing Sidekiq + Redis + whenever with ActiveJob + SolidQueue.

Moving deployments to Kamal 2 with Traefik and Let’s Encrypt.

Catch up on it here: JuggleBee’s Great Leap – Rebuilding a Rails 4 App in Rails 8 (Part 1)

Now—back to the post.

The Daunting Database Migration

Legacy JuggleBee had been coasting along happily on Postgres 9.6 — which, back in 2016, was the latest and greatest. Fast forward to today and it’s long past its sell-by date, with official support ending in November 2021. Upgrading wasn’t just about keeping up with the times; Postgres 17.5 brings some serious perks:

Native JSON field type support.
Incremental backups with pg_basebackup --incremental, slashing backup time and storage usage.
Noticeable performance gains from better memory management, indexing, and partitioning.
Improved observability via enhanced EXPLAIN options and richer stats views.
…and more.

It was a no-brainer to upgrade, but the version gap meant one wrong move could corrupt thousands of user, auction, and invoice records. That made reliable backups non-negotiable before touching a single byte. Luckily, I already had a manual backup process baked into my deploy routine. Here’s the script (feel free to steal any of the scripts in my posts):

#!/bin/bash

DB_CONTAINER=($(sudo docker ps | grep postgres | awk '{print $NF}'))
BACKUP_NAME=dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql
BACKUP_FOLDER=db_backups
KEEP=10

# Dump the database into a backup sql file
echo "Creating the database dump..."
docker exec -t $DB_CONTAINER pg_dumpall -c -U postgres > $BACKUP_NAME
echo "Database dump created."

echo "Moving database backup to backup folder..."
mkdir -p $BACKUP_FOLDER
mv $BACKUP_NAME $BACKUP_FOLDER
echo "Backup moved to backup folder."

echo "Deleting old releases..."
(cd $BACKUP_FOLDER && (ls -t | head -n $KEEP; ls) | sort | uniq -u | xargs rm -rf)
echo "Backup stored."

One catch: pg_dumpall (used above) tries to dump everything — including Postgres cluster-wide settings — which can be version-specific and cause headaches on import. For a major version jump, you want pg_dump, which targets a single database and avoids the version mismatch landmines.

For the migration, I only needed to change the docker command we executed - with the added ENV vars, that is:

DB_USER=db_user
DB_PASSWORD=db_password
DATABASE_NAME=database_name

# ...

docker exec -e PGPASSWORD=$DB_PASSWORD -t $DB_CONTAINER \
    pg_dump -U $DB_USER $DATABASE_NAME > $BACKUP_NAME

With the new backup in hand, importing into Postgres 17.5 went off without a hitch — no edits, no drama. Honestly, I was braced for a fight given the version gap, but the data was simple enough (and avoided fancy Postgres features) that it just… worked. A rare and pleasant surprise in a project full of moving parts.

Listing Image Migration

Unlike the data migration before it, migrating all the listing images (just shy of 50,000!) came with its own set of headaches. The legacy setup used CarrierWave with a custom uploader and fixed S3 paths, which worked fine at the time but wasn’t exactly future-proof. Since I was already upgrading to Rails 8, it made sense to tackle this technical debt head-on and move to ActiveStorage — effectively retiring these gems:

carrierwave
fog-aws
mini_magick

… and replacing them with image_processing for post-processing.

In the old days, uploads required creating an “Uploader” class and mounting it on a model. For example:

# app/models/image.rb
class Image < ActiveRecord::Base
  mount_uploader :aws, ImageUploader
end

# app/uploaders/image_uploader.rb
class ImageUploader < CarrierWave::Uploader::Base
  include CarrierWave::MiniMagick
  storage :fog

  process resize_to_fill: [850, 850]

  version :thumb do
    process resize_to_fill: [280, 280]
  end

  def store_dir
    "listings/#{model.listing_id}/#{model.id}"
  end
end

With ActiveStorage, uploaders and hard-coded S3 paths are gone. You simply declare the attachment in your model (after setting up config/storage.yml):

class Image < ApplicationRecord
  has_one_attached :file do |attachable|
    attachable.variant :thumb, resize_to_limit: THUMB_DIMENSIONS, preprocessed: true
  end
end

That takes care of future uploads — but what about migrating the 50,000+ legacy images stored in the old bucket? The image.aws field plus CarrierWave’s store_dir gave me the exact file path to each image. I then wrote a script to:

Download each image from the legacy bucket.
Re-upload it through ActiveStorage so it generates its own hashed storage path.
Skip already-migrated images to allow safe re-runs.

Here’s the script in all its glory (run synchronously to avoid AWS rate limits — which meant a cool 4 hours of migration time):

#!/usr/bin/env ruby

require_relative '../config/environment'
require 'aws-sdk-s3'
require 'stringio'

OLD_S3_BUCKET = Rails.application.credentials.dig(:old_aws, :bucket)
OLD_S3_REGION = Rails.application.credentials.dig(:old_aws, :region)
OLD_S3_ACCESS_KEY_ID = Rails.application.credentials.dig(:old_aws, :s3_key)
OLD_S3_SECRET_ACCESS_KEY = Rails.application.credentials.dig(:old_aws, :s3_secret)

# Optional: skip already migrated images
SKIP_EXISTING = true

s3 = Aws::S3::Client.new(
  region: OLD_S3_REGION,
  access_key_id: OLD_S3_ACCESS_KEY_ID,
  secret_access_key: OLD_S3_SECRET_ACCESS_KEY
)

puts "Starting image migration..."

Image.find_each do |image|
  begin
    if SKIP_EXISTING && image.file.attached?
      puts "Skipping Image #{image.id} (already attached)"
      next
    end

    # Construct old S3 key from uploader logic - your path here
    key = "listings/#{image.listing_id}/#{image.id}/#{File.basename(image[:aws].to_s)}"

    obj = s3.get_object(bucket: OLD_S3_BUCKET, key: key)

    image.file.attach(
      io: StringIO.new(obj.body.read),
      filename: File.basename(key),
      content_type: obj.content_type || 'image/jpeg'
    )

    puts "Migrated Image #{image.id} (Listing #{image.listing_id})"
  rescue Aws::S3::Errors::NoSuchKey => e
    warn "Image #{image.id} missing in old bucket: #{key}"
  rescue => e
    warn "Failed to migrate Image #{image.id}: #{e.class} - #{e.message}"
  end
end

puts "Migration script finished"

Four hours later, we were in business — all images were now managed by ActiveStorage.
Future uploads are handled automatically, thumbnails are generated on demand, and the whole setup is cleaner and easier to maintain.

Credentials & Security

You might have noticed the use of Rails.application.credentials in the previous script. That’s new territory — Rails encrypted credentials didn’t exist back in 4.2.

Back then we had secrets.yml, which stored everything in plain text and was meant to be excluded from Git. In theory, you’d inject it during deploy with whatever tooling you used. In practice… I was lazy. My deploys were manual, the repo was private, and I just checked them straight in. Big no-no. Thankfully, Bitbucket never got hacked — but let’s just say this setup wouldn’t pass any kind of security audit.

Rails 5.2 introduced encrypted credentials — finally, a way to store secrets in plain text locally while Rails encrypts them with a master key. That master key stays out of Git and gets injected during deploy. Much better.

Fast forward to today, and Kamal (my de facto deployment tool) takes it a step further with built-in support for pulling secrets straight from password managers like Bitwarden, 1Password, or LastPass. That means my Rails master key, database credentials, and other environment variables can live safely in Bitwarden, and Kamal just grabs them during deploy. No manual copying, no “where did I put that key?” moments, and no plain-text secrets hanging around in the repo.

Here’s an example using Bitwarden via the CLI. This snippet fetches all secrets and assigns them to variables in .kamal/secrets:

SECRETS=$(kamal secrets fetch --adapter bitwarden-sm all)

KAMAL_REGISTRY_PASSWORD=$(kamal secrets extract KAMAL_REGISTRY_PASSWORD $SECRETS)
RAILS_MASTER_KEY=$(kamal secrets extract RAILS_MASTER_KEY $SECRETS)
POSTGRES_USER=$(kamal secrets extract POSTGRES_USER $SECRETS)
POSTGRES_PASSWORD=$(kamal secrets extract POSTGRES_PASSWORD $SECRETS)

The only catch: you’ll need to have the Bitwarden CLI installed and authenticated on every machine you deploy from. It’s a one-time setup, but totally worth it for the peace of mind of never having to worry about leaked secrets again.

Lessons Learned

Looking back, a few big takeaways stood out:

Scripts are your best friend. Whether it’s a database dump, image migration, or credentials setup, having a repeatable script means you can run it, tweak it, and run it again without reinventing the wheel. It also removes a ton of mental overhead when you’re juggling multiple moving parts.
Test migrations in staging — thoroughly. Moving to PostgreSQL 17.5 could have been a disaster if I’d gone straight into production. Running the full migration end-to-end in a safe environment gave me confidence and caught subtle issues before they ever touched live data.
Expect the cleanup phase. Even after the “big ticket” migrations were done, staging revealed a laundry list of smaller fixes — broken image links, JavaScript load order issues, outdated gem calls, and other gremlins. None of these were major individually, but together they took nearly two weeks to iron out. Build that buffer into your timeline.
Take the opportunity to ditch technical debt. CarrierWave, fog-aws, Sidekiq, Redis… all of these had served me well for years, but replacing them with ActiveStorage and SolidQueue means fewer dependencies to maintain, fewer services to monitor, and a cleaner architecture.
Security deserves equal billing with features. Rails encrypted credentials plus Bitwarden CLI integration finally dragged my secrets management into the modern age. No more plain-text secrets in Git. Enough said.
Modern Rails is worth the leap. From importmaps to Kamal, the tooling around Rails 8 makes deployment, scaling, and maintenance dramatically simpler than what I was doing in 2015.

Closing thoughts

And with that, JuggleBee officially joined the modern Rails era.

This wasn’t just a version bump — it was a full-stack rejuvenation.
The app runs faster, the infrastructure is leaner, and I finally have a deployment pipeline I can trust at 2 a.m. without crossing my fingers.

Was it worth skipping incremental upgrades? Absolutely. Starting fresh on Rails 8 gave me a clean slate to rebuild only what mattered, using tools that will keep JuggleBee humming for years to come.

If you’ve been sitting on a legacy Rails app, staring down the upgrade path and wondering if it’s worth the effort — it is. Just plan your migrations, test them in staging, and embrace the opportunity to shed some old weight while you’re at it.

JuggleBee’s now live on Rails 8 / Ruby 3.4.3 / PostgreSQL 17.5, with ActiveStorage handling thousands of images, Bitwarden keeping our secrets safe, and Kamal making deployments a one-command affair.

Now it’s time to step away from the terminal, grab a cold beer, and actually enjoy the thing I’ve been rebuilding over the last month — until the next big upgrade comes along.

JuggleBee’s Great Leap - Rebuilding a Rails 4 App in Rails 8 (Part 1)

Thu, 21 Aug 2025 08:06:05 +0000

JuggleBee was born in 2015. It was Namibia's first online auction platform and is still one of the biggest today. I built it with Ruby on Rails 4.2 on Ruby 2.2. It sat there, rock-solid and stubbornly stable, only needing the occasional dust-off and minor tweak over the years. At various points in time, I thought about upgrading the various versions; however, I was stuck between a rock and a hard place — in order to upgrade Ruby, I had to upgrade Rails, and vice versa. The idea of incremental upgrades felt like a nightmare — two battlefronts to fight on, Ruby on one side and Rails on the other.

Fast forward to 2025. With the arrival of my daughter, I acquired a smattering of free time interspersed with sleepless nights. The perfect time to finally bite the bullet, bring JuggleBee into the 21st century (you know what I mean), and get these upgrades done. After much pondering and planning, only one realistic option remained... incremental upgrades would take months with constant patching between every version bump; I would have to take the leap from Rails 4.2 straight to Rails 8, with Ruby hopping from 2.2 to 3.4.3. It was quite the journey, and what follows is a breakdown of the challenges and learnings I made along the way.

Starting Fresh

Not to blow my own horn or anything, but I was in a pretty good place with this migration plan. The codebase of JuggleBee was intentionally built with self-contained business logic components, defining a clear separation of concerns. The models and controllers were not overly bloated, with liberal usage of "service objects" performing the more complicated logic, and an added separation of logic between my controllers and views using the "view decorator" pattern. This architecture made the copy-pasta approach almost… dare I say… fun. But let’s not kid ourselves — a jump from Rails 4.2 to 8 is no walk in the park.

As part of the rails new process (after installing the latest Ruby and necessary Rails gems), and before the true code migration could begin, I just needed an empty, runnable project with the necessary gems installed. I appended my old Gemfile with the auto-generated one, removing all locked versions to ensure the latest compatible versions were installed. I also identified irrelevant and dead gems, removing those and replacing them with alternatives where necessary (more detail on this later).

Reading into each of the default gems specified by the rails new generator gave me a good understanding of what the current Rails stack looks like. I didn’t need all of it, so some were commented out, but I did take some of the new suggestions into account. Puma, for example, replaced Unicorn, which I was previously using. I could also get rid of God, in the non-divine sense, as I no longer needed to monitor my server state manually. All in all, this whole process didn’t take more than an hour or so.

Models, Controllers, Services & Views (in that order)

These being purely Ruby code made it the easiest place to start. Even though we jumped up from Ruby 2.2 to 3.4.3, not all that much in the core language changed. Twas Rails that was the most behind. For example, JuggleBee was developed before the abstract ApplicationRecord class made its way into the Rails architecture!

Models

The models were the easiest to migrate over, as they already had a smattering of unit tests behind them. First, though, we had to get the database up and running. Spoiler alert: I was also updating our Postgres version from 9.6 to 17.5 as part of this big update. The old migration files were fossils — brittle, outdated, and utterly unfit for a modern Rails 8 app. The simplest solution was to drop a pg_dump of the current database (just on my local copy of the now legacy JuggleBee) and import it, generating the schema.rb. I could now copy across my models and test them out in the rails console.

Some of the updates required to get things up and running were:

belongs_to is now a required atribute. I have a home-grown version of polymorphism which allows a Listing to be either a Product or Auction and the belongs_to on these associations are optional, so I had to update these associations accordingly (*side note: a refactor waiting to happen*). So,
```
belongs_to :auction
belongs_to :product
```
becomes
```
belongs_to :auction, optional: true
belongs_to :product, optional: true
```
I had a couple of instances of update_attributes (very selective. Given they bypass validations, they were used with extreme caution) which is now deprecated and had to be changed to update.
Deprecated validation methods such as validates_presence_of :name needed updating to validates :name, presence: true sort of changes.

As for the views, the gems I used (haml-rails, redcarpet, simple_form, cocoon, etc) are all still actively maintained and required no changes at all — a very pleasant surprise.

Controllers

Next up were the controllers. Thanks to my use of service objects for the bulk of complex logic, migrating controllers was mostly painless. Rails 8 is stricter, and that’s where most of my changes were required. While bringing over controllers, I also began migrating the service objects they called upon, which are POROs and required almost no changes.

The main updates included:

Params passed to background jobs now must be valid JSON. This was especially relevant for controllers triggering email or background tasks.
Controller filters were renamed to actions (before_filter → before_action).
Controller hooks like before_action should come after the method they reference, not at the top of the file (a style guideline enforced in modern Rails apps).
redirect_to :back was replaced with redirect_back fallback_location: root_path (or an appropriate fallback path).
The responders gem is no longer included in Rails, so respond_with calls were rewritten using respond_to blocks.

All in all, the MVC migration was more about cleaning things up and embracing modern Rails conventions rather than fighting major incompatibilities.

JavaScript Modernization

This is where things started to get spicy — the kind of spicy where you wonder if you just bit off more than you can chew. So much has changed in the front-end assets side of things. JuggleBee leverages jQuery (thankfully I dodged the CoffeeScript bullet) with Sprockets as the asset pipeline. Modern Rails favours importmaps as the default asset manager and pipeline, and keeping with the spirit of rejuvenating JuggleBee and bringing it up to speed, I signed up to it too. This allowed me to replace a bunch of gems which added various front-end features, such as chartkick, masonry and bootstrap with the importmaps pin alternative. Some libraries had to remain as CDN imports in my layout file, due to the order at which these JavaScripts got initialized and loaded by the DOM.

My suite of JavaScript classes also needed a bit of love and attention. The Sprockets

//= require

statements were replaced with

import

and my classes now had to export themselves so that they could be loaded as ES modules. All the files had to be relocated from app/assets/javascripts/ to app/javascript/. The way we add our JavaScript base file into our application view layout also had to change slightly, going from

<%= javascript_include_tag "application" %>

<%= javascript_importmap_tags %>

Even though jQuery is considered a bit long in the tooth, given the plethora of really solid UI frameworks like Vue and React, I opted to keep my reliance on it for the time being. It still works, is actively maintained, and trying to replace it now would be a whole new kettle of fish. An adventure for another day.

Background Jobs & Scheduling

This area was one of the biggest wins in the entire migration. JuggleBee had the “classic” background processing setup: Sidekiq + Redis + whenever (for cron). It worked fine for years, but it always felt a little… heavy, like lugging around a toolbox just to tighten a single screw. Sidekiq required its own container, Redis was a hungry beast that always felt like it was asking for more memory, and whenever meant fiddling with cron jobs and ensuring everything stayed in sync across deploys. It worked, but it was yet another moving part in an already aging stack.

Enter SolidQueue — a gem that ships with Rails 8, built to replace Sidekiq-like setups with something that is both simpler and more tightly integrated with ActiveJob. The real beauty? No Redis. SolidQueue uses the same database you already have (Postgres in our case) to manage job queues, which meant I could drop an entire service and reclaim a chunk of server memory.

Here’s what this meant for JuggleBee:

No more Sidekiq configuration, container management, or Redis headaches.
The whenever gem (used for cron scheduling) could be thrown out too, thanks to SolidQueue’s built-in recurring.yml.
Background jobs now feel like a natural part of Rails — no extra glue required.

To put it in perspective, my stack went from:

Rails App + Sidekiq + Redis + whenever + cron

to:

Rails App + SolidQueue

That’s it. Beautiful, minimal, and a lot less to maintain.

Another chef’s kiss moment was how little code I had to change. Most jobs migrated over with minimal tweaks — the biggest adjustment being that job arguments must be JSON-serializable. This meant replacing keyword arguments with hashes like:

EmailJob.perform("MyEmailClass", {"from" => current_user.name, "subject" => "Hello there"})

instead of:

EmailJob.perform("MyEmailClass", from: current_user.name, subject: "Hello there")

It was one of those rare upgrades where less really is more. Dropping Redis and cron alone made this whole migration feel worth it.

Infrastructure & Deployment

For years, deployment was powered by a custom shell script I wrote. It wasn’t flashy, but it was reliable and got the job done. It handled atomic releases, cleaned up old deployments, built Docker images, restarted containers, and even maintained a cache for faster updates. For a single-developer project like JuggleBee, it was the perfect balance of simplicity and control.

Here’s the core of that script:

#!/bin/bash

branch=${1:-master}
cwd=/home/ubuntu
repo_url=your_repo_here
revision=master
keep=5
timestamp=$(date +%s)
cache=$cwd/.git_cache
releases=$cwd/releases
mkdir -p $releases
previous=$releases/$(ls $releases/ -t | head -n 1)
release=$releases/$timestamp

if [ ! -d $cache ] ; then
        git clone $repo_url $cache
fi

echo "downloading latest source code from $branch..."
mkdir -p $release
(cd $cache && git gc --prune=now && git remote prune origin && git fetch origin && git reset --hard origin/$branch && git archive $revision | tar -x -c $release)

echo "release timestamp is: $timestamp ($release)"

echo 'building docker images...'
/bin/bash -c "(cd $release && docker compose -f docker-production.yml build)"

if [ $? -eq 0 ]
then
        if [[ $previous != "" ]] ; then
                echo 'stopping previous containers...'
                /bin/bash -c "(cd $previous && docker compose -f docker-production.yml stop && docker ps -a -q --filter='status=exited' | xargs docker rm)"
        fi

        echo 'restarting application...'
        /bin/bash -c "(cd $release && docker compose -f docker-production.yml up -d)"

        echo 'deleting old releases...'
        (cd $releases && (ls -t | head -n $keep; ls) | sort | uniq -u | xargs rm -rf)

        echo 'creating symlink.'
        rm $cwd/current-release
        ln -s $release $cwd/current-release

        echo 'deploy complete.'
fi

Honestly, this script could have kept soldiering on for years… until Kamal walked in like the cool new kid who makes your old tricks look ancient. It wasn’t broken — far from it — but Kamal is like having a personal DevOps engineer in your terminal. It takes all the things I cared about (Dockerized deploys, atomic releases, rollbacks) and adds extra superpowers I didn’t even realize I needed.

Introducing Kamal 2

Kamal is a server provisioning and deployment tool built specifically (but not limited to) Rails apps. It automates a ton of tasks that my script didn’t — and one of the most significant changes? No more Nginx.

Kamal ships with a built-in Traefik proxy that handles all your routing and SSL certificates out of the box. No more tinkering with nginx.conf files or restarting a separate webserver. One less dependency chewing through RAM and one less thing to break at 2 am.

Here’s what Kamal brings to the table:

kamal setup: installs Docker, Git, and all required dependencies on your server.
kamal deploy: builds your Rails app into a Docker image, pushes it to your registry, and runs it on the server.
Traefik proxy with SSL (via Let’s Encrypt): you get HTTPS without lifting a finger.
Accessory management: want Postgres or Redis? Kamal spins them up as Docker containers.
Scaling: need more capacity? add another container in deploy.yml and Kamal will route traffic automatically.

The impact of this was huge. I went from managing Docker builds, old release directories, and an Nginx webserver, to just running one command. There’s something almost unsettling about how smooth it is — I felt like I was missing steps at first, like forgetting my keys when leaving the house.

Wait, that’s it? Did I actually deploy? Did I forget something? Oh… it’s done already. Huh.

This wasn’t just a convenience win — it was a dependency detox. Between dropping Nginx here and killing Redis with SolidQueue earlier, my infrastructure got a lot lighter, faster, and cheaper to run. Kamal didn’t just evolve my old script — it rendered half of its logic unnecessary.

Half Way There

With the new Rails 8 foundation in place, JuggleBee has already shed a lot of its old skin. We’ve modernized the models and controllers, swapped out a creaky asset pipeline for importmaps, retired Sidekiq, Redis, and cron in favor of SolidQueue, and traded a homegrown deployment script (solid as it was) for the convenience and power of Kamal 2. The app is lighter, faster to deploy, and much easier to maintain — but we’re not done yet.

Getting the Rails 8 app running and deployable was only half the battle. Now comes the rest of the journey:

Migrating data from a legacy PostgreSQL 9.6 database to a fresh PostgreSQL 17.5 instance.
Replacing CarrierWave with ActiveStorage and migrating all user-uploaded files into a new S3 bucket.
Locking down credentials with Rails encrypted secrets and Bitwarden CLI.
Cleaning up leftover code smells, finalizing test coverage, and polishing the overall performance of the new stack.

That’s some of what Part 2 will cover — all the finishing touches, the unexpected hurdles, and the final steps that took JuggleBee from a Rails 4 relic to a lean, modern, and production-ready Rails 8 app.

Stay tuned for Part 2, where the migration story continues.

Mastering JavaScript: The Power of forEach and Ternary Operators

Mon, 18 Aug 2025 20:42:57 +0000

This article explores how to effectively use JavaScript's forEach method in combination with the ternary operator, enhancing your understanding of the underlying code while writing it more efficiently!

Image credit: Star Wars character © Lucasfilm Ltd. & TM. All Rights Reserved. Coca-Cola can © The Coca-Cola Company. Used under fair use for educational purposes.

Introduction

Using JavaScript's forEach method in conjunction with the ternary operator can increase your coding efficiency. Learning how to integrate different methods like this will enable you to write cleaner, more efficient code, enhancing readability and functionality.

Throughout the article, we will discuss key JavaScript concepts, including:

Objects: Understanding how to structure and utilize objects to organize data.
Arrays: Learning how arrays can store multiple values and how to manipulate them.
forEach Method: Discovering how to iterate over arrays efficiently using this built-in method.
Iterating and Modifying Object Arrays: Exploring techniques to update object properties within arrays.
Ternary Operator: Mastering this concise alternative to traditional if-else statements for decision-making.

JavaScript Objects

An object in JavaScript is a collection of related data and functionality, organized as key-value pairs. Objects help you organize related information, making managing and accessing data in your code easier.

The following code defines a JavaScript object named Anakin. This object contains several key-value pairs that describe his attributes:

const Anakin = {
  name: "Anakin Skywalker",
  ForcePath: "light",
  affiliation: "Jedi",
  homePlanet: "Tatooine",
  lightsaberColor: "blue",
  mentor: "Obi-Wan Kenobi",
  apprentice: "Ahsoka Tano",
  knownAs: "The Chosen One"
};

JavaScript Array

A JavaScript array is a special type of object used to store multiple values in a single variable. Arrays are like lists that can hold a collection of items, such as numbers, strings, or even other objects. Each item in an array has a specific position, called an index, starting from zero. This makes accessing, adding, or modifying items using their index easy.

We can create two new Star Wars character objects, and then add them to an array as follows:

const characters = [Anakin, ObiWan, Dooku];

JavaScript forEach Method

The forEach method in JavaScript is a built-in function used to execute a specific function once for each element in an array. It's a convenient way to loop through all the items in an array without having to write a traditional for loop.

When you use forEach, you provide a function that will be called for each element in the array. This function can perform any operation you need, such as logging values to the console, updating elements, or performing calculations.

While iterating over the array with forEach, you can access the values of an object's properties using dot notation. Dot notation allows you to easily retrieve or update the value associated with a specific key in an object.

We can iterate over the Star Wars characters array and console log each character’s name, ForcePath, and affiliation as follows:

characters.forEach(character => {
  console.log(`Name: ${character.name}`);
  console.log(`Force Path: ${character.ForcePath}`);
  console.log(`Affiliation: ${character.affiliation}`);
});

Iterating and Modifying Object Arrays

Now that we have an understanding of a JavaScript object, an array, and the forEach Method: Let’s write code to iterate and modify the object arrays’ affiliation values based on each character's ForcePath value.

If the character has a value of “light“ for their ForcePath, then their affiliation value is “Jedi.“ If the character has a value of “dark“ for their ForcePath, then their affiliation value is “Sith.“

characters.forEach(character => {
  if (character.ForcePath === "dark") {
    character.affiliation = "Sith";
  }
});

Now, changing Anakin’s ForcePath to dark changes his character affiliation to Sith!

Ternary Operator

The ternary operator in JavaScript is a shorthand way of writing an if-else statement. It allows you to make a quick decision between two values based on a condition. The ternary operator uses the ? and : symbols and follows this basic structure:

condition ? valueIfTrue : valueIfFalse

Here's how it works: if the condition is true, the operator returns the value before the colon (:); if the condition is false, it returns the value after the colon. It's a concise way to assign values or execute expressions based on a condition, making your code shorter and often easier to read.

We can revise the if statement code inside the forEach loop to a ternary operator for better readability and concise code:

characters.forEach(character => character.ForcePath === "dark" ? character.affiliation = "Sith" : character.affiliation = "Jedi");

CodePen Demonstration

To see the code in action, check out the complete implementation on CodePen here. Make sure to open the console log to view the results.

My Personal Use Case

As a personal project, I am working on a JavaScript Pac-Man game based on Ania Kubów’s 1-hour Pac-Man in JavaScript YouTube tutorial. This tutorial was featured both on Scrimba and freeCodeCamp, and it’s a really fun way to learn JavaScript!

???? Here is a link to my JavaScript Pac-Man game, which is in progress.

I added levels to my game. When each level is completed, I increase the speed of Pac-Man and all the ghosts.

Following Ania’s tutorial, I created the four ghosts using a JavaScript Ghost class stored in a ghosts array. After completing each game level, I needed to update each ghost's speed value to achieve the desired result.

As a quite comical glitch, as the levels progress, the ghosts' speed increases so much that the gameplay becomes unplayable; they zip by so fast that avoiding them is impossible!

export class Ghost {
  constructor (className, startIndex, speed, size, color, eyes) {
    this.className = className;
    this.startIndex = startIndex;
    this.speed = speed;
    this.size = size;
    this.color = color;
    this.eyes = eyes;
    this.currentIndex = startIndex;
    this.isScard = false;
    this.timerId = NaN;
  }
}

export const ghosts = [
  new Ghost ('blinky', 321, 225,`ghost-${ghostSize}`, 'ghost-red', `ghost-look-left-${eyeSize}`),
  new Ghost ('inky', 376, 275,`ghost-${ghostSize}`, 'ghost-blue', `ghost-look-up-${eyeSize}`),
  new Ghost ('pinky', 377, 250,`ghost-${ghostSize}`, 'ghost-pink', `ghost-look-down-${eyeSize}`),
  new Ghost ('clyde', 378, 300,`ghost-${ghostSize}`, 'ghost-orange', `ghost-look-right-${eyeSize}`),
];

The ghosts' speeds are initially set to different values in milliseconds, which determine how quickly they move. After each level is completed, the speed of each ghost is increased by reducing the time interval by 25 milliseconds. This makes the ghosts move faster, adding to the challenge of the game as players progress through the levels.

Using all of the JavaScript concepts covered in this article, I wrote the following code to “cap“ each ghost's speed at 100 milliseconds, which solved the issue of the ghost moving at an unplayable rate.

 ghosts.forEach(ghost => ghost.speed !== 100 ? ghost.speed -= 25 : ghost.speed = ghost.speed)

Be sure to listen to the HTML All The Things Podcast!

???? I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

With CodeMonkey, learning can be all fun and games! CodeMonkey transforms education into an engaging experience, enabling children to evolve from tech consumers to creators. Use CodeMonkey's FREE trial to unlock the incredible potential of young tech creators!

With a structured learning path tailored for various age groups, kids progress from block coding to more advanced topics like data science and artificial intelligence, using languages such as CoffeeScript and Python. The platform includes features for parents and teachers to track progress, making integrating coding into home and classroom settings easy.

Through fun games, hands-on projects, and community interaction, CodeMonkey helps young learners build teamwork skills and receive recognition for their achievements. It fosters a love for coding and prepares children for future career opportunities in an ever-evolving tech landscape.

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Become a hireable developer with Scrimba Pro! Discover a world of coding knowledge with full access to all courses, hands-on projects, and a vibrant community. You can read my article to learn more about my exceptional experiences with Scrimba and how it helps many become confident, well-prepared web developers!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

To become a better JavaScript developer, it's important to learn and understand the underlying logic of your code. This provides you with the skill to revise it using built-in methods, resulting in cleaner and more efficient code. For example, once you understand the logic and how to write a for loop, you can alternatively use JavaScript’s forEach method.

Another example of code revision is using a ternary operator instead of an if-else statement. Combining shorthand operators and built-in methods further helps you to create more concise and readable code.

Most importantly, enjoy the process of coding! I created objects featuring Star Wars characters to illustrate the concepts discussed. I then used these concepts to revise the code in my JavaScript Pac-Man game! What entertainment genres do you enjoy? Do you find coding games fun as well? Customize your learning experience to make it enjoyable and become a better developer!

Let’s connect! I’m active on LinkedIn and Twitter.

Sharding & Partitioning Secrets You Were Never Told

Fri, 09 May 2025 17:16:44 +0000

Beneath every blazing-fast app, behind every seamless digital experience, lies a forbidden architecture—one that few dare to discuss. Two ancient techniques, whispered in server rooms and scribbled in the margins of database logs, hold the key: Sharding and Partitioning.

But beware—this knowledge is dangerous.

Partitioning: The Silent Knife in the Dark

Your database is a living entity, growing, consuming, swelling until it chokes on its own weight. Then... the knife falls.

Partitioning splits the beast—not by destroying it, but by carving it into manageable pieces. Each slice obeys a hidden rule (a date, a name, a secret key), allowing queries to move like shadows, slipping through only what they need.

The Good: Faster. Cleaner. Contained.

The Bad: Still one beast. Still one lair.

The Truth: You’ve only delayed the inevitable.

⚔️ Sharding: The Fracturing of Realms

When one world is no longer enough, you shatter it.

Sharding does not cut—it replicates, spawning parallel dimensions of data, each ruling its own domain. No single point of failure. No master, only fragments of power.

The Good: Infinite scale. Unbreakable resilience.

The Bad: Complexity. The risk of imbalance.

The Truth: Once you shard, there is no going back.

The Forbidden Choice
Partitioning is the monk’s path—orderly, controlled, but limited.

Sharding is the warlock’s gambit—unleashing power at a cost.

Which will you choose when your data demands sacrifice?

The secrets deepen… Unlock the truth here.

The Most Powerful Refactor You’ll Never Commit

Mon, 31 Mar 2025 19:52:45 +0000

Sometimes the most effective change you can make isn’t in the code at all—it’s in how you think about the code. It’s a shift in understanding, not syntax. This kind of change happens quietly: a name stays the same, no lines are added or deleted, but your mental model adjusts. You stop fighting what a variable should mean and start working with what it does mean. In doing so, you unlock momentum. You’re no longer blocked by a mismatch between intention and reality. You simply choose to interpret differently, and the problem dissolves.

This comes up constantly in programming. We all value clarity and meaning in the names we choose—function names, field names, class names, all of it. When those names align with their purpose, it’s easier to reason about the system. But that alignment isn’t always perfect, and chasing it can become a trap. The code might be working just fine, doing exactly what you need, but its wording is off. That tension can tempt you to refactor—rename, restructure, redefine—when what’s really needed is a change in how you think about the thing in front of you.

Letting go of that urge doesn’t mean ignoring problems or giving up on maintainability. It means recognizing that not all mismatches need to be resolved in code. Sometimes it’s more pragmatic to mentally adapt than to physically rewrite. This kind of decision can accelerate progress—helping a team build on existing systems rather than stalling out in pursuit of semantic perfection. Especially in fast-moving environments, reframing how you interpret a symbol or component can be the difference between moving forward or grinding to a halt.

That said, it’s not free. This is a form of technical debt. Like all debt, it carries risk. Over time, a system full of misnamed parts can create real confusion. But in my experience, when managed intentionally, this kind of debt-taking often pays off. It lets teams prioritize function over form, momentum over polish. The key is awareness: knowing when you’re choosing to change your mind instead of the code, and making sure that choice is deliberate. It’s not a failure of discipline—it’s a technique. And sometimes, it’s the best one you’ve got.

Code Refactoring - Python Best Practices and Tips

Wed, 26 Jun 2024 14:38:16 +0000

Software normally fails when it becomes so complex that it can no longer provide the additional features needed while remaining error-free. Refactoring is used to improve the code design to make it easier to understand and extensible. If you believe that a feature may be needed and your current code will not easily accommodate it, you can refactor that code. You make it easier to add that feature now, rather than worrying about what you should change in your code to add the feature later.

Importance of Refactoring for Code Maintainability and Readability

Why should you refactor? By removing duplicate code, you reduce the overall codebase, making it easier to modify and understand. Hence, you have less code that is easier to modify and understand, which you are well aware of if you look at huge programs and try to understand how they work.

Writing understandable code will make it easy to modify and maintain the code. By refactoring the code, you will understand the system better. If you know the system better, it would be easier to spot bugs.
Refactoring also helps you write code faster. If you write understandable code, you will spend all your time adding features instead of having to go back and try to understand the code. You have written repetitively to fix bugs and incorporate new features.
Refactoring also makes the code easy to read. Eliminating duplication makes modification easy and minimizes complex conditional logic.

In this article, I will cover the importance of refactoring, its principles and designs, and how you can improve your program readability through refactoring techniques. I will also discuss the best practices for enhancing the performance of your Python code.

Identifying Code Smells and Refactoring Opportunities

Introduction to Code Smells and Their Impact on Code Quality

While refactoring code, you are looking for bad smells, which indicates design problems. A code smell is like detecting in-depth issues and concerns in the application or its logic. These issues are not bugs and errors but deviations from the code design and its fundamentals that negatively impact the code quality. This violation will not affect the code compilation but will make the program performance vulnerable to future security threats. Therefore, these code smells are known as bad smells that require a thorough investigation of the program codebase to take immediate action to enhance the quality.

Common Code Smells in Python Programs

When the developer fails to write the code as per the defined design standard, it leads to code smell. Bad code is the result of hard deadlines, mismanagement, shortcuts, and inexperienced developer skills, which leads developers to make mistakes during the development process. Now, in Python, various types of code smell may differ from project to project. These are:

Duplicate Code: One of the most common code smells is code duplication. It means that a similar block of code is used more than once in the program. Instead of copy-paste, there is also duplication in the code structure and inheritance hierarchies. Therefore, fixing it is easy by extracting the duplicate code into a separate function and then calling it whenever you need to.
Long Methods: Another common code smell is long methods. This occurs when the function is too long and is responsible for many tasks. Breaking the long methods into smaller methods, where each must perform its task independently, will resolve this issue.
Improper Names: Using the proper names of variables, classes, and methods will make the code understandable and clean. If you use character-based names or non-descriptive function names, it leads to code smell that makes it difficult to read and maintain. Therefore, the naming convention should be descriptive.

Some other code smells that need your attention are:

Techniques for Identifying Refactoring Opportunities Using Code Reviews and Analysis Tools

Code review is the process used to detect quality issues in an application. The most common issue that impacts code quality is bad smell. Code refactoring is an effective process for tracing code smell and maintaining software quality. It makes the code cleaner, concise, and effective without modifying its core functionalities. Furthermore, code review and analysis tools will help you identify the areas that benefit from refactoring. Several techniques for identifying refactoring opportunities are as follows:

Note: Some people think that refactoring is related to applying design patterns to your code, which is not true. However, spending a lot of time creating a better design is a simple refactoring goal.

Duplicate Code: Duplicate code is a common issue for refactoring. pylint, and FindBugs are effective tools for analyzing and finding duplicate pieces of code. These tools reduce the risk of inconsistencies and make maintenance easier.
Complexity Analysis: PyCharm is an IDE that provides the features of code analysis and refactoring tools and helps identify areas that would benefit from refactoring. In addition, tools like SonarQube and Code Climate will ensure the complexity analysis of code and provide the necessary tips to make it less complex.
Code Static Analysis: mypy is a tool used to check Python code to identify potential bugs in your code. This tool ensures that your code follows a consistent structure.
Security Analysis: Tools like Bandit will help Python developers identify potential security threats in their code.

Principles and Patterns of Refactoring

Introduction to Refactoring Principles

To write a maintainable and clean code of high quality, there are certain guidelines known as refactoring principles. These principles are the set of instructions proven to work over the years. These popular principles are as follows:

DRY: Known as "Don’t Repeat Yourself.". This principle draws attention to the duplication problem within the code. When a block of code is used repeatedly, it makes the code harder to maintain and update because updating would be required at multiple locations. To implement this principle, developers must create a method containing duplicate content to ensure that logic is written in only one place and that the function can be called when needed.
KISS: Knows as "Keep It Super Simple". This principle focuses on writing the code as simply as possible and in a way that the junior developer can easily understand. It highlights the simplicity of the code design and implementation, which makes the code more maintainable and readable. The main point is to avoid unnecessary complexity that leads to poor code quality and confusion among developers.
SOLID: This principle is further divided into five principles that you can follow as the code passes the prototype phase. These five principles are as follows:
1. S-Single Responsibility Principle (SRP): This principle emphasizes that each class in the code should have one responsibility or purpose. It ensures that the specific class or module is focused on one task, which makes the code less complex when modification is required.
2. O-Open/Closed Principle (OCP): This principle emphasizes that each fundamental of code, like classes, modules, and functions, should be open to changes and modification without the need to change their existing behavior. This makes the code more flexible and modular.
3. L-Liskov Substitution Principle (LSP): This principle's focus is that each derived class should be able to implement or replace the base class without any error. It means that the objects of the superclass are replaceable by subclasses without affecting the program's behavior. It makes the code more extensible and interchangeable.
4. I-Interface Segregation Principles (ISP): This principle focuses on implementing multiple small interfaces based on client needs instead of one large interface. In this way, clients can interact with a specific interface according to their needs instead of a monolithic interface.
5. D-Dependency Inversion Principle (DIP): These principles emphasize the use of an abstraction layer instead of the direct interaction between high- and low-level modules. This means that the high-level modules should not directly focus on the low-level module, which makes them highly coupled and difficult to modify.

Exploring Common Refactoring Patterns and Techniques

Let's explore common code refactoring patterns and techniques. These areas follows:

Extract Method: Used to break large methods into separate functions or methods to simplify complex logic and make them more manageable.
Replace Conditional with Polymorphism: Replaces the complex conditional logic with a polymorphism or inheritance concept to make the code easy to understand and modify.
Extract Class: Used to place all related methods and fields in one class. It makes the class more manageable when it becomes large and complex; therefore, handles some responsibilities in a separate class.
Extract Variable: Used to capture all complex expressions and variables and replace their names with descriptive names.
Remove Parameters: Remove all unnecessary parameters used in the method signature to improve readability.
Split Loop: Divide the large loop expression into smaller loops to enhance code clarity.
Introduce Design Patterns: Use design patterns to solve recurring problems instead of writing the code yourself.

Understanding When and How to Apply Each Refactoring Pattern Effectively

Selecting the correct refactoring pattern and techniques and understanding when to use each depends on the code requirements. They require careful consideration and context upon which each is used. Let's explore the requirements of some of them:

1. Extract Method

When to Apply: Having duplicate and large methods that are replaced with a small separate method.
How to Apply: Identify the duplicate code, extract the code into a separate method, and Call the method where needed.

2. Replace Conditional with Polymorphism

When to Apply: Code containing complex conditional logic with object behavior changing on the basis of different states.
How to Apply: Remove all conditional logic and replace them with separate classes, where each class defines a separate state. Each class has its own method and fields.

3. Extract Class

When to Apply: One class performs too many distinct tasks and has many responsibilities. This makes the code logic complex.
How to Apply: Identify the methods and related fields that have similar tasks and group them into separate classes.

4. Extract Variable

When to Apply: When the same expression is used repeatedly within the method. Therefore, it is used to enhance code readability.
How to Apply: Identify all repeated expressions within the method. Then, assign it to a variable with a descriptive name.

5. Remove Parameters

When to Apply: When the parameter used in the method signature is no longer necessary. Furthermore, removing the parameter does not affect the functionality of the method.
How to Apply: Identify the unnecessary parameter and check the method body if it is used within the method. Next, remove the parameter when it is unnecessary and update the caller.

#An Example for removing the unnecessary parameter of middle name 
#which is not used 
def enter_Name(f_Name, m_Name, l_Name):
    return f"{f_Name} {m_Name} {l_Name}"
# Usage
full_name = enter_Name("Harry", "", "Ford")
print(full_name)
#----------------------------------------------------------------!
#After Refactoring
def enter_Name(f_Name, l_Name):
    return f"{f_Name} {l_Name}"
# Usage
full_name = enter_Name("Harry", "Ford")
print(full_name)

Refactoring Techniques for Improved Readability

Breaking Down Long and Complex Functions into Smaller One

One of the most common techniques for code refactoring is the extract method. This technique is used to break down complex and larger methods into smaller ones that are more manageable. Here, the block of code that performs a specific task is extracted into the new function. In addition, if the method is too old and not used frequently, then replacing the function call with method code i.e. inline method is preferable to avoid duplication and reduce complexity. Also, try to use the descriptive names of the methods that specify their task and the variable names within the method.

Caution: Always ensure that the refactored code maintains the same functionality as the original code. Also, thoroughly test to detect any unintended changes in behavior.

Improving Variable Names and Code Comments for Clarity and Understanding

When writing the code, use descriptive names for variables, functions, classes, and all other elements that adhere to industry standards and conventions. The use of a naming convention will improve the readability of code because it properly conveys its purpose and functionality, making it easier for a developer to understand the codebase and logic. In addition, the use of comments within the code will clarify the tasks and responsibilities of the classes and functions. Therefore, to implement the code refactoring, improve the variable name and add comments to clarify the code.

FAQs

Q: What is code refactoring in Python?
A: In Python, it is the process of restructuring Python's existing code without changing its external behavior.

Q: Is it important in Python development?
A: It is important in Python because it enhance readability, code quality, and maintainability and reduces bug risk.

Q: Is there any tool available with the IDE in Python?
A: Tools like PyCharm, Visual Studio Code with Python extensions, Rope, and Black are commonly used for code refactoring in Python.

Wrapping Up

In conclusion, we discussed the importance of code refactoring in the era of programming. Whether you're developing a small application or an enterprise-level application, code quality matters the most. Refactoring is not a magic button that resets the entire code, but it tells you the effective approach for writing maintainable code. It contains many strategies and techniques by which the developer can write perfect code. The perfect code requires fewer upgrades and enhances productivity. I hope this guide is helpful for you. Thank you for reading this. Happy Coding!

Reference

PyCharm Refactoring Documentation
PEP 8 style guide for Python code
Effective Book on Refactoring