About

I build Oracle APEX applications for enterprise clients, and I write about what actually happens when you do

Most technical writing shows you the finished thing. The query that worked, the architecture that scaled, the clean solution. That skips the part where you spent a Saturday finding out the option you needed does not exist, or where you fixed the problem and it was still slow.

That is the part I write about.

The work

I am a senior Oracle consultant at Qualogy in the Netherlands, building Oracle APEX applications and REST services for enterprise clients. Fifteen years in, starting from database administration, which turns out to matter more than expected. A lot of the performance problems I run into are not application problems at all.

The work is usually some version of the same thing: a system that has to be fast enough, correct enough, and maintainable by whoever comes after me. Constraints I cannot negotiate away, and a deadline.

Why I write

Two reasons, and I would rather be direct about both.

Writing forces me to actually understand something. It is easy to get code working and move on. Explaining why it works, to a junior developer who has never touched Oracle APEX, is where the gaps show up.

And I want the developers who read this to consider working with us. Qualogy hires, I am part of the team that does the work, and I would rather you know what that work looks like before you talk to a recruiter about it. What you read here is the actual job.

What you will find here

Deep technical pieces on Oracle APEX, ORDS, PL/SQL and increasingly AI inside the database. Benchmarks with real numbers, not vibes. Code you can run. The approaches that failed, kept in, because those are usually more useful than the one that worked.

Some pieces are about the job rather than the code: what it is like switching into tech, what I got wrong, what I would tell someone starting now.

Credentials, briefly

Oracle ACE Associate, fifteen years working with Oracle, starting in database administration and moving into APEX development and consulting.
The code from these articles is on GitHub.

The other thing

I am a serious anime fan, which is why the benchmark data in some of these articles is five hundred titles from MyAnimeList instead of the usual employees table. If you are going to spend a Saturday writing test scripts, you may as well enjoy the data.

Get the writing

New pieces go out by email when they publish. No schedule promises beyond that, no marketing sequences, just the article and occasionally what got cut from it for length.

If you are dealing with an Oracle problem that sounds like something you read here, you can mail me at rmangoensentono@qualogy.com.