It’s my first day on the job — a dot com startup in early ‘99 — when I realize there is no internet connection in the office. A couple guys had modems in their workstations, but despite piles of cat3 running around the office, there was no official uplink. An internet startup company.
This wouldn’t stand. Although Google hadn’t yet supplanted Yahoo!, and YouTube wouldn’t exist for another six years, having no ‘net connection caused immediate withdrawal symptoms. Something had to be done.
After scrounging around the office, I managed to find an old Cyrix-based system that was collecting dust, plus one US Robotics modem, and a Linksys 10Mbps NIC. The office had three phone lines, which seemed like overkill; I figured we could spare one. I installed Slackware, set up a basic firewall with ipfwadm (the 2.0.xx kernel way of doing things), and stuck it on the network. Finally, a little script to dialup to my student account at school and establish the PPP connection, and we were in business!
Suddenly, the entire office (about ten people at the time) were able to check their email and do some basic surfing, all over a shared 28.8kbps connection. (It worked surprisingly well.) After a few weeks of prodding, the sales guys learned to stop trying to use line #2 to dial out, screwing up the connection for everyone.
The typical git workflow involves creating a topic branch any time you work on a non-trivial feature. I’ve found this to be a good practice, with several benefits. I’m frequently working on several distinct features simultaneously, and topic branches make this trivial.
However, there is one annoyance for me, as a C++ user. The last step of the topic branch approach, after you’re done developing and testing, is to move the changes back to master and push back to the central server. (At least, that’s how we do it.) The common way of doing this is:
git checkout master
git merge myfeature
Note: I’m making the assumption that your myfeature branch was already rebased on top of master’s head, making the ‘merge’ step in the above snippet a simple fast forward.
At this point, your working directory is essentially unchanged. The checkout of master reverted all the changes in your branch in your working tree, but the merge restored them all. It’s great, except for the fact that all the changed files end up being touched, resulting in newer modification times on the filesystem. The primary annoyance, as a C++ user, is this can result in a time-consuming recompile (and re-test, if you’re particularly anal).
As it turns out, there’s a simple way to update the master branch’s head without first checking it out. While you’re in your myfeature branch, you can issue this command:
git push . HEAD:master
As I said above, I’m only concerned with the case where your feature is already rebased on top of master, so no merging needs to take place. Issuing this command causes master’s head to be updated to the current branch’s head, bypassing the merge step and therefore not causing all your changed files to be touched again.
Now when you checkout master, it’s already updated and can be pushed to the central server, no recompiling needed.
I’ve been extremely busy over the past few months, between a consulting gig and trying to get my company off the ground, thus the radio silence. (The upside: less talking about doing, more doing.)
I just tweaked a few things on this site, including disabling comments. The spammers were starting to abuse them multiple times a day, and it’s simply not worth worrying about for now.
I have had a few ideas kicking around in my head lately; also, I’m basically wrapping up the consulting job at this point. Hopefully that’ll translate into less stagnation for my little site here…
This is a composite created from three source images: one exposed for the sky, one exposed for detail in the shadows, and one in-between. The composite image retains color information from all areas of the image. Pretty cool, huh?
There is also a ridonkulously big version of the image. For the curious, I used the tutorial from Instructables (intended for Gimp users).
In my last entry, I talked about closed-minded attitudes about new (or just unfamiliar) programming styles. I’ve been thinking a lot about why Python — or any other dynamic language — is more powerful than a more rigid, statically typed language. For the purposes of this article, I consider C++ rigid, even though it supports some dynamic typing facilities.
At first glance, it seems like you are actually losing something good when you switch to a dynamic language. You lose compile-time type checking, which is a useful way of detecting errors before ever running the program. In a dynamic language, the compiler (if there is one) doesn’t know the types of any objects until runtime, so it cannot verify the validity of the operations performed on them until execution time. As a beginner in the language, this can be surprising and frustrating. For example, your program may work normally until you hit one less-used branch of the code, and it bombs out with a TypeError. [Read more →]
… or, Stop being so myopic, and I’ll stop calling you code monkeys.
First, a quote from the famously eloquent Donald Rumsfeld:
“There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.”
There’s a real problem among programmers. (Well, there are several, but we’ll stick to just one for now, okay?) We know they’re cocky, but this is generally regarded as a strength. However, it plays badly with the next fact, care of Rummy: they don’t know what they don’t know. There are unknown unknowns.
The thing is, there is a sequence of events that plays out through your entire life as a coder. It goes something like this:
Look at the pure crap you wrote a couple years ago.
I figured I’d document for posterity some of the issues I had with my Kubuntu 7.10 → 8.04 update. I approach all major updates with trepidation, and as usual, it was justified.
First of all, the updater application worked well. I had to expand the window to show the terminal when it updated OpenVPN, which would hang waiting for me to enter my username and password. (This actually happened twice). Also, it is occasionally interactive, asking you to look at changes it wants to make to certain config files. This is a good thing, but it would be nice to have all the questions come at the beginning or the end, so the update can be unattended (since it takes several hours). [Read more →]
From the this-should-be-obvious-by-now dept.: I recently added an integration test suite to our codebase, which gives us the ability to write some tests that were impossible when we only had unit and system test suites. Once it was stable, I added it to our nightly build process, so it would be tested every night.
I updated our Linux build machine with the new nightly build script. At the same time, I was configuring our new, faster Windows build machine to replace our old, pokey one. Since the old Windows machine is expected to be rendered obsolete, I didn’t bother installing the new build script on it. So Windows just continued running the normal build, unit tests, and system tests. We knew the integration tests worked on Windows anyway, because we ran them by hand just recently (right?).
This Sunday, about a week later, the new Windows machine came online. I installed all the prerequisites (which only took a few hours, because we have an awesome wiki full of HOWTOs), connected it to our network, and installed the updated build script. By now, you know what happened next: I ran the build script, and everything worked except the integration tests. The code checked out, compiled, unit tested, and system tested just fine. But the one thing that wasn’t tested nightly — the integration test suite on Windows — was broken.
Our strategy of automating everything continues to pay dividends. And it shows what happens when you don’t. If you aren’t able to regularly test your software in some kind of automated fashion, it is broken. You just don’t know it yet.
It’s reminiscent of the days when IBM proved the power of computer software by facing off against chess grandmaster Gary Kasparov. Kind of exciting in that sense. According to the author, their artificial intelligence isn’t better than the best poker players… yet.
I’ve personally written one program that plays an online flash game, by screen scraping and mouse pointer movement. It didn’t require any AI component, and it was purely for fun; no profit motive. Needless to say, this is intriguing; of course, I know I’m supposed to use my powers for good.
Website note: I’m opening up comments generally. I noticed Wordpress gives me a neat summary of recent activity, so I can delete spam pretty easily.
Neuroscientist Jill Bolte Taylor describes the surprisingly moving experience of having a stroke in the left hemisphere of her brain. Highly recommended 18-minute talk.
I figured I’d document for posterity some of the issues I had with my Kubuntu 7.10 → 8.04 update. I approach all major updates with trepidation, and as usual, it was justified.