DEV Community: Wilbur Suero

Writing Maintainable AI Prompts in Rails with Promptly

Wilbur Suero — Mon, 18 Aug 2025 22:03:48 +0000

A few months ago, I was helping a Rails team add AI-generated onboarding emails to their app. It seemed simple at first: drop an OpenAI.chat(...) call inside a mailer, pass in the user’s name, and let the model draft a warm welcome.

By the second week, things got messy.

Different controllers and jobs had their own inline prompts.

Some prompts were copy-pasted with slight tweaks (“friendly tone”, “professional tone”, etc.).

Marketing wanted localized versions for Spanish and Portuguese.

QA asked, “How do we know the prompts didn’t change by accident?”

We ended up with prompt spaghetti—hard to test, impossible to translate cleanly, and brittle whenever we tried to refactor.

That experience sparked the idea for Promptly: a small gem that brings Rails conventions to AI prompt management.

The Problem: Prompts Don’t Belong Scattered in Code

Rails developers already know the pain of hard-coded strings—why we use views, partials, and I18n instead of littering messages across controllers. Yet many of us are now hardcoding AI prompts directly in service objects or background jobs.

It doesn’t scale.

Duplication: The same wording lives in multiple places.
Localization headaches: Inline strings don’t play well with I18n.
No safety net: Refactors can silently change how the AI behaves.

The Solution: Promptly

Promptly lets you define AI prompts as ERB or Liquid templates, stored in a Rails-native directory structure. Just like you’d render a view, you render a prompt:

# app/prompts/welcome_email.erb
Hello <%= @user.name %>, welcome to our service!
We’re excited to have you join.

# In your mailer or service:
render_prompt("welcome_email", user: @user)

This unlocks the same benefits Rails developers already rely on elsewhere:

Maintainability → All prompts live in one place.
Localization → Templates can use I18n just like views.
Testability → You can write RSpec tests that assert on rendered prompt output.

Why Rails Conventions Matter

Rails has always thrived on convention over configuration. Promptly doesn’t reinvent the wheel; it extends familiar concepts (views, templates, helpers) into the AI space.

Instead of partials, you have prompt templates.
Instead of locals, you have prompt variables.
Instead of ad-hoc strings, you have structured, versionable files.

Getting Started

Add it to your Gemfile:

gem 'promptly'

2.Create your first template in app/prompts.
3.Render it anywhere with render_prompt.
4.Add tests to verify the output.

Full docs are in the GitHub repo.

Looking Ahead

Promptly is intentionally small. It’s not trying to be a full-blown AI orchestration platform. But by solving one narrow pain point—making prompts maintainable, testable, and Rails-friendly—it can help Rails apps adopt AI without chaos.

The next steps may include:

Prompt versioning.
Preview workflows in Rails consoles.
Deeper integration with related gems like semantic search adapters.

If you’re a Rails developer experimenting with AI, try Promptly. It may save you from prompt spaghetti before it starts.

Feedback and contributions are welcome, the best ideas usually come from real-world use.

🚨 Introducing GemGuard: Automated Security for Ruby Gems (Scan, SBOM, Typosquat, Auto-Fix)

Wilbur Suero — Mon, 11 Aug 2025 02:05:38 +0000

Links:

GitHub: github.com/wilburhimself/gem_guard
RubyGems: rubygems.org/gems/gem_guard

TL;DR

✅ Scan dependencies for known vulnerabilities (OSV.dev + Ruby Advisory DB)
🕵️ Detect typosquat packages before they bite
📜 Generate SPDX / CycloneDX SBOMs
🛠 Auto-fix vulnerable gems safely
⚡ Clean CLI + CI-ready
Version: 1.1.x

Why GemGuard?

Because security shouldn’t be an afterthought. It should be:

Pragmatic – only what matters, no noise
Fast – instant feedback in dev or CI
Integrated – works with your normal Ruby workflow

What is GemGuard?

GemGuard is a lightweight Ruby security tool that:

Scans your Gemfile.lock for known vulnerabilities
Detects typosquat risks via fuzzy matching
Generates SBOMs (SPDX and CycloneDX)
Auto-fixes vulnerable gems with safe version upgrades
Plays nicely with CI/CD

Installation

# Add to your Gemfile (recommended for projects)
gem "gem_guard", "~> 1.1"

# Or install globally
gem install gem_guard

Verify:

gem_guard version
# => 1.1.x

Quick Start

Scan your project:

gem_guard scan
# ✅ No vulnerabilities found!
# or exits non‑zero if issues are found

Detect typosquats:

gem_guard typosquat
# No potential typosquat dependencies found.

Generate an SBOM:

gem_guard sbom --format spdx --output sbom.spdx.json
gem_guard sbom --format cyclonedx --output bom.cdx.json

Auto‑Fix Vulnerabilities

Preview (dry run):

gem_guard fix --dry-run

Apply fixes (creates a Gemfile.lock backup by default):

gem_guard fix
# 📦 Created backup: Gemfile.lock.backup.2025...
# ✅ Updated nokogiri to 1.18.9
# 🔄 Running bundle install to update lockfile...

Options:

--interactive: confirm each update
--no-backup: skip lockfile backup
--gemfile, --lockfile: custom paths

Tip: Re-scan after fixing

gem_guard scan

Clean CLI

gem_guard --help
# config, scan, typosquat, sbom, fix, version

Exit codes:

0: success / no vulns
1: vulnerabilities found
2: errors (e.g., missing files)

CI/CD Integration (GitHub Actions)

name: security-scan
on: [push, pull_request]
jobs:
  gemguard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.3'
          bundler-cache: true
      - run: gem install gem_guard
      - run: gem_guard scan --format json > gemguard-report.json
      - run: gem_guard typosquat --format json > typosquat-report.json
      - name: Upload reports
        uses: actions/upload-artifact@v4
        with:
          name: gemguard-reports
          path: |
            gemguard-report.json
            typosquat-report.json

Fail builds on vulnerabilities (default behavior). If you want non-blocking scans (e.g., on main), wrap with || true or use matrix strategies.

Configuration

Create .gemguard.yml:

lockfile: Gemfile.lock
output:
  format: table   # table | json
typosquat:
  similarity_threshold: 0.82
  risk_levels:
    high: 0.9
    medium: 0.85

View current config:

gem_guard config --show

Why GemGuard?

Minimal setup, zero noise
Pragmatic defaults, sensible exit codes
Works offline for typosquat via fallback popular gems
Well-tested (RSpec), standardrb formatting
Designed for CI from day 1

How It Compares

Bundler Audit: great for advisories; GemGuard adds typosquat + SBOM + auto-fix
OSV-Scanner: broad ecosystem; GemGuard is Ruby-first with tighter UX and auto-fix
Trivy/Grype: container focus; GemGuard slots into pure-Ruby pipelines easily

Use GemGuard standalone or alongside your existing stack.

Roadmap

Enriched advisories (GHSA/CVE links, CVSS)
Optional dependency graph visualizations
Interactive TUI
More fix strategies and guards

Contribute / Feedback

Issues/PRs welcome: add tests, keep it minimal and intention-revealing
Prefer failing test → minimal fix → refactor
Security disclosures: see SECURITY.md

Try It Now

gem install gem_guard
gem_guard scan
gem_guard typosquat
gem_guard fix --dry-run

If this helps you ship safer Ruby apps with less fuss, drop a ❤️ and share!

— Built for Rubyists who like fast feedback, clean CLIs, and reliable automation.

Issues and PRs welcome → github.com/wilburhimself/gem_guard

How I Built a RAG System in Rails Using Nomic Embeddings and OpenAI

Wilbur Suero — Fri, 18 Jul 2025 19:48:41 +0000

Retrieval-Augmented Generation (RAG) lets you bring your own data to LLMs—and get real answers. I’ll show how I used the open-source nomic-embed-text-v2-moe model for semantic search in a Rails app, while still using OpenAI for generation.

🧠 What is RAG?

RAG (Retrieval-Augmented Generation) enhances LLMs by feeding them relevant chunks of your data before generating a response. Instead of fine-tuning, we give the model useful context.

Here's the basic pipeline:

[ User Question ]
        ↓
[ Embed the Question (Nomic) ]
        ↓
[ Vector Search in PgVector ]
        ↓
[ Retrieve Relevant Chunks ]
        ↓
[ Assemble Prompt ]
        ↓
[ Generate Answer with OpenAI ]

🧰 The Stack

Rails – Backend framework, routes, controllers, and persistence
Nomic Embedding Model – For semantic understanding of data
FastAPI – Lightweight Python server to serve embeddings
PgVector – PostgreSQL extension to store and query vector data
OpenAI GPT-4 / GPT-3.5 – For the final response generation

🛠 Step 1: Run the Nomic Model Locally (Optional but Fast)

You can run the nomic-embed-text-v2-moe model using sentence-transformers in a Python FastAPI app:

from fastapi import FastAPI, Request
from sentence_transformers import SentenceTransformer

app = FastAPI()
model = SentenceTransformer("nomic-ai/nomic-embed-text-v2-moe")

@app.post("/embed")
async def embed(req: Request):
    data = await req.json()
    input_text = data["input"]
    embedding = model.encode(input_text).tolist()
    return { "embedding": embedding }

This becomes your internal embedding API, replacing OpenAI’s /embeddings.

📄 Step 2: Chunk and Store Your Data

Split your content into short passages (~100–300 words), embed them via your FastAPI endpoint, and store the results in PostgreSQL with pgvector.

Add a vector column:

psql -d your_db -c "CREATE EXTENSION IF NOT EXISTS vector;"

class AddEmbeddingToDocuments < ActiveRecord::Migration[7.1]
  def change
    add_column :documents, :embedding, :vector, limit: 768 # Nomic v2-moe size
  end
end

🤖 Step 3: Embed User Queries via Nomic

In your Rails controller:

def get_embedding(text)
  response = Faraday.post("http://localhost:8000/embed", { input: text }.to_json,
                          "Content-Type" => "application/json")
  JSON.parse(response.body)["embedding"]
end

Use the same model for both document and query embeddings.

🔍 Step 4: Perform Vector Search with PgVector

Search your documents for the closest matches using cosine distance:

Document.order("embedding <-> cube(array[?])", query_vector).limit(5)

These top chunks become the context for the LLM.

🧾 Step 5: Build a Smart Prompt for OpenAI

Concatenate the top passages and feed them into OpenAI’s chat API:

client.chat(
  parameters: {
    model: "gpt-4",
    messages: [
      { role: "system", content: "You are an assistant answering based on the provided context." },
      { role: "user", content: build_contextual_prompt(user_input, top_chunks) }
    ]
  }
)

✅ Why Use Nomic for Embeddings?

High-quality, open-source, multilingual
No token limits — runs locally or self-hosted
Zero vendor lock-in at the embedding layer
Great performance on MTEB and real-world retrieval

💡 Why I Still Use OpenAI for the LLM

The generation step is where OpenAI shines. Instead of replacing it prematurely, I decoupled the embedding stage. Now I can experiment, optimize, and even switch LLMs later if needed.

🧠 Takeaways

RAG doesn’t need to be a heavyweight system.
Open-source embeddings + OpenAI generation = powerful, flexible hybrid.
PgVector + Rails makes vector search feel native and hackable.

The Art of Idiomatic Ruby: Principles and Practices for Elegant Code

Wilbur Suero — Mon, 17 Mar 2025 17:29:02 +0000

As developers, we're constantly seeking to improve our craft and develop a coding style that's both effective and elegant. Ruby stands out among programming languages for its expressiveness and focus on developer happiness. The philosophy behind Ruby and its most popular framework, Rails, has shaped how countless developers think about software design, readability, and the overall development experience.

In this post, I'll explore the key principles behind idiomatic Ruby, analyze what makes Ruby code truly "Rubyesque," and share practical ways to incorporate these principles into your own work.

Core Philosophy of Idiomatic Ruby

Ruby's approach to programming is built on several foundational principles:

Convention over Configuration

One of Ruby's most influential frameworks popularized the concept of sensible defaults and conventions. Rather than requiring developers to make countless trivial decisions, idiomatic Ruby emphasizes having established patterns that make assumptions about what developers need and provide streamlined pathways for common tasks.

This philosophy extends beyond frameworks into coding style, where established patterns and clear conventions are favored over reinventing the wheel or introducing unnecessary complexity.

Beautiful Code

In the Ruby community, code isn't just functional—it's a form of craft. There's a strong emphasis on the aesthetics of code, with the understanding that beautiful code is more maintainable, more enjoyable to work with, and ultimately more effective. This focus on beauty manifests in a preference for expressive, readable syntax that almost reads like natural language.

Programmer Happiness

"Optimize for programmer happiness" is a consistent theme in the Ruby community. While some languages and frameworks optimize primarily for performance or flexibility, Ruby prioritizes the developer experience. This perspective views coding as a creative act that should be enjoyable rather than tedious.

Opinionated Software Design

Idiomatic Ruby doesn't shy away from having strong opinions about how software should be built. Rather than trying to accommodate every possible approach, Ruby and its ecosystem often present "The Ruby Way" of doing things. Making strong choices about architecture and design patterns creates a more cohesive and understandable codebase.

Elements of Idiomatic Ruby Style

When examining truly elegant Ruby code, several distinctive characteristics emerge:

Expressive Naming

Idiomatic Ruby places tremendous importance on choosing the right names for variables, methods, and classes. It favors descriptive, sometimes longer names that clearly communicate intent over terse abbreviations. The goal is code that can be read and understood without extensive comments or documentation.

For example, instead of:

def calc_ttl_prc(items)
  # Calculate total price with discount
  items.sum(:price) * 0.9
end

Idiomatic Ruby prefers:

def total_price_with_discount(items)
  items.sum(:price) * 0.9
end

Embracing Ruby's Natural Expressiveness

Truly Rubyesque code leans heavily into the language's syntax to create code that feels natural and reads almost like English prose. It makes full use of Ruby's blocks, optional parentheses, and symbol shortcuts to create concise yet readable code.

# Less idiomatic
users.select { |user| user.subscribed? }.each { |user| user.send_newsletter }

# More idiomatic 
users.select(&:subscribed?).each(&:send_newsletter)

Domain-Driven Design

Idiomatic Ruby often designs code around domain concepts rather than technical implementation details. Classes and methods reflect the business domain, making the code not just functional but a representation of the problem space itself.

Pragmatic Testing Approach

The Ruby community has evolved a pragmatic approach to testing. While testing is valued, there's a focus on testing the outcomes that matter rather than implementation details. System tests that verify functionality from the user's perspective are often favored alongside focused unit tests.

Strategic Metaprogramming

Ruby's powerful metaprogramming capabilities are a double-edged sword. Idiomatic Ruby uses metaprogramming strategically to eliminate boilerplate and create more elegant APIs, not as a showcase of technical wizardry.

Key Design Patterns in Ruby

Several design patterns are central to idiomatic Ruby programming:

Active Record Pattern

The Active Record pattern, which blends database access and business logic into a single object, is widely used in the Ruby ecosystem. While this approach breaks with strict separation of concerns, it creates an intuitive model that's easy to work with.

class Product < ApplicationRecord
  has_many :reviews
  belongs_to :category

  validates :name, presence: true
  validates :price, numericality: { greater_than: 0 }

  def discounted_price
    price * 0.9
  end
end

Modules and Concerns for Shared Behavior

Instead of deep inheritance hierarchies, idiomatic Ruby favors using modules as "Concerns" to share behavior across multiple classes. This creates more flexible composition without the rigid structures that deep inheritance can create.

module Trackable
  extend ActiveSupport::Concern

  included do
    has_many :audit_logs
    after_save :record_change
  end

  def record_change
    audit_logs.create(action: "updated")
  end
end

class Product < ApplicationRecord
  include Trackable
  # Product-specific code...
end

Convention-Based Routing

RESTful routing establishes clear conventions for mapping HTTP verbs and URLs to controller actions, creating a predictable structure for web applications.

Service Objects for Complex Operations

For operations that span multiple models or incorporate complex business logic, Ruby developers often employ service objects—dedicated classes that encapsulate a single operation or transaction.

class OrderProcessor
  def initialize(order, payment_details)
    @order = order
    @payment_details = payment_details
  end

  def process
    return false unless valid?

    ActiveRecord::Base.transaction do
      process_payment
      update_inventory
      send_confirmation
    end

    true
  end

  # Private methods for each step...
end

How to Write Idiomatic Ruby

If you're inspired by Ruby's elegant approach and want to incorporate elements of idiomatic style into your own work, here are some practical steps:

1. Prioritize Readability Above All

Write code for humans first, computers second. Invest time in creating clear, expressive code that future developers (including your future self) will easily understand.

2. Embrace Ruby's Unique Features

Work with Ruby's strengths rather than fighting against them. Learn what makes Ruby special—blocks, procs, symbols, method_missing, etc.—and use those features to create more elegant code.

# Instead of:
["apple", "banana", "cherry"].map { |fruit| fruit.upcase }

# Write:
["apple", "banana", "cherry"].map(&:upcase)

3. Design Around Your Domain

Structure your code to reflect the business or problem domain rather than technical considerations. Your classes and methods should speak the language of your users and stakeholders.

4. Follow Conventions but Break Them When Necessary

Establish and follow conventions in your codebase, but be willing to break them when they don't serve your needs. Ruby isn't dogmatic about rules—it's pragmatic about results.

5. Value Simplicity Over Complexity

Resist the urge to over-engineer. The Ruby community often advocates for the simplest solution that works, even if it's not the most theoretically pure or technically impressive.

6. Consider the Whole System

Think holistically about your application rather than optimizing individual components in isolation. An idiomatic approach considers how all parts of a system work together to create a cohesive whole.

7. Make Development Enjoyable

Finally, remember that coding should be enjoyable. Create tools, processes, and code that make development a pleasure rather than a chore—this is perhaps the most Ruby-like approach of all.

8. Pay Attention to Code Smells

Learn to recognize and refactor common code smells:

# Code smell: Long method
def process_order
  # 100 lines of code doing many different things
end

# Refactored: Extracted methods with clear purposes
def process_order
  validate_order
  process_payment
  update_inventory
  send_confirmation
end

9. Follow Community Style Guides

Familiarize yourself with established Ruby style guides like the one from GitHub or Rubocop's defaults. These encapsulate years of community wisdom about what makes Ruby code clear and maintainable.

Idiomatic Ruby represents a philosophy of software development that values human factors alongside technical considerations—code that's not just functional but beautiful, maintainable, and enjoyable to work with.

By prioritizing readability, embracing Ruby's unique features, and focusing on developer happiness, you can create code that not only works but brings joy to those who interact with it. That's the true spirit of Ruby.

What aspects of Ruby's style have influenced your own development approach? What patterns or practices do you find most valuable in your own Ruby projects? Share your thoughts and experiences in the comments below.

Understanding Form Objects in Ruby on Rails

Wilbur Suero — Thu, 13 Mar 2025 21:38:04 +0000

In Ruby on Rails applications, handling complex forms can become messy when too much logic is stuffed into models or controllers. This is where Form Objects come in—a design pattern that helps separate form-related logic from Active Record models, making our applications more maintainable and testable.

The Problem with Traditional Forms

By default, Rails encourages using Active Record models directly in forms. However, this approach has some downsides:

Fat Models: Business logic and validation bloat the model, making it harder to maintain.
Fat Controllers: Controllers become responsible for handling complex form submissions.
Multiple Models in One Form: Standard Rails forms work well with single models, but handling multiple related models can be cumbersome.

To address these issues, we use Form Objects.

What is a Form Object?

A Form Object is a Plain Old Ruby Object (PORO) designed to handle form submissions. It encapsulates form-specific validations and persistence logic while keeping models and controllers clean.

When to Use a Form Object

When a form involves multiple models.
When you want to keep your controllers thin and models focused.
When form validation differs from the database schema.
When reusing form logic across multiple places in your application.

Implementing a Form Object in Rails

Let's walk through an example where we create a UserRegistrationForm that handles user sign-ups along with profile information.

Step 1: Create the Form Object

Create a new file in app/forms/user_registration_form.rb:

class UserRegistrationForm
  include ActiveModel::Model

  attr_accessor :name, :email, :password, :password_confirmation, :bio

  validates :name, :email, :password, :password_confirmation, presence: true
  validates :password, confirmation: true
  validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }

  def initialize(attributes = {})
    super(attributes)
  end

  def save
    return false unless valid?

    ActiveRecord::Base.transaction do
      user = User.create!(name: name, email: email, password: password)
      Profile.create!(user: user, bio: bio)
    end
    true
  rescue ActiveRecord::RecordInvalid
    false
  end
end

Step 2: Use the Form Object in the Controller

Modify the UsersController to use the UserRegistrationForm:

class UsersController < ApplicationController
  def new
    @form = UserRegistrationForm.new
  end

  def create
    @form = UserRegistrationForm.new(user_params)

    if @form.save
      redirect_to root_path, notice: 'User registered successfully!'
    else
      render :new
    end
  end

  private

  def user_params
    params.require(:user_registration_form).permit(:name, :email, :password, :password_confirmation, :bio)
  end
end

Step 3: Update the View

Modify the new.html.erb view:

<%= form_with model: @form, url: users_path do |form| %>
  <div>
    <%= form.label :name %>
    <%= form.text_field :name %>
  </div>

  <div>
    <%= form.label :email %>
    <%= form.email_field :email %>
  </div>

  <div>
    <%= form.label :password %>
    <%= form.password_field :password %>
  </div>

  <div>
    <%= form.label :password_confirmation %>
    <%= form.password_field :password_confirmation %>
  </div>

  <div>
    <%= form.label :bio %>
    <%= form.text_area :bio %>
  </div>

  <div>
    <%= form.submit 'Register' %>
  </div>
<% end %>

Benefits of Using Form Objects

Separation of Concerns: Keeps models and controllers focused on their primary responsibilities.
Improved Testability: You can test form logic independently.
Easier Maintenance: Avoids bloated models with unnecessary validations.

Form Objects in Ruby on Rails provide a clean way to manage complex form submissions while keeping code organized. By encapsulating form logic in a dedicated class, we improve maintainability, readability, and re-usability in our applications.

If you're dealing with bloated models and controllers due to complex forms, consider adopting Form Objects as a structured solution!

Background Jobs in Rails: A Look at SolidQueue

Wilbur Suero — Wed, 12 Mar 2025 05:43:03 +0000

Coming from a Rails background, one of the most common patterns developers rely on is background job processing. Traditionally, this has meant reaching for Sidekiq, Resque, or Delayed Job—external tools that require Redis or additional infrastructure. But what if you could handle background jobs natively within your database? Enter SolidQueue.

In this post, I’ll explore how SolidQueue changes the game for Rails developers, how it compares to existing background job solutions, and how you can start using it today.

SolidQueue in Rails 8: Built-In Background Jobs

With the release of Rails 8, SolidQueue is now bundled as the default background job system. This means that if you're starting a new Rails 8 application, you already have everything you need to manage background jobs without any additional dependencies.

Minimum Required Version

SolidQueue requires Rails 7.1 or later to function. However, for full integration and the best experience, Rails 8 is recommended since it comes pre-configured.

Understanding SolidQueue: Background Jobs Without External Dependencies

SolidQueue is a database-backed queuing system designed to work seamlessly with Active Job in Rails. Unlike Sidekiq or Resque, which rely on Redis, SolidQueue keeps everything within your application’s SQL database. The result? Simplified infrastructure, reduced operational complexity, and one less dependency to worry about.

Key Features of SolidQueue

Native Database Integration: Jobs are stored and managed using PostgreSQL, MySQL, or SQLite—whichever database your Rails app already uses.
Active Job Compatibility: Works out of the box with Rails' Active Job framework.
No Additional Services Required: Eliminates the need for Redis or external queueing systems.
Mission Control UI: Provides a web interface to monitor and manage jobs.
Automatic Job Retries & Error Handling: Ensures reliable job execution.

How to Set Up SolidQueue in Rails 8

If you're using Rails 8, SolidQueue is already included, and you just need to enable it.

Enabling SolidQueue in a New Rails 8 App

For new Rails 8 applications, SolidQueue is the default Active Job adapter. To ensure it is enabled, check your config/application.rb:

config.active_job.queue_adapter = :solid_queue

Then, run the database migrations to set up the necessary tables:

rails db:migrate

Setting Up SolidQueue in an Existing Rails 7.1+ App

If you're on Rails 7.1 or later and want to use SolidQueue, you'll need to install it manually:

# Add to your Gemfile
gem 'solid_queue'

Then, run the installation generator:

bundle exec rails generate solid_queue:install
rails db:migrate

Defining and Enqueueing Jobs

Creating jobs with SolidQueue is no different from using Active Job:

class ExampleJob < ApplicationJob
  queue_as :default

  def perform(name)
    puts "Processing job for #{name}"
  end
end

ExampleJob.perform_later("Alice")

Running Jobs

SolidQueue requires a supervisor process to run jobs. Start it with:

bundle exec solid_queue:start

This will process jobs from the database queue, similar to how Sidekiq works.

A More Detailed Example: Processing an Order in Rails 8

Let’s say we’re building an e-commerce application and need to process orders asynchronously. With SolidQueue in Rails 8, we can handle this with ease.

Step 1: Define the Job

class ProcessOrderJob < ApplicationJob
  queue_as :default

  def perform(order_id)
    order = Order.find(order_id)
    order.process_payment!
    order.update!(status: "completed")
    puts "Order ##{order.id} has been processed."
  end
end

Step 2: Enqueue the Job When an Order is Created

Modify your OrdersController:

class OrdersController < ApplicationController
  def create
    @order = Order.create!(order_params)
    ProcessOrderJob.perform_later(@order.id)
    redirect_to @order, notice: "Your order is being processed."
  end
end

Step 3: Start the Worker Process

To start processing jobs, simply run:

bundle exec solid_queue:start

Now, every time a new order is created, it will be processed in the background by SolidQueue.

Comparing SolidQueue to Sidekiq

Feature	SolidQueue (Database-Backed)	Sidekiq (Redis-Backed)
Dependency	Uses SQL database	Requires Redis
Infrastructure	No extra services needed	Needs Redis, Sidekiq
Performance	Good for most applications	Optimized for high throughput
UI for Jobs	Mission Control UI	Sidekiq Web UI
Reliability	Database transactions ensure safety	Redis-based, requires persistence tuning

If you’re running a high-throughput application with millions of background jobs per day, Sidekiq may still be the best choice. But for most Rails applications, SolidQueue provides a much simpler, integrated solution without the extra operational burden.

When Should You Use SolidQueue?

SolidQueue is a great choice if:

You want to avoid the overhead of running Redis.
Your application already relies heavily on its database.
You prefer an all-in-one solution with built-in job monitoring.
You need Active Job compatibility with minimal setup.

However, if you need extreme performance and high concurrency, Sidekiq might still be the better option.

SolidQueue represents a shift in how Rails developers can handle background jobs. By leveraging the database as a queueing system, it removes the need for external services like Redis while maintaining reliability and simplicity. With Rails 8, SolidQueue is now the default, making background job processing more accessible than ever.

If you’re using Rails 8, try it out today—it’s already built in! And if you're on an older version, upgrading to Rails 8 or installing SolidQueue manually can help simplify your background job processing.

Concurrency vs. Parallelism in Go: What Every Developer Should Know

Wilbur Suero — Tue, 11 Mar 2025 16:05:45 +0000

Following up with my previous post about Concurrency in Go, many developers encounter a common misconception: that Go provides true parallelism by default. While Go excels at concurrency with its lightweight goroutines, achieving effective parallel execution requires understanding Go's runtime scheduler and how GOMAXPROCS affects program behavior. This post explores how Go handles concurrency, when it achieves parallelism, and how it compares to other programming languages.

Concurrency vs. Parallelism: Fundamental Distinctions

These terms are often conflated but represent distinct concepts:

Concurrency: The ability to structure a program to handle multiple tasks, potentially overlapping in time. It's about program design and decomposition of problems into independently executable units.
Parallelism: The simultaneous execution of multiple computations, typically on separate CPU cores. It's about execution and hardware utilization.

As Rob Pike famously said: "Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once."

Go's goroutines and channels provide elegant concurrency primitives, but actual parallel execution depends on runtime configuration and hardware capabilities.

Go's Concurrency Model: Goroutines and the Runtime Scheduler

Go implements a CSP-based (Communicating Sequential Processes) concurrency model using goroutines—lightweight, user-space threads managed by Go's runtime rather than the operating system. Compared to OS threads which might require megabytes of stack space, goroutines start with only 2KB, allowing programs to spawn millions of them efficiently.

Here's a simple example demonstrating goroutine creation:

package main

import (
    "fmt"
    "time"
)

func sayHello() {
    fmt.Println("Hello from a goroutine!")
}

func main() {
    go sayHello() // Launch goroutine
    time.Sleep(100 * time.Millisecond) // Give goroutine time to execute
    fmt.Println("Main function continues execution")
}

While this code runs the sayHello() function concurrently with the main function, it doesn't necessarily execute in parallel. Understanding why requires examining Go's scheduler architecture.

Go's Scheduler: The M:P:G Model

Go's scheduler implements what's known as the M:P:G model:

G (Goroutines): Application-level tasks
M (Machine): OS threads that execute code
P (Processor): Logical processors that manage execution contexts

In this model:

Each P maintains a local queue of runnable goroutines
Ms (OS threads) execute goroutines from the P they're assigned to
When a P's queue is empty, it attempts to steal work from other Ps

This sophisticated work-stealing scheduler efficiently distributes goroutines across available system resources, but the number of Ps is the key limiting factor for parallel execution.

Controlling Parallelism with GOMAXPROCS

By default, Go sets GOMAXPROCS equal to the number of available CPU cores since Go 1.5. This value determines the number of Ps (logical processors) in the runtime.

You can explicitly control this setting in your code:

package main

import (
    "fmt"
    "runtime"
    "time"
)

func cpuIntensiveTask(id int) {
    fmt.Printf("Task %d starting on CPU %d\n", id, runtime.NumCPU())
    // Simulate CPU-intensive work
    for i := 0; i < 1e9; i++ {}
    fmt.Printf("Task %d completed\n", id)
}

func main() {
    numCPU := runtime.NumCPU()
    fmt.Printf("System has %d CPU cores\n", numCPU)

    runtime.GOMAXPROCS(numCPU) // Explicitly set to use all cores
    fmt.Printf("GOMAXPROCS set to %d\n", runtime.GOMAXPROCS(0))

    start := time.Now()

    // Launch CPU-intensive goroutines
    for i := 0; i < numCPU; i++ {
        go cpuIntensiveTask(i)
    }

    // Wait for goroutines to complete (in production, use sync.WaitGroup)
    time.Sleep(5 * time.Second)

    fmt.Printf("Execution time: %v\n", time.Since(start))
}

When GOMAXPROCS > 1 and your system has multiple cores, Go can truly execute goroutines in parallel. However, several factors can still limit actual parallel performance.

Go's Parallelism: Capabilities and Limitations

Go can achieve true parallelism, but with important caveats:

Strengths:

Automatic Scaling: Go automatically distributes work across cores
Low Overhead: Goroutines and channel communication have minimal overhead
Work Stealing: Efficient distribution of tasks to prevent cores from idling

Limitations:

Cooperative Scheduling: Goroutines yield control only at specific points (function calls, channel operations, etc.)
Stop-the-World GC: Garbage collection pauses can temporarily halt all execution
Scheduler Overhead: The work-stealing algorithm adds some overhead
Network-Bound Performance: For I/O-heavy workloads, adding cores may not improve throughput

Benchmarking Parallelism in Go

To evaluate parallelism gains, you can use the testing package with the -cpu flag:

// parallelism_test.go
package main

import (
    "runtime"
    "testing"
)

func BenchmarkComputation(b *testing.B) {
    for i := 0; i < b.N; i++ {
        // CPU-intensive computation
        result := 0
        for j := 0; j < 10000000; j++ {
            result += j
        }
    }
}

Run with: go test -bench=. -cpu=1,2,4,8

Comparative Analysis: Parallelism Across Languages

Language	Parallelism Model	Strengths	Limitations
Go	M:P:G scheduler with goroutines	Easy concurrency, low overhead, work stealing	Cooperative scheduling, GC pauses
Rust	OS threads + async/await	Zero-cost abstractions, fine-grained control	Steeper learning curve, manual synchronization
C++ (std::thread)	Direct OS thread mapping	Maximum performance, precise control	High thread creation overhead, manual resource management
Java	Thread pools, ForkJoinPool	Rich ecosystem, mature tooling	Higher memory overhead, complex thread management
Python	GIL in CPython, multiprocessing	Simple API, good for I/O	GIL prevents true threading parallelism
Node.js	Event loop + worker threads	Excellent for I/O, non-blocking	Single-threaded main loop, callback complexity

Optimizing Go for Parallel Workloads

For CPU-bound tasks requiring maximum parallelism:

Profile First: Use go tool pprof to identify bottlenecks
Tune GOMAXPROCS: Sometimes setting lower than available cores improves performance
Optimize Work Distribution: Divide work into equally sized chunks
Minimize Contention: Reduce lock contention and shared memory access
Consider sync.Pool: Reduce GC pressure for frequently allocated objects
Use Performance-Oriented Packages: Consider github.com/valyala/fasthttp over net/http for web servers

Example of balanced work distribution:

package main

import (
    "fmt"
    "runtime"
    "sync"
)

func processRange(start, end int, wg *sync.WaitGroup) {
    defer wg.Done()
    // Process the assigned range
    sum := 0
    for i := start; i < end; i++ {
        sum += i
    }
    fmt.Printf("Range %d-%d sum: %d\n", start, end, sum)
}

func main() {
    const totalWork = 1000000
    numCPU := runtime.NumCPU()
    runtime.GOMAXPROCS(numCPU)

    var wg sync.WaitGroup
    chunkSize := totalWork / numCPU

    for i := 0; i < numCPU; i++ {
        start := i * chunkSize
        end := start + chunkSize
        if i == numCPU-1 {
            end = totalWork // Handle any remainder in the last chunk
        }

        wg.Add(1)
        go processRange(start, end, &wg)
    }

    wg.Wait()
    fmt.Println("All work completed")
}

When to Emphasize Parallelism in Go

Go's design philosophy prioritizes simplicity and maintainability over raw CPU performance. Consider these factors when deciding how much to invest in parallel optimizations:

I/O-Bound vs. CPU-Bound: For I/O-bound applications, Go's concurrency model already provides excellent throughput without explicit parallelism tuning
Development Time vs. Runtime: Optimize only when performance requirements demand it
Scalability Requirements: Consider future workload growth patterns
Resource Constraints: Memory limitations may favor alternative approaches

Go provides sophisticated concurrency primitives that make parallel programming more accessible than many other languages. While Go can achieve true parallelism, understanding the nuances of its scheduler, the GOMAXPROCS setting, and inherent limitations helps developers make informed architectural decisions.

For most applications, Go's default configuration provides an excellent balance of throughput and simplicity. When optimization is necessary, profiling and benchmark-driven tuning yields the best results.

Whether you're building high-performance web services, data processing pipelines, or distributed systems, Go's approach to concurrency and parallelism offers a compelling foundation for modern software development.

What has been your experience with parallelism in Go? Share in the comments below!

Concurrency in Go: A Rails Developer’s First Encounter with Goroutines

Wilbur Suero — Wed, 05 Feb 2025 13:55:27 +0000

Coming from a Ruby on Rails background, one of the most striking differences when switching to Go is how it handles concurrency. Rails applications often rely on external tools like Sidekiq, Resque, or Thread-based parallelism to manage background jobs and concurrent tasks. Go, on the other hand, has concurrency built into the language itself, using lightweight goroutines and channels.

In this post, I’ll walk through the key differences between Go’s concurrency model and Ruby’s threading model, why Go’s approach is so powerful, and how you can start writing concurrent Go programs.

Understanding Concurrency in Go

Go was designed from the ground up to support concurrency as a first-class feature. The key components of its concurrency model are:

1. Goroutines: Lightweight, Managed Threads

A goroutine is a function that runs concurrently with other functions. Unlike system threads, goroutines are extremely lightweight because they are managed by the Go runtime, not the OS. They start with just a few kilobytes of stack space and grow as needed.

Starting a goroutine is as simple as using the go keyword:

package main

import (
    "fmt"
    "time"
)

func sayHello() {
    fmt.Println("Hello from a Goroutine!")
}

func main() {
    go sayHello() // This runs concurrently
    time.Sleep(time.Second) // Prevent main from exiting immediately
}

Here, sayHello() runs in a separate goroutine. The main function needs a Sleep to ensure the goroutine gets time to execute before the program exits.

2. Channels: Safe Communication Between Goroutines

Goroutines don’t share memory by default. Instead, they communicate using channels, which provide a safe way to pass data between them.

package main

import "fmt"

func main() {
    ch := make(chan string)

    go func() {
        ch <- "Hello, World!" // Send data into the channel
    }()

    message := <-ch // Receive data from the channel
    fmt.Println(message)
}

This approach eliminates many of the pitfalls of traditional multi-threading, such as race conditions and complex locking mechanisms.

How Ruby Handles Concurrency

Ruby’s concurrency model is different. By default, Ruby threads are OS-managed and can be affected by the Global Interpreter Lock (GIL) in MRI (Matz’s Ruby Interpreter). This means only one thread executes at a time, limiting true parallelism.

1. Ruby Threads: OS-Managed and Heavyweight

Ruby supports threads, but they are heavier than Go’s goroutines. Here’s a simple example of spawning a thread in Ruby:

thread = Thread.new do
  puts "Hello from a Thread!"
end

thread.join # Wait for the thread to finish

While this works, Ruby threads consume more memory than goroutines and are subject to OS scheduling.

2. Background Jobs: Offloading Work

Since Ruby’s threading model isn’t great for high concurrency, Rails developers often turn to background job processing frameworks like Sidekiq or Resque, which rely on Redis and external worker processes to handle concurrency.

Example of Sidekiq in Rails:

class HardWorker
  include Sidekiq::Worker

  def perform(name, count)
    puts "Doing hard work for #{name} #{count} times!"
  end
end

HardWorker.perform_async("John", 5)

While these tools work well, they introduce extra dependencies and infrastructure complexity compared to Go’s built-in concurrency model.

Key Differences: Go vs. Ruby Concurrency

Feature	Go (Goroutines & Channels)	Ruby (Threads & Background Jobs)
Lightweight	Yes, goroutines are extremely lightweight	No, Ruby threads are OS-managed and heavier
Managed by	Go runtime	OS scheduler
Parallel Execution	Yes, true parallelism possible	Limited due to GIL in MRI
Built-in Concurrency	Yes, goroutines & channels are first-class citizens	No, relies on third-party solutions like Sidekiq
Memory Usage	Low, goroutines share heap efficiently	High, OS threads are heavier
Scalability	Scales well due to efficient concurrency model	Requires external tools for large-scale concurrency

When to Use Concurrency in Go

Now that you see how Go’s concurrency model differs, here are some real-world scenarios where goroutines and channels shine:

Handling thousands of simultaneous requests in a web server
Streaming data processing (e.g., real-time analytics)
Efficient background job execution (e.g., email processing, batch jobs)
High-performance APIs with non-blocking I/O

Here’s an example of a simple HTTP server in Go that handles requests concurrently using goroutines:

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, %s!", r.URL.Path[1:])
}

func main() {
    http.HandleFunc("/", handler)
    go http.ListenAndServe(":8080", nil) // Runs in a goroutine
    select {} // Keep the program running
}

Each request runs in its own goroutine, making the server highly scalable.

For a Rails developer transitioning to Go, the built-in support for concurrency is a game-changer. Go’s goroutines and channels eliminate much of the complexity involved in traditional multi-threading. Unlike Ruby, where you often rely on background job queues and OS-managed threads, Go lets you write highly concurrent applications with minimal dependencies and better performance.

If you're coming from Rails, expect some initial adjustment when learning Go’s concurrency patterns. However, once you get used to goroutines, channels, and Go’s structured simplicity, you’ll see why Go has become the go-to language for scalable and high-performance systems.

Hash Maps

Wilbur Suero — Sat, 11 Feb 2023 04:48:36 +0000

A hash map, also known as a dictionary or associative array, is a data structure that stores key-value pairs and provides fast access to the values based on their keys. In Ruby, the hash map data structure is implemented as a hash, which is represented by curly braces {} and each key-value pair is separated by a comma ,.

Let's now look at some examples of hash maps in Ruby.

Example 1: Counting occurrences of elements in an array

In this example, we'll create a hash map to count the occurrences of each element in an array.

# Define the array
arr = [1, 2, 3, 1, 2, 3, 4]

# Create a hash map to count the occurrences of each element
counts = {}
arr.each do |element|
  if counts[element].nil?
    counts[element] = 1
  else
    counts[element] += 1
  end
end

# Print the counts
puts counts # Output: {1=>2, 2=>2, 3=>2, 4=>1}

Example 2: Finding the frequency of words in a string

In this example, we'll create a hash map to find the frequency of words in a string.

# Define the string
str = "Ruby is a dynamic, open source programming language with a focus on simplicity and productivity."

# Create a hash map to find the frequency of words in the string
words = str.split(" ")
frequency = {}
words.each do |word|
  if frequency[word].nil?
    frequency[word] = 1
  else
    frequency[word] += 1
  end
end

# Print the frequency of words
puts frequency # Output: {"Ruby"=>1, "is"=>1, "a"=>2, "dynamic,"=>1, "open"=>1, "source"=>1, "programming"=>1, "language"=>1, "with"=>1, "focus"=>1, "on"=>1, "simplicity"=>1, "and"=>1, "productivity."=>1}

Example 3: Grouping elements of an array by their type

In this example, we'll create a hash map to group the elements of an array by their type.

# Define the array
arr = [1, "Hello", 2.0, [1, 2, 3], {a: 1, b: 2}]

# Create a hash map to group the elements of the array by their type
grouped = {}
arr.each do |element|
  type = element.class
  if grouped[type].nil?
    grouped[type] = [element]
  else
    grouped[type].push(element)
  end
end

# Print the grouped elements
puts grouped # Output: {Fixnum=>[1, 2], String=>["Hello"], Float=>[2.0], Array=>[[1, 2, 3]], Hash=>[{:a=>1, :b=>2}]}

Practical Usage of Hash Maps in Ruby

Hash maps are widely used in Ruby for various purposes such as:

Storing configuration settings
Counting occurrences of elements in an array
Finding the frequency of words in a string
Grouping elements of an array by their type
Implementing memoization
Implementing caches
Implementing symbol tables in compilers

In this blog post, we learned about hash map implementation in Ruby and saw several examples of how they can be used in practice. From counting occurrences of elements in an array to grouping elements of an array by their type, hash maps are a versatile data structure that can make our lives as developers much easier.

I hope this article helped give you a deeper understanding of hash maps and how to implement them in Ruby. If you have any questions, comments, or examples of your own, feel free to reach out. I'd love to hear from you!

Remember to share your thoughts, and other implementations in different languages, or simply keep in touch.

Thank you for reading!

Stacks and Queues

Wilbur Suero — Fri, 10 Feb 2023 17:43:15 +0000

Stacks and Queues are two basic data structures used in computer science and software engineering. This post will explain what stacks and queues are, how they function, and how to use them in Ruby. I will also add RSpec tests for the implementations.

Stacks

A stack is a data structure that operates on the Last-In-First-Out (LIFO) principle. This indicates that the last item added to the stack will be the first to be deleted. Stacks are frequently used in programs to keep track of function calls (the call stack) or to reverse the order of items.

Here's an example of a basic Ruby stack implementation:

class Stack
  def initialize
    @elements = []
  end

  def push(element)
    @elements.push(element)
  end

  def pop
    @elements.pop
  end

  def empty?
    @elements.empty?
  end
end

In this implementation, the push method is used to add an element to the top of the stack, the pop method is used to remove the top element from the stack, and the empty? method is used to determine whether the stack is empty.

Here are some RSpec tests for our stack implementation:

describe Stack do
  describe "#push" do
    it "adds an element to the top of the stack" do
      stack = Stack.new
      stack.push(1)
      stack.push(2)
      expect(stack.instance_variable_get(:@elements)).to eq([1, 2])
    end
  end

  describe "#pop" do
    it "removes the top element from the stack" do
      stack = Stack.new
      stack.push(1)
      stack.push(2)
      expect(stack.pop).to eq(2)
      expect(stack.instance_variable_get(:@elements)).to eq([1])
    end
  end

  describe "#empty?" do
    it "returns true if the stack is empty" do
      stack = Stack.new
      expect(stack.empty?).to be true
    end

    it "returns false if the stack is not empty" do
      stack = Stack.new
      stack.push(1)
      expect(stack.empty?).to be false
    end
  end
end

Queues

A Queue is a FIFO (First-In-First-Out) data structure. This implies that the first thing added to the queue will also be the first item withdrawn. Queues are frequently used to create waiting lines or to schedule jobs.

Here's an example of a simple Ruby queue implementation:

class Queue
  def initialize
    @elements = []
  end

  def enqueue(element)
    @elements.push(element)
  end

  def dequeue
    @elements.shift
  end

  def empty?
    @elements.empty?
  end
end

In this implementation, the enqueue method is used to add an element to the end of the queue, and the dequeue method is used to remove the initial element from the queue, and the empty? method determines whether the queue is empty.

Here are some RSpec tests for our queue implementation:

dedescribe Queue do
  describe "#enqueue" do
    it "adds an element to the end of the queue" do
      queue = Queue.new
      queue.enqueue(1)
      queue.enqueue(2)
      expect(queue.instance_variable_get(:@elements)).to eq([1, 2])
    end
  end

  describe "#dequeue" do
    it "removes the first element from the queue" do
      queue = Queue.new
      queue.enqueue(1)
      queue.enqueue(2)
      expect(queue.dequeue).to eq(1)
      expect(queue.instance_variable_get(:@elements)).to eq([2])
    end
  end

  describe "#empty?" do
    it "returns true if the queue is empty" do
      queue = Queue.new
      expect(queue.empty?).to be true
    end

    it "returns false if the queue is not empty" do
      queue = Queue.new
      queue.enqueue(1)
      expect(queue.empty?).to be false
    end
  end
end

I'm thrilled to have shared my knowledge of stack and queue algorithms in Ruby with you. These fundamental ideas are necessary for any computer science student or programmer to understand. Experimenting with these algorithms in Ruby was a great learning experience for me, and I hope it was for you as well.

It's now your turn! I'd love to learn about how you've implemented these techniques in different programming languages. Share your ideas, ask questions, and let's keep growing and learning together. Don't be afraid to post a comment. I'm looking forward to hearing from you!

The most serious programming error to avoid is failing to do thorough testing.

Wilbur Suero — Thu, 09 Feb 2023 05:56:38 +0000

Programming is a multi-step process that requires a lot of problem-solving. Despite the greatest efforts of programmers, errors are unavoidable. Certain mistakes, however, are more common and have a greater impact on the code's functionality and efficiency. In this blog article, we'll discuss one such blunder that every programmer should avoid.

"Not sufficiently testing code" is the one mistake that everyone should avoid.

Code testing is an essential part of the software development process. It aids in the detection of bugs and verifying that the code is functioning properly. On the other side, many programmers either do not test their code at all or do not test it well. This may result in unexpected behavior, bugs, and finally dissatisfied consumers.

To avoid making this mistake, it is critical to establish a rigorous testing approach that tackles all probable scenarios. This includes edge case testing, system compatibility testing, performance testing, and security testing. With the use of automated testing methods, test coverage may be enhanced and the process simplified.

Using the Test-Driven Development (TDD) approach is one of the best techniques to ensure thorough testing. Developers write tests before writing actual code in the TDD approach. This facilitates the specification of exact code requirements and ensures that the code, once built, conforms with those requirements. TDD assists developers in detecting errors early in the development process, making it easier and faster to resolve them.

Finally, fully testing code is a crucial piece in the software development process that should not be overlooked. It can save time and effort while eventually improving the user experience. Avoiding this error will result in a more stable and trustworthy codebase that meets user expectations.

Establishing my own foundation

Wilbur Suero — Wed, 08 Feb 2023 13:12:24 +0000

It's easy for me as a developer to become preoccupied with the technical aspects of my profession, such as mastering new tools and technologies, learning new programming languages, and delivering code that meets specifications. But I've realized how important it is to establish a firm foundation of personal convictions to attain great success in my career.

We'll look at some of the most important personal values for developers and how they might help you thrive and feel happy at work in this post.

Pay close attention to the details.

One of the most important personal qualities for developers is attention to detail. To produce high-quality code, one must pay close attention to the details, guarantee that the requirements are satisfied, and ensure that the code is error-free. When you pay attention to detail, you will be able to produce more dependable and efficient code, and your team and stakeholders will appreciate you for it.

Curiosity and a desire to learn

Curiosity and a desire to acquire knowledge are two other essential characteristics of developers. Because technology and programming languages are always changing, a successful developer must constantly learn and adapt to new tools and techniques. If you like learning, you will be able to stay up with the most recent innovations in your sector and be more productive and efficient at work.

Communication skills

Effective communication is a critical personal value for engineers. When working with team members, stakeholders, and clients, you must be able to effectively communicate your ideas and perspectives. Strong communication skills will allow you to work more effectively with others and convey your thoughts and solutions more effectively.

Accountability and responsibility

Developers are accountable for the code they write, ensuring that it meets quality requirements and performs as intended. When you have a strong sense of responsibility and accountability, you may create a good reputation as a developer by being more dependable and trustworthy.

Empathy and collaboration

To produce high-quality software that meets the needs of users, developers must be able to understand their desires and requirements as well as interact effectively with team members and stakeholders. When you have high collaboration and empathy qualities, you may create long-lasting connections with people and execute effectively in a team.

Flexibility and adaptability

Developers must be able to pivot quickly in response to changing demands, technologies, and workflows. When you have a flexible and adaptive attitude, you will be better capable of managing changes and unanticipated obstacles, and you will also be more effective and productive at work.

Quality obsession

A quest for perfection is another important character trait for developers. Developers must be committed to building code that is reliable, scalable, and secure. If you have a strong desire for excellence, you will be more motivated to do your best work and will be more likely to be recognized and rewarded for your efforts.

Finally, personal values are crucial in determining your success and satisfaction as a developer. By emphasizing qualities such as attention to detail, a love of learning, effective communication, responsibility and accountability, empathy and teamwork, flexibility and adaptation, and a passion for quality, you will be laying the groundwork for a solid career.

These principles serve as a compass for my work, guiding me in making decisions, confronting obstacles, and interacting with others in a way that is true to who I am and what I stand for. By focusing on my principles, I can continue to grow as a developer and advance professionally.

So, whether you're a new developer or an experienced veteran, I encourage you to pause and consider your values. What guiding principles drive your work? What motivates and inspires you to do your best work? By focusing on your own convictions, you may establish a firm career foundation and pave the route for success and fulfillment.