Musings of a programmer, musician, photographer, and Christian.

Single Return Considered Harmful

It’s funny sometimes how when you’ve done something in a particular way for long enough, it’s easy to forget why you do it the way you do. I’ve been a big fan of early return for a long time and was recently challenged on my view. The argument I had received in favor of single return was dubious to me, but it’s always good to recheck why you do something when you’ve forgotten.

So, while the title is a little hyperbolic, in most common programming languages of today, programming in a single return is decidedly worse than multiple return.

Website Whitelisting

For my Church’s public wifi network, my pastor wanted to only allow access to sites from a whitelist. Doing this turned out to be a bit trickier than we thought.

Storage System Design Considerations, Part 1

When designing storage systems for applications, not building something like a SQL/NoSQL database, I’m talking the layer/logic that goes on top, you have to consider a whole bunch of things if you want to build the “right thing™” for your application.

In part one, we’ll be considering the simple cases (spoiler: most cases are simple) and SQL databases, in part 2 we’ll be considering NoSQL databases.

Java Server Best Practices

When writing Java servers (or servlets that run in a container), I’ve learned a few things that have saved me a bunch of trouble during development, as well as later on.

Dependency Injection Without a Framework

I think that most people would agree these days that dependency injection is a good thing for many reasons.

  • It allows you to decouple concrete classes from each other
  • It makes for a uniform method of object construction
  • It simplifies plumbing
  • Makes it easier to make testable classes

The problem that I have with it is that, at least in Java, the main frameworks for doing it, being Guice and Spring, can sometimes be as bad as the problem DI tries to solve.

Removing Magic

When starting as a software developer, everything seems like magic, compilers, IDEs, networking, kernels, etc. While we can ignore how these things work, to really grow as a developer, the magic must be removed. At the end of the day, our job is to produce something that works, having a well-rounded knowledge of how the full stack works can help you to understand when weird stuff happens, and come up with useful theories as to what is going on. Much as when I was a kid, I tended to take things apart to see how they work, and most times was able to get it back together; apologies to my Dad for the barometer/thermometer pieces he found one day. Here are a few things you might consider doing to “take things apart” and remove the magic.

Why Java?


I started my professional career with a Pascal program (I know that dates me a bit) and then continued with C and C++ and discovered Python around version 1.4 and used it heavily for over ten years, and really didn’t like Java when I first met it (version 1.3-1.4 time frame).

I’ve also used a ton of other languages for real deployed projects, like Python, Ruby, C, C++, Common Lisp (which I <3 love), C#, Clojure, Visual Basic, and Go, so I’m a not the average “blub” programmer saying this.

But since about 13 years into my career, it’s become my tool of first choice for most things.

Python Fun - Onliners

I’ve not done a ton of programming in Python for a while, but I still do like the language. I also like trying to do things in one line (ok, one statement), just because it’s a bit more difficult :). These are pretty old, but I used to keep these in my email signature line…