I’d like to point you to this blog article about “cycle stepped” 6502 emulator. It is well described and can be a neat read for xmas vacation.

Read More

Suppose you are developing a boring Jenkins pipline (like Jenkinsfile-s) with no time at all.

You are forced to commit and then run the jenkins pipeline. Jenkins download the code from your LOCAL repository.

To avoid commit& push roundtrip you are using the simple git daemon command to expose your local repository to jenkins. So jenkins see every commit you has just done.

And you end up doing a lot of commits, full of trial and errors: you would like to “squash” them before pushing your work to your remote repository, to avoid co-worker laugh your wasted time(!)

Git can do that, but I have an hard time to find the easier way of doing it, even reading git books!

So let me explain to you:

Read More

Some co-workers started using Apache Kafka con a bunch of our Customers.

Apache Kafka is a community distributed event streaming platform capable of handling trillions of events a day. Initially conceived as a messaging queue, Kafka is based on an abstraction of a distributed commit log[*].

To get this goal, Apache Kafka needs a complex servers setup, even more complex if you want the certification for the producing company (Confluent).  Now, if you are planning to use Kafka like a simple JavaMessaeSystem (JMS) implementation, think twice before going on this route.

PostgreSQL 12 offers a fair (and open source) partition implementation, whereas if money are not a problem, Oracle 12c can happy scale on billions of record before running into troubles (and ExaData can scale even more).

PostgreSQL and Oracle offer optimizations for partitioned data, called “Partition Pruning” in PostreSQL teminology:

With partition pruning enabled, the planner will examine the definition of each partition and prove that the partition need not be scanned because it could not contain any rows meeting the query's WHERE clause. When the planner can prove this, it excludes (prunes) the partition from the query plan.

This feature is quite brand new (popped in PostreSQL 11) but it is essential to a successful partition strategy. Before these feature, partitioning was a black magic art. Now it is simpler to manage.
Read More