For Christmas last year, my wife bought me a Seiko SKX-009 which I absolutely love. Even though I love it, I looked at a bunch of higher end Swiss watches but found that even though many of them look really great (I came pretty close to buying an Omega Seamaster Planet Ocean Chrono), but realized that when it came to the features I use on the SKX, the number of Swiss watches that actually fulfil them is very few. Like the Fortis Marine Master and Cosmonaut were the only two I could find - but while they fit what I want, I don’t care so much for the styling. But the accuracy of a Swiss watch was appealing as the SKX had settled to losing 15 seconds a day, which isn’t wonderful. But at least it was a very consistent 15 s/d.
I’ve been interested in timekeeping devices for many years, and have generally been facinated with watches, and in the last year or so, I’ve become I big fan of mechanical ones.
N.B. Some of this revolves around puppet, but if you know nothing about puppet, you won’t miss anything.
I’ve been doing a bunch of stuff in puppet lately. Since my actual puppet runs are inside VMs which I nuke fairly frequently, doing the actual bits of development in the VM is impractical (and somewhat dangerous even).
I use git to do my normal version control anyway, so that’s nothing
earth shattering, but I also use git to update
the VM from what’s on my laptop because it works really well.
Since I do that, the number of commits I generate can get large, as some commits are adding a close quote or colon, or what have you. Not only that, but I often have a few commits that I never want to actually get merged at the end of the day because they’re just there to set the node configration, or tweak things that only apply because I’m fiddling in a dev vm, and not a real environment.
How to manage all of this?
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.
It’s been close to a year since I started my shorthand quest in earnest.
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.
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.
Somewhat written to future-me, but also to others who may be looking in the direction of these things.
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.
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.