DEV Community: Bruno Pacheco

Rebuilding Praecepta: From a Trie to Bitsets, and a Fair Benchmark Against Camunda and Drools

Bruno Pacheco — Sat, 07 Nov 2026 21:38:35 +0000

In January 2023 I wrote about optimizing decision-making with a trie. The idea worked in principle: part of it was implemented, and is still maintained, at Pictet Tech. The numbers looked great, as you can see in my previous post.

Going through my old repositories for opportunities to test Claude, I decided to explore the major problem of that solution: the trie's memory exploded as tables grew; a generated table of 1,000 rules took over 1 GB. And during the development process, Claude told me that the first benchmark was not entirely fair, as Praecepta ran a different hit policy from Camunda and Kogito, and two of the services read one input from the wrong field.

So I refactored the engine and the benchmark, and completed the Maven plugin that compiles tables at build time. The result of the refactoring can be found in Praecepta 0.1.0 on Maven Central. The principles are still the same: a small, dependency-free Java engine for DMN decision tables. It now also has a website for the guide and the API documentation.

This post covers what changed, a benchmark against Camunda and Drools that I tried hard to make fair (including where it flatters Praecepta, and where Praecepta is slower), and what those engines do that Praecepta does not. This post also covers how open Praecepta is, and what could come next. That last part is where I would love your opinion.

From a trie to bitsets

A decision table is a simple list of rules. Each rule tests some input columns (country is "PT" or "ES", age in [18..65), or "anything") and produces outputs. The previous solution, a custom implementation of a trie, stored every possible path through the columns, and every "anything" cell multiplied the paths. That multiplication was the memory problem!

I tried a couple of things back then, including quantum computing via qengine: encoding the input as bits and each rule as quantum logic gates, to see whether a quantum circuit could beat the trie. It ran only on a simulator, but the thought stayed with me: rule matching is boolean logic over bits. The bitset index is the classical, practical version of that thought.

In the end, I stopped thinking about it. But now, in 2026, and with Claude's support, the new core uses bitsets. Every rule gets one bit. For every column, each distinct value the rules can tell apart gets a mask: the set of rules that accept it.

Column `country`	rule 1	rule 2	rule 3	rule 4
`"PT"`	1	0	1	1
`"FR"`	0	1	1	0
any other value	0	0	1	1

Rule 1 tests "PT", rule 2 tests "FR", rule 3 is "anything" (so it is in every mask), and rule 4 is not("FR"). Evaluating an input looks up one mask per column and ANDs them together. A 64-bit AND checks 64 rules at once, and the bundled 119-rule table fits in two words. Memory grows with columns × values × rules, never with the product of values, and the 1,000-rule table that needed 1 GB now takes 0.6 MB, and reading it from DMN and building it takes about a quarter of a second in a fresh JVM.

And the best part: the hit policy falls out of the bits too. Bits are numbered in rule order (or priority order), so FIRST is "lowest set bit", which is a single CPU instruction.

Numbers and dates work the same way: the boundaries the rules mention (18, 65, date("2025-01-01")) split each column into intervals, a binary search finds the interval, and each interval has its mask.

What else changed

The core was not the only change. Praecepta now also has:

Strict DMN 1.3 hit policies: UNIQUE, ANY, PRIORITY, FIRST, OUTPUT ORDER, RULE ORDER, and COLLECT with SUM, MIN and MAX.
FEEL cells on string, number and date columns: lists, not(...), comparisons, intervals and null.
Validation when the table is built: overlapping rules, conflicting outputs, rules that can never fire, and gaps (inputs no rule covers, with an example).
DMN import and export: Praecepta reads DMN 1.1–1.5 files, including those from Camunda Modeler.
A Maven plugin that validates tables at build time and generates typed input and output records, so your application ships only the engine.
Java 21+, with the engine as a JPMS module. Everything is tested on Java 21, 25 and 27.

The benchmark

Since the first benchmark was not fair, I rebuilt it from scratch. This time Praecepta runs against Camunda 8 and Drools (the DMN engine inside Kogito), and every engine gets exactly the same work.

How I measured it

Same rules, same file, for every engine. Each table is written once as a DMN document, and every engine, Praecepta included, reads that document, as an application loading a .dmn file would. Before any timing, every engine evaluates the whole workload and its answers are compared with Praecepta built straight from the rules. The run aborts if any engine disagrees.
Supported, default setups: Camunda 8's DMN engine (dmn-scala 1.12.6, the one Zeebe embeds) and Drools 10.2.0's DMN runtime.
The same input for all: a Map of values. Praecepta's fastest path (generated classes with enums) is shown separately and labelled as its best case.
Many tables:
- Real: the 119-rule table from 2023 (values blurred, FIRST hit policy).
- Generated, synthetic: string columns only.
- Generated, mixed: string, number and date columns, with comparisons, intervals and not(...).
- Sizes: the generated tables run from 10 to 10,000 rules and from 5 to 20 columns. The same 1,000 rules are also run under each hit policy, and with inputs that match no rule.
More than an average: latency percentiles, memory allocated per decision, throughput with 1, 4 and 8 threads sharing one engine, the time to build an engine, and the time to the first decision in a fresh JVM.
The released engine: I measured the same engine code that is in the 0.1.0 release.
Machine: Apple M2 Pro (8 performance cores), 16 GB, macOS 26.7.1, OpenJDK 27.0.1. JMH: 5 × 2 s warm-up and 5 × 3 s measurement iterations, 3 forks.
Everything is public: the results keep every log, the raw JMH output and the environment, and one script reruns the whole suite in about 2.5 hours. To check that the picture is not an artefact of my machine, I also ran the short profile on a GitHub Actions runner (AMD EPYC, 4 vCPUs, Linux, Java 25). It used one fork, so its numbers are noisy, and its absolute times are 1.5–3× higher, but the ranking holds on every table. On mixed-1000, for example, Praecepta took 1.0 µs, Camunda 519 µs and Drools 421 µs.

Latency as tables grow

µs per evaluation	Praecepta 0.1.0	Camunda 8	Drools 10.2.0
real (119 rules)	0.19	19.3	43.5
synthetic-10	0.15	4.20	5.89
synthetic-100	0.16	19.1	14.5
synthetic-1000	0.25	146	126
synthetic-10000	0.67	1,333	1,419
mixed-10	0.31	7.05	7.95
mixed-100	0.44	33.2	31.3
mixed-1000	0.64	263	256
mixed-10000	1.51	3,118	3,122

The bigger the table, the bigger the gap:

Praecepta: from 10 to 10,000 mixed rules, its time goes from 0.31 to 1.51 µs, 5× slower for 1,000× more rules.
Camunda and Drools: their time grows roughly with the number of rules, from about 7 µs to about 3,100 µs.
The ratio: Praecepta is 25–40× faster on 10 rules, 70–120× on 100, 400–600× on 1,000 and about 2,000× on 10,000. On the real table it is 104× faster than Camunda and 233× faster than Drools.

More columns cost Praecepta little: with 1,000 rules, going from 6 to 18 mixed columns takes it from 0.62 to 1.12 µs. Number and date columns cost it 2–3× string columns, because a binary search over decimals is slower than a hash lookup; that one has an issue.

Not every number is equally precise: 51 of the 63 latency measurements have a 99.9% confidence interval within ±10%. The widest is Drools on synthetic-10000, at ±33%. All of them are in the results, if you want to check.

Hit policies, and inputs that match no rule

µs per evaluation, 1,000 mixed rules	Praecepta 0.1.0	Camunda 8	Drools 10.2.0
COLLECT	0.64	263	256
FIRST	0.53	49.6	248
PRIORITY	0.55	287	252
RULE ORDER	0.64	285	257
UNIQUE (1,000 rules that never overlap)	0.23	161	128
No rule matches (COLLECT)	0.32	261	197

Praecepta: the hit policy barely changes its time, because it is one operation on the bits that matched. An input that matches nothing costs no more than one that matches.
Camunda: it is 5× faster under FIRST, which suggests it stops at the first match.
Drools: it takes about the same time under every policy. When nothing matches, it still pays about three quarters of the time of a match, and Camunda nearly all of it.
The real table has no such inputs: its last rule matches anything.

Tail latency and memory per decision

µs per evaluation	p50	p99	p99.9
Praecepta, real	0.17	0.29	0.54
Camunda 8, real	17.7	32.4	41.1
Drools 10.2.0, real	51.8	69.8	85.5
Praecepta, mixed-1000	0.67	1.00	2.57
Camunda 8, mixed-1000	250	323	444
Drools 10.2.0, mixed-1000	260	309	386

Tails: Praecepta's 99.9th percentile on mixed-1000 (2.6 µs) is still about 100× below the others' median.
The slowest decisions: each engine's single slowest decision took up to a few milliseconds, most likely from pauses in the JVM or the operating system, which every engine sees.
Allocation: on tables of up to 1,000 rules, Praecepta allocates 32 to 466 bytes per decision. Camunda allocates 22 KB to 1.5 MB, and Drools 16 KB to 375 KB. Less garbage means less garbage collection under load.

Throughput with threads

Here, all three engines do well: they can be shared between threads, and all of them scale.

From 1 to 8 threads: Praecepta goes from 5,374 to 33,796 decisions per millisecond (6.3×), Camunda from 61 to 451 (7.4×) and Drools from 21 to 146 (7.0×).
Locks: Praecepta's engine is immutable, so threads share it without any.
mixed-1000, 8 threads: 11,721 decisions per millisecond for Praecepta, against 29 for Camunda and 23 for Drools.

Start-up and building

ms	Praecepta 0.1.0	Camunda 8	Drools 10.2.0
Read the DMN and build the engine, warm JVM: real	6.5	22.6	36.1
Read the DMN and build the engine, warm JVM: mixed-1000	45	57	437
First decision in a fresh JVM: real	76	469	379
First decision in a fresh JVM: mixed-1000	240	774	1,005

"First decision" starts a new JVM, reads the DMN file, builds the engine and evaluates one input. On the real table, Praecepta answers in 76 ms, 5–6× sooner than the others. That matters for command-line tools, serverless functions and test suites, and much less for long-running services.

Memory

"Retained heap" is the heap still in use after building the engine in a fresh JVM and running a garbage collection.

At 10,000 rules: Praecepta holds 5 MB, against 133 MB for Camunda and 108 MB for Drools.
Across all the generated tables: it uses 6 to 88 times less.
The real table: Praecepta's footprint there was too small for the measurement to resolve (under 0.5 MB).

Where Praecepta is slower: building FIRST and PRIORITY tables

Build time in a fresh JVM, 1,000 mixed rules	Praecepta 0.1.0	Camunda 8	Drools 10.2.0
COLLECT	0.30 s	0.87 s	1.17 s
RULE ORDER	0.27 s	0.83 s	1.07 s
FIRST	3.6 s	0.85 s	1.15 s
PRIORITY	68.7 s	0.82 s	1.12 s

When it builds a FIRST or PRIORITY table, Praecepta looks for rules that can never fire: the validation described above. The check is exact, and on 1,000 random, overlapping rules it is expensive: 3.6 s under FIRST, and over a minute under PRIORITY. Evaluation is not affected, and the real 119-rule FIRST table builds in 74 ms. Still, a minute is not acceptable, and fixing it is on my list: issue #29 tracks making the check optional, bounded or cheaper.

Praecepta's best case

Feeding a Map costs two hash lookups per column: one to read the value, one to find its mask. With the Maven plugin, inputs are generated records, and string columns with a value list become enums, whose masks are found by position instead of by hashing:

That is about 100 ns per decision on the real table, from an earlier run of the same code. But to keep the comparison fair, everything above uses Map inputs for every engine, Praecepta included.

Being fair: what the numbers do not say

Numbers like these are easy to oversell, so here is what they do not say.

Where the comparison flatters Praecepta, or is limited:

Praecepta does less work. Camunda and Drools are general FEEL interpreters. Even when a cell is a simple test, they evaluate it through machinery that can handle arbitrary expressions, and they return richer results. Praecepta only supports what it can index.
It is still a microbenchmark. It runs in-process, on one machine. A real service adds HTTP and serialisation, which usually cost far more than 20 µs, so in many systems the engine is not the bottleneck at all.
Generated tables are not real ones. Their rules are random, so they overlap in ways real tables may not. Only one real table was measured: the DMN conformance kit's tables all use boolean columns, which Praecepta does not support yet.
Not every option was measured. Drools' compiled (executable) model, generated at build time by Kogito, was not measured; it may be faster than the runtime DMN path I used. Drools' experimental "alpha network" option gave wrong answers on these tables in 10.2.0, so the harness refused to time it.

What Camunda and Drools do that Praecepta does not:

Full FEEL: functions, arithmetic, contexts, lists, and tests across several columns (income > 2 * rent). Praecepta cells are FEEL simple unary tests on one column.
Decision requirement graphs: decisions feeding other decisions, business knowledge models and boxed expressions.
More types: boolean, time and date-time columns (planned).
Tooling and services: visual modellers, decision services, process engines, audit and explanation of decisions.
Proven conformance: Drools runs the official DMN conformance kit; Praecepta has not been run against it yet.
Maturity: large communities, years of production use, and commercial support.

So, if your decisions are mostly decision tables with simple cell tests, and latency, memory or start-up matter to you, give Praecepta a try. If you need full DMN, Camunda and Drools are the better choice.

How to use it

Using it is simple. First, add the engine (it has no dependencies):

<dependency>
  <groupId>io.github.brunopacheco1</groupId>
  <artifactId>praecepta-engine</artifactId>
  <version>0.1.0</version>
</dependency>

Then load a DMN file, bind the inputs, and evaluate:

record Customer(String country, Integer age) {}

DecisionTable table;
try (var dmn = Files.newInputStream(Path.of("discount.dmn"))) {
    table = DmnReader.read(dmn);
}
var engine = PraeceptaEngine.<Customer, String>builder()
        .table(table)                              // hit policy, column types, value lists, rules
        .input("country", Customer::country)
        .numberInput("age", Customer::age)
        .output(output -> output.values().get("tier"))
        .build();

engine.evaluate(new Customer("PT", 30));          // e.g. [gold]
engine.validationReport();                         // overlaps, unreachable rules, gaps

Or let the Maven plugin compile your tables (Excel, CSV or DMN) at build time:

<plugin>
  <groupId>io.github.brunopacheco1</groupId>
  <artifactId>praecepta-maven-plugin</artifactId>
  <version>0.1.0</version>
  <executions><execution><goals><goal>generate</goal></goals></execution></executions>
  <configuration>
    <packageName>com.acme.pricing</packageName>
    <tables>
      <table><source>src/main/rules/discount.dmn</source></table>
    </tables>
  </configuration>
</plugin>

Optional<DiscountOutput> discount = Discount.evaluate(new DiscountInput(DiscountInput.Country.PT, new BigDecimal(30)));

The build fails if the table has errors (for example, two UNIQUE rules that overlap), and only the engine is needed at runtime. The README has the details.

How open is it?

I wanted a small project that is easy to trust. Here is what that means in practice:

Licence: Apache-2.0. The repository is REUSE-compliant: every file says who wrote it and under which licence.
Everything in public: the code, the CI, the modernisation plan phase by phase, the benchmark harness and every result, and the issues. So are the roadmap, the architecture, the security assurance case and the governance, which also says who takes over if I stop.
Release integrity: every artifact is GPG-signed and ships with an SBOM (CycloneDX), build provenance (SLSA, verifiable with gh attestation verify) and third-party notices. The builds are reproducible.
Checks on every change: tests on three Java versions, plugin tests on three Maven versions, an enforced code style with compiler warnings as errors, a SonarCloud quality gate, CodeQL, dependency licence and vulnerability checks, and fuzzing of the two parsers that read untrusted input, on every pull request that touches the engine and for longer every week.
A protected main: signed commits only, and every change arrives through a pull request that passes the checks and is approved by a code owner.
Badges from independent issuers: the OpenSSF Best Practices silver badge and OpenSSF Baseline level 1 (every answer links to its evidence), REUSE compliance checked by the FSFE, and the OpenSSF Scorecard, which rechecks the repository every week: 8.8 / 10.

The lowest Scorecard item is code review, and it is worth explaining. Anyone can fork the project and open a pull request. The check measures something else: whether each change that reached main was approved by someone other than its author. Today that is zero, because I am the only maintainer, and nobody can approve their own changes. The same reason keeps branch protection from a full score: I merge my own pull requests with an administrator's bypass. Every contribution I review raises the first, and a second maintainer would close both. The governance explains how to become one. Which brings me to the next part.

Want to help?

If you would like to contribute, the website gathers the guide, the API documentation and how the engine works, and the contributing guide explains how to build and test it. Here are some good first issues:

I would also welcome reviewers and a co-maintainer: the governance describes the roles and how decisions are made.

What could come next?

These are the features I think would be useful; the roadmap puts them in order for the next year. Tell me which ones you would use: a 👍 on the issue is enough, and a comment if you would like to build it.

Wrapping up

The 2023 trie proved the idea and hit a wall. Bitsets took it further: on these tables, 20 to 2,000 times faster than general-purpose DMN engines, with 6 to 88 times less memory, and honest about what it does not do, including a build that is still slow for large FIRST and PRIORITY tables. Give it a try, tell me where it breaks, and tell me what you would like it to do next.

Namárië | See you | Bis geschwënn | Até mais | À bientôt

Teaching a Machine to Say Namárië

Bruno Pacheco — Thu, 05 Nov 2026 20:27:04 +0000

In my very first Quenya post (so proud of myself!), I listed QuenyaTTS among the tools worth knowing: a text-to-speech system for Quenya built by Annie Zhou for her 2024 master's thesis at the University of Groningen.

I found this project quite interesting and thought that perhaps I could improve it by trying a few different techniques. First, I mined some issues of Parma Eldalamberon (published by the Elvish Linguistic Fellowship) for pronunciation rules that Annie's code might be missing. Second, I tried to extract the phonetics from a recording of Tolkien himself reciting Namárië, published by the Romanian Tolkien Society.

This post is about what changed, and about what happened when I put the synthetic voice next to Tolkien's.

How Annie's system works

A text-to-speech system like this one works in two steps:

From text to sounds. A set of rules turns written Quenya into phonetic symbols (IPA). Elen síla lúmenn' omentielvo becomes ˈɛlɛn sˈiːla lˈuːmɛnn ɔmɛntiˈɛlvɔ: which sounds to make and where the stress falls.
From sounds to audio. A neural model, IMS-Toucan from the University of Stuttgart, turns those symbols into a voice.

What changed in Annie's code

I used Claude to find gaps in how Annie's code converts Quenya into the International Phonetic Alphabet. The rules were rewritten and checked against Appendix E of The Lord of the Rings, Eldamo, several published pronunciation guides, and Tolkien's own notes in Parma Eldalamberon. Some examples: hr and hl are read as plain r and l, w becomes v only at the start of a word, archaic spellings such as þ are read with their Third Age sound, and stress follows the Appendix E rule (never the last syllable; the second-to-last if it is heavy, otherwise the third-to-last). Every rule now has a test.

Annie's original project contained a modified copy of an older Toucan. Now the Quenya-TTS repository holds only the Quenya parts, and Toucan comes in unchanged, at a fixed version. Quenya is given to Toucan as phonetic symbols, and since Toucan has never heard Quenya, it borrows the settings of Finnish, Tolkien's own inspiration for the language.

Toucan starts speaking at the very first moment of the file, so the first syllable came out clipped. The tool now adds a short silent pause before the first sound. A side effect was that the model filled that pause with a little noise, heard as an extra k or p before the first word, so that pause is now muted.

Comparing with Tolkien

Tolkien recorded himself reciting Namárië. I wrote a small script that compares any recording with our output, line by line:

A speech recogniser for many languages (wav2vec2 XLSR) writes down which sounds it hears in both recordings. Comparing that with what our rules ask for gives a phone error rate: the lower, the closer to the rules.
Both melodies are drawn on top of each other, in semitones.

There are two caveats. The recogniser is not perfect; for example, it hears many open e sounds as closed ones. And Tolkien's tape is old and noisy. So the numbers are a guide, not a grade.

Once Tolkien's recording was correctly cut into the lines of Namárië, I ran the script three times, each round fixing what the previous one showed:

Round	What changed	Error rate (ours)	Length vs Tolkien
1	first comparison	27%	0.86
2	slower, flatter melody	24%	0.99
3	silent pause before the first word	22%	0.97

Tolkien's own recording scores 33% against our rules, but listening to it, you can tell that the recogniser misses some of his phonemes. Manual corrections could probably improve that rate, but the purpose of this exercise was to find big pronunciation gaps to fix in Annie's code.

What I learned

The rules agree with Tolkien. Where the recogniser hears Tolkien clearly, he says what the rules predict. The one interesting difference is ly, as in ilyë and hiruvalyë: the rules use a single sound, but in Tolkien's voice the recogniser hears two phonemes, l followed by y. The sources leave both readings open (in Tengwar, ly is one letter with two dots below), so I kept the single sound.

The remaining errors are probably the model's. I don't have access to Annie's trained model, and the few Quenya recordings available aren't enough to train a new one (more on that below). The main remaining issues are:

the model can't make the soft l, so ilyë comes out as "ihe";
a final r is weak and gets heard as l (Valimar, tellumar), where it should be trilled;
the d of undulávë drifts toward b, between two rounded u.

Not enough voice

To see how far existing recordings could take the model, I fine-tuned Toucan on Kaggle with about eight minutes of Quenya readings, for private testing only. After 5,000 training steps, the model sounded better on the sentences it had heard and worse on the ones it hadn't: a textbook case of overfitting. Better rules can't fix that. What the model needs is hours of clean Quenya, ideally from a single voice.

What comes next

My own voice first. I wrote a recording script of 2,500 lines, about 90 minutes of speech split into 25 sessions: first the lines of lesson 1 of Ma Quetilyë Quenya?, then attested phrases, then sentences built from words attested in Eldamo. I record it at home with a small tool that can also play the synthetic version of each line. The same recogniser I used on Tolkien now checks my own takes, and it is humbling: it catches me on nw, ny, au and an initial qu more often than I would like.

Then volunteers. A small website is almost ready, where volunteers can read sessions of the same script in their browser. A reviewer listens to each session and accepts it, or asks for single lines to be read again. A voice is used for training only once it has enough accepted audio.

I changed my mind about one thing since I first wrote this post: the recordings will not be published under an open licence. They are used only to train the model. Every volunteer can download their own recordings and do whatever they like with them, and can export or erase their data at any time, as the GDPR requires. The website, the storage and the training all run on servers in the European Union, in Luxembourg and Portugal.

A voice that is nobody's. A model trained on someone's voice will sound like them. So the model I publish will speak with a blended voice that belongs to no single volunteer. Every audio file it produces will carry an inaudible watermark marking it as synthetic, as the EU AI Act asks, and its licence will forbid using it to imitate a real person.

If you would like to lend your voice, see the volunteer voices issue. I will write a follow-up post once the model has learned to speak with my voice.

Please let me know if you have any feedback.

Namárië | See you | Bis geschwënn | Até mais | À bientôt

Installing FreeBSD on a HP 250 G9

Bruno Pacheco — Mon, 28 Oct 2024 21:36:50 +0000

I’ve acquired a Hewlett-Packard 250 15.6-inch G9 laptop with an Intel 12th Gen Core i3-1215U, 8GB of RAM, and a 500GB SSD. Not impressive hardware, I admit, but I will not run a lot of things locally anyway. So, let’s go directly to the point.

I have installed FreeBSD 14.1. Actually, it is not as daunting as it may sound. The installation process is straightforward and easy to understand. The most complex thing would be partitioning, but in my case, I used the entire disk—no need for dual boot—I let the tool do its job alone.

I will not add screenshots of each step, as much more experienced people have thoroughly covered it. Please refer to this video, from RoboNuggie. Approximately 70% of everything I needed to do is explained in that video.

I will list below what was not covered in that video, like playing protected media, graphics, audio, and WiFi configuration.

Video

This laptop has the Alder Lake-UP3 GT1 [UHD Graphics], which requires drm-61-kmod.

$ cd /usr/ports/graphics/drm-61-kmod
$ sudo make install clean
$ sudo sysrc kld_list+=i915kms

Windows Manager

I am using Mate; for that, I simply followed the FreeBSD Handbook.

Chromium and CDM

I found a couple of tutorials online, but here I will share simpler steps for supporting protected media playback—Netflix, Spotify, etc.—in Chromium:

Install Chromium and Foreign CDM:

$ sudo pkg install foreign-cdm chromium
$ sudo sysrc linux_enable="YES"
$ sudo service linux start

Download ports and FreeBSD source code to compile www/linux-widevine-cdm.

$ sudo pkg update
$ sudo pkg install portsnap git
$ sudo portsnap fetch
$ sudo portsnap extract
$ sudo git clone -b releng/14.1 https://git.freebsd.org/src.git /usr/src

Install Linux Widevine CDM

$ cd /usr/ports/www/linux-widevine-cdm
$ sudo make install clean

Open chrome://flags in Chromium and enable Cdm Storage Database and Cdm Storage Database Migration:
Close Chromium and open again.
You can test if DRM is enabled using https://bitmovin.com/demos/drm.

Printer

I have an HP OfficeJet, and from past Linux experience, I knew about HPLIP. Fortunately, it was also available as a binary to be installed with pkg install hplip.

Audio

Audio configuration is also simple. I needed to load a driver and configure hot-swap from speakers to headphones and vice versa whenever a new device was (un)plugged into the audio jack. I followed this tutorial.

Wifi

This was the most difficult part of the configuration. My first attempt was loading the driver compatible with my card. Apparently, the chipset was supported, and it worked at first. But as soon as I started consuming videos, it proved unstable. I tried a WiFi micro adapter, but it was quite slow. After a lot of reading on forums and some headaches, I discovered the Wifibox project.

It’s a clever idea of running WiFi drivers inside a Linux guest VM and bridging the connection back to the host machine. The footprint is quite small, but I can use the full potential of my WiFi. I followed this tutorial.

Not tested components

I haven’t tested Bluetooth or HDMI audio output.

Tested platforms:

Zoom
Webex
GeForce Now
Netflix
Amazon Primevideo
Spotify

Well, that is it with some manual steps, I have a operating system that is fit to my needs.

See you | Bis geschwënn | Até mais | À bientôt | Ciao

Say hello to FreeBSD

Bruno Pacheco — Thu, 17 Oct 2024 19:57:14 +0000

Hello, Bestie!

I started the hobby of testing operating systems somewhere between 2006 and 2009. However, like many of you, I relied solely on social media to document my experiences. Unfortunately, much like the Library of Alexandria, Orkut is lost — though not necessarily as significant in terms of historical relevance.

Back then, I experimented tons of different Linux distros, including a Brazilian one called Kurumin Linux!

I also explored some unconventional systems, like BeOS, OpenSolaris, OpenDarwin, and others I can no longer recall. VirtualBox was a lifesaver when hardware support was lacking — unsupported hardware is always the ultimate barrier — but whenever possible, I tested systems directly on my machine.

I remember spending hours downloading images and burning them onto CDs. My desktop was decent but still slow and limited, so installations could take up to an hour, not to mention the configuration and updates. Any mistake meant starting over from scratch. Actually, my first Debian experience came from a CD I requested online, which I received a few weeks later. I can’t fully express the mix of emotions I felt with each attempt: exhaustion, joy, frustration, accomplishment, anger, happiness, and even occasional anxiety.

All of this is just to illustrate how challenging it could be, and FreeBSD was no exception. I managed to install it after a couple of attempts. Everything needed to be compiled locally, including Java! It was the only time I ever had the opportunity to recompile a kernel!

The result was an exceptionally fast and lightweight operating system. I used it for a while, but the challenges of version upgrades and limited compatibility with browser technologies of that time (e.g., Silverlight and Adobe Flash) eventually pushed me back to Linux.

In 2015, I bought my first laptop, and that hobby came to an abrupt halt. Laptops often come with hardware specifically tailored to the software they ship with, sometimes even locked down. After a while, I just accepted using Windows with the Linux Subsystem. Everything worked as expected, and I gradually forgot the thrill of testing new operating systems.

My old lad survived nearly 10 years with just a couple of upgrades — extra RAM and replacing the HDD with an SSD — but it's no longer functional, or perhaps I just didn't want to try fixing it. I immediately disassembled it to show my daughter what it looked like inside. I was time to move on.

While searching for a new laptop, all those memories came flooding back. I decided then to buy relatively older hardware (released in 2022), without an operating system or any warranty restrictions. I wanted freedom.

Now it's 2024, and the FreeBSD ecosystem has evolved for the better. Ports and compilation are still necessary for things like certain drivers and DRM-protected content (e.g., Netflix and Spotify), but they are no longer the default or the only option available. It takes just 5 minutes to install the entire OS, followed by several extra hours to configure every possible aspect — from screen brightness adjustments and automatic switching when headphones are detected, to automounting USB drives and optimizing CPU frequency.

The result is once more fantastic, a fast, reliable and secure operating system.

P.S.: I will follow this post with instructions on how to install FreeBSD 14.1 on my hardware.

See you | Bis geschwënn | Até mais | À bientôt | Ciao

My Journey to Open Data

Bruno Pacheco — Tue, 04 Jul 2023 21:02:28 +0000

Well, this is not exactly a technical article. This post describes the end of a quest, and the beginning of a new journey: my first step towards Open Data, a world of fairy, strange people willing to change the world.

My first contact with that world happened two years ago when I started learning Luxembourgish. Quickly, I discovered the lack of online content, community support, and learning tools. Then I decided to use my superpowers to build an application called LOD to Anki. This software aims to export the words from LOD.lu into Anki flash cards. Please follow the links to learn more about them.

Unfortunately, scraping the LOD's content proved to be an inefficient strategy. The HTML structure of the old website was cumbersome, making web crawling complex and slow. How would I keep my dataset updated? How would I ensure the performance of my tool? There was only one answer to those questions. I decided to ask for the data directly.

To my surprise, the Zenter fir d'Lëtzebuerger Sprooch (ZLS) answered back. They shared the link to LOD's dataset, exposed on the Luxembourgish Open Data Platform, and I marveled!

With the dataset in hand, I rapidly developed my project. It was easy to integrate into the software, giving me time to focus on the Anki deck development instead. Thanks to that, all the important words listed by Schwätzt Dir Lëtzebuergesch books series are now documented and shared on GitHub, for anyone to use and learn.

That innocent interaction with ZLS and their dataset helped me make a small but positive impact on society. A few people expressed their gratitude for the software. Moreover, the LOD.lu's audio content was size reduced, with unnoticed quality loss, because I shared László's suggestion on audio compression with ZLS, potentially reducing their network traffic.

Indeed, the planet is round, rotating, and revolving. Two years later, I seized the opportunity to join the fairy people. I am now working for the Luxembourg National Data Service (LNDS). I will be one of the many human beings working behind the curtain, integrating and providing solutions to support research and innovation through data.

I would like to express my appreciation to all the people at Pictet Technologies. These four years of learning and growth were undoubtedly decisive in my career success.

See you | Bis geschwënn | Até mais | À bientôt

The secret of long-lasting code

Bruno Pacheco — Sun, 05 Feb 2023 02:30:44 +0000

I cannot talk about every software developer in the world, but I imagine that most of us had to deal with legacy applications at some point in our careers.

But, before diving into it, we should find a definition of legacy software, and Gartner says:

An information system that may be based on outdated technologies, but is critical to day-to-day operations. Replacing legacy applications and systems with systems based on new and different technologies is one of the information systems (IS) professionals’ most significant challenges. As enterprises upgrade or change their technologies, they must ensure compatibility with old systems and data formats that are still in use.

Now, let us review that definition, to understand the assumptions and reasons for software to be considered legacy.

Software based on outdated technologies, but critical to day-to-day operations.

For me, this is somewhat of a paradox. The software should not use outdated technologies if it is critical to day-to-day operations. So, either both day-to-day operations and the application are old, so the whole thing is old and must be reviewed, or the software took too much time to be developed, so it does not fulfill the requirements anymore.

In the end, this is about how often you review the software requirements. Keep questioning if the way you work is still correct. Or if the technology is still a good fit for your problem. No one should expect that a particular solution will last forever.

Replacing legacy applications and systems with systems based on new and different technologies.

In my viewpoint, Replacing a system represents the end of the line. It means that someone made a terrible decision of not investing time and money to keep the process fine and tuned. Or someone made a wrong technical/architectural choice. Or someone poorly analyzed the requirements. Ultimately, it is too late to fix that.

As enterprises upgrade or change their technologies, they must ensure compatibility with old systems and data formats that are still in use.

Well, that is not surprising and is not a problem for legacy applications only. No matter the size of the application or the technology you use, integration is always a challenge. It is more of a coordination issue and requires regular attention. And it can break at any minute, in unexpected places.

Summing up, Bad decision-making is solely the root cause of a legacy system. The software is not legacy. The legacy (or the burden) is the mindset that kept the software as it was until it became a legacy.

Continuous Refactoring / Upgrading

From a business perspective

The requirements evolve and require regular ongoing review, often needing refactoring to align the code with these changes. That may add overhead to the business analyst, as the new feature needs to be compatible with existing ones. And refactoring may also increase the risk of introducing defects.

But on the other hand, when we choose a shorter path, to avoid needed enhancements, we may postpone fixes to existing bugs, or increase technical debts, which is also dangerous to the project.

So, to business stakeholders, refactoring is an investment. Well-written stories and well-defined test scenarios will guide the developers in the right direction, and BDD and E2E tests are great tools to detect regressions, so don't be afraid of the new.

From the development perspective

Writing code is challenging. Enhancing existing code can be double challenging, depending on how far you are from the new requirements. Touching someone's code can be even dangerous, as you may not have that person to guide you. All this will make any developer anxious.

Regular coders will stay in their comfort zone and keep things as they are. Outstanding engineers will take the task but may fail on the first try. However, with enough perseverance, they will excel.

For me, refactoring is about rethinking and learning. It keeps all senior and junior developers up to date about the technology and the business. The more refactoring you do, the simpler and faster you will develop new features.

Risks of not continually improving your code

Well, your technical debt increases. And technical debt is a concept that refers to the cost of maintaining a software system due to quick and inefficient solutions to problems. It represents the trade-off between short-term development speed and long-term technical excellence. For more details, please follow these links:

Benefits of doing so

Refactoring/upgrading is not only rewriting code/replacing technology with something else. It is all about stability. Tackling technical debt strengthens maintainability, thread safety, security, scalability, and low footprint. All these are crucial factors for a long-lasting project.

But apart from that, keeping a stable project up and running brings satisfaction, visibility, and recognition. Nothing is more satisfying than a well-done job. And you and your project will become a reference for peers and stakeholders.

What to do then

Each project is unique, but there are some steps to follow:

Evaluate your situation and prepare a plan. You want to know where you are and what to do, before starting the journey;
Break it down into small pieces. It will be easier to get accepted and validated. You can start with single components or fix duplicated code. Clean Code provides you with many insights;
Make sure you have good test coverage, it will support you on avoiding regressions. If the test coverage is not enough, TDD (Test-driven Development) is a good thing to start practicing here;
Improve your app monitoring and traceability. Not just to prepare for possible new bugs, but also to look at your current situation. For monitoring, I suggest Prometheus, For traceability on Spring Boot, Sleuth is the easiest choice. Please, read this article understand the concept of Distributed Tracing.

Apart from that, there is not much to do than doing your job as it is supposed to be. Excellent coding principles, clean code, meaningful tests, code review, pair programming, Sonar, intelligent IDEs, AI... Use every weapon you may have to ensure the code you write is well written and well covered.

Conclusion

The golden rule here is: never to stop trying new things, or you are stuck in the past. And most probably, everyone else will waste a lot of time and money doing the same thing you did over and over. At some point, your software will become a legacy system, and everyone will complain. Eventually, it will get replaced.

So, please do not be afraid of changing the code. No piece of code is generic enough to cover all possibilities, nor so well written that is the best solution for the requirements.

See you | Bis geschwënn | Até mais | À bientôt

Optimizing Decision Making with a Trie Tree-Based Rules Engine: An Experience Report

Bruno Pacheco — Tue, 24 Jan 2023 01:41:09 +0000

In Pictet Technologies, my team relies a lot on decision models. These models allow our business analysts to input Compliance business rules directly into the systems with minimal developer intervention. When I joined the company, we used to use both Drools and Camunda. However, we faced severe memory and performance issues, specifically with Camunda, prompting me to explore alternatives.

For those not familiar with these solutions, both are rules engine providers. And a rules engine is a software system designed to process and execute sets of business rules. These rules provide automated decisions based on a set of inputs. In a nutshell, a rules engine is a very sophisticated if/else interpreter. For more details, I suggest you follow this link.

The first challenge I encountered was with the decision model and notation file (or DMN). By the way, DMN is the “standard” format that both Drools and Camunda implement. While it is relatively easy to understand, it is impossible to load the same file on both vendors. Another point is that most of our cases are simple decision tables. If it were not for the number of rules, it would be simpler to code the business rules in Java directly.

But the most critical issue related to these engines was performance. Our DMN-based services struggled to handle concurrent usage. Even on single requests, the process took longer than our clients were expecting.

Starting the journey

Initially, I evaluated alternative solutions, but ultimately, Drools and Camunda were the dominant players in the field when I started these studies. And both were and still are easy to use and integrate with, free to use, and offer tools for maintaining the DMN files.

The next step was using a database, where the rules could be stored and easily accessed through queries. However, this approach quickly resulted in poor performance.

Eventually, I began exploring the possibility of developing my solution, which prompted me to conduct research. That was when I discovered the Trie Tree, a rather basic data structure that arranges words in shared prefixes. Please, follow this link for details on how Trie Tree works. There is also this visualization tool to get acquittance with this data structure.

Image reused from GeeksForGeeks

Upon closer examination, I found that treating each input of a rule as a character in a string, Trie Tree is a good solution for a rules engine. The challenge when I started developing it was the “ANY” value, which allows any input value for a given entry. To accommodate this, it was necessary to accurately propagate the children of the ANY node to all siblings, and vice versa, ensuring the correct branch may be traversed.

Another challenge of implementing the Trie Tree was the multiple rules triggering implemented by both vendors. To achieve it using Trie, the leaf node should contain a sorted collection of rule IDs - the sorting mechanism depends on the Hit Policy selected by the developer. In most of our cases, we use the FIRST hit policy, which retrieves the first element of the collection sorted by rule id.

Reviewing the solution

The overall performance was exceptional, as demonstrated later. However, memory consumption remained high. After studying other Trie Tree implementations - Radix Tree is an example - I developed an algorithm to eliminate ANY nodes without siblings, as it is always the default branch. This approach reduced some subtrees to just one node.

After further testing, I realized that the number of nodes is significantly smaller if I ordered the inputs appropriately. That is a computationally complex problem, but luckily, there is a simple approach to avoid testing all possible scenarios. One should sort the input entries based on the number of ANY values they have. In one particular service, this technique allowed us to reduce the number of nodes from 30k to 1.5k.

Preparing this article

First, I transformed this Trie Tree implementation into an open-source project, which I called Praecepta (Rules in Latin), so anyone can try it out. Then, I added three modules to it, with a decision table based on a real scenario (blurred input/output values). Each module uses a different framework: Praecepta, Camunda 7, and Kogito (the newest Kie solution for the Cloud).

I used SpringBoot 3.0.2, GraalVM 22 (JVM mode), a MacOS 2,6 GHz 6-Core Intel Core i7, running 1000 users for 5 minutes. The idea was to test how memory consumption and CPU usage evolve. Below, I compared the footprint of these three solutions. I collected the total count of requests, throughput, memory consumption, and CPU usage using VisualVM and Gatling.

Beating Kogito and Camunda

The numbers do not lie!

Solution	Requests (total count)	Throughput (mean count/s)	Memory (Peak)	CPU
Praecepta	6.614.663	21.337	~100MB	~25%
Kogito	3.615.549	11.663	~225MB	~30%
Camunda 7	1.238.667	3.995	~450MB	~35%

Conclusions

You can see the results below.

Sadly Camunda 7 did not perform well. It was 3x slower and 2x bigger than Kogito. The last proved acceptable given the numbers, but still, it had twice as much memory as Praecepta. Praecepta, on the other hand, steadily kept memory below 100MB, with low CPU usage and 2x greater throughput, compared to the second place.

The outcome is not that Kogito nor Camunda sucks. It always depends on what we plan and want in our system. If you have a much more complex scenario, Kogito or Camunda may fit better to your needs, but first, you should evaluate other solutions before buying/using one of them.

For our team, a simple data structure had an immensely positive impact. We could provide microservices with a smaller footprint and much higher availability.

For me, It was an excellent opportunity to use my computer science background and learn new things.

Results

Praecepta - TrieTree

Kogito

Camunda

See you | Bis geschwënn | Até mais | À bientôt

Staying Sharp in Software Engineering

Bruno Pacheco — Sat, 07 Jan 2023 21:15:24 +0000

When it comes to working, learning is often a key concern. That is especially true in software engineering, where there is always a way to do something faster, cheaper, or better, which often requires new technologies. In this field, it is also crucial to ensure high-quality code. That includes not only coding, but also dependency management, testing, code review, continuous integration and deployment, tracing, monitoring, and measuring.

Fortunately, most of those tasks can be automated, allowing developers to focus on the actual coding. However, this is just the beginning of the journey to becoming a developer.

Acquiring experience in software engineering is a long and tedious process that requires constant practice and learning. However, it is easy to get comfortable, relying on familiar ideas and solutions. After a year, you may know enough about how and where to do things, but after five years, all the projects may start to look the same. Finding new ways to challenge yourself and try new things is indispensable to avoid stagnation.

I was talking to friends at work and this topic came to life. I will share what I often do to continue learning. Please, join me on this journey.

Online Coding Challenges

One way to keep learning is by participating in online coding challenges. These challenges can be a fun and engaging way to learn, as they often have a game-like structure with small challenges that increase in difficulty as you progress.

One benefit is that coding challenges can help you stay up-to-date with the latest technologies and programming languages. These platforms offer also challenges in different areas, such as algorithms, data structures, and design patterns.

Another benefit is that coding challenges can help you develop problem-solving and critical-thinking skills. Many challenges require you to think creatively and bring solutions to complex problems, which can be a great way to exercise your brain and improve your overall problem-solving abilities.

Coding challenges can also be a great way to build your portfolio and demonstrate your skills. Many platforms allow you to share your progress and accomplishments, and earning badges or ranking highly on leaderboards can be a great way to showcase your abilities to others.

However, this approach can be time-consuming, as it often requires a significant investment of time and effort to finish. Additionally, the competitive nature of these platforms can be stressful for some people and may not be a good fit for everyone.

Have a coding partner

Another way to challenge yourself and learn new things is to work with a peer. Having someone alongside can help keep your motivation up and provide opportunities for feedback and review.

There are several ways you can find a peer to learn software engineering with:

Join online communities or forums related to software engineering. These communities often have members willing to mentor or collaborate with others.
Reach out to local meetup groups or attend industry events in your area. These events can be a great way to meet other software engineers and find potential peers.
Connect with people in your professional network. Ask around to see if anyone is interested in collaborating or learning together.
Consider joining a study group or starting one of your own. You can find other people interested in learning what you want to learn and meet regularly to study and learn together.

Overall, the key is to be proactive and put yourself out there. Don't be afraid to reach out to people and ask if they would be interested in learning together. That is a valuable way to deepen your understanding of a topic and gain new perspectives, but there are potential challenges.

One challenge is time constraints. Depending on your schedules, usually, it is hard to find time to work together. We need to be flexible and work around each other's schedules.

Motivation can also be a challenge when learning with a peer, especially when working on a difficult or complex topic. You must be proactive to keep each other motivated and on track.

Finally, conflicts can arise when working with a peer. You should be open to feedback and find ways to resolve any disagreement that may emerge constructively.

Code for yourself

The benefits of working on projects relevant to your interests or needs are clear goals and purpose. By that, you are more likely to stay engaged and motivated, which can help you learn more effectively.

In addition to the learning opportunities, working on real-world problems can give you valuable experience that can be helpful when applying for jobs or working on professional projects. This hands-on experience can help you stand out in a competitive job market and give you confidence in your abilities.

Finally, seeing a project through from start to finish is very rewarding. Developing a tool or application to solve a specific need can be a very fulfilling accomplishment, as you see the results of your work practically and tangibly.

On the other hand, you may encounter different challenges, like time constraints. Balancing these projects with other commitments, such as work or family, can be quite difficult. Finding time to work on your projects can require careful planning and time management.

Debugging and troubleshooting can also be more challenging when working on your own. Without the benefit of colleagues to collaborate with, you may have to spend more time figuring out problems and fixing errors.

Finally, limited exposure can be challenging when working on projects for yourself. Without a team or organization behind you, it can be harder to get your work noticed and recognized by others. That can make it harder to build a portfolio or get feedback on your work.

To cut it short

While stepping out of your comfort zone can be time-consuming and require a lot of effort, it will help you gain new perspectives and be very beneficial in the long run.

It's imperative to seek out different resources, such as books, courses, real-world projects, or friends, to ensure that you are well-rounded and have a broad range of experience.

Useful links

Brilliant - Huge variety of content, from Quantum Mechanics to Computer Science
3Blue1Brown - Youtube Channel to learn Linear Algebra, Calculus and more
HackerRank - Very good online coding platform
Kaggle - Public datasets and competitions for Machine Learning
NotRocketScience_ - Technical challenges proposed by László
Google Qwiklabs - Hands-on oriented web courses for Google Cloud Computing
LinkedIn Learning - Web courses
Coursera - More web courses
Udemy - And more web courses

See you | Bis geschwënn | Até mais | À bientôt

Covid led me to my first open-source contribution

Bruno Pacheco — Wed, 04 Jan 2023 01:00:58 +0000

It's been a while since I've shared anything here. Mostly because my interests and priorities have changed. But now I'm back, and I hope to produce more content.

Let's go back to 2020, when I stopped writing. The Covid era, baby!

There were people going crazy because they couldn't see other people. There were people baking bread and brewing beer at home. And I was becoming a first-time parent, or at least starting the journey.

I'm an engineer by love and a developer to the bone. Like everyone else, I was looking for something to focus my thoughts on. And an article about a COBOL system that was overloaded in the US caught my attention. Of course, I had heard of COBOL in university, but the most "hardcore" language I had briefly touched was C/C++.

I was bored, and I didn't want to see more of REST, more of C-like languages, or more of architectural problems. I wanted something more basic, easy to start and easy to stop. Why not COBOL? I thought it might be useful in the future.

So, like any developer would do, I started a web course. If you're interested, you can check it out on LinkedIn Learning.

What did I find out? COBOL is an elitist and segregating language. You have to have access to mainframes to code, and you have to have access to paid tools to code and debug. There is only one open-source compiler for COBOL, GnuCOBOL. And when I started my journey, there were zero open-source debuggers.

I was totally disappointed. How could that be? COBOL is a f**** old language. So I started digging around forums and I found an IBM learning platform that was oriented towards COBOL. If I remember correctly, the students got access to mainframes. But one thing caught my attention: there was another frustrated person complaining about the lack of open-source tools to code on a regular computer. They shared that they were writing a COBOL debugger for VSCode.

I tried out that tool and I thought it was a great idea. But soon I realized it wasn't mature enough to debug even one of the simplest tasks I did in the web course I mentioned.

Well, as we say in Rio, I had the cheese and the knife in my hands. I'm a developer, and I wanted to learn COBOL. So why not contribute to that tool? That little comment turned my course in a divergent direction. Soon I forgot about "how to read a file in COBOL" and started asking "how GnuCOBOL transpiles code into C", "how to debug C in the command line", and "how gdb integrates with VSCode."

In the middle of the project, I was already in touch with GnuCOBOL developers, asking them for new compiler features to help debug float and binary data types supported by that compiler. I was also adding support for JavaScript expressions in the debugger inspection view. And in my latest contributions, I was working on debugging remote processes and SSH tunneling.

All of this, all of those long nights coding, just because of a comment on a forum about COBOL.

And you know what? It was an amazing experience. I learned a lot of things, perhaps nothing directly useful for my current daily duties, but at least I contributed to an open-source project, impacting the lives of thousands of other anonymous developers.

See you | Bis geschwënn | Até mais | À bientôt

Quarkus, Kotlin and GraalVM

Bruno Pacheco — Fri, 22 Nov 2019 19:48:13 +0000

During a chat with László, I've asked him for some ideas to practice Quarkus and GraalVM, he suggested to code the classic game Snake (AKA Worms by me :P).

Motivations

Why Quarkus? I've read an article saying that Quarkus is a great and promising solution for Java in the Cloud, as it drastically reduces the application's footprint and has an insanely fast startup when running on native code.

GraalVM is a general-purpose VM for running applications written in a bunch of different languages, allowing a polyglot code. At first glance, I felt it was an amazing thing to try, and so I did. In the end, this first trial wasn't fruitful, due to some strange bug on a node app I was coding at that time, so I just gave up for that moment.

Kotlin has no reasonable arguments to be here except it is a brand-new Java dialect which I was already learning, but I have never used it on something substantial, so why not?

Starting the adventure

I've started the project just reading the guides on Quarkus.io, which are quite hands-on, but superficial. Quarkus is simple to use, as any recent framework for web development. So simple that in five minutes I had a rest service running locally... of course, an HTTP call returning a "Hello World" string doesn't deserve to be called a service, does it?

So, to start your project from scratch, they have implemented a bootstrap command. Please refer to the followin command:

mvn io.quarkus:quarkus-maven-plugin:1.0.0.CR1:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=getting-started \
    -DclassName="org.acme.quickstart.GreetingResource" \
    -Dpath="/hello"

And an easy way to add new dependencies:

mvn quarkus:add-extension -Dextensions="vertx"

Moving on, my first steps were: defining the domain, JPA, H2, a couple of CRUD endpoints and some DTOs. After having this square-shaped code, I decided to migrate it to Kotlin, and bugs started popping up as expected.

The first problem which I had to face was JPA. It requires open classes and by default it isn't true for Kotlin. To fix this, there's a flag to enable JPA support during compilation. I don't like this kind of solution, but this is somewhat my fault as I wanted to use a mature Java library instead of using something more Kotlin-like.

The second problem was the JSON payload serialization. I had some issues with JSON-B (the default option), and then I decided to try Jackson. Again, just for the sake of simplicity, as I was already testing tons of new things.

It worked nicely and the DTOs were cleaner than before. However, another plugin had to be added to the Kotlin compiler (the no-arg plugin option) and a custom annotation to help the compiler identifying the DTOs.

@Dto
data class MatchMapPlayer(
        var playerId: Long,
        var status: MatchPlayerStatus = MatchPlayerStatus.PLAYING,
        var wormLength: Int = 0,
        var direction: Direction = Direction.DOWN,
        var position: List<MapPoint> = arrayListOf()
)

The third problem was similar to the JPA issue. All managed beans have to be open. Can you guess the solution? Yes another Kotlin compiler flag.

So, in the end, my Koltin compiler configuration looked like the following:

<configuration>
  <compilerPlugins>
    <plugin>jpa</plugin>
    <plugin>no-arg</plugin>
    <plugin>all-open</plugin>
  </compilerPlugins>
  <pluginOptions>
    <option>all-open:annotation=javax.ws.rs.Path</option>
    <option>all-open:annotation=javax.enterprise.context.ApplicationScoped</option>
    <option>all-open:annotation=javax.enterprise.context.RequestScoped</option>
    <option>all-open:annotation=javax.ws.rs.ext.Provider</option>
    <option>all-open:annotation=javax.persistence.MappedSuperclass</option>
    <option>all-open:annotation=javax.persistence.Entity</option>
    <option>all-open:annotation=javax.persistence.Embeddable</option>
    <option>no-arg:annotation=com.dev.bruno.worms.dto.Dto</option>
  </pluginOptions>
</configuration>

I've also created an abstract Repository class to have a common behavior for all entity repos (copying Spring), but I had a problem with the dependency injection in the superclass.

I tried using constructor dependency injection, passing it from the child to the superclass using super, but it hasn't worked properly. The work around was injecting the EntityManager directly in the field, like this:

    @PersistenceContext
    protected lateinit var em: EntityManager

Then, I had to change all @OnToMany from List/Set to MutableList/MutableSet.

And finally, I don't remember why, but now all fields in the domain and DTO classes were var, instead of val. I have to check why again.

I've also implemented some business code, which is not important to discuss here (but if you are interested, go to
this link).

And GraalVM enters the scene...

After trespassing the first barrier, I was ready for the next boss (the final one?): compiling the project to native code.

According to Quarkus.io, this shouldn't be complicated as they aim to simplify native code compilation using their on maven plugin. Even their guides being simplistic, they are not lying. But they could have mentioned the Reflection limitation in GraalVM, which will be explained in the following lines.

So, to build the app, you have to run a similar mvn command:

mvn clean package -Pnative -Dnative-image.docker-build=true

By the way, I was building a containerized native code, that's why there's this docker-build arg. They also provide a dockerfile sample.

I thought at this stage that would be enough, but no. After running the build and running the app on Docker, I faced exceptions on Jackson. So, reflection is not supported by default on native code and it took me a while to understand why, and a bit more to find a way to fix it.

On a side note, the build consumes a lot of memory and CPU, almost killing my old Lenovo. :(

So, GraalVM does allow you to use reflection, but for that, you need to add a config file, located at META-INF/native-image/reflect-config.json (it can be in a different folder with a different name, but this is the default path).

First I decided not to manually write this file, and after googling I've found this blog presenting an agent to do this job. The idea is to observe the JVM during runtime and generate the config.

To do this, you simply have to run the app with the following command:

$JAVA_HOME/bin/java -agentlib:native-image-agent=config-output-dir=META-INF/native-image your.jar

After running the app with this agent, the generated file was hugely polluted and it didn't fix the problem anyway, as the agent didn't add all needed classes. So, I ended up typing the file manually. And surprisingly, I only had to add the DTO classes.

The file should look something like this:

[
  {
    "name": "com.dev.bruno.worms.dto.ExceptionResponse",
    "allDeclaredConstructors": true,
    "allPublicConstructors": true,
    "allDeclaredMethods": true,
    "allPublicMethods": true,
    "allDeclaredClasses": true,
    "allPublicClasses": true,
    "fields": [
      {
        "name": "message",
        "allowWrite": true
      }
    ]
  }
  ...
]

Conclusions

I do recognize the benefits of using Kotlin such as nullability, immutability, less verbose code, tons of new coder-friendly functions, however they are not that important when you have clean code and efficient testing.

Also, I don't like polluted POM files, and it annoyed me having to add build plugins, compiler flags and configurations. I felt guilty about using JPA and Jackson though. Perhaps, if I had used something more Kotlin oriented, I wouldn't have had these issues. Let's see what happens in the next project.

Quarkus has an insanely fast startup indeed, and the memory footprint is great. I have used a micro instance on Google Cloud to test the game, and it handled properly the load, without crashing anything. Quarkus is a bit immature yet, as it required some refactoring when I decided to move to newer versions. Nonetheless, it is promising, as it has huge support for different technologies and libraries. I'll use it again.

I have loved GraalVM at first sight, as the wish of a polyglot code is in my mind for a while, and now it's becoming reality. In the end, I didn't use this feature, however, the native code generation fascinated me as well. I didn't like the way it consumes resources though. Compiling any other language code to native is not consuming 10% of what GraalVM has consumed from my machine (not judging...). I would wait for improvements on this area before using it on commercial solutions.

To sum up: I have enjoyed playing with all these new technologies all together. Due to time and availability constraints, I couldn't investigate more. Perhaps improving and refactoring the code. The final solution is not bad and it has proven to me that Java definitely can be used in the cloud, it's just a matter of investment in new solutions, like Quarkus and GraalVM.

Please, refer to the project repository to have a better picture of what I have coded. And feel free to comment out there.