When we bought our house in the woods, it came with outbuildings. There’s the Rat Shack, which looked like maybe someone was going to build a granny unit and then gave up and just parked a camping trailer there instead. And then there’s the Toxic Waste Shed, which looks like a shipping container made of plywood and is full of shelves stocked with rusty electronics (!) and half empty cans of paint, tar, and solvents. But our favorite is the Pantry, an 8×8 room with a concrete floor, stud and drywall walls, and electrical wiring but the wires terminate about a foot outside the building. Maybe it was built to house the water pressure pump, which ultimately got located elsewhere, or maybe it was gonna be a weed drying room, or…we dunno. We thought of making it a chapel, but instead we insulated the heck out of it and installed baker’s racks and use it to store bulk and canned goods.Continue reading
So this feels like the most Silicon Valley thing I’ve said in a few years, but the thing I’m working on right now is basically the same parts and programming language I was working on as a hobby back in 1997. Yes, the machine is in someone else’s data center, yes, the services it’s interacting with are running in still other data centers; even so, I am writing Perl CGI scripts and cron jobs to respond to automated messages and run intermittent build and release processes. What a blast from the past.
I have been writing programs of varying complexity since I was in the 6th grade, so, call it 39 years. For a portion of that time, call it 14 years, I worked on code that had other people contributing to it. During that, what, 36% percent of my programming life, I learned many lessons that I’ve carried into my solo programming.
Tools, best practices, all kinds of work patterns and code idioms show up in my personal projects not because they’re the most efficient way to get the project done, but because I’ve learned that if I ever do want to collaborate with someone, then that’s made a heck of a lot easier if I do some planning in the beginning. Also, because I love future me, I don’t want to give future me some big pile of spaghetti code with all kinds of undocumented special cases just built in.
So, I came out of retirement to work on a neato project. I’m doing a lot of programming, architecture, release management, project management, and, um, reporting. So, that’s why I’m not doing a whole lot of bagpiping or anything. Because this is fun and important.
But nobody cares about that. The interesting thing here is that when I came on board there was git and not a whole lot else in the way of engineering support. I know how horribly messy a build and release system can get, let alone a development workspace, without some good process and support tools in place. So I started thinking about continuous integration, bug tracking, and an artifact repository.
I then mentioned this in a work context and was reminded that a “team” of only three people probably didn’t need a CI system and an artifact repository, but maybe a bug tracker wasn’t a bad idea. And that made sense. I have worked with enough QA people, though, and people who were serious and thoughtful about configuration management and build/release process, to still feel like having a dedicated build machine is probably a Good Idea. I just feel kind of itchy when I think about distributing software that was built on a programmer’s laptop.
Time passed. I wrote a lot of code. Other folks did. We threw some stuff away, we built some stuff, and now we’ve reached a major internal milestone. I’ve released some software internally, and it was built on my laptop. By me. By opening a terminal window and typing `mvn package`. I still kind of cringe to think about that, even though when I go to the trouble of articulating why, it turns out that in this particular case it is okay. I’m distributing an early beta/late alpha dev build.
Anyway, tonight I had a bit of spare time. Did I play video games? Did I veg out to some Netflix? Or did I install Nexus and TeamCity and try them out? Yeah, you guessed it. I still don’t think that we need an artifact repository. Not yet, anyway. We don’t have enough distinct modules to need it (unlike at Netflix, where we had a score or more internally developed libraries). But I found that setting up TeamCity was really easy (well, except for the part where it doesn’t grok my local MySQL installation) and it doesn’t confuse me with a lot of words that don’t mean what I think they mean. I might actually turn our cute itty bitty Mac Mini into our build server. Won’t that be a kick?
You know. For fun.
I dunno, back in, like, 2010, I was working on software that had something like 1 zillion dependencies (or, you know, 50. Same thing) and keeping track of consistent versions of all the dependencies was a real pain in the neck. Our organization had a dedicated CM team who set up Artifactory and Ivy and we worked pretty hard at being flexible with which version of commons-lang we actually required.
But note, that was a full time job, just managing the artifact repo and the build system. So now here I am, managing a team and we’re developing a suite of programs. We’re building some custom code, but a lot of what we want to do is accomplished with off-the-shelf libraries, each of which is available from Maven central. Of course, each one pulls in a different version of slf4j or bcprov or whatever. With only a couple of dependencies, it’s okay, there are no collisions. But last night I pulled in jets3t and *poof*, the app would no longer start because jets3t’s version of bouncycastle collides with the version I was already using, so uh oh, we can’t do encryption because the class loader is confused.
Easy enough to solve (downgrade bouncycastle to the version jets3t plays with) but this is my reminder that configuration management is actually a full time job, and there are best practices and frameworks and all that good stuff.
If you read a book about software development or start a repository on github or bitbucket or launchpad, you’ll confront the question of software licensing very early on — likely, before you even get to the question of what development environment you’re going to use. I’ve come to decide that this is not really helpful.
When I worked at startups, the code we wrote in-house was proprietary. We didn’t open source it, although occasionally we would contribute back to some projects. The point of the software team at those companies was to encode the business into bits that customers would pay hard cash in order to execute. We didn’t even think about licensing the software until it was time to think about how we were planning to sell it – a question which depended a great deal on the marketing department and the business in question.
Now, I’m writing software for my own entertainment. If one thinks hard about it, one might come up with ways to make money off of that, but that’s a hell of a lot of work and I’ve got bagpipes to play and tunes to learn and, let’s be real, dishes to wash and goofing off to be doing. My wife is doing amazing things and that’s enough startupness in the house at one time. When I started working on this turn based game server, I thought the way it would go would be to provide the server for cheap (or free) and then the money would get made by developing games that would run on top of the server. Now I’m looking at the software and its possibilities and thinking that the system itself has value to some entities (schools and researchers) and maybe I should think harder about selling it that way.
This decision is kind of important. Right now, I’ve got all the source code sitting in private repositories. It’s copyrighted by me, and it’s not licensed, period. If I were to open source it, that would make selling the server software impractical. The only way to sell open source software is to provide some kind of value-added service on top of it, and that kind of work really cuts into bagpiping. Also, and this may shock some folks, I’m not really very good with people. A service job isn’t one I’m going to succeed in.
If I’d gone with an open source license up at the beginning of this project, there’s not really any way to undo that. So, note to other software developers who like to fool around with code and write stuff just for fun: private repositories are your friend. Write your code, fool around with stuff, refactor and publish to your heart’s content. Then, when you finally get to some point where the license actually matters, then fire up your IDE’s copyright plugin and have it stick whatever boilerplate you decide on at the top of all your files.
Back in, like, 1987, I lived in an apartment with three other guys. The four of us were all computer science majors and one of them had this catchphrase that we heard often late in the evening as he was working on his homework: “It was perfect, so I fixed it.”
That has stayed with me. Think about it, do you ever just look at something you’ve made and think, “Yeah, that’s great. I’m going to just leave that alone.” Well, if that’s you, then you can just move along. The rest of us morons just can’t leave well enough alone. Today’s examples: 1Password and my current software hobby. 1Password v3 allowed for synchronizing data across multiple devices by using Dropbox. Version 4 lets you use any folder, not just the top level Dropbox folder (this means that one might, for instance, use a shared Dropbox folder to share with one’s wife). The problem, though, is that the Android app, 1Password Reader, doesn’t decrypt the keychain properly. It can find it, but now that I’ve upgraded my desktop to use 1Password version 4 I can’t actually read the data on my phone or my tablet. It was working great, so I upgraded and now it’s less useful. Thanks.
That upgrade also required that I upgrade the OS on my laptop. So now it’s running OS X 10.8 “some stupid cat.” Meanwhile, I’ve decided that it’d probably be a good idea to rewrite my game server to run in Google’s App Engine environment. So now I’ve spent about a day and a half going around and cleaning up dangling pointers to obsolete Java frameworks and Maven installations. The “upgrade” seems mostly to have had the effect of making my IDE slower, my tools less reliable, and my hard disk more full. It was working fine, so I fixed it. Fantastic.
Oh yeah, and Oracle claims to have released a version of the Java SDK that plugs like a zillion security holes, so I had to download and install that. Because my old SDK was working fine.