DEV Community: Abdelkader Boudih

Finding the Road Back Home: Building a Clean PostGIS Gem for Rails 8

Abdelkader Boudih — Sat, 31 May 2025 13:58:51 +0000

Or: How I Finally Stopped Having Monkeys in My Codebase

After years of wrestling with spatial data in Rails, my codebase had become a literal zoo—complete with monkeys swinging through monkey patches, chaotic adapter inheritance trees, and compatibility disasters that made upgrades feel like playing Jenga with gorillas. But I've finally escaped the zoo by creating activerecord-postgis, a clean, Rails 8-friendly PostGIS adapter gem. Here’s the real story behind it.

The Problem: Welcome to the Jungle

If you’ve handled spatial data in Rails, you know the pain:

Monkey Patches Everywhere: ActiveRecord was mutated beyond recognition.
Inheritance Chaos: Adapter hierarchies tangled beyond belief.
Module Madness: Gems battling each other through aggressive method prepends.
Upgrade Nightmares: Rails upgrades—from 6.1 to 8—left everything broken.

My own code was a guilty example:

# Monkey patch central
class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter
  include SpatialMixin
  prepend YetAnotherSpatialPatch

  alias_method :old_create_table, :create_table

  def create_table(*)
    # Terrifying spatial logic
    old_create_table(*)
  end
end

Yes, it worked—if you ignored the fragility and constant fear.

Rails 8: Déjà Vu All Over Again

When Rails 8 hit, upgrading was brutally hard—just like Rails 6.1 had been. Each weekend I spent wrestling monkeys felt increasingly wasted. I realized: why keep patching when I could rebuild?

Rebuilding: Not as Simple as it Sounds

Starting fresh didn’t mean I’d just rename st_point to spatial_pt and watch users suffer. Sure, I love clean code, but developers need stability and clear APIs—not surprises from my whims.

With AI shaping documentation, naming APIs oddly is a fast route to frustration. OSS developers (myself included) work at His Majesty’s pleasure—unpaid, unsponsored, no fancy funding. Writing docs was tedious, but now, with AI, I just jot down ideas and let ChatGPT, Claude, or Gemini handle formatting. It's like hosting "AI’s Got Talent," voting on which version makes the semifinals.

The New Way: Rails-Friendly and Stable

The new gem, activerecord-postgis, offers:

1. Rails-Compatible Extensions

PostgreSQLAdapter.prepend(PostGIS::AdapterExtensions)
ActiveRecord::Type.register(:st_point, Type::Point, adapter: :postgresql)

ActiveSupport.on_load(:active_record_postgresqladapter) do
  ActiveRecord::ConnectionAdapters::PostGIS.initialize!
end

2. Column Methods Done Right

# Clear and precise migrations
create_table :locations do |t|
  t.st_point :location, geographic: true
  t.st_polygon :boundary, geographic: true
end

3. Fully Integrated Rails Type System

class Point < Spatial
  def initialize(srid: 0, has_z: false, has_m: false, geographic: false)
    super(geo_type: "point", srid: srid, has_z: has_z, has_m: has_m, geographic: geographic)
  end
end

4. Reliable Schema Dumping

No more schema mysteries:

create_table "locations", force: :cascade do |t|
  t.st_point "location", geographic: true
  t.st_polygon "boundary", geographic: true, srid: 4326
end

A Note on the Past

The old adapters weren’t inherently bad—they were forks of the standard PostgreSQL adapter with spatial types. I myself participated in early monkey patching—not due to lack of skill, but because ActiveRecord wasn't mature enough then to handle such mutations. No bashing the original devs; they did their best with what they had.

Lessons Learned (Again, the Hard Way)

Work With Rails: Going against Rails always makes life harder.
Stable APIs Matter: Exotic naming frustrates users and AI tools.
AI Helps Documentation: Writing docs is now dramatically easier.
Real-World Testing: Gems should thrive in actual apps, not just isolated tests.

The Road Ahead

Future plans include:

Advanced PostGIS features
Performance enhancements
Richer documentation (AI-assisted, naturally)
Spatial data validations

Coming Home

After endless monkey-patching, returning to clean code feels liberating. If you're managing spatial data in Rails, embrace the new, stable approach—your future self (and sanity) will thank you.

activerecord-postgis is ready on GitHub—clean, stable, monkey-free.

Yes, this article is redacted with AI assistance—not generated. Not because I'm farming views, but because English is not my native language.

Building ActiveCypher: When Ruby Learns to Speak Graph

Abdelkader Boudih — Sun, 25 May 2025 23:47:32 +0000

Building ActiveCypher: When Ruby Learns to Speak Graph

Sol 1: ActiveCypher started as one of many frameworks. When you build frameworks for a living, you learn to think differently. Not "how do I solve this problem?" but "how do I solve this category of problems?"

The vision: a universal Cypher translator. If it speaks modern Cypher, we speak back. No legacy support. Your 2012 database with its quirky syntax? Use AI to migrate it or hire a real developer.

Sol 42: Learning graph databases was... educational. Every YouTube short made it look simple. Every documentation page told a different story. Half were 404s. The other half wanted my email for a webinar about enterprise solutions.

Meanwhile, that one developer who memorized the entire OpenCypher spec was waiting to roast anyone who dared implement it wrong. Framework builders live in fear of that person. They keep us honest.

Sol 73: First working version. String concatenation everywhere:

def match(pattern)
  @query_string += "MATCH #{pattern} "
  self
end

It worked. Sometimes. But frameworks cannot be fragile. When someone builds their business on your code, "sometimes" is not acceptable.

Sol 156: The real education came from studying great software. Not tutorials or blog posts, but actual code. How does Arel handle complexity? How does ActiveRecord stay extensible? What makes a framework survive decades instead of months?

The answer was always the same: architecture over features.

Sol 234: Enter the AST. Abstract Syntax Trees are how real compilers work. If it was good enough for GCC, it was good enough for ActiveCypher.

Every Cypher clause became a node:

module AST
  # The simplest node - just a value
  LiteralNode = Data.define(:value) do
    def accept(visitor)
      visitor.visit_literal_node(self)
    end
  end

  # Clean, focused, single responsibility
  class LimitNode < ClauseNode
    attr_reader :expression

    def initialize(expression)
      @expression = expression
    end
  end
end

Clean. Predictable. Extensible.

Sol 301: Clause ordering. MATCH before WHERE. WHERE before RETURN. Simple rules, but how to encode them?

I spent an afternoon choosing numbers. Not random numbers. Not sequential numbers. The right numbers. Numbers that would live in the codebase forever, silent guardians of query correctness.

Framework design is full of these moments. Small decisions that echo through time.

Sol 342: The compiler emerged:

def visit_limit_node(node)
  @output << 'LIMIT '
  render_expression(node.expression)
end

def visit_literal_node(node)
  param_key = register_parameter(node.value)
  @output << "$#{param_key}"
end

Each node knew how to render itself. The tree structure made invalid queries impossible. This is what separates frameworks from scripts.

Sol 423: Production deployment. ActiveCypher now sits between our applications and both Memgraph and Neo4j. Like a couples therapist, it helps them communicate despite their differences.

query = Cyrel.query
             .match(Cyrel.n(:person, :Person))
             .where(Cyrel.prop(:person, :age) > 25)
             .return_(:person)

# Same query, two databases
memgraph_adapter.run(query.to_cypher, query.params)
neo4j_adapter.run(query.to_cypher, query.params)

Sol 456: Someone asked about supporting an older Cypher syntax. I pointed them to our philosophy: latest protocols only. The graph database world moves fast. Supporting legacy means moving slow.

Harsh? Maybe. But frameworks must choose: support everything poorly or support the future well.

Sol 512: The AST design proved portable. When we need more speed, the same tree structure will work in Go. Or Rust. Or yes, even COBOL (though that remains a theoretical exercise).

The numbers I chose for clause ordering? They travel with the design. Some decisions transcend language boundaries.

Sol 567: Framework building is lonely work. No pull requests on experimental code. No contributors until it proves itself. Just you, the spec, and the fear of that one developer who knows every edge case.

But when it works? When production systems rely on your abstraction? When complex becomes simple? That is why we build frameworks.

Sol 580 (4 months ago): RedisGraph announced its deprecation. "Official support for RedisGraph will end on January 31, 2025. After this date, commands will be disabled on Redis Enterprise Cloud, and no further support will be provided across platforms."

The architecture of Redis was never ready to receive all that graph data. I had to remove the RedisGraph adapter. Another vendor drops out. This is why frameworks must be vendor-agnostic. Databases come and go. Standards endure.

Sol 640 (2 months ago): Ruby developers started complaining. The neo4j driver had stopped working in its recent version. Vendor lock-in strikes again. It reminded me of the ElasticSearch gem story, where they nuked the adapter to prevent OpenSearch usage.

I contacted the Memgraph team. They were different. They believed in standards. They wanted developers to have choices.

This reinforced my vision: something standard. Something where an AI assistant would not give conflicting solutions because two vendors decided to diverge. One Cypher. Many databases. No politics.

Final Log Entry: ActiveCypher runs in production. It handles real queries for real applications. It speaks fluent Cypher to multiple databases. It refuses to support your legacy syntax.

More articles will come as I learn more. Framework building is never done. There is always another edge case, another optimization, another database claiming Cypher compatibility.

But for now, ActiveCypher does what it promised. It helps Ruby speak graph. Cleanly. Reliably. With carefully chosen numbers ensuring everything happens in the right order.

Even if those numbers have their own secret significance.

Especially then.

Smarter RAG Systems with Graphs

Abdelkader Boudih — Tue, 06 May 2025 18:47:18 +0000

Introduction: So You Want Your LLM to Stop Guessing

Everyone’s buzzing about Retrieval-Augmented Generation (RAG) like it’s the second coming of AI engineering. And honestly? It kinda is. Your large language model is excellent at confidently making things up—because it doesn’t actually know anything beyond whatever data it was last trained on (hello, 2023).

That’s where RAG comes in: bolting on real, external knowledge so your LLM stops hallucinating and starts reasoning.

But here’s the thing: knowledge isn’t just about facts. It’s about how things connect. And when relationships matter, you don’t want a flat file or a relational torture device. You want a graph.

Enter the graph database. Specifically: Memgraph—a real-time, in-memory graph database that feels like it was built by actual humans for other actual humans, not for a distributed cluster of suffering.

And now, before someone @ me:

I am not a Memgraph employee.

I’m not paid by Memgraph.

I still stick Post-its on my fridge and call it MemFridge.

I'm not being forced by Memgraph to write this article after I pushed the Epstein files into their trial database.

I'm not locked in a basement in Zagreb, Croatia—though if you squint, Maghreb kind of sounds like it.

I'm actually writing this while nursing a sore throat and reflecting on whether the AI apocalypse will arrive before I find decent cough syrup.

I’m just a person who builds with RAG systems, has trust issues with stale data, and wants tools that don’t make me cry.

So let’s get into why Memgraph is great for building fast, intelligent, less-fake AI systems—and how it fits into a modern RAG stack without making you sell your soul to Kubernetes.

Graph Databases in RAG: Where They Fit

Let’s sketch out a typical RAG architecture:

Your vector DB fetches semantically relevant chunks. Your graph DB like Memgraph injects contextual relationships, hierarchy, metadata, and freshness. Combine both, and your LLM isn’t just guessing—it’s understanding.

Use cases:

Link authors, topics, and papers in a knowledge graph to avoid hallucinations.
Show product recommendations in context ("people who viewed this also viewed...").
Trace real-time fraud patterns across entities.

Vector search gives you "what." Graph search gives you "why." And Memgraph gives it to you in milliseconds before the user attention span is over.

Memgraph’s Engine: Performance Meets Simplicity

From a user's perspective, Memgraph provides modes for different scenarios:

1. In-Memory Transactional Mode (Default)

Need speed? This is the Sonic Boom mode.

Stores all data in RAM.
Blazing-fast traversals for multi-hop queries.
Perfect for low-latency, high-throughput RAG pipelines.

Think real-time recommendations, fraud detection, or live knowledge graphs.

2. In-Memory Analytical Mode

Optimized for running complex analytical queries and algorithms.
Great for heavy-duty graph computations, batch processing, and analytics.

3. On-Disk Transactional Mode (Experimental)

Data stored primarily on disk to handle larger graphs.
Currently experimental, with lower query performance.

Use this mode cautiously—ideal if your graph outgrows RAM, but be aware of the trade-offs.

Streaming (Always Fresh Data)

Streaming isn't technically a storage mode—it's your data ingestion method, compatible with any of the above modes.

Direct Kafka and Pulsar integrations.
Ingest new data as it arrives.
Keeps your knowledge graph updated without painful rebuilds.

Imagine your knowledge graph evolving as users interact. Your RAG system stays fresh. Just stream, merge, respond.

Developer Experience: The Stuff That Actually Matters

Memgraph is built like someone actually thought about the person using it. You get:

Cypher support: Same query language as Neo4j. No learning curve if you’ve touched a graph before.
Prototype-level support for ActiveCypher: A lightweight ORM inspired by ActiveRecord for Rubyists who like danger.
Memgraph Lab: A GUI that doesn’t make your eyes bleed. Visualize, explore, debug.
Docs that don’t insult you: Actually helpful. Actually updated.
Browser-based Playground: No install. Just run and play.

You know how most databases feel like they were built by a committee in 1997 in LaTeX?

Memgraph feels like it was built by someone who’s built an actual app before.

Query Examples: Because Words Are Cheap

// Get related topics in 2 hops
MATCH (topic:Concept {name: 'Graph Databases'})-[:RELATED_TO*1..2]->(other)
RETURN other.name LIMIT 10;

class Concept < ApplicationGraphNode
  property :name, type: :string
end

# Inserting a concept
Concept.create(name: "Vector Embeddings")

Integration Into a RAG Stack

You can slot Memgraph into your AI stack easily:

Combine with vector DBs like pgvector or even use Memgraph's built-in vector search.
Serve via REST, WebSockets, or Bolt.
Extend with custom graph procedures (in your language of choice, because sanity matters).

Want to update your graph as new documents are embedded? Use streaming integrations.

Want to prioritize certain paths based on weights? Use Cypher and built-in graph algorithms.

Want to sleep? Use snapshots and WALs with in-memory modes, but remember—data still lives in RAM.

What Could Go Wrong? (Spoiler: Not Much)

Graph too big for RAM? You could try the experimental on-disk mode, but expect lower performance.
Need high availability? Memgraph supports replication and High Availability (Enterprise Edition).
Want vector-native features? Memgraph's built-in vector search works well for smaller embeddings. For huge embeddings, pair with a dedicated vector DB (preferably one that doesn’t have a 9-figure marketing budget).

It’s not magic. It’s just designed like it’s 2025 and not 1995.

Final Thought: Just Try It

If you’re building RAG systems or doing anything graph-related, and you want your queries fast, your setup sane, and your dev experience not soul-crushing—give Memgraph a spin.

Try it for free. It runs in Docker. It has a Playground. It might even make you like databases again. They have a cloud solution that doesn't force you to hire that guy who knows "Kubernetes" after watching a Fireship video.

https://memgraph.com

Prompts in MCP: Preloaded Sanity, Not Just Fancy Slash Commands

Abdelkader Boudih — Tue, 06 May 2025 12:52:30 +0000

TL;DR:

MCP Prompts aren’t just templates. They’re server-defined, user-discoverable scripts designed to prevent your AI from doing exactly what it would do if left to its own devices: improvise badly. Prompts let you say, "Hey AI, do this very specific thing. And please don’t freestyle it into a motivational poem or a crime."

🎭 What Are Prompts (and Why Should You Care)?

Prompts in MCP are like scene instructions for your AI. Without them, the model shows up like an unpaid improv actor—confident, enthusiastic, and terrifyingly unsupervised.

With prompts:

You say: "Summarize this changelog."
It doesn’t: "Rephrase it as a love letter from a tired developer to their codebase."
You say: "Generate a git commit."
It doesn’t: "Write a haiku about file deletions."

🧩 Anatomy of a Prompt (or, How to Stop Guessing)


{
  "name": "generate-git-message",
  "description": "Write a concise Git commit message",
  "arguments": [
    {
      "name": "changes",
      "required": true
    }
  ]
}

No guessing. No passive-aggressive comments from the model. Just a prompt, an argument, and an obedient response like:

"Fix off-by-one error in loop. Stop breaking things, Jerry."

Okay, maybe still passive-aggressive. But helpful.

🔎 Prompt Discovery (But Not By the AI, Calm Down)

Prompts aren’t discovered by the LLM. Let’s squash that fantasy right now.

Here’s how it really works:

The client calls prompts/list from the MCP server.
It decides what prompts to surface in the UI (like slash commands, menus, or keyboard shortcuts).
When a user selects one, the client fetches it via prompts/get, fills in the arguments, and passes it along to the AI as pre-structured messages.

The AI doesn’t decide which prompts to use. It doesn’t go browsing. It doesn’t have agency. It gets what it’s given—like a helpful chatbot on a tight leash.

The session is maintained by the client, not the LLM. The LLM doesn’t even know what a session is unless you tell it. It just lives in the bubble the client builds around it, like a very powerful goldfish.

📦 Context Injection (a.k.a. Prompts With Homework)

Let’s say you want your AI to analyze logs and review a code file. Don’t just paste it all into the text field like a digital junk drawer. Use a structured prompt:


{
  "role": "user",
  "content": {
    "type": "resource",
    "resource": {
      "uri": "file:///main.py",
      "text": "...",
      "mimeType": "text/x-python"
    }
  }
}

Then follow up with:

“Now compare that to this server log that looks like it’s been cursed.”

Your AI will know what’s going on, and for once, it won’t hallucinate that your log is a philosophical riddle.

🤹 Multi-Turn Prompts: When You Want a Conversation, Not a Monologue

A basic prompt says: “Write a commit message.”

A multi-turn prompt says:

"What's the bug?"

"What have you tried?"

"How many times have you cried about it?"

These interactions guide the user and the model like a therapist gently walking you back from the edge of another systemd rant.

⚠️ Prompt Security: Protect Users from Themselves (and Your LLM)

Let’s be honest, if a user can pass custom input to a prompt, they will find a way to:

Inject something malicious
Break the formatting
Ask the AI if it's "feeling okay today" and then have a 2,000-token spiral about the nature of free will

So sanitize. Validate. Rate-limit.

Just because it's a prompt doesn't mean it's safe. This isn't a spa day—it’s a potential shell command disguised as a “file analysis request.”

💥 Real Examples (for the Delightfully Deranged)

🔹 `debug-error`


{
  "name": "debug-error",
  "arguments": [{ "name": "error", "required": true }]
}

Input: "Cannot read property 'length' of undefined"

Output: "Ah, JavaScript. Undefined chaos again. Let’s walk through the fire together."

🔹 `generate-apology-email`


{
  "name": "generate-apology-email",
  "arguments": [{ "name": "incident", "required": true }]
}

Input: "Deployed broken code to production on Friday at 4:55pm"

Output:

"Dear team, I have made choices. None of them good. Here's how I plan to fix the chaos I unleashed..."

🔹 `name-my-startup`


{

  "name": "name-my-startup",
  "arguments": [{ "name": "idea", "required": true }]
}

Input: "AI-powered cat feeder with mood tracking"

Output: "Purrlytics™ — Data-Driven Feline Satisfaction" (You're welcome.)

✅ Conclusion: Prompts Keep You Honest

MCP Prompts are the difference between:

AI that works with context, structure, and sanity
And AI that responds to "summarize this changelog" with "Here’s a poem about endings"

They let you scale functionality, standardize interactions, and—most importantly—prevent your AI from becoming a dangerously confident improv artist with API keys.

So next time someone says “we don’t need structured prompts,” just remember: that’s how you end up with an AI that flirts with your infrastructure monitor.

If You Think MCP Is Just a Tool Registry, You’re Missing the Point

Abdelkader Boudih — Tue, 06 May 2025 12:05:26 +0000

TL;DR:

If you think Model Context Protocol (MCP) is just a boring tool registry, think again. It’s more like giving your AI a Swiss Army knife—with a concierge who hands over exactly the right tool at exactly the right moment. Each AI session is isolated, reducing chaos and preventing leaks, and everything is logged like a black box flight recorder.
In short: MCP is not a dumb proxy. It’s structured autonomy with context-aware safeguards.

🛠 The Swiss Army Knife Myth

Let’s get one thing straight: MCP is not just a static tool registry. Sure, it lets your AI discover available functions or APIs—but calling it a registry is like calling a Swiss Army knife “just some blades.”

What sets MCP apart is its context-driven, session-specific dynamic tooling. Your AI doesn't sift through a buffet of random tools—it gets a curated menu based on who the user is, what the session needs, and what permissions apply.

This means:

Admins might get one toolset.
Guests get a safer, restricted subset.
Your AI doesn’t need to memorize every API ahead of time or rely on brittle if-else spaghetti. It discovers tools at runtime, adapting in real-time.

🧪 One Session, One Sandbox: Isolation That Actually Works

Each session under MCP runs in a clean, isolated environment. Think of it like astronauts in separate Mars habitats. If one habitat gets messed up, it doesn't affect the others.

Each session has:

Its own memory and context
Its own standard input/output
Its own execution state

This means tools triggered in one session can’t leak into another. One user’s wild API experiment won’t ruin someone else’s workflow or expose sensitive data. It also makes debugging beautifully simple—no session-crossing nonsense to worry about.

📼 Session Logs: JSON-RPC as Black Box Recorder

MCP sessions include structured logging of all JSON-RPC calls, which turns each session into a transparent, replayable story. You’ll see:

What tools were discovered
Which were invoked
The exact inputs and responses
Any glorious, flaming errors

This isn’t just for post-mortems when something catches fire. These logs are gold for proactive monitoring, too. Set alerts. Spot suspicious patterns. Roll back or quarantine tools if needed.

🚨 Dumb Proxies: Don’t Be That Person

Now, let’s talk about what not to do.

A dumb proxy is when you simply expose all your tools to the AI with no context, no control, and no oversight. You just wire everything up and hope for the best. The model tries every tool it sees, errors explode like fireworks, and you learn very quickly what not to do.

You might think:

“Why not just let the AI figure it out? It’s smart!”

Right. And toddlers are good at juggling chainsaws.

Without isolation, permissions, or dynamic context, you’re setting up a system where the AI might:

Delete important data
Spam endpoints with bad input
Leak internal notes to public channels
Order 1,000 pizzas because you said you were hungry. (True story—probably.)

MCP, by contrast, enforces proper boundaries and only surfaces the tools that make sense in a given moment. It’s like replacing your toddler-chainsaw problem with a trained sous-chef who knows exactly when to use the paring knife.

✅ Conclusion: Stop Calling It a Registry

MCP is not a registry. It’s not a dump truck of APIs. And it’s definitely not a dumb proxy.

It’s a dynamic, context-aware protocol that acts like:

A Swiss Army knife with an expert concierge
A Mars-grade isolated sandbox per session
A JSON-RPC black box for every decision your AI makes

If you treat it like just another plugin system, you’re missing the point—and probably setting yourself up for a fun little disaster.

So the next time someone tells you MCP is “just a registry,” go ahead and roll your eyes. Then explain, calmly, that you’d rather not hand a toddler a loaded API ever again.

For more in-depth info, check out the official MCP documentation. Happy hacking.

The Rise of 'Vibe Packages' in Open Source Development

Abdelkader Boudih — Sat, 12 Apr 2025 14:35:10 +0000

When AI-Driven Speed Meets Open Source Ecosystems

In the world of open source, a strange new trend has emerged: the rise of “vibe packages.” These are libraries, SDKs, and API wrappers that pop up almost overnight – often crafted by enthusiastic junior developers riding high on AI code generators. They appear in droves on GitHub and package registries, tackling every API or service imaginable.

At first glance, this sounds like a win for developer productivity and open source abundance. Who wouldn’t want more code available to solve problems? But scratch the surface, and you’ll find a Wild West of unlicensed copy-paste code, half-baked implementations, and forgotten repositories. In this post, we’ll explore what vibe packages are, why they’re spreading (especially in niche programming languages), and how the community is reacting – with equal parts excitement and eye-rolling.

What Are "Vibe Packages"?

“Vibe package” isn’t an official term – it’s a tongue-in-cheek label for the flood of quickly published libraries generated more for the vibe of coding than for any real production need.

These packages are often:

Created by junior developers with the help of AI coding tools.
Thin wrappers around APIs with minimal (or no) testing.
Rebranded copies of other projects, sometimes with the original comments and todos still in place.
Missing licenses or published with inappropriate ones.

The result? A sea of packages that look shiny but are often brittle, shallow, or ethically dubious.

Niche Language Ecosystems: From Curated to Cluttered

The impact is especially pronounced in smaller ecosystems like Fortran, Nim, or even Elixir. These languages used to have few but carefully maintained libraries. Now? API wrappers and SDKs appear for every new hot service—whether or not there’s a real need.

For example:

A wave of unofficial OpenAI SDKs popped up in Dart, Zig, Rust, even Fortran.
Some projects are just AI-generated regurgitations of API docs.
Entire structures are copy-pasted across languages with little adaptation or review.

Where once developers had to build something from scratch, now they have to sift through clones and half-formed libraries.

Case Study: The API Wrapper Gold Rush

When OpenAI released their API, unofficial wrappers flooded GitHub in days. Dozens of "OpenAI for X" libraries emerged, often indistinguishable from each other and rarely production-ready.

One example: a Fortran wrapper for OpenAI's API. It was impressive on paper—but under the hood, it was a minimal HTTP layer with zero error handling and no community engagement.

Other wrappers:

Skipped licensing.
Borrowed structure and code directly from existing SDKs.
Were generated, posted, and abandoned all in a weekend.

The result? A cluttered ecosystem that confuses users, duplicates effort, and disincentivizes original maintainers.

Community Reactions and Consequences

Original Maintainers: Why Bother?

For those who spent months building thoughtful libraries, it’s disheartening to see a thin GPT-generated wrapper get more stars. It leads to:

Burnout.
Reluctance to publish early versions.
Extra work policing licenses and clones.

Junior Devs: Confidence on Shaky Ground

Publishing a library with AI’s help feels empowering—but it can lead to:

False confidence in one's skills.
Poor understanding of the codebase.
Ethical gray areas when listing it on a resume.

AI is a great assistant—but claiming generated code as your own without understanding it invites trouble down the line.

Companies: Dependency Roulette

An engineer finds a new wrapper that looks solid and integrates it into production. But:

No tests.
No maintenance.
Security holes or leaks appear months later.

Many vibe packages don’t survive real-world stress.

Seasoned Devs: Holding Back

Some are choosing not to release unless the project feels “enterprise-ready,” just to avoid being lumped in with low-effort clones.

Others take the mentorship route: filing issues, offering feedback, or guiding enthusiastic newcomers into creating sustainable packages.

Conclusion: Navigating the Vibe Package Era

We’re in a golden age of code generation—but it’s also the noisiest. Developers of all skill levels are publishing more, faster. That’s not inherently bad. But if quantity outpaces quality, we risk drowning in mediocrity.

If you’re a junior dev:

Publish, but learn what you’re publishing.
Take feedback seriously.
Use AI as a stepping stone, not a crutch.

If you’re a maintainer:

Lead by example.
Offer guidance, not gatekeeping.
Consider new strategies for building and maintaining community trust.

If you're part of a team:

Vet your dependencies.
Check for licenses, commits, tests, and maintainers.
Don’t trust the README at face value.

AI has made it easier to ship. But it’s still up to us to build wisely, publish responsibly, and guide others in doing the same.

Because in the end, not all that glitters is gold. Sometimes it’s just polished copy-paste. And the best vibe? One that lasts.

LLMs and the Ossification of APIs: Are We Stuck with Prehistoric Patterns?

Abdelkader Boudih — Fri, 11 Apr 2025 12:48:10 +0000

When AI Coding Assistants Influence API Design in Ruby

The Ruby community has always valued elegant API design and idiomatic code. But recently, a new factor is subtly influencing how our APIs evolve: AI coding assistants. Tools like GitHub Copilot and ChatGPT have become our AI pair programmers, trained on millions of lines of existing Ruby code. They excel at recognizing and reproducing common coding patterns.

While this speeds up development, it also introduces an unintended side effect: API designs are becoming "fossilized" into their current form, as deviations from the norm are discouraged by the very tools meant to help us.

In this post, I'll explore how Large Language Models (LLMs) and AI code assistants can create inertia around API design. I focus on how these tools reinforce existing patterns, making any novel or unconventional API feel "wrong" or hard to reason about, even if it's technically correct.

The goal isn't to vilify AI helpers (they're incredibly useful! I argue with Grok and Claude on a daily basis) but to raise awareness of this subtle problem and encourage reflection in the Ruby community.

The Rise of AI Pair Programmers in Ruby

AI-assisted development has quickly gone from novelty to normalcy. GitHub Copilot, ChatGPT, Claude and similar tools are now integrated into editors such as VSCode, Cursor, Zed, Windsurf, JetBrains and Notepad (with a subscription), offering autocomplete or even generating entire blocks of code.

These assistants are trained on vast repositories of open-source code, which means they've learned the dominant patterns and idioms of languages. For Ruby, they know Ruby on Rails conventions, popular gem APIs, style guide preferences, and so on.

This has obvious benefits: they can produce code that looks right at a glance. For standard tasks, the AI's output often adheres to community style and best practices because it's copying from what most developers do. It's like having an encyclopedic junior developer who always codes in a textbook style.

However, this strength is also a weakness. LLMs are inherently conservative in that they regurgitate patterns from training data. When faced with something new—be it a cutting-edge library, a new framework, or an unconventional API design—these tools struggle.

I recently tested Replit to see if it supports a UI framework I like, Flowbite. The LLM acknowledged it was familiar with Flowbite, but then simply aliased shadcn in the import statement and proceeded with its previous patterns.

AI code assistants are superb followers of convention. But what happens when we need to break convention or update it? This is where API ossification comes in. Developers might unwittingly start treating the AI's suggestions as the path of least resistance, sticking to familiar patterns to keep the AI (and by extension themselves) comfortable.

API Ossification: When Patterns Become a Prison

In software, "ossification" refers to something becoming rigid and resistant to change. For APIs, ossification means the design and usage patterns harden such that breaking away from them is very difficult.

Historically, API ossification is a concern in long-lived protocols (like TCP/IP) where entrenched assumptions make evolution difficult. Now we're seeing a form of it in application-level code, reinforced by AI training.

If we only ever accept what the AI suggests, we risk reinforcing designs that may not be optimal, just common. Our APIs stop evolving; they simply repeat the past. How does this manifest in day-to-day coding?

First, deviations feel "incorrect." When we encounter or attempt a different approach that the AI isn't expecting, it often won't autocomplete it nicely. This lack of affirmation can make a developer second-guess the approach. We've grown used to that little Copilot gray text completing our thoughts. If it doesn't appear (or shows something off-base), we might assume we're doing something wrong. The result? We retreat to a pattern that Copilot recognizes, because its suggestions give a subconscious nod of approval.

Second, tooling feedback reinforces the norm. It's not just the AI autocompletion. Our linters, formatters, and other static analysis tools are built with certain expectations. They might flag code that, while valid, is unusual. When our tools constantly underline something in yellow or throw warnings, it wears on our confidence in that code.

Third, perceived correctness can override actual correctness. We humans are highly visual and context-driven. If code looks like what we're used to, we instinctively trust it more. Conversely, code that looks "odd" is suspect. AI suggestions amplify this—if the AI writes a snippet that looks polished, we assume it's correct. If we write something ourselves that the AI didn't suggest, and especially if it triggers lint warnings, we start to doubt ourselves, maybe even start considering a career in farming or fishing.

The danger is that perceived correctness (following familiar patterns) overrides technical correctness. An API design could be perfectly valid or even superior, but if it doesn't resemble what we've seen before, developers may resist it.

Case Study: When Official APIs Defy Convention – Anthropic's Ruby SDK

A recent example of new-vs-old style friction comes from the Anthropic API (the company behind Claude). For a while, Ruby developers had access to Anthropic's AI via an unofficial gem by Alex Rudall.

This community gem, initially called anthropic (later ruby-anthropic), was built in a very Ruby-ish way. It followed conventions that Rubyists expect: configuration via a block, plain old Ruby objects, and using Faraday for HTTP under the hood. Faraday is the de facto standard HTTP client adapter in Ruby, and the gem's documentation explicitly references Faraday::Errors, confirming it uses Faraday for network calls. This choice made sense—Faraday is widely used, integrates with middleware for logging or retries, and any Rubyist using the gem would feel right at home with its behavior.

Fast forward to now: Anthropic released an official Ruby SDK (packaged as the anthropic gem, with Alex Rudall even donating the gem name to them).

Official support is great news, but the API design and implementation of the official SDK took a lot of Rubyists by surprise. Instead of following the patterns set by the unofficial gem (and other Ruby API wrappers), the official SDK introduced a new client API that feels influenced by other languages like Go or Java. It was decided to reduce dependency.

For instance, it doesn't use Faraday at all—it comes with its own HTTP adapter and connection pooling system, more like what you'd see in a Go HTTP client or a Java OkHttp setup, rather than a typical Ruby script that just uses Faraday to allow adapter selection. The README notes that each client manages its own HTTP connection pool for concurrency, a concept more common in lower-level languages or explicitly concurrency-oriented Ruby code.

The surface API also has subtle differences. The unofficial gem had a very idiomatic usage, e.g., using class methods like Anthropic.messages.create(...) with hash options, similar to how something like the Stripe Ruby SDK or ActiveRecord might work. The official SDK, by contrast, might require instantiating a client (Anthropic::Client.new) and then calling methods on it (e.g., client.messages.create(...)). It also introduced a typed interface (using Sorbet RBI/RBS for type checking).

From a purely technical standpoint, there's nothing wrong with the official SDK's approach. In fact, it might offer performance and reliability benefits (like thread safety and fewer GC churn by reusing HTTP connections).

Today, however, such changes come with a new kind of friction: our AI copilots and established habits push back against the unfamiliar design. A developer trying out the official Anthropic SDK might encounter a few pain points:

First, muscle memory & AI suggestions. If they used the older gem (or even the OpenAI Ruby gem, which is similar in style), they might start coding by habit. They type Anthropic. and perhaps Copilot suggests Anthropic.messages.create(...) because that pattern was common in the unofficial SDK. But in the official SDK, maybe you need to do client = Anthropic::Client.new first and use that instance.

Second, deviation from community tools. Not using Faraday means the official SDK might not seamlessly fit into middleware stacks that Ruby devs use (like instrumenting Faraday for logging or metrics). Meanwhile, an AI tool likely has seen tons of Faraday usage and zero of whatever internal HTTP client Anthropic uses, so it won't suggest how to add a logging interceptor or retry logic on this new client.

Third, cognitive dissonance in style. Ruby developers pride themselves on APIs that read naturally. A non-idiomatic style stands out. If the official client has method names or patterns that feel imported from Java/Go, a developer might initially think "am I using this right? It feels clunky."

The end result is that developers may hesitate to adopt the official SDK or fully embrace its new patterns. Some might stick with the older community gem because it's familiar and all their tools support it. Others might use the official one but internally wrap it in something that feels more like Faraday to satisfy their own sense of normalcy—you can see that with 100 implementations around MCP specification in JavaScript with mcp-framework taking the lead

Case Study: When AI and Linters Mislead – The `render` Method Confusion

It's not only big SDK designs that face this pattern inertia; even small design choices in a gem can cause confusion when they collide with established meanings. I ran into this firsthand with a gem I authored called action_mcp. This gem allows building prompt/response flows and "tools" for LLMs in a Rails application following the MCP spec.

In this domain, it made perfect sense for me to define a method called render – because the gem is about rendering AI responses (text, images, audio, resources, etc.) as the output of an LLM tool or prompt. So inside an ActionMCP::Tool class or prompt, you might see something like:

# inside a tool's perform method
render(text: "Calculating #{a} + #{b}...")
render(text: "The sum is #{sum}")

What could be more reasonable? The method name render perfectly describes what it does: it takes content (or an error or image) and renders it into the response that will be sent back via the LLM.

However, the moment I started using this in a Rails project with GitHub Copilot enabled and RuboCop linting my code, I realized I'd stepped on a linguistic landmine. Both Copilot and RuboCop seemed to assume render meant ActionController's render method.

In Rails, render is a heavily used method to render views or JSON, etc., within controller actions. My gem's render is something entirely different (it doesn't render a view; it produces an AI message), but the tools don't know that context.

GitHub Copilot's reaction: Whenever I wrote a render( call in my tool class, Copilot kept trying to autocomplete it with typical controller options – e.g., it would suggest things like render json: ... or render template: ... because it's seen thousands of controllers do that. It might even try to close the method with an end early, thinking I was in a controller action rendering and done.

RuboCop's reaction: RuboCop also got confused. It might have rules around controllers using render properly. I saw warnings about the arguments to render or the context of render because RuboCop assumed I was calling ActionController::Base#render incorrectly.

The combination of Copilot's misguided suggestions and RuboCop's warnings created a strong impression that I was doing something "bad," even though I knew logically that ActionMCP::Tool#render was fine. I caught myself momentarily considering, "Should I rename that method to something else, just to avoid these hassles?"

That right there is the ossification pressure in action! The AI and lint tools were nudging me to rename or redesign a perfectly valid API in my gem, purely because it clashed with a more common meaning of render.

This demonstrates how LLMs can make correct code feel incorrect. The code looked like something else to the AI, so it kept telling me to change it. If I didn't have confidence in my intent, I might have listened.

The New Challenge: Balancing Innovation and Expectation

These case studies underline a new challenge for Ruby (and likely all programming ecosystems): How do we continue to innovate in API design under the watchful eye of AI "mentors" that learned from the pre-history? It's a strange question to face. In the past, introducing a new library or pattern required convincing other developers; now, it seems we also have to convince the AIs (indirectly, by retraining or by user feedback) – or work around them. Maybe I should become an AI DEV advocate and spend my days tweeting motivational text until Grok learns it.

Let's break down what's happening:

First, developer expectations are AI-shaped. As developers, our expectations are now partly formed by what AI assistants deem likely. If every time you type code, Copilot suggests a certain completion, you begin to expect that pattern in your code. When an API deviates from that pattern, it's jarring. The Anthropic SDK story is a case in point: the community might have been ready to accept a new approach, but their expectations were anchored by the unofficial gem and similar libraries.

Second, toolchain feedback loops. Linters and other automated feedback tools encode rules – sometimes flexible, sometimes rigid. When those rules collide with a new design, they produce warnings or errors. We have multiple layers of "automated opinions" now: the AI that writes the code and the linter that reviews it. If both are trained on the same corpus of existing code, they'll likely agree on what's normal. So a new API design gets flagged from two sides, doubling the developer's impression that it's wrong.

Third, "looks correct" vs "works correctly." If an API design itself is different, an AI might produce code that looks right but actually targets a different API. For example, had I not known better, I might accept Copilot's suggestion to call render json: ... in an ActionMCP tool – which would totally not do what was intended, because my render doesn't take a :json option.

Fourth, misleading documentation & learning resources. Many of us learn via googling error messages or copying code from StackOverflow. If the community is slow to write about a new API, AI might surface older documentation or Q&A that no longer applies. For instance, developers searching for "Anthropic Ruby API example" might find blog posts or Q&As related to the unofficial gem (with Faraday) and use those, not realizing the official SDK works differently.

The sum of these pressures is that API designers might feel discouraged from deviating too far from established patterns. If you're a Ruby gem author in 2025, you have to wonder: will my target audience be comfortable with this design, or will their AI tools rebel and tag me persona non grata? Do I pick the novel approach that might be better, or do I stick with conventions so that adoption is smoother?

It's almost like we have a new stakeholder in API design, not just the end-user and the maintainer, but the AI intermediary that needs to "get it" for the end-user to have a good experience. For the Ruby community, which historically has embraced DSLs and unconventional but elegant solutions, this is a cultural shift.

Imagine if something as innovative as Rails itself, with all its domain-specific magic, were introduced today. Would Copilot constantly fight DHH while he was typing out has_many :through => ... in 2004? Would linters scream about missing class definitions for methods created by method_missing? (They often do, even now.) Yet Rails succeeded in part because the community was willing to learn a new paradigm.

Conclusion

AI assistance in coding is here to stay, and overall, it's a positive development for productivity. But it comes with the subtle side effect of reinforcing the status quo. APIs and coding styles could ossify, not because of technical limitations, but because deviation triggers confusion – in our tools and then in ourselves.

As Ruby developers and library authors, we should be mindful of this dynamic. The next time an official SDK or a new gem comes along with a bold design choice, check if any resistance you feel is due to genuine technical critique or just the discomfort of the unfamiliar amplified by AI-trained expectations.

We should strive to remain critical thinkers: sometimes the "weird" new way might actually be an improvement, and we shouldn't dismiss it outright because our AI buddy hasn't seen it before. On the flip side, when designing APIs, it's worth considering how autodidactic tools perceive your API. It sounds odd, but you might ask, "If a newbie relies on Copilot to use my library, will it help or hinder?"

This doesn't mean never breaking convention, but it means you may need to educate both the community and the AI. That could be through very clear documentation, examples (so that they hopefully get into the training data), or even collaborating with lint tool authors to create custom rules that understand your DSL.

Ultimately, awareness is the first step. The Ruby ecosystem has thrived on expressiveness and innovation. By recognizing the ossification pressure from AI, we can take steps to ensure we don't become stuck in old ways. With conscious effort, we can have the best of both worlds: enjoying AI assistants for the routine stuff, while keeping our minds open to new ideas that break the mold.

Rails Version Management with Rails AppVersion

Abdelkader Boudih — Thu, 02 Jan 2025 21:14:58 +0000

Rails AppVersion provides a standard way to handle version and environment information in Rails applications. It eliminates the need for custom version management solutions while providing useful conventions for error tracking, caching, and deployment verification.

Key Features

Version information through Rails.application.version
Environment management via Rails.application.env
Version-aware response headers
Cache key generation
Console environment information

Basic Setup

# Gemfile
gem "rails_app_version"

# Terminal
bundle install
rails app:version:config
echo "1.0.0" > VERSION

Common Use Cases

Error Tracking:

Sentry.init do |config|
  config.release = Rails.application.version.to_s
  config.environment = Rails.application.env
end

Cache Management:

def index
  Rails.cache.fetch("index-page-#{Rails.application.version.to_cache_key}") do
    render :index
  end
end

Version Headers:

# config/app_version.yml
staging:
  middleware:
    enabled: true
    options:
      version_header: X-Staging-Version
      environment_header: X-Staging-Environment

Testing:

class VersionTest < ActiveSupport::TestCase
  test "version information" do
    assert_equal "1.2.3", Rails.application.version.to_s
    assert_equal "1-2-3", Rails.application.version.to_cache_key
  end
end

Version Management Options

VERSION File (Recommended):

1.2.3

YAML Configuration:

shared:
  version: <%= Rails.root.join('VERSION').read.strip rescue '0.0.0' %>
  revision: <%= Rails.root.join('REVISION').read.strip rescue (`git rev-parse HEAD`.strip rescue '0') %>

Accessing Version Details:

Rails.application.version.major      # => 1
Rails.application.version.minor      # => 2
Rails.application.version.patch      # => 3
Rails.application.version.full       # => "1.2.3 (abc123de)"

Environment Management:

Rails.application.env               # => "staging"
Rails.application.env.production?   # => false
Rails.application.env.staging?      # => true

The gem is available at https://github.com/seuros/rails_app_version under the MIT License.

NoFlyList: How NoFlyList Optimizes Tag Queries

Abdelkader Boudih — Fri, 20 Dec 2024 14:55:07 +0000

Database-Specific Strategies

NoFlyList automatically detects your database type and uses optimized queries:

class Product < ApplicationRecord
  include NoFlyList::TaggableRecord
  has_tags :categories
end

# This generates different SQL for each database
Product.with_any_categories("electronics", "gaming")

PostgreSQL Optimization

PostgreSQL query:

# Using array operators and CTE for better performance
SELECT "products".*
FROM "products"
WHERE "products"."id" IN (
  SELECT DISTINCT "products"."id"
  FROM products
  INNER JOIN "product_taggings" ON "product_taggings"."taggable_id" = "products"."id"
  INNER JOIN "product_tags" ON "product_tags"."id" = "product_taggings"."tag_id"
  WHERE "product_taggings"."context" = 'category'
  AND "product_tags"."name" = ANY(ARRAY['electronics', 'gaming'])
)

MySQL Optimization

MySQL query:

# Using FIND_IN_SET and subqueries
SELECT `products`.*
FROM `products`
WHERE `products`.`id` IN (
  SELECT `products`.`id`
  FROM products
  INNER JOIN `product_taggings` ON `product_taggings`.`taggable_id` = `products`.`id`
  INNER JOIN `product_tags` ON `product_tags`.`id` = `product_taggings`.`tag_id`
  WHERE `product_taggings`.`context` = 'category'
  AND `product_tags`.`name` IN ('electronics', 'gaming')
  GROUP BY `products`.`id`
)

SQLite Optimization

SQLite query:

# Optimized for SQLite's simpler query planner
SELECT "products".*
FROM "products"
WHERE "products"."id" IN (
  SELECT "products"."id"
  FROM products
  INNER JOIN product_taggings ON product_taggings.taggable_id = products.id
  INNER JOIN product_tags ON product_tags.id = product_taggings.tag_id
  WHERE product_taggings.context = 'category'
  AND product_tags.name IN ('electronics', 'gaming')
)

Complex Queries

# Finding products with ALL specified tags
Product.with_all_categories("electronics", "gaming")

# PostgreSQL uses:
SELECT "products".*
FROM "products"
WHERE "products"."id" IN (
  SELECT "products"."id"
  FROM products
  INNER JOIN "product_taggings" ON "product_taggings"."taggable_id" = "products"."id"
  INNER JOIN "product_tags" ON "product_tags"."id" = "product_taggings"."tag_id"
  WHERE "product_taggings"."context" = 'category'
  AND "product_tags"."name" IN ('electronics', 'gaming')
  GROUP BY "products"."id"
  HAVING COUNT(DISTINCT "product_tags"."name") = 2
)

# Finding products without specific tags
Product.without_any_categories("discontinued")

# Finding products with exact tag set
Product.with_exact_categories(["electronics", "gaming"])

Performance Tips

Index Optimization:

class CreateProductTags < ActiveRecord::Migration[7.2]
  def change
    add_index :product_tags, :name
    add_index :product_taggings, [:taggable_id, :taggable_type, :context]
  end
end

Unlike AATO, the gem support multiple database connections and mixed adapters.

Counter Cache:

class Product < ApplicationRecord
  has_tags :categories, counter_cache: true
end

Eager Loading:

# Efficient loading of products with their tags
Product.includes(:categories)
       .with_any_categories("electronics")

Debugging Queries

Use query logging to see optimizations:

# config/environments/development.rb
config.active_record.verbose_query_logs = true

# In console
Product.with_any_categories("electronics").explain

Common Patterns

Category Trees:

Product.with_all_categories("electronics")
       .with_any_categories("gaming", "professional")

Exclusions:

Product.with_any_categories("electronics")
       .without_any_categories("discontinued", "clearance")

Exact Matching:

Product.with_exact_categories(["gaming", "electronics"])

Each pattern generates optimized SQL based on your database.
If you know a better query, feel free to open a pull request on the adapter query.

NoFlyList: Custom Tag Screening with NoFlyList

Abdelkader Boudih — Fri, 20 Dec 2024 14:47:13 +0000

Tag parsing seems simple until you handle real user input.

Let's explore how NoFlyList's transformers handle messy tag data submitted.

Basic Setup

rails generate no_fly_list:transformer

Default transformer:

module ApplicationTagTransformer
  module_function

  def parse_tags(tags)
    if tags.is_a?(Array)
      tags
    else
      tags.split(separator).map(&:strip).compact
    end
  end

  def recreate_string(tags)
    tags.join(separator)
  end

  def separator
    ','
  end
end

Real-World Examples

Hashtag Transformer

module HashtagTransformer
  module_function

  def parse_tags(tags)
    return tags if tags.is_a?(Array)

    tags.scan(/#[\w-]+/).map { |tag| tag.delete('#') }
  end

  def recreate_string(tags)
    tags.map { |tag| "##{tag}" }.join(' ')
  end
end

class Post < ApplicationRecord
  include NoFlyList::TaggableRecord

  has_tags :hashtags, transformer: HashtagTransformer
end

post = Post.new(content: "Check out #rails #ruby #webdev")
post.hashtags_list = post.content  # Extracts: ["rails", "ruby", "webdev"]

Multi-Language Transformer

module MultiLangTransformer
  module_function

  def parse_tags(tags)
    return tags if tags.is_a?(Array)

    tags.split('|').map do |tag_pair|
      lang, tag = tag_pair.split(':').map(&:strip)
      "#{lang}:#{tag}"
    end
  end

  def recreate_string(tags)
    tags.join(' | ')
  end
end

class Article < ApplicationRecord
  has_tags :keywords, transformer: MultiLangTransformer
end

article.keywords_list = "en:ruby | es:rubí | fr:rubis"

Hierarchical Tag Transformer

module CategoryTransformer
  module_function

  def parse_tags(tags)
    return tags if tags.is_a?(Array)

    tags.split('>').map(&:strip)
  end

  def recreate_string(tags)
    tags.join(' > ')
  end
end

class Product < ApplicationRecord
  has_tags :categories, transformer: CategoryTransformer
end

product.categories_list = "Electronics > Computers > Laptops"

Custom Normalization

module NormalizedTransformer
  module_function

  def parse_tags(tags)
    tags = tags.split(',') unless tags.is_a?(Array)

    tags.map do |tag|
      tag.strip
         .downcase
         .gsub(/[^a-z0-9\s-]/, '')  # Remove special chars
         .gsub(/\s+/, '-')          # Spaces to hyphens
    end.uniq.compact
  end

  def recreate_string(tags)
    tags.join(', ')
  end
end

class Photo < ApplicationRecord
  has_tags :labels, transformer: NormalizedTransformer
end

photo.labels_list = "Nature Photos, WILDLIFE shots, Outdoor-Photography"
# Transforms to: ["nature-photos", "wildlife-shots", "outdoor-photography"]

Context-Specific Transformers

Mix transformers based on tag context:

class Article < ApplicationRecord
  include NoFlyList::TaggableRecord

  has_tags :categories, transformer: CategoryTransformer
  has_tags :hashtags, transformer: HashtagTransformer
  has_tags :keywords, transformer: MultiLangTransformer
end

Testing Transformers

class TransformerTest < ActiveSupport::TestCase
  test "hashtag parsing" do
    input = "#ruby #rails doing #testing"
    expected = ["ruby", "rails", "testing"]
    assert_equal expected, HashtagTransformer.parse_tags(input)
  end

  test "hierarchical parsing" do
    input = "Tech > Software > Tools"
    expected = ["Tech", "Software", "Tools"]
    assert_equal expected, CategoryTransformer.parse_tags(input)
  end
end

Remember: Transformers are your first line of defense against messy tag data. Like TSA agents, they ensure only properly formatted tags make it through to your system.

Part4

NoFlyList: Choosing Between Polymorphic and Model-Specific Tags

Abdelkader Boudih — Fri, 20 Dec 2024 14:39:04 +0000

Let's build a blog platform to understand when to use polymorphic vs model-specific tags.

Setup

# Create our models
rails generate model Article title:string content:text
rails generate model Video title:string url:string
rails generate no_fly_list:install      # For polymorphic tags
rails generate no_fly_list:tagging Article
rails generate no_fly_list:tagging Video

Scenario 1: Shared Categories

Articles and videos share the same category system:

class Article < ApplicationRecord
  include NoFlyList::TaggableRecord

  has_tags :categories,
    polymorphic: true,  # Uses shared tags table
    restrict_to_existing: true
end

class Video < ApplicationRecord
  include NoFlyList::TaggableRecord

  has_tags :categories,
    polymorphic: true,
    restrict_to_existing: true
end

# Usage
article = Article.create!(title: "Rails Tips")
article.categories_list = "programming, tutorials"

video = Video.create!(title: "Rails Setup Guide")
video.categories_list = "programming, beginners"

# Find all programming content across both models
articles = Article.with_any_categories("programming")
videos = Video.with_any_categories("programming")

Scenario 2: Model-Specific Tags

Articles have technical requirements, videos have equipment details:

class Article < ApplicationRecord
  include NoFlyList::TaggableRecord

  has_tags :technical_requirements  # Model-specific
end

class Video < ApplicationRecord
  include NoFlyList::TaggableRecord

  has_tags :equipment_used  # Model-specific
end

# Usage
article.technical_requirements_list = "ruby-3.2, rails-7.2"
video.equipment_used_list = "sony-a7iii, rode-mic"

Mixed Usage

Combine both approaches:

class Article < ApplicationRecord
  include NoFlyList::TaggableRecord

  has_tags :categories, polymorphic: true  # Shared
  has_tags :technical_requirements         # Specific
  has_tags :author_notes                   # Specific
end

# Find articles by shared categories and specific requirements
Article.with_any_categories("programming")
       .with_all_technical_requirements("ruby-3.2")

Database Structure

Polymorphic tags:

# application_tags
create_table :application_tags do |t|
  t.string :name
  t.timestamps
end

# application_taggings
create_table :application_taggings do |t|
  t.references :tag
  t.references :taggable, polymorphic: true
  t.string :context
  t.timestamps
end

Model-specific tags:

# article_tags
create_table :article_tags do |t|
  t.string :name
  t.timestamps
end

# article_taggings
create_table :article_taggings do |t|
  t.references :tag
  t.references :article
  t.string :context
  t.timestamps
end

When to Use Each

Use polymorphic tags when:

Tags need to be shared across models
You want centralized tag management
Tags require validation across all models

Use model-specific tags when:

Tags are unique to the model
You want simpler queries
Tags don't need to be shared

Performance Considerations

Polymorphic tags:

One query across multiple tables
Slower for large datasets
More complex indexes

Model-specific tags:

Direct table access
Faster for single-model queries
Simpler indexing

Part3

NoFlyList : How NoFlyList Got Cleared for Production

Abdelkader Boudih — Fri, 20 Dec 2024 14:36:41 +0000

As the maintainer of Acts-as-Taggable-On (AATO), I started seeing patterns of technical debt and maintenance challenges around 2018. While AATO served its purpose well, its legacy codebase began showing signs of strain, especially with modern Rails applications.

The Birth of NoFlyList

NoFlyList wasn't born in a weekend hackathon, it evolved over years of real-world testing across multiple production applications.

The name comes from how the TSA tags passengers and bags for extra screening.
Much like the TSA's tagging system, this gem manages and validates tags.
And unless you're actually building TSA software, you won't have any naming conflicts in your codebase.

The initial concept emerged from a protocol and platform for sustainable, traceable and resilience supply chains, where the constraints of AATO became evident and ultimately lead me to the development of a more robust, flexible solution.

Let's walk through a practical example of how NoFlyList handles one of these real-world scenarios.

class Product < ApplicationRecord
  include NoFlyList::TaggableRecord

  has_tags :categories,
    polymorphic: true,           # Shared across models
    restrict_to_existing: true,  # Only allow predefined categories
    counter_cache: true         # Track usage statistics
end

This simple configuration represents years of learning about what teams actually need in production. Each option addresses specific pain points discovered in real applications:

Polymorphic tags came from the platform needing to share categories across products and services.
Tag restrictions emerged from a content management system requiring controlled vocabularies.
Counter cache was added after seeing performance issues in high-traffic situations.

Database-Specific Optimizations

One feature that took significant real-world testing was the database-specific query strategies. Different applications had different scaling challenges:

# PostgreSQL-optimized query
Product.with_all_categories("electronics", "gaming")
       .with_any_features("wireless", "bluetooth")

# MySQL-specific optimizations, model is using another connection.
MySqlProduct.without_any_categories("discontinued", "clearance")

Testing Infrastructure

The test helpers was build from actual testing patterns i use across multiple applications:

class ProductTest < ActiveSupport::TestCase
  include NoFlyList::TestHelper

  test "product categorization" do
    assert_taggable_record Product, :categories
    assert_tagging_context Product, :categories, polymorphic: true
  end
end

Next Steps

While NoFlyList is now ready for public use, i'm still extracting and refining features based on real-world usage patterns. Future releases will include:

Additional query optimizations
Enhanced migration tools
More granular caching options

The gem is stable and production-tested, but i'm continuously identifying features that could benefit the broader Rails community.

The repo

Part2

DEV Community: Abdelkader Boudih

Finding the Road Back Home: Building a Clean PostGIS Gem for Rails 8

The Problem: Welcome to the Jungle

Rails 8: Déjà Vu All Over Again

Rebuilding: Not as Simple as it Sounds

The New Way: Rails-Friendly and Stable

1. Rails-Compatible Extensions

2. Column Methods Done Right

3. Fully Integrated Rails Type System

4. Reliable Schema Dumping

A Note on the Past

Lessons Learned (Again, the Hard Way)

The Road Ahead

Coming Home

Building ActiveCypher: When Ruby Learns to Speak Graph

Building ActiveCypher: When Ruby Learns to Speak Graph

Smarter RAG Systems with Graphs

Introduction: So You Want Your LLM to Stop Guessing

Graph Databases in RAG: Where They Fit

Memgraph’s Engine: Performance Meets Simplicity

1. In-Memory Transactional Mode (Default)

2. In-Memory Analytical Mode

3. On-Disk Transactional Mode (Experimental)

Streaming (Always Fresh Data)

Developer Experience: The Stuff That Actually Matters

Query Examples: Because Words Are Cheap

Integration Into a RAG Stack

What Could Go Wrong? (Spoiler: Not Much)

Final Thought: Just Try It

Prompts in MCP: Preloaded Sanity, Not Just Fancy Slash Commands

🎭 What Are Prompts (and Why Should You Care)?

🧩 Anatomy of a Prompt (or, How to Stop Guessing)

🔎 Prompt Discovery (But Not By the AI, Calm Down)

📦 Context Injection (a.k.a. Prompts With Homework)

🤹 Multi-Turn Prompts: When You Want a Conversation, Not a Monologue

⚠️ Prompt Security: Protect Users from Themselves (and Your LLM)

💥 Real Examples (for the Delightfully Deranged)

🔹 debug-error

🔹 generate-apology-email

🔹 name-my-startup

✅ Conclusion: Prompts Keep You Honest

If You Think MCP Is Just a Tool Registry, You’re Missing the Point

🛠 The Swiss Army Knife Myth

🧪 One Session, One Sandbox: Isolation That Actually Works

📼 Session Logs: JSON-RPC as Black Box Recorder

🚨 Dumb Proxies: Don’t Be That Person

✅ Conclusion: Stop Calling It a Registry

The Rise of 'Vibe Packages' in Open Source Development

When AI-Driven Speed Meets Open Source Ecosystems

What Are "Vibe Packages"?

Niche Language Ecosystems: From Curated to Cluttered

Case Study: The API Wrapper Gold Rush

Community Reactions and Consequences

Original Maintainers: Why Bother?

Junior Devs: Confidence on Shaky Ground

Companies: Dependency Roulette

Seasoned Devs: Holding Back

Conclusion: Navigating the Vibe Package Era

LLMs and the Ossification of APIs: Are We Stuck with Prehistoric Patterns?

When AI Coding Assistants Influence API Design in Ruby

The Rise of AI Pair Programmers in Ruby

API Ossification: When Patterns Become a Prison

Case Study: When Official APIs Defy Convention – Anthropic's Ruby SDK

Case Study: When AI and Linters Mislead – The render Method Confusion

The New Challenge: Balancing Innovation and Expectation

Conclusion

Rails Version Management with Rails AppVersion

NoFlyList: How NoFlyList Optimizes Tag Queries

Database-Specific Strategies

PostgreSQL Optimization

MySQL Optimization

SQLite Optimization

Complex Queries

Performance Tips

Debugging Queries

Common Patterns

NoFlyList: Custom Tag Screening with NoFlyList

Basic Setup

Real-World Examples

Hashtag Transformer

🔹 `debug-error`

🔹 `generate-apology-email`

🔹 `name-my-startup`

Case Study: When AI and Linters Mislead – The `render` Method Confusion