Kaveh Shahbazian dc0d

Enhancing Software Verification: Leveraging Business-Specific Signals in Application Logs for Decoupled Testing

Executive Summary

Traditional software testing methodologies, particularly state-based and collaboration-based verification, frequently encounter a significant challenge: tight coupling between tests and the underlying implementation details. This coupling leads to brittle tests that require extensive maintenance during refactoring, undermining development efficiency and confidence in the codebase. This report explores an alternative paradigm: leveraging business-specific signals embedded within application logs for test verification.

While logs have historically been relegated to debugging and operational monitoring, this analysis demonstrates their potential as a robust, decoupled mechanism for behavioral testing. The report investigates the reasons for the historical underutilization of logs in testing, primarily identifying technical hurdles such as data volume, noise, and pars

function: compare R:n to X:n and Y:n {
 if R > X {
  if R > Y {
   result : 2
  }
  else {
    result : 1
  }
 }

🗓️

workspace <- just a plain directory
├── main  <- main checkout
├── branch1
├── branch2
└── branch3

list of worktrees

Crap Code Properly

This post contains some personal experiences formed while working on some personal projects. Do not use any of these in your work or your teams ¯\_(ツ)_/¯.

Directory Layout

Use this directory layout:

.
├── core

A Simplified View of a GenServer

The most famous Actor Model implementation is Erlang Machine, also called BEAM. And OTP is one of the most exciting parts of BEAM. The GenServer is a very flexible and versatile abstraction provided by BEAM. Any server whose design is based on the server/client pattern can be implemented as a GenServer.

A GenServer consists of a mailbox, an event-loop, and a set of callbacks. The runtime concerns are abstracted away. We only need to focus on our solution. Then we pass that to the runtime as a set of callbacks. We are not involved with any concurrency-related concerns!

It sounds stupid to get excited over this. Nevertheless, giant industries rely on this abstraction - and BEAM because it is one of the most interesting cases for the Separation of Concerns principle. It’s like: the GenServer actor (it’s an actor) tells us, “I’ll take care of the runtime concerns (the concurrency stuff), and you take care of the business logic.” And yes, one could argue it is also a case of I

OOP/reduce branching through polymorphism demonstration

code is a liability and must be disposable

All the reduction in revenue comes from the code. All the lost opportunities and overdue time-to-market come from the code. The code causes long lead times. All the bugs come from the code. And for developers all the beautiful weekends, that you could be spent with your kids and your family, but weren't so, come from the code.

Code is a liability, not an asset. The functionality of it could be an asset, assuming you're building something that someone is willing to pay for it. If it was possible to have the functionality, without the code, that would be Nirvana! Unfortunately, that's not possible.

We know that if we want the functionality, we can not avoid the code. Yet, maybe we can try to make the code disposable. The presence of disposable code is less intrusive and you can get on more easily with your life.

There are two aspects to the code production process. First, it is possible to focus on the process of code generation, which nobody likes to talk about b

This talk by Sandi Metz, on OOP, is very interesting. I enjoy watching it from time to time.

	% This is Prolog. This is not Perl.

	:- module(p99, []).

	% source:
	% https://www.ic.unicamp.br/~meidanis/courses/mc336/2009s2/prolog/problemas/

	% P01
	last_of([X], X).
	last_of([_\|Rest], R) :-