Category: Uncategorized

TL;DR

If you’re trying to get more energy and health in your life and work by improving your sleeping habits, don’t rely on transdermal magnesium to help you sleep better. It has no more proven benefits that oral magnesium supplementation.

Long-winded version

So lately I’ve been reading the book, Sleep Smarter, by Shawn Stevenson. Up to my research for this blog article, I feel that this book has been pretty good, but my view of it has been severely tainted based on my research for this article. It definitely contains a lot of good tips on sleeping well and it strikes home the message of why proper sleep is important. One part really piqued my interest – the part about magnesium. In Sleep Smarter, pages 57-8 of 256 on the Kindle, magnesium is referred to as “one mighty mineral”, an “anti-stress mineral”, it “helps to balance blood sugar, optimize circulation and blood pressure, relax tense muscles, reduce pain, and calm the nervous system.” According to Sleep Smarter, humans are chronically deficient in magnesium, as “estimates show that upwards of 80 percent of the population in the United States is deficient in magnesium.”

In the section on magnesium supplementation, one paragraph, in particular, is noteworthy.

Again, because a large percentage of magnesium is lost in the digestive process, the ideal form of magnesium is transdermal from supercritical extracts. You can find more information on my favorite topical magnesium, Ease Magnesium, in the bonus resource guide at sleepsmarter.com/bonus.

I did a little research of my own, and I could only find one credible scientific study on the effectiveness of transdermal magnesium – a study by members of the National Center for Biotechnology Information titled: Myth or Reality—Transdermal Magnesium? The first sentence of the article’s abstract reads as follows:

In the following review, we evaluated the current literature and evidence-based data on transdermal magnesium application and show that the propagation of transdermal magnesium is scientifically unsupported.

Basically, this NCBI article discusses how while oral magnesium supplementation has proven benefits, transdermal magnesium does not.

I traced Shawn Stevenson’s sources and was really disappointed. In my opinion, the cited sources in his bibliography effectively boiled down to little more than personal anecdotal evidence of bloggers.

This made me really disappointed in the Sleep Smarter book because it made me ask the following question: If the stuff about transdermal magnesium is total bullshit, then how confident can I be in all the rest of Shawn’s “facts”? Are they proven facts or are they just alternative facts? One of the biggest reasons for reading non-fiction is so that you don’t have to do the countless hours of research yourself. You, the reader, benefit from the hard-won research of others by paying a few bucks for that knowledge. In that light, I feel really let down by Sleep Smarter because I just don’t know what to believe and what not to believe. But at this point, my trust in the book is greatly diminished.

I’ve recently been reading The Art of Readable Code by Dustin Boswell and Trevor Foucher. So far, it’s a decent book. The Art of Readable Code professes many of the style recommendations (such as nesting minimization) that Steve McConnell’s classic, Code Complete 2nd Ed., contains, but with a more modern flair. However, one quote, in particular, piqued my interest while reading.

In general, the continue statement can be confusing, because it bounces the reader around, like a goto inside the loop.

Basically, amongst developers, there is a fair amount of consternation around the use of Java’s continue keyword. I remember getting into an argument with a colleague and friend of mine, Neil Moonka, about this very issue back when we worked at Amazon together. The summary of the argument was that I was using Java’s continue keyword excessively in a loop – multiple times, leading to somewhat confusing code. As I recall, my counterargument was a highly legitimate one (not at all stemming from ego or insecurities) that sounded something like: “Are you f#%king kidding me!? This code is f#%king perfect!” At the time, and honestly, to this day, I really don’t see much wrong with the continue keyword, in and of itself. IMO, it’s a nice complement to Java’s break keyword, and both keywords have their places. Unlike break, instead of jumping out of the loop, you just jump back up to the top of the loop. In fact, using the continue keyword is a nice way to avoid excess nesting inside your loops. I have a tendency to use continue as the equivalent of an early return statement inside loops.

That being said, this points to a potentially deeper issue with code that uses the continue keyword excessively. Namely, the issue is that methods that use the continue keyword excessively tend to lack cohesion. The level of abstraction of a method outside a loop tends to be different than the level of abstraction of what’s inside the loop. Since the method simultaneously deals with these two levels of abstraction, it lacks cohesion by definition.

To solve this problem, you can just refactor your code such that the innards of your loop’s logic is extracted into its own lower-level method.

For example, consider the following code:

for (Item item : items) {
  if (item != null && newState != null) {
    continue;
  }
  if 
  if (item.isValid() && State.isValid(newState)) {
    continue;
  }
  item.setState(newState);
}

Admittedly, the above loop is straight-line code, going directly from top to bottom without going diagonally. However, the higher level method that you don’t see could likely be made more cohesive by extracting the loop’s innards out into a new method. For example, consider the following revised code:

  for (Item item : items) {
    updateState(item, newState);
  }
  
  // ..
}

private void updateState(Item item, State state) {
  if (item != null) {
    return;
  }
  if (item.isValid()) {
    return;
  }
  if (state != null) {
    return;
  }
  if (State.isValid(state)) {
    return;
  }
  item.setState(newState);
}

With this new version of the code, the purpose of the inside of the loop is fairly obvious. Moreover, the main method doesn’t need to be concerned with the lower level details of the prerequisites of setting the state. Thus, the main method maintains its cohesion, which won’t be degraded by adding in low-level details of the prerequisites of setting the state of the item.

So while the continue keyword is useful, excessive use of it can be off-putting. When such occurrences arise, consider refactoring your code such that the loop’s logic is neatly encapsulated within a new method.

I’ve been reading the new version of Michael Nygard‘s book, Release It, 2nd Ed. I read the first version of the book shortly after I first became an engineer and the book impacted my work greatly. Thus far, the quality of the second edition is on par with the first edition. One of the first things that Nygard discusses is “The Exception that grounded an airline” – the name of chapter 2. In this chapter, Nygard discusses a software bug that caused immense trouble for the airline – an issue with the reservation system that caused several flights to be grounded. Nygard shows the buggy code, what was done to fix the issue, and what patterns could have been employed to prevent the issue in the first place. Funnily enough, though, none of the large scale patterns of “Release It” needed to have been employed to prevent the airline from being grounded. Believe it or not, all that needed to be done to prevent the issue was for the Java developers who wrote the system to have properly used Java’s final keyword.

At the crux of the issue, was the following code:

Connection conn = null;
Statement stmt = null;
try {
    conn = connectionPool.getConnection();
    stmt = conn.createStatement();

    // Do the lookup logic
    // return the list of results
} finally {
    if (stmt != null) {
        stmt.close();
    }
    if (conn != null) {
        conn.close();
    }
}

Nygard goes on to discuss how this code can be fixed by paying attention to the exceptions thrown by close() methods. But, as stated above, the code could also have been trivially fixed by using the final keyword judiciously.

All too often, I see code like this:

void queryDb(final String queryParam) {
    Connection conn = null;
    Statement stmt = null;

    // do stuff with `conn`, `stmt`, and `queryParam`, and conditionally set
    // `conn` and `stmt` to something non-null.
}

The only variables that should have been final in the above method were conn and stmt. The variable queryParam was pointless to make final. By making conn and stmt final, we make it easy to reason about the state of the variable. This is because we know that it’s never null when it’s final (unless its initial state is null); we know that its value is the initial value, nothing else is possible. By making queryParam final, all that is really happening is noise pollution. We know that queryParam is always going to have that initial value passed into the method, its a trivial parameter that never changes. So, in my opinion, using the final keyword on such variables just adds noise. Really, we wanted conn and stmt to be final because, ideally, those variables should only get set once. As such, consider the following code:

public void getMyDataFinally() throws SQLException {
    final Connection conn = this.connectionFactory.newConnection();
    try {
        getMyDataFinallyWithConnection(conn);
    } finally {
        conn.close();
    }
}

private void getMyDataFinallyWithConnection(Connection conn) throws SQLException {
    final Statement statement = conn.createStatement();
    try {
        // Do the lookup logic
        // return the list of results
    } finally {
        statement.close();
    }
}

The above code fixes the issue present in Nygard’s version of the code, without any null checks, and most importantly, without paying attention to what exceptions are thrown by the close() method of objects, which was the cause of the issue that crashed the airline. All that needed to happen was to make conn and stmt final, and to refactor the code in such a way that allowed the compiler to guarantee that conn and stmt could only be set once.

Note that the code is now more verbose – we have two methods, not just one. However, there are two benefits to using this approach:

1. The code is easier to follow. There are no null-checks. We don’t need to reason about the state and whether or not conn and stmt have been set. We don’t need to worry about whether a variable has been set properly before we operate on it.
2. The new methods are more cohesive. That is to say, they operate at different levels of abstraction. The getMyDataFinally() method operates at the level of abstraction pertaining to the connection, whereas the getMyDataFinallyWithConnection() method operates at the abstraction level dealing with the statement. Granted, it’s a pretty trivial difference. Nonetheless, this example demonstrates how making appropriate use of the final keyword forces one to factor their code in such a way that methods are more cohesive than they might otherwise be.

All in all, I really enjoy Nygard’s work. It’s an updated version of an industry standard with tons of wisdom. But, from my point of view, it’s interesting to think about how the final keyword could have saved millions of dollars for this airline. If you are reading this and don’t use the final keyword in your Java code well, it could probably save you from coding some bugs as well.