NoSQL schema design - A question that pops up frequently in developer discussions is 'how to structure your data in a NoSQL way?'. To shed a light on this, we have a look at the approach invented 50 years ago and still an all time favorite.

Development Containers are supposed to liberate your development environment from a specific local installation, like container technology liberated your runtimes (a.k.a YAMLed them into Docker or Kubernetes). Development != Runtime Containerization for development has some overlap and quite some difference to containerization for production:

Imagine, you are tasked with maintaining a Java application that needs to run on more than one Java version. You want to ensure that it compiles, tests and builds on all of them. This is our story, buckle up, there are a few moving parts

GitHub Actions are rapidly becoming my favorite CI environment. Their marketplace has an action for everything. Sometimes it takes a little trial and error before things work smoothly. This is one of that stories. Authentication is everything Imagine the following scenario: you have developed a set of private TypeScript (or JavaScript) packages and have successfully deployed them to the private GitHub npm registry under the name @myfamousorg/coolpackage - where myfamousorg must match the repository owner (org or individual). Now you want to use them in your application. That application shall be packed in a Container and made available in GitHub's private registry. All that automated using GitHub Actions.

TOTP and vert.x - Time-based one-time passwords (TOTP) are a common security feature in Identity Providers (IdP). There are use cases beyond IdP, mine was 'Understanding what it takes'). TOTP interaction You have two phases: enrollment and use. During enrollment a secret is generated and (typically) presented as QR Code. A user points one of the many Authenticator apps to it and gets a numeric code that changes once a minute. When you use it, you pick the current number and paste it into the provided field. The backend validates the correctness with some time leeway. What it is not Typically when enrolling you also get recovery codes, sometimes called scratch codes. They are NOT part of TOTP and implementation is site specific and not standardized. An implementer might choose to check your recovery codes when your TOTP fails or provide a separate interaction using those. The initial confirmation, is actually the first instance of "use" and one could have a successful enrollment without it. This is depending on the implementation. It isn't foolproof. An attacker could trick you into typing your TOTP code into a spoofed form or just hijack your session (cookie). That's why responsible web apps run a tight security with CSP and TLS (and once browser support is better Permission Policy)

TDD is favored by very succesfull engineers as a means of accellerating software development by preserving quality. Objections are plenty. The talk by Burt Hufnagel tries to address those. The TDD Paradox: TDD requires you to write more code, so you can be done sooner. It's like learning to drive a car. Your first mile takes, give or take, 40-50h to complete: Driving lessons, driving tests, get the license issued before you drive. You can walk a lot more in 50 hours, you get the drift...

Case insensitive deserialization - Growing up in Windows with BASIC you learn case doesn't matter, so Color is the same as COLOR or cOLOR when it comes to variable names. Same applies to @Formula or item names in Notes documents. On the other side, Linux, Java, JavaScript and JSON are very much case sensitive. This poses a challenge when deserializing (handcrafted) JSON files.

The Quest for a software documentation system - Software documentation is a thankless business and never complete. Picking the right system can make or break your documentation success Contenders We have a number of options commonly used, each with strengh and weaknesses.

No man is an island and no code you write lives without dependencies (even your low-level assembly code depends on the processor's microcode). Testing (with) dependencies can be [insert expletive] The general approach to make dependent code testable is Dependency injection. Instead of calling out and create an instance of the dependency, the dependency is hand over as parameter. This could be in a constructor, a property setter or as method parameter.

Given that Domino once was build to run on 486 capacity of servers, Docker and Domino are posed to be a match made in heaven (eventually). Jesse shared shared his Weekend Domino-Apps-in-Docker Experimentation, Paul shared his learning points and Daniel provided the invaluable Domino on Docker build scripts. So it's time to contribute my share. The topic is slightly more exotic