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.
Facetime stopped working on my laptop sometime this year. I don’t know anyone far away with whom I actually want to chat, so I only use it when Junglemonkey goes out of town. She’s out for a few days and today the Badb came back from camp and of course we all want to see one another. Junglemonkey called my cell phone and complained that we weren’t answering Facetime and we were pigs. It turns out that my iPod’s application was working okay (but we didn’t hear it beeping, in the other room, in my purse, etc.) but my laptop’s app wasn’t. It never rang. I should know, I was sitting at my computer while it was failing to connect.
Eventually, I got it sorted out. It turns out that this is a thing – some unspecified change gets made to an obscure security file and suddenly Facetime and other messaging clients Just Don’t Work. Thanks, Apple.
My computer is new. The operating system is new. However, I’ve had a Mac laptop since 2003 and whenever I upgrade I migrate my user. Some of the files on my hard drive still date back to those early days. In this case, the problem file dated from 2006. Holy cow, 2006! That was two computers ago!
This seems to happen to me all the time. I’m wrapping up whatever I’m working on and I have a plan for what comes next. Then, before I have finished the current project but after all the real decisions have been made, I start coming up with all sorts of new projects. I haven’t really analyzed this behavior before, nor even reflected too much on it (although it does bear a strong resemblance to how I envision software development in general – but that’s a separate discourse), but I suppose it’s because the part of my mind that’s involved in creative problem solving gets antsy when it’s idle and starts coming up with things to do.
Some of these things might actually be really cool and worth pursuing, but most of them are, I think, the equivalent of sudoku or crossword puzzles. They’re engaging and require mental effort but in the end they just don’t produce anything good or useful. They’re intellectual busywork. That’s not bad if one is just trying to stay sharp, but it can be really distracting if there is real work to be done. To me, being able to tell when it’s appropriate to follow up on these fun side projects and when it’s not is a skill that I prize and try to develop. Acting on that decision is discipline.
I commonly talk about startups being, “resource constrained,” and use that as the starting point of my analysis of how a startup chooses technology, human resource policy, and other business decisions. Given that you want to do lots of things but you only have the ability to do a few things, which things do you choose to do? How you answer indicates, in some fundamental ways, what kind of a person you are; it reveals what you hold to be really important. What’s most important, people or money? Who’s more important, yourself or your family or strangers or shareholders?
It’s a common observation that ideas are cheap; that it’s execution that is expensive and valuable. So here’s an idea that has popped up to the forefront of my mind; it’s been kicking around for a while, but I don’t claim any kind of proprietary interest in it. It is certainly in the category of distraction to me since it is nowhere near the projects that I have coming up. I’ll write it down here so that if any of the three occasional readers wants to pick it up and run with it, they can be my guest. And if not, then the next time I’m actually idle and trying to stay sharp, it’ll be there for consideration.
Think about LACS; the idea was pretty nifty. An app that discovered other instances without being told explicitly by the user where those instances were; it exchanged data with the discovered instances without really interacting with the user, and the user got to see what was going on and to inject new data into the mix. That was cool. What if the messages had some extra metadata, like how reliable the author considers the message, or the repeater does; when the message was created, maybe other stuff. But really just playing urban legend, right? How interesting would that be? This is almost like Twitter, except that with Twitter (and Facebook, and G+, and the like) you have to choose what you see. You explicitly follow people, and they explicitly retweet (or like or repost or whatever) items. That gets you the water cooler conversations, but it doesn’t get you the snippets you overhear at a restaurant or in line at the grocery store. What if your phone communicated with the phones around you, collecting messages and offering messages and then the results of those exchanges came up in your Twitter feed? We all have these explicit networks – our friends, our families, our coworkers, our congregations and classmates – but there are also these implicit, loosely defined and weakly bound networks based on where we stop for gas, where we shop for butter, and where we go for burritos. Social networking apps try to emulate the explicit networks and extend their reach, sending messages out farther than we normally do in personal interactions. What about the others?
I hate the idea of foursquare because I think it’s creepy (and more than a little stupid) to advertise your specific, personal location at any and every moment. “Hey, Internet, Charles Emerson Winchester III is at Taqueria Vallarta in Felton right now and therefore a good hour and a half away from his house full of expensive and easily fenced consumer electronics. Also, please let his psycho stalkers know this.”