Coded Smorgasbord: On the Hard Problems

As the saying goes, there are two hard problems in computer science: naming things, cache expiration, and off-by-one errors. This little snipped of anonymously supplied PHP code highlights the first one of those challenges:

 // if no error commit if ($is_fail) { $binder->commit(); }

$is_fail is obviously inaccurately named, or maybe it's more accurate than we think. There's obviously a failure someplace around here.

Speaking of hard problems, defending against nulls is an important thing a programmer must do. Jim J found this" unique defense against nulls in some C# code.

Waybill.AgentAgreementId = null;Waybill.AgentAgreementId = 1; //in case if AgentAgreementId == null

Well, at least we know it won't be null. It seems like maybe there was an easier way to enforce that.

Nothing helps you solve weird bugs better than some decent logging. Annis supports a product that logs really aggressively. So much so, that it would fill up the disk. Was the fix to add log rotation? No, of course not. They just deleted the log files. What's interesting, and made me blink when I saw it, is how they delete the log files.

cat /dev/null > json.log

This" isn't actually wrong. Or maybe it isn't. If this file is hardlinked elsewhere, simply rming it is only going to remove one of the links. The total storage it takes up is still allocated to the other links. Writing the contents of /dev/null to the file will ensure that the file takes up zero bytes, regardless of the links.

Is that a good idea? Honestly, I can't be sure. Are hardlinks even a problem for this file? Is the filesystem they're using going to play nice with this approach?

Regardless, I've learned a new way to empty a file.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!