How to organize a Visual Studio Solution

Visual Studio is a capricious product, and its "Solution" subsystem is especially capricious. When you look at what options are available you might think you have a great degree of freedom to structure things the way you want, but as you will inevitably (and painfully) find out later, many things have to be done in precisely one, entirely undocumented way, or else there will be pain of the worst kind: Visual Studio will malfunction either without any error message, or with error messages that are completely unhelpful for locating and fixing the problem.

Here is a list of things I have (painfully) found out over the years.

Incident Impact Calculation Formula

The Mike Nakis formula for calculating the impact of an incident:

I = S × G × T

Where:

• I is the impact of the incident.
• S is the severity of the incident.
• G is the geographic pervasiveness of the incident.
• T is the temporal pervasiveness of the incident.
  

Thus:

On the "Dotfuscator" tool by PreEmptive Solutions

I am giving this tool a try at work, and I am encountering a great many problems with it. I decided to publicly document my findings.

[SOLVED] Maven deploy fails with status 422 unprocessable entity

It has been more than a year since I created this question on GitHub Community; a couple of days after that I found the solution by myself, so I answered my own question, and to this date comments keep being added by people who were helped by my post.  

When I look at it today, I notice that my answer has this particular style, this grumpy indignation which has become so characteristic of me, after a lifetime of battling with lame software, and even worse, with lame error messages. 

I thought I should share this on my blog for posterity.

Here is the link:

Program Code is Uncountable

There are some words in English that are uncountable. For example: cheese, furniture, music, evidence, research, knowledge, information, etc. When we speak of those things in plural, we still use the singular form: "I would like to order a four-cheese pizza", "Let me give you some of my furniture", "We need to consider all the evidence", etc.

If you are using mock objects you are doing it wrong.

Abstract:

The practice of using Mock Objects in automated software testing is examined from a critical point of view and found to be highly problematic. Opinions of some well known industry speakers are cited. The supposed benefits of Mock Objects are shown to be either no real benefits, or achievable via alternative means.

So the "master" branch is not kosher anymore

The origins of the debate go so far back that they are lost in the mists of time, but a good starting point (which contains references to prior debate) is an Internet Draft from 2018 titled Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs. Some especially woke communities like the Python community had already started applying some of the recommendations in this draft as early as 2019, but things really picked up steam in 2020, with the murder of George Floyd.

On messages and message-passing

Over the decades, numerous software system architectures have emerged which require invocations across subsystems to be done via message-passing instead of programmatic interface method calls. Such architectures are so common that many programmers have come to regard message-passing as an end in and of itself, oblivious of the fact that it is nothing but a (poor) technical mechanism for accomplishing a certain architectural goal.

On UML (oh, do not get me started)

The UML logo, by Object Management Group®, Inc. from uml.org; Public Domain.

This post is intended as support material for another post of mine; see michael.gr - The Deployable Design Document.

The Universal Modeling Language (UML) (Wikipedia) was intended to be a standard notation for expressing software designs, and to replace the multitude of ad-hoc notations that software architects have been using on various mediums such as whiteboard, paper, and general-purpose box-and-arrow diagram-drawing software. The idea was that by following a standard notation which prescribes a specific way of expressing each concept, every diagram would be readily and unambiguously understood by everyone.

It has miserably failed.

The famous "Could not load file or assembly or one of its dependencies" error message

If you have ever done any software development under Microsoft Windows you have probably come across this famous error message: "System.IO.FileNotFoundException : Could not load file or assembly 'Acme.dll' or one of its dependencies. The specified module could not be found." 

Modern software makes heavy use of dynamic link libraries, and the problem with this kind of libraries is that for various reasons they might not be there when you need them, resulting in runtime errors. This is the runtime error you get under Windows when this happens.

Naturally, when you see this message, the first thing to do is to check whether Acme.dll is there, and what you usually discover is that the file is indeed there. When dealing with computers, most error messages that you come across tend to leave some room for troubleshooting, but when the system is reporting that a certain file does not exist on your very own filesystem, while the file is most certainly there, the situation seems really hopeless. You are stymied. 

On JUnit's random order of test method execution

This is a rant about JUnit, or more precisely, a rant about JUnit's inability to execute test methods in natural method order. 

Definition: Natural method order is the order in which methods appear in the source file.

What is the problem?

Grumpy Posts

Besides the delicate grumpiness which is gratuitously scattered throughout this blog like the golden rays of light in a gentle sunset, there exist a few blog posts which have been written with the express purpose of venting out some major grumpiness.

Here is a list of them:

On UML (oh, do not get me started)

The Wild, Wild Web

On JUnit's random order of test method execution

On UUIDs and GUIDs

On scripting languages

Why Oracle sucks

The GWX (Get Windows 10) KB3035583 trojan horse

"By using this site, you agree to the use of cookies."

(The list will be extended as more posts are added.)

What is wrong with UUIDs and GUIDs

Introduction

Universally Unique Identifiers (UUIDs) otherwise known as Globally Unique Identifiers (GUIDs) are 128-bit numbers that are often used to identify information. In its canonical representation, a UUID looks like this: 2205cf3e-139c-4abc-be2d-e29b692934b0.

The Wikipedia entry for Universally Unique Identifier (⬀) says that they are for practical purposes unique and that while the probability that a UUID will be duplicated is not zero, it is so close to zero as to be negligible. Wikipedia then does the math and shows that if 103 trillion UUIDs are generated, the chance of duplication among them is one in a billion.

Despite the infinitesimally small chances of receiving a duplicate UUID, there exist programmers out there who are afraid of this actually happening, and who will not hesitate to suspect duplicate UUIDs as being responsible for an observed malfunction rather than first look for a bug in their code. Clearly, these folks do not understand the meaning of infinitesimally small chance, so let me try to explain it:

Infinitessimally small chance means practically impossible to happen, and the practically part is only mentioned for scientific correctness: practically, you can disregard the word practically and consider it as simply impossible to happen.

Great. Now, let me tell you why I hate UUIDs.

On scripting languages

Foreword

Historically, the difference between scripting languages and real programming languages has been understood as the presence or absence of a compilation step. However, in recent decades the distinction has blurred; from time to time we have seen:

• Interpreters for languages that were originally meant to be compiled.
• Compilers for languages that were originally meant to be interpreted.
• Scripting engines internally converting source code to bytecode before interpreting it.
• Real languages compiling to bytecode which is then mostly interpreted and rarely converted to machine code.

So, compiled vs. interpreted does not seem to be the real differentiating factor; nonetheless, we can usually tell a scripting language when we see one. So, what is it that we see?