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(TM)” 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. Even with various considerations to think about, hard and fast rules about datastores tend to get very difficult, as the various considerations can push things around quite a bit as to how to best implement them for today while taking tomorrow into account.

Somewhat written to future-me, but also to others who may be looking in the direction of these things. General Software ApacheDirectoryStudio / apacheDS If I ever need to deal with LDAP in any way, this tool will make me have a happy. Keystore Explorer For dealing with Java Keystores. The commandline tool supplied with Java kinda sucks, this makes it easier, especially for things like x509v3 extensions which you need to twiddle if you ever do CA work.

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 Injection: if something is singleton (request, global or any other scope), the only things injected to it should also be singleton – otherwise you get implicit singletons of things the singleton holds, and may not be what you want – and generally harder to reason about.

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.

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.

Background 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.

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… Mandlebrot set #this one really only works if your terminal window is 80 wide import os;map(lambda i:os.

AKA Good Programmers Are Doing Real Science There are a bunch of long-ish winded definitions of the scientific method, but I think a reasonable pithy description would be: Come up with a theory to explain an existing phenomena. Use that theory to come up with a falsifiable prediction. Conduct experiments to prove or disprove the truth of the prediction. Independent parties repeat #3 and reproduce the results. Now if the experiments at step three or four disprove the truth of the prediction, one of a few things can happen:

When dealing with the problem of a long method, the simplest thing you can usually do is to break it into it’s conceptual pieces and have a series of tail called functions that call the next chunk of the computation.

So given this:

private Thing methodThatIsTooLong(TypeThing arg1, OtherType arg2) {
   // chunk1
   // chunk2
   // ....
   // chunkN
}

You get:

In The Cult Of Abstraction I railed against the over-use of abstraction. Here, I want to talk about a particular source cause of over-abstraction I have seen (and been guilty of). Recently, while working with another team here at Spotify, I was working through some of their test code using the Helios Testing Framework, and the harness used a surprisingly complicated tree of classes to set up the various containers it used.

While I’m often at odds with software frameworks (libraries are to be preferred over frameworks, generally), I’ve found that process frameworks can be very good indeed, when done right. Implementors of agile methodologies ironically can fall into the trap of doing it wrong. Why ironic? Well let’s look at the agile manifesto from the agile manifesto website: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan What I’ve heard is that in many companies they prescribe: “We do agile this way”, which breaks the first statement of agile.

I’ve known handywrite shorthand for a number of years, and finally decided that I should learn shorthand proper, ideally with the best bang/buck ratio, as well as minimal amount of initial learning, with being able to ramp up the amount I learn later, as time permits. I settled on Gregg shorthand, Anniversary Edition. In hunting the net in the hopes of learning Gregg, I’ve found a bunch of PDFs that I’ve found helpful.