Code Without Rules

The true meaning of unit testing

2018-06-08T00:00:00+00:00

You probably already know what “unit testing” means. So do I.

But—what if our definitions are different? Does unit testing mean:

Testing a self-contained unit of code with only in-memory objects involved.
Or, does it mean automated testing?

I’ve seen both definitions used quite broadly. For example, the Python standard library has a unittest module intended for generic automated testing.

So we have two different definitions of unit testing: which one is correct?

The tragic tale of the deadlocking Python queue

2017-08-16T00:00:00+00:00

This is a story about how very difficult it is to build concurrent programs. It’s also a story about a bug in Python’s Queue class, a class which happens to be the easiest way to make concurrency simple in Python. This is not a happy story: this is a tragedy, a story of deadlocks and despair.

This story will take you on a veritable roller coaster of emotion and elucidation, as you:

Shiver at the horror that is concurrent programming!
Bask in the simplicity of using Queue!
Frown at a mysteriously freezing program!
Marvel as you discover how to debug deadlocks with gdb!
Groan as reentrancy rears its ugly head!
Gasp as you realize that this bug is not theoretical!
Weep when you read the response of Python’s maintainers!
Rejoice when you hear the Python’s maintainers new response!

Join me, then, as I share this tale of woe.

Python decorators, the right way: the 4 audiences of programming languages

2017-08-10T00:00:00+00:00

Python decorators are a useful but flawed language feature. Intended to make source code easier to write, and a little more readable, they neglect to address another use case: that of the programmer who will be calling the decorated code.

If you’re a Python programmer, the following post will show you why decorators exist, and how to compensate for their limitations. And even if you’re not a Python a programmer, I hope to demonstrate the importance of keeping in mind all of the different audiences for the code you write.

Lawyers, bad jokes and typos: how not to name your software

2017-06-14T00:00:00+00:00

When you’re writing software you’ll find yourself naming every beast of the field, and every fowl of the air: projects, classes, functions, and variables. There are many ways to fail at naming projects, and when you do the costs of a bad name can haunt you for years.

To help you avoid these problems, let me share some of bad naming schemes I have been responsible for, observed, or had inflicted on me. You can do better.

Maintainable Python applications: a guide for skeptical Java developers

2016-10-30T00:00:00+00:00

When you’ve been writing Java for a while switching to Python can make you a little anxious. Not only are you learning a new language with new idioms and tools, you’re also dealing with a language with far less built-in safety. No more type checks, no more clear separation between public and private.

It’s much easier to learn Python than Java, it’s true, but it’s also much easier to write unmaintainable code. Can you really build large scale, robust and maintainable applications in Python? I think you can, if you do it right.

The suggestions below will help get you started on a new Python project, or improve an existing project that you’re joining. You’ll need to keep up the best practices you’ve used in Java, and learn new tools that will help you write better Python.

Vanquish whiteboard interview puzzles with test-driven development

2016-04-04T00:00:00+00:00

Whiteboard coding puzzles are of course utterly terrifying and totally unrealistic, which does not recommend them as an interview procedure. Yet they are still commonly used, which means the next time you interview for a programming job you might find yourself asked to solve an algorithmic problem with a 30 minute deadline, no text editor and a stranger who will decide your future employment staring at you expectantly.

Personally this is where I start to panic, just a little: am I fraud? Can I really write software?

I can, in fact, and so can you. And one of the techniques you can use to develop software will also allow you to go from a blank whiteboard to an impressed interviewer.

Let’s see why focusing on the puzzle is the wrong approach, and then move to explaining how you can achieve your real goal: impressing the interviewer.

The evolution of resource cleanup in Python

2016-03-22T00:00:00+00:00

The software you use was written by developers just like you. They made mistakes just like you do, learned and improved just like you do. But you have a huge advantage: you can learn from the mistakes and discoveries they have already made. I’ve discussed comparing and contrasting a single task across multiple alternative technologies, using resource cleanup idioms of C++, Go and Python as an example. Another technique for gaining technical depth is examining a single technology and seeing how its support for a single task evolved over time. As an example, let’s consider resource cleanup in Python.

Resource cleanup, compared: Python, Go and C++

2016-03-10T00:00:00+00:00

As a programmer you are expected to learn new technologies regularly. Even when the documentation is excellent, there will typically be underlying assumptions that go unstated because they are so obvious to the writer. And documentation is not always good.

But if you have relevant technical depth you will be able to recognize the commonalities and differences within a category of technologies, e.g. programming languages or databases. This means a new programming language will be easier to learn: you will recognize familiar features, different trade-offs, and some of the motivations of design choices. You will also be better able to judge the usefulness of the new technology. One way to improve your technical depth is to compare a single task across multiple technologies.

A better alternative to memorizing your development process

2016-03-01T00:00:00+00:00

Software projects are full of rules that you must memorize:

“Do not modify this file, as it is automatically generated.”
“If you modify the SchemaVersion field in this module you must also edit config/schema_version.ini.”
“All classes and functions must be documented.”

But human beings are very bad at remembering things, especially if they’re sleep-deprived parents like me. A moment of distraction and you’ve forgotten to write an upgrade script for the database schema… and you might only find out after the production upgrade fails. What to do? Automate!

What should you do when testing is a pain?

2016-02-21T00:00:00+00:00

Have you ever sat down to test your code and realized it’s going to be an utter pain? It may be too difficult, boring, or repetitive, it may just be too confusing… whatever the problem is you just can’t get yourself motivated to write those tests. What should you do? The easy answer: stop procrastinating and just follow the rules. Testing is good for you, like eating boiled brussels sprouts. But the easy answer is often the wrong answer. Boiled brussels sprouts are inedible; roasted brussels sprouts are delicious. Maybe there’s another way to achieve your goals.