Domain Oriented Programming

A Software Design Pattern which brings the principles of Inheritance, Encapsulation and Polymorphism one level up from the Class level to the Subsystem level, and offers a way of realizing relationships between classes so as to achieve dependency inversion by means of propagation instead of injection.

Part 1: Dependency Inversion

The software that we write often invokes other software to get parts of the job done. These are known as Services or Dependencies. If Class A is making use of some Class B, then Class A depends on Class B, so Class B is a dependency of Class A. 

The principle of Dependency Inversion (⬀) says that a class should not contain any direct calls to specific instances of any of its dependencies. Instead, it should receive these instances as parameters during initialization.

That's all very nice, but passing dependencies around can become quite a complicated business, and in large systems it can become a nightmare.

On Validation vs. Error Checking

Let me start with a couple of pedantic definitions; stay with me, the beef follows right afterwards.

Conventional wisdom says that validation is different from error checking.

• Validation is performed at the boundaries of a system, to check the validity of incoming data, which is at all times presumed to be potentially invalid. When invalid data is detected, validation is supposed to reject it. Validation is supposed to be always on, you cannot switch it off on release builds and only have it enabled on debug builds.
• Error checking, on the other hand, is performed inside a system, checking against conditions that should never occur, to keep making sure that everything is working as intended. In the event that an error is encountered, the intent is to signal a catastrophic failure. Essentially, the term Error Checking is shorthand for Internal Error Checking. It can be implemented using assertions, thus being active on the debug build only, and having a net cost of zero on the release build.

So far so good, right?

Stackoverflow is not suitable for poignant questions

As the screenshot proves.

Index of notable GitHub projects

Intertwine (C#, Java)

A framework for automatically converting method invocations of any programmatic interface into a single-method normal form and converting back to invocations of the original interface.
https://blog.michael.gr/2022/12/intertwine.html
For C#: https://github.com/mikenakis/IntertwineCSharp
For Java: https://github.com/mikenakis/Public/tree/master/intertwine

VsDebugLogger (C#)

Speeds up Visual Studio debug output by orders of magnitude.
https://github.com/mikenakis/VsDebugLogger

bathyscaphe (Java)

Deep immutability assessment (and coming soon: thread-safety assessment) for java objects.
https://blog.michael.gr/2022/05/bathyscaphe.html

testana (Java)

A command-line utility for running only those tests that actually need to run.
https://blog.michael.gr/2018/04/github-project-mikenakis-testana.html

classdump (Java)

A command-line utility for dumping the contents of class files.
https://blog.michael.gr/2018/04/github-project-classdump.html

bytecode (Java)

A lightweight framework for manipulating JVM bytecode.
https://blog.michael.gr/2018/04/github-project-bytecode.html

On Recruiters

Image from Freepik

Note: This post is a draft; work-in-progress.

If you have ever been in the job market looking for the next move on your career, you cannot have failed to notice that job advertisements on various job boards fall in two distinctly different categories: those that disclose the identity of the employer, and those that do not.

As a rule, a job advertisement will not fail to state exactly who the employer is when the employer is doing their own hiring, either direcrly or via an exclusive partnership with a hiring agency. On the other hand, when the job advertisement keeps the identity of the employer a secret, referring to them as "my client", or utilizing subterfuges such as "a well-established company", "a leader in the field", etc., this means that it has been posted by an independently acting recruiter (henceforth simply "recruiter") who does not have an exclusive agreement with the employer. (And the term "my client" is almost always a lie.)

The reason for the secrecy is not understood by most candidates; a common misconception is that some employers wish to remain unidentified when hiring. This is true in such an exceedingly small percentage of cases that it is almost mythological. The true reasons for secrecy in job advertisement are the following:

• To prevent candidates from bypassing the recruiter and directly contacting the employer.
• To prevent other recruiters from finding out about the job and creating their own competing job advertisements for it.
• To post advertisements about jobs that do not actually exist. (You might say, huh? -- I will explain, keep reading.)

The case for software testing

What to reply to a non-programmer who thinks that testing is unnecessary or secondary

At some point during his or her career, a programmer might come across the following argument, presented by some colleague, partner, or decision maker:

Since we can always test our software by hand, we do not need to implement Automated Software Testing.

Apparently, I reached that point in my career, so now I need to debate this argument. I decided to be a good internet citizen and publish my thoughts. So, in this post I am going to be deconstructing that argument, and demolishing it from every angle that it can be examined. I will be doing so using language that is easy to process by people from outside of our discipline.

In the particular company where that argument was brought forth, there exist mitigating factors which are specific to the product, the customers, and the type of relationship we have with them, all of which make the argument not as unreasonable as it may sound when taken out of context. Even in light of these factors, the argument still deserves to be blown out of the water, but I will not be bothering the reader with the specific situation of this company, so as to ensure that the discussion is applicable to software development in general.

In its more complete form, the argument may go like this:

Red Heart Stickers

In this post I am documenting sightings of these red heart stickers.

If anyone knows what these are, who sticks them, what for, please do let me know.