std.out of RagingGeek

In the grim darkness of the 41st millennium, there is only war. Amidst the bloodshed and destruction, there is a legend that is whispered in hushed tones by the few who dare to speak of it. He is known as Santa Claus, a figure shrouded in mystery and fear.

Long ago, Santa Claus was a benevolent being who brought joy and cheer to the masses. But as the ages passed and the galaxy was consumed by darkness, Santa Claus changed. He became twisted and corrupt, his heart blackened by the horrors he witnessed.

Now, Santa Claus prowls the battlefields of the Imperium, searching for those who have been naughty. He punishes them with his bag of grim presents, which are said to contain all manner of torture devices and other foul gifts.

Once upon a time in the city of Tarkov, there was a man known only as the Ghost. No one knew his real name, or where he came from. All they knew was that he was a skilled combatant and a force to be reckoned with in the city's chaotic streets.

The Ghost was a mysterious figure, always shrouded in secrecy and confusion. Some said he was a former special forces operator, while others claimed he was just a simple mercenary. Whatever the truth may be, one thing was certain - the Ghost was a survivor.

He had managed to stay alive in Tarkov for years, long after the city had been sealed off from the rest of the world. The authorities had turned the city into a lawless battleground, where rival factions fought for control of its valuable resources.

Amidst the chaos, the Ghost roamed the streets, taking on any job that would keep him alive. He was a solitary figure, preferring to work alone rather than join any of the city's factions.

But there was one thing that set the Ghost apart from everyone else in Tarkov. It was the jingle of dog tags in his pocket, a constant reminder of the enemies he had slain in the city's streets.

To the Ghost, the dog tags were more than just a memento. They were a symbol of his determination to survive, no matter what the cost. And to the populace of Tarkov, the jingle of those dog tags struck fear in their hearts.

For they knew that wherever the Ghost went, death was sure to follow. And so, they whispered his name in hushed tones, hoping that they would never cross paths with the fearsome survivor.

Case 31: The Eloquent Sandal

In this case we have a question posed to the Master Kaimu about the nature of NULL, and if it is a value, or the absence of value. he replied to the students “Null” and walked away. This led the monks to continue the debate into the wee hours of the night. During this discussion a monk throws a sandal through the air in frustration at the banter, and the monks contemplate if the sandal was a eloquent call for silence, or an absence thereof.

Null and its properties can be vexing for new developers, I have known a few that have felt that 0 and Null are for the most part identical, to be treated as having 0 of something, or in the state of boolean, to be considered false. NULL is much more nuanced and can actually mean different things depending on how your business rules wish to interpret it. 

To completely disambiguate this, NULL in of itself is the absence of data, it should be a representation of the UNKNOWN, a placeholder value that fills a column or variable that has not been provided a knowable value. What this means to your system may vary, and generally should receive a “DEFAULT” behavior. If your system defaults open/positive, then it may conduct behavior as if the NULL really contained a positive value in your system, say you have a system that mails paper bills to customers if they choose, or if they haven’t chosen otherwise. In this case, your table of customers might have a boolean field that indicates if the customer has elected for electronic billing. NULL in this table may indicate that the customer hasn’t yet contacted the business and elected in either direction. You still have to bill them, so you will likely send them a paper bill as that was the default behavior well before paperless was even an option.

On the flip side let’s say you have a telecommunications process at the same company, this telecommunications process sends useful SMS messages to customers when there is something of interest happening with your business. This process due to telecommunication regulations requires an opt-in approach, where people must explicitly give permission to receive your texts. In the event of a NULL in this field, you would opt toward the negative, and not send the text, in case they did not actually want to receive one.

Now in both of the above examples, it is usually better to assign default values, though that also eliminates some information from the system. NULL can be useful in measuring despite itself having no intrinsic value. Consider that if a field in the table is NULL when the customer has not provided a response, and false or true when they do, then the NULL itself can be used in reporting and projection. You can measure the total number of Trues, the total number of False, and the total NULL records, and determine the % of people using the system, the percentage of people refusing the system, and the % of people that haven’t leveraged the system in either direction. This can then be used to determine marketing strategies to move the NULL’s into one of the camps. 

Case 30: Cups

In today’s case we have a lesson in integers and a bit of Java as well. Here the monks are troubled by a program that is throwing errors about the array index being out of bounds, despite the array being declared at 1000 elements in length and that the single byte integer index they are using goes to 255, which the reader must assume that their data being processed is under that threshold. The master then asks what the broom in the corner is, and when the monks rightly respond that it is a broom, the master begins swinging it around his head causing massive destruction within the room, shouting “not a broom”.

The lesson we have here is buried in the details, firstly, Java does not have unsigned integer, so what they believe is a maximum value of 255 is actually -127 to 127 with a bit remaining for signage. Thus when their integer increments and overflows it’s max value, it reverses the sign and thus escapes the boundary of the array. The broom is used to demonstrate that not all bits are the same, some carry numeric information, and others carry details about that information.

Case 29: Goldfish

In today’s case, we have a tale of how a particular nun rose to be in charge of all concerns of the temple. In the story we see her compete with a monk of the order, in which they must fix the ponds in front of their monastery that have become overgrown and choked of life. The monk toils and strips his pond of all debris, refills the area with quality water, and then buys expensive fish to adorn his pond daily. Each day the Nun does nothing, or at least it appears so by the head of the monastery. This angers the Abbott, and he threatens punishment. On the end of the story we find the nun had in fact dug trenches in a way that she could easily purge the stagnant waters, and then replenish them from a mountain stream easily, thus bringing the stream borne fish into her pond. Thus she was made head of automated testing. and we are left to assume this lead to her rise in power.

The point of the allegory here I think is that one can toil through repetitive tasks and burn time and money doing so, or you can automate your processes and be rewarded. I’ve definitely seen both sides of this equation. Testing certain types of code can prove difficult if the automated testing solutions haven’t quite matured for a target market. We have great tools like JUnit for testing Java, PHPUnit for PHP, and JSUnit of course for Javascript, not to mention many other tools undoubtedly out there on the market to simplify developer’s lives. Hand testing code is unwieldy, and will almost always guarantee gaps in testing and bugs in production. This isn’t to say that automated testing will close all gaps and eliminate all bugs. But automated testing doesn’t get tired, it doesn’t dislike tedium and won’t cast it’s hands up and say “I tested that 5 iterations ago, nothing should’ve happened to it, so I can skip it”. That is a strength, that if you follow a TDD or at least a reasonably thorough test writing regimen, can ensure that the boring tests don’t get overlooked due to time and patience.

TDD is I think an ideal approach, that I haven’t done the research enough to know how widely spread it is. To be honest the idea sounds overkill, where you write the smallest available test that will fail, then write code to fix that “bug” like “I need a car class, so I’ll test for the ability to make a new car, when that test fails, I’ll write an empty class declaration for car, then the test passes, now it needs x function, so I’ll write a test that calls x function, when that test fails, I’ll fix it by writing an empty function body called x.” This methodology is certainly comprehensive and in the end of the development cycle you will have a code complete test suite that will test all facets of your application, but at the same time, if you’re writing tests just as much as code, you’re effectively doubling the amount of time for your initial build, and I’m certain there aren’t many development houses willing to absorb that up front cost, no matter how attractive the regression test suite would be. Alternatively you can design and build, then build a test harness around your new functionality, thinking of all possible permutations of use and misuse and verify your tests come out as expected, this may not be as comprehensive, but makes for a reasonable compromise.

Case 28: Echo

Here the a Server Ops Monk is conducting a port scan on a system and finds some ports he believes are no longer valuable to be open and services running. he goes to tell the abbott of these services and that they should be shut down as they serve no value. The abbot then sends the monk to the mountain as punishment for a year. There he has an old terminal which occassionally sends him data. He is unable to reply with anything but the exact message that was relayed to him. Thus he was enlightened.

In this case I believe this may reveal some details about the infrastructure that the author works with. Here we have talk about Echo and Discard Protocols, which in modern computing do not serve much purpose. As the echo protocol simply returns the exact payload that was sent to it, while the discard protocol drops whatever is sent to it. In modern systems these are disabled by default as they are not commonly needed. The monk being given a VT220 is relevant information here, as terminals operate either in a half-duplex local echo, or rely on a remote echo in order to service the screen reflecting what the user is inputting. So in environments where terminals might be still in use, or old legacy code is harnessing it for some purpose that was derived from those old systems, these services are still valuable.

Case 27: Koan Zero

Here the temple scribe who writes the Koans of the day(the articles present on thecodelesscode.com) is approached and questioned as to why the Koans do not start at 0, which would be more logical for koans about programming. The scribe realizes the missed opportunity and sulks about the matter. Until an Abbess presents herself and reveals to the scribe a way to correct the situation. As all koans are built upon those that came before, one must only subtract the wisdom of the koan to arrive at koan Zero, and so forth for any negative values prior. The scribe was thus enlightened, but also tasked with double the efforts.

Case 26: The Uncorrected Monk

Here we have a simple case, in this case the Master is analyzing some code that was written, and is seen crying at his keyboard over the poor quality of the code. Priests come to attend and find out why the Master is weeping, when they discover it is due to poor quality code they immediately indicate that the monk who wrote the code should be corrected, and that it start with a simple whipping. The master relents and lowers his robe to reveal his back in preparation for the lashing.

Case 25: Compromise

In this case study, we have a coding version of Solomon’s Judgement. Two developers come before the Master seeking a decision on which strategy to employ on implementing some change. Both were sure that their method would be the best and put up their strongest arguments. The Master then determined that the solution should be split in half, and that each monk shall perform their half in their preferred solution. Both of the developers then argued that it would be chaotic and not the best solution for their project. To which the Master agrees.

While there is no outcome witnessed in this case, I believe the Master attempted to get the pair of developers to open up to compromise, by showing them the only alternative. Often times developers get caught in their ways, believing that their methods are the best methods, often because they are time tested and worked for that developer well for previous projects. Many developers may approach the idea of using a different methodology cautiously, fearful of the impacts such changes to their workflow may have. Thus developers often stick to their guns and advocate for their chosen method as the best method. This can be unfortunate as the realm of computer science is always advancing and modern techniques are constantly being developed. 

Developers should do their best to keep an open mind, and engage with people presenting alternatives to the current methodology where possible. Sometimes new techniques can bear fruit, we are in an eruption of new tools and new approaches to tasks(TDD, Agile, DevOps, Frameworks), so it makes sense that there may be some that are worth taking some time to vet out.

Case 24: The Red Notebook

In today’s case study we have a monk who is attempting to decipher the puzzle that is one of the elder monks, who has a propensity to respond to inquiry with null. The monk set out to log all of the possible states in which Kaimu the elder would respond with null. After a period when asked if he had deciphered the answer, he responded similarly and was beaten by his peers. The Master heard of this and sent a questionnaire to the young monk to which he received a handful of answers, mixed with null and silence. The Master then sent a request to educate the young monk for several incorrect responses, and then reward the ones who beat him for their service.

The underlying tale here is that the monks can be seen as processes in a system in this case. Here a monk attempting to monitor another monk to determine why sometimes the monk would respond with null. The monitoring monk fails to find the flaw, and responds to his peers with null on inquiry, this causes them to beat up the monk, alerting the elders to the fact that there may be an issue with the monitoring monk. The Master submits a series of probing questions, and based on the outcome knows what steps to perform to correct the monk, and replenish his notebook so that he may try again.

To fully translate this, you have a process that runs that sometimes returns an unexpected null(a NullException) so you write a process that monitors for Null Events(a Catch), and logs the times that it occurs such that you can remedy the Null conditions. However this process also returns Null Exceptions of its own. Here the Master who is the programmer assigned to this system does some debugging by trying to feed the Monitor various inputs attempting to determine which of the many possible queries will result in incorrect responses. These are then remedied through a code change, and the monitor put back in place to continue its efforts.

Ideally this kind of testing should have been conducted before the process was put in place, In the example however it is clear that the example that the faulty process was caught in production. This is why unit testing done at the Dev, QA and UAT levels need to be comprehensive to ensure a robust system. 

Dev’s have an ugly habit of shortsighted testing, many of them consider the happy paths, or focus on the code that they changed, and may not consider regression or negative paths are worth their effort. These Dev’s move the technical debt of refactoring and rework right on the timeline, thrusting Risk and Rework onto QA. QA may or may not catch the bugs if their test plans don’t have adequate code coverage or do not anticipate possible dependencies breaking with the change and thus do not regression adequately. This then allows the bugs to slip another gate and land in the hands of User Testing. User Testing while good at detecting unexpected user behavior and impact to the system is not always as comprehensive as QA, and is likely to miss edge case scenarios as well, resulting in defects being released to the wild.

This explains quite a bit on why Test-Driven Development has begun to take off in a great many places, for if you write a test, then the minimum code necessary to complete that test, you will in a majority of cases end up with strictly tested and high quality code. The downside to this methodology is that your test code ends up being more expansive and more time consuming than the actual application being developed. Management that is focused on short delivery timelines and accepts the risk of a few bugs making their way into the final product may not accept TDD as a good methodology for them.

Case 23: Shape

In this story we have a nun walking past a monk coding, she looked at the code and declared that it wasn’t right, and walked away. The monk complained to the abbess of the temple that the nun had judged him unfairly. The abbess then goes to the nun seeking to correct her poor behavior, and is then shown the error of her thinking.

The abbess in the story says that the code runs completely satisfactory and saw nothing wrong with it. the Nun then takes the clay pitcher she had been working on, batters it into near oblivion and then pours water into it, the water holds, and thus the nun says that the jug must then be satisfactory.

This story is all about style. You can have code that runs perfectly, with no bugs or errors of any discernable kind, and still have a mass of horribly written mess. This is where nightmare tales of spaghetti code dwell. Stories of applications that work, until they inevitably don’t, or need to be extended in some fashion, and the developers left behind(assuming the coder has smartly left the organization in search of other repositories to defile) are then tasked with making sense of the glob of code, in order to fix/enhance. This results in a lot of swearing and a lot of wasted man-hours spent in analysis.

Code style, the shape the code takes is just as important as it’s functionality. Ultimately the shape of the code is meaningless to the computer, as once the code is compiled, or interpreted by the system, the original shape has typically been optimized and converted into something that probably only barely resembles the code we have written. Code style and shape are important for workplace sanity however, comments on obscure lines, good and consistent indentation style, and placement of braces, are all very important. What is not entirely important are the silly brace placement and tabs vs spaces debates that developers get caught up in, due to their own personal preferences and anal retentiveness. The importance, is that the project have consistent bracing and spacing. Whether you are a tabs guy, or a spaces guy, I could care less, as long as your code is consistently one or the other. you will find my code typically is tabbed with K&R 1TBS bracing, but that doesn’t mean I won’t adapt to whatever is in front of me. The hard rules of coding dictate that you:

Have a style of some kind, absence of style is not a style

It is consistently applied.

That you adapt your style to the existing style of the project if maintaining legacy code.

Case 22: Safety

In todays study, we have a monk who seeks to use a 3rd party library in his code, and has been told that he may, assuming he build a wrapper to provide an interface, when the Master hears of this he suggests that the priest who advised the monk and the Master ride together. Upon stepping into the priest’s car, the monk finds the car has had the majority of amenities removed, and the hood welded shut. The master claims this is great fortune, for the amenities would prove dangerous distractions and the hood would only give people access to ruin the system. 

This story is a common one in software development, where people decide to envelope complex code in some form of wrapper or functionality that ensures ease of use while also obfuscating what lies beneath, abstracting it away. In a way this methodology can be seen everywhere in modern software development. No longer do we code in assemble or machine code, in direct communication with the bare metal beneath our code abstractions, instead we code in a language that translates, or compiles into the machine instructions required. So we can definitely say that some abstraction is a good thing. I think that the master in this story seeks to advise the priest in the risks that wrappers impose. When you wrap behavior and abstract away the actual library you are utilizing you will almost certainly do the following:

add additional complexity to the system, by creating an interface layer that is proprietary and may not be as easily understood as compared to the direct library access, which is typically better documented and accompanies the library.

create artificial boundaries that limit the developers trying to utilize the system. Typically an interface will be purpose built, and attempt to shield “unnecessary” features from the developers on the other side, this of course limits usage to what is expected behavior, and limits the versatility of the library being purposed

Case 21: Interrupt

This codeless code entry is a rather silly topic, one that is philosophical and geeky, but doesn’t really set out to evoke thought on the nature of computer science.

Case 20: Neither Yes Nor No.

In this case we have the Java Master, a nameless nun, and the god of silence between words speaking of the nature of a database column named complete. This column takes a 1 a 0 or potentially a null value. The nun is trying to ascertain the truth of this column, and it’s purpose, it appears by name and by pattern to be a integer field acting as a boolean, though without knowledge of the underlying system this is simply an educated guess. She talks of inserting a 2 into the table to see what becomes of it. 

Ultimately I think this case study is strong focused on the fact that null does not indicate knowledge, but rather the absence of it. A lot of applications treat a null value as if it was a known quantity, and thus attempt to behave as if the field was simply false or blank, but in some scenarios this can be a dangerous practice. Consider a survey application, where each column represents an answer, the answers can be from 0-5 with 0 being the worst score. if the user exits the survey prematurely, some of the survey questions may receive a null value, and should likely be stored as such. When a reporting application then acts on this data, it definitely should not treat nulls as 0′s, as that will skew the results in a negative manner. It is best in those scenarios to skip or ignore any null values in the table, and properly average the fields that are NOT NULL. this ensures that you are accurately reporting on given data, and not making assumptions or skewing data by mixing in void.

Case 19: By any other name

In this case we see the Scribe Qi being asked why he has named the clans and temples of their monastary, but not the individual monks in his documents. The scribe responds that when writing numbers would you name every number 7. The scribe is rebutted by a note on his door the next day with a static variable declaration of NUM_DAYS_IN_WEEK. 

Here we see that it is useful to name significant numbers, rather than use them throughout your application code. Many times a programmer might lazily write 7′s anywhere there’s a expectation of length of a week, or 365 for days of the year(except for leap year of course) and 24 for hours in a day. This is done mostly because these magic numbers are considered to be relatively standard and should not change, so why spend the time to define a Static variable and using it throughout the code, and having to remember this token instead of the simple number 7?

This is because while it may be obvious when you initially write the code, it may be ambiguous to others in some cases, and it is also possible that as the world slows in orbit around the sun we may see more days in a year, and our calendar itself while fairly stable today, may find itself replaced in the future by a yet unnamed calendar specification. What is concrete today may not be the same tomorrow, and being able to simply redefine a static var will certainly be easier than refactoring every usage of the number in code.