Sorry for the late post.

Anyway, what have you been watching/reading this week?

Feel free to talk about something you saw that was cool, something that was bad, ask for recommendations, or anything else you can think of.

If you want to, feel free to find the thing you're talking about and link to its Anilist, MAL, or any other anime/manga database you use!

Preface

Occasionally I feel the need to touch on the subject of code quality, particularly because of the importance of its impact on technical debt, especially as I continue to encounter the effects of technical debt in my own work and do my best to manage it. It's a subject that is unfortunately not emphasized nearly enough in academia.

Background

As a refresher, technical debt is the long-term cost of the design decisions in your code. These costs can manifest in different ways, such as greater difficulty in understanding what your code is doing or making non-breaking changes to it. More generally, these costs manifest as additional time and resources being spent to make some kind of change.

Sometimes these costs aren't things you think to consider. One such consideration is how difficult it might be to upgrade a specific technology in your stack. For example, what if you've built a back-end system that integrates with AWS and you suddenly need to upgrade your SDK? In a small project this might be easy, but what if you've built a system that you've been maintaining for years and it relies heavily on AWS integrations? If the method names, namespaces, argument orders, or anything else has changed between versions, then suddenly you'll need to update every single reference to an AWS-related tool in your code to reflect those changes. In larger software projects, this could be a daunting and incredibly expensive task, spanning potentially weeks or even months of work and testing.

That is, unless you keep those references to a minimum.

A Toy Example

This is where "wrapping" your external libraries comes into play. The concept of "wrapping" basically means to create some other function or object that takes care of operating the functions or object methods that you really want to target. One example might look like this:

<?php

class ImportedClass {
    public function methodThatMightBecomeModified($arg1, $arg2) {
        // Do something.
    }
}

class ImportedClassWrapper {
    private $class_instance = null;

    private function getInstance() {
        if(is_null($this->class_instance)) {
            $this->class_instance = new ImportedClass();
        }

        return $this->class_instance;
    }

    public function wrappedMethod($arg1, $arg2) {
        return $this->getInstance()->methodThatMightBecomeModified($arg1, $arg2);
    }
}

?>

Updating Tools Doesn't Have to Suck

Imagine that our ImportedClass has some important new features that we need to make use of that are only available in the most recent version, and we're several versions behind. The problem, of course, is that there were a lot of changes that ended up being made between our current version and the new version. For example, ImportedClass is now called NewImportedClass. On top of that, methodThatMightBecomeModified is now called methodThatWasModified, and the argument order ended up getting switched around!

Now imagine that we were directly calling new ImportedClass() in many different places in our code, as well as directly invoking methodThatMightBecomeModified:

<?php

$imported_class_instance = new ImportedClass();
$imported_class_instance->methodThatMightBeModified($val1, $val2);

?>

For every single instance in our code, we need to perform a replacement. There is a linear or--in terms of Big-O notation--a complexity of O(n) to make these replacements. If we assume that we only ever used this one method, and we used it 100 times, then there are 100 instances of new ImportClass() to update and another 100 instances of the method invocation, equaling 200 lines of code to change. Furthermore, we need to remember each of the replacements that need to be made and carefully avoid making any errors in the process. This is clearly non-ideal.

Now imagine that we chose instead to use the wrapper object:

<?php

$imported_class_wrapper = new ImportedClassWrapper();
$imported_class_wrapper->wrappedMethod($val1, $val2);

?>

Our updates are now limited only to the wrapper class:

<?php

class ImportedClassWrapper {
    private $class_instance = null;

    private function getInstance() {
        if(is_null($this->class_instance)) {
            $this->class_instance = new NewImportedClass();
        }

        return $this->class_instance;
    }

    public function wrappedMethod($arg1, $arg2) {
        return $this->getInstance()->methodThatWasModified($arg2, $arg1);
    }
}

?>

Rather than making changes to 200 lines of code, we've now made changes to only 2. What was once an O(n) complexity change has now turned into an O(1) complexity change to make this upgrade. Not bad for a few extra lines of code!

A Practical Example

Toy problems are all well and good, but how does this translate to reality?

Well, I ran into such a problem myself once. Running MongoDB with PHP requires the use of an external driver, and this driver provides an object representing a MongoDB ObjectId. I needed to perform a migration from one hosting provider over to a new cloud hosting provider, with the application and database services, which were originally hosted on the same physical machine, hosted on separate servers. For security reasons, this required an upgrade to a newer version of MongoDB, which in turn required an upgrade to a newer version of the driver.

This upgrade resulted in many of the calls to new MongoId() failing, because the old version of the driver would accept empty strings and other invalid ID strings and default to generating a new ObjectId, whereas the new version of the driver treated invalid ID strings as failing errors. And there were many, many cases where invalid strings were being passed into the constructor.

Even after spending hours replacing the (literally) several dozen instances of the constructor calls, there were still some places in the code where invalid strings managed to get passed in. This made for a very costly upgrade.

The bugs were easy to fix after the initial replacements, though. After wrapping new MongoId() inside of a wrapper function, a few additional conditional statements inside of the new function resolved the bugs without having to dig around the rest of the code base.

Final Thoughts

This is one of those lessons that you don't fully appreciate until you've experienced the technical debt of an unwrapped external library first-hand. Code quality is an active effort, but a worthwhile one. It requires you to be willing to throw away potentially hours or even days of work when you realize that something needs to change, because you're thinking about how to keep yourself from banging your head against a wall later down the line instead of thinking only about how to finish up your current task.

"Work smarter, not harder" means putting in some hard work upfront to keep your technical debt under control.

That's all for now, and remember: don't be fools, wrap your external tools.

I bought one of those cheap miniature drones that are flimsy but overall pretty fun to start with. Now, I have the bug to get something with a camera, more flight time, and can withstand the wind. Any suggestions on what I could get <$150 that would be a good investment.

Any maintenance tips or flying in public tips?

Intro

Hello everyone,

Today we cover equilibriums and phase changes. Through that we will get a basic understanding of how things like pressure, temperature, density, volume, etc. are related.

The previous chapter can be found here: https://tildes.net/~science/8ao/. I highly recommend that you read it before continuing.

A collection of all topics covered can be found here: https://tildes.net/~tildes/8al/.

Subject

Summarized

"Equilibrium" is fancy word for "balance". A system is in equilibrium when it is in balance with the surrounding systems. Any system will naturally attempt to be in equilibrim, and will adapt its physical properties to do so.

A phase change is the transition of matter from a state (solid, liquid, gas, or plasma) to a different state. This happens due to a change in internal energy, changing how a material is bonded.

Now that we have it summarised, lets dig a bit deeper.

Equilibrium

A system always tries to be in balance with its surrounding systems. We maybe don't think about this a lot, but we are all very familiar with this principle since we observe it every day.

If you have a cup of hot cocoa, it will cool down until it has reached ambient temperature. At this point, the cocoa is considered to be in "thermal equilibrium". If we fill a balloon with air, it will expand. It will do so until the air inside the balloon has the same pressure as the air outside the balloon. At this point, the balloon is considered to be in "barometric (pressure) equilibrium".

Just like when we talk about energy, there is a relationship when we talk about equilibriums. We have something we call (you may remember this from basic chemistry) an "ideal gas". An ideal gas is a good way of looking at this principle. Since the temperature, volume and pressure have a direct relationship.

Pressure-volume-temperature diagram for ideal gases.

In the diagram above we can see that if we change one of the three variables, then one (or both) of the other two variables has to change too. For instance, if we heat some air in a canister, the air will try to expand. But being unable to change in volume, it will instead increase pressure. [1]

Phase changes

Any material has a set of phases. The ones we'll discuss are the solid, liquid and gaseous phases. Unless we control the material's environment very carefully, materials will always follow this order when energy is added. Solid becomes liquid, liquid becomes gas, and vice versa. For instance water; ice (solid) becomes water (liquid), water becomes steam (gas). So each of these transformations is a phase change.

So when water is solid (ice), the molecules are in a grid. The molecules do not move around much, maybe a little bit where they stand. But they all still stand in a grid.

When the water gets heated up, the molecules will start to move. Molecules have a natural attraction to each other due to subatomic forces like the van der Waals force. So the molecules will no longer stay in a grid, but they will still keep each other close due to this attraction. So a material that sticks together but freely moves around is called a liquid.

Once the material overcomes this natural attraction, the molecules can go anywhere they want. And that's when we get a gas. Or steam, in the case of water. All of this applies even for materials we don't usually imagine would melt or evaporate, for instance steel.

Here is a visual representation of the three states.

Now comes the fun part. Ice is water that is at 0 degrees Celcius or below. Liquid water is water that is 0 degrees and above. But wait! Does that mean that water can be both solid and liquid at the same temperature? Yes, indeed. A material requires a certain amount of internal energy to become liquid. That is why internal energy and temperature is often used interchangeably, but is not exactly the same.

The water molecules in ice will use the supplied energy to get excited and start moving around. This continues until the solid-liquid water reaches a point where all molecules move around. At that point it has completely become a liquid. While water is in solid-liquid state, the amount of internal energy dictates how much is liquid and how much is solid. The exact same thing happens with water at 100 degrees. It can be steam or liquid, but not fully either until it reaches a certain amount of internal energy.

Here is a diagram of this process.

Another fun tidbit that makes water special: Water has a lower density as a solid than it has as a liquid, when both are at 0 degrees Celcius. This means that per unit of volume ice weighs less than (liquid) water. Therefore ice floats on top of water. This is the only material that behaves in this way. And thats extremely important to our existince, since it helps regulate heat in the ocean.

Steam engines (and implication)

We have learned a few new things today. But there is one really important wrinkle to all of this. A system always will try to be in balance. And this we can exploit. Pressure is a type of "pushing". So thats a type of work! And an increase in thermal energy can lead to an increase in temperature. We remember that from the ideal gas. So if we cleverly organize our system, we can create work from heat! This is the basis behind most heat engines (simplified a ton). We supply thermal energy to some gas or fluid, and extract work from this gas or fluid.

A classical example is the steam engine. We have water inside a closed system. When we heat up the water, it will turn into steam. And this steam will want to be much less dense than water. As a consequence, the pressure inside the water tank increases drastically. We release a small amount of this steam into a closed piston.

Here is an animation of this in action.

The piston suddenly gets a high pressure level. As we remember, it will want to be in equilibrium with its surroundings. Currently the pressure inside the piston is much higher than outside the piston. As we remember from the ideal gas law, a higher volume will mean a lower pressure. So the piston will be moved, as the steam expands to reach a pressure balance. The movement from the piston will drive something, like a wheel. The steam is removed from the expanded piston, and the piston will return to its closed position.[2] Then the process is repeated again and again, to have the piston continously move something.

All that from a bit of water in a tank and some supplied heat.

Whats next?

Next time we will talk about another important property. Entropy! In the previous topic I had a lot of questions regarding the quality of energy types, and what specifies heat from work on an intrinsic level. Entropy is the big answer to this. From that we will also cover the heat death of the universe, which would be a good introduction to "a laypersons introduction to nihilism" if we have any philosophers here.

Note

[1] For solid and fluid materials (as well as non-ideal gassess) this becomes a lot more complicated. If we ever do a "layperson's intro to fluid mechanics" we will cover it then.
[2] This described design is very inefficient and very simplified. Usually the piston is made so steam is supplied in turns supplied to either side of the piston. Then the work will both removed the steam that already performed work as well as move the piston. That way you can have continous movement in both directions.

See for instance this image.