Ifad on Marcello Barnaba

ansible-wsadmin: Bypassing AdminConfig to Automate WebSphere via JMX

Sat, 11 Apr 2026 00:00:00 +0000

tl;dr — IBM WebSphere has a clean configuration API (ConfigService) buried under a broken string-based wrapper (AdminConfig). I built an object-oriented Jython layer that hooks into ConfigService directly via JMX — easing configuration and ensuring type correctness through metadata introspection — plus a persistent daemon that eliminates JVM boot overhead, and 55 idempotent scripts that integrate with Ansible’s change detection. github.com/vjt/ansible-wsadmin

In 2021, I spent six months automating the IFAD WebSphere infrastructure with Ansible. The stack was IBM WebSphere Application Server (WAS), WebSphere Portal Server (WPS), and Business Automation Workflow (BAW) — a clustered deployment with a Deployment Manager, multiple nodes, federated LDAP, SIB messaging, the works.

The standard approach to automating WAS is to write Jython scripts using AdminConfig, AdminTask, and AdminApp — the four global scripting objects that IBM provides inside wsadmin. I tried that. It lasted about a day before I started looking at what’s underneath.

What I found changed how I approached the entire project. It also produced a library full of ideas I never had a chance to describe properly — until now, with a little help from Claude.

Integrating OneSpan Two-Factor Products with Ruby

Fri, 11 Sep 2020 00:00:00 +0000

I was tasked with integrating OneSpan (formerly VASCO) hardware token two-factor authentication into a Ruby stack — wrapping their proprietary VACMAN Controller C SDK for local OTP validation, and building a client for their OneSpan Authentication Server (originally named Identikey Authentication Server, and renamed mid-project) SOAP API. Neither had a Ruby library.

For vacman_controller there was a starting point: a Ruby C extension by Marcus Lankenau wrapping the AAL2 SDK. One commit, no releases, rough around the edges, but a solid foundation — linking, importing tokens and basic wrappers — was there. I forked it at IFAD, fixed it, extended it, and pushed 97 additional commits on top. 14 releases, v0.1.0 through v0.9.3.

For identikey there was nothing — OneSpan ships a Java SDK, no Ruby library exists. I wrote one from scratch: 123 commits, 18 tags, v0.2.0 through v0.9.1.

Both are on GitHub. Here’s what’s inside.

ChronoModel 1.0: Seven Years to Ship

Sat, 06 Apr 2019 00:00:00 +0000

🔍

2026 retrospective
My last release was v1.2.2 in May 2019. After that, Geremia Taglialatela took over and pushed it to v5.0.0 with Rails 8.1 and Ruby 4.0 support. 34 releases spanning 14 years, 201 stars, and still actively maintained. The API documentation and the repo are both alive.

Seven years ago I released ChronoModel v0.1.0 — a Ruby gem that gives ActiveRecord models temporal capabilities on PostgreSQL. Five days of hacking, thirty-six commits, no tests, and a confession about monkey-patching the PostgreSQL adapter constant.

Today I’m tagging v1.0.0. The commit message is :gem: this is v1.0.0. Not much of a speech, but the code speaks for itself: 506 commits, 31 releases, 52 files changed, 5,392 lines added. The core idea — updatable views on public, current data on temporal, history on history with table inheritance — never changed. Everything else did.

A Shameless Translation Memory Importer for Pontoon

Wed, 14 Feb 2018 00:00:00 +0000

🔍

2026 retrospective
The repo at github.com/ifad/translation-memory is still public, still has no README, and the Pontoon fork it talks to remains private. Mozilla’s upstream is open and very much alive. Whether anyone at IFAD still runs Pontoon eight years on, I honestly don’t know — I built this for one project on my desk, not as a corporate workflow change. The hyphen-stripping regex did its job for the months I needed it. Then, presumably, the next Pontoon schema migration broke something. That’s what happens to integrations that talk to a database directly.

IFAD is a UN agency that operates in English, French, Spanish, and Arabic. Every public-facing string in our Rails apps needs to exist in four languages, which means we have a translation team, which means we have a translation workflow, which on most projects involves a desktop CAT tool, files attached to emails, and translation memories shipped around as XML.

That workflow does not survive a project I’m building right now. It’s a Rails web app on a tight schedule, the source strings change every week, and by the time a translator has finished a TM file and emailed it back the strings have already moved. I need translators and developers looking at the same database in real time. I pick Mozilla Pontoon — open-source, free, adaptable, written in Django, backed by Postgres — and stand it up for my project. The catch: there is a corpus of translations from the previous tool that I want to seed Pontoon with on day one, so the translators don’t start from a blank slate.

Today I start a translation-memory repo and write the first parser. The project is described, with all due engineering humility, as “Parser for TMX, SDL/XLIFF and TXML files and shameless importer into Mozilla Pontoon”. The “shameless” part is doing a lot of work in that sentence.

From Heathen to Colore: A Document Pipeline Story

Fri, 15 Jan 2016 00:00:00 +0000

🔍

2026 retrospective
Colore is still alive at github.com/ifad/colore — Geremia Taglialatela took over after I drifted onto other things and pushed the project forward through Ruby 2.7, 3.0, 3.1, 3.2, sidekiq 6, and modern CI. He sits at 354 commits — three times mine. The nginx C module Joe wrote in February 2015 is unchanged. Heathen the standalone service was eventually folded directly into Colore as a library; the original repo is archived but the code lives on inside lib/heathen/ of Colore. Same idea, fewer moving parts.

IFAD is a UN agency that runs on documents. Loan agreements, evaluation reports, country strategy notes, board decisions, project briefs — every web application we build sooner or later needs to take a Word file and give back a PDF, or take a scan and give back something searchable, or take an arbitrary blob and turn it into a thumbnail. Three years ago we decided to stop solving this problem one application at a time and put it behind a single service.

Today I’m merging v1.0.0 of Colore. It’s the second attempt at that service, and it’s the one we get to keep. This is the story of both attempts and the people who built them — because almost none of the code below is mine.

Eaco: The Holder of the Keys of Hades

Sat, 28 Feb 2015 00:00:00 +0000

🔍

2026 retrospective
Eaco reached v1.0.0 on May 5, 2016 — commit message: “This is v1.0.0. Two years in production.” It grew to 54 stars, 8 forks, 240 commits, and ran authorization at IFAD for five more years after that. Geremia Taglialatela picked it up in 2020 and kept it running on Rails 6.0 and 6.1, then modernized the CI in late 2025. The ABAC-with-hash-ACLs pattern turned out to be exactly right for an organization where access is determined by position, department, and working group — not just “admin or not.” The repo is still online, and the YARD documentation is still some of the most thorough I’ve ever written for a gem.

Scriptoria is an internal workflow application at IFAD — a UN specialized agency in Rome — and its authorization layer has been annoying me for months. The code works, but it’s tangled into the app. Every time we need to add a new role or change who can access what, we’re editing application code that shouldn’t care about authorization semantics.

So eight days ago I started extracting it. Today I’m releasing the result: Eaco — an Attribute-Based Access Control framework for Ruby, named after Eacus, the holder of the keys of Hades in Greek mythology.

172 commits. Five releases. 100% test coverage. And a Saturday afternoon I’ll never get back.

Hermes: contextual help in 48 hours (Rails Rumble 2013)

Sun, 20 Oct 2013 00:00:00 +0000

🔍

2026 retrospective
The “contextual help” space exploded into a whole product category — Intercom, Pendo, Appcues and others now do this commercially at scale. IFAD’s fork lived on for years inside the agency. The Rails Rumble itself stopped running after 2015, and the era of 48-hour competition hackathons gave way to AI hackathons and startup weekends. The repo is archived but still up.

The Rails Rumble is — was — a 48-hour hackathon where teams of up to four people build a complete web app from scratch using Ruby. No prep work, no pre-written code. Just caffeine, git, and a deadline.

This year our team — @amedeo, @liquid1982, @maisongb, and me — built Hermes: the epic messenger service, entry #385.

(My previous Rumble entry was Guess The Friend in 2012, with a different team.)

data-confirm-modal: When a User Did Too Much Damage

Tue, 02 Jul 2013 00:00:00 +0000

🔍

2026 retrospective
This tiny gem grew to 268 stars and 112 forks, with 32 contributors over 7 years. It learned Bootstrap 3, then 4 with auto-detection (v1.6.0), got a non-Rails mode with dataConfirmModal.confirm() callbacks (v1.2.0), an npm package still pulling 3,700 downloads/week (v1.6.2), and kept working with every Rails version through 6.0. The concept became so mainstream that every UI framework now ships its own confirmation dialog component. The repo is still up.

A user at IFAD did too much damage last week.

Not maliciously — they just clicked through a chain of destructive actions, happily dismissing the browser’s confirm() dialogs without reading them. Because nobody reads those. They’re ugly grey system dialogs that blend into the background of your workflow. Click OK, click OK, click OK — and suddenly half the data is gone.

So I fixed it. And then I extracted the fix into a gem, because this problem isn’t specific to our application. Today I’m releasing data-confirm-modal — 116 lines of JavaScript that replace Rails’ built-in confirm() with a Bootstrap modal.

ChronoModel: Time Travel for PostgreSQL

Mon, 07 May 2012 00:00:00 +0000

🔍

2026 retrospective
ChronoModel is still alive — 14 years, 41 releases, 201 stars. The rules got replaced by INSTEAD OF triggers in v0.6 (2014), the box()/point() hack by proper tsrange columns, and the monkey-patching by a proper adapter registration. Geremia Taglialatela took over maintenance in 2020 and pushed it to v5.0.0 with Rails 8.1 and Ruby 4.0 support. The core idea — updatable views on public, current data on temporal, history on history with table inheritance — never changed. The repo is healthy and actively maintained.

Update, April 2019: ChronoModel reached 1.0 — seven years, 506 commits, and 31 releases later.

We’re building a CRM at IFAD — a UN specialized agency in Rome — and one of the hard requirements is temporal data. We need to know what a record looked like at any point in the past. What was this project’s budget on March 15th? When did this beneficiary’s address change? Who approved what, and what did the record look like at the time?

I’d been prototyping a PostgreSQL schema approach for this — views, rules, table inheritance — and it worked. Then Amedeo, my boss, looked at it and said: “This shouldn’t live inside the CRM. Make it a reusable framework.”

He was right. The temporal pattern has nothing to do with CRM logic. It belongs in a gem.

So I had five days of uninterrupted focus, and today I’m releasing ChronoModel — an ActiveRecord extension that gives your models full temporal capabilities on PostgreSQL. What Oracle sells as Flashback Queries and charges enterprise money for, we can do with standard SQL on Postgres 9.0+.