That old house

Thu, 17 Sep 2015 13:30:00 GMT

To the new owners of our old house:

Hi —

I hope you enjoy this home as much as we did. Any paperwork we had related to the maintenance of the house is in the bottom left-hand drawer of the kitchen desk. Most of that we acquired from the prior owners, but it may be useful to you.

The martin house out back is held up by a rope. In the autumn, once the birds have cleared out (usually by Thanksgiving), you can lower the house down and clean it out with a water house before you hoist it back up. The birds will return in the spring, and they'll appreciate it.

The whitetail deer that live in the greenbelt drop their fawns between March and May. They have been known, on occasion, to give birth beneath the deck. If they do, try not to disturb them; they'll be up and about in a few days. Sometimes, when the fawns are a few weeks old, the doe will leave them in the yard while she goes foraging. They are not abandoned: the momma deer will return within a few hours to pick up the baby. Once, they even left a fawn on the front porch by the door! (But that was a bit unusual.) They will move through the yard at night, and will set off the motion-sensitive light on the back deck. If it keeps you awake, you might have to shut it off.

The greenbelt itself is part of the regional drainage system. I'm told that it may fill up if there's a really heavy rainstorm, but that never happened while we were there. Some of the neighbors have have mentioned seeing a "lake" in their back yard but it never got high enough to threaten the house. That's what it's supposed to do: hold the water so that it doesn't flood downtown.

The rabbits will occasionally come through, too, but they don't set off the light like the deer.

If you happen to see a cow, it probably got loose from one of the ranches nearby. If it's drinking a beer, then...well, never mind. You'll just have to cross that bridge when you come to it.

I know you can't see the highway from the back, but you can hear it. Twice a year, there's some sort of festival on the opposite side of the highway and it gets really noisy, but it only seems to last a day or two.

You may have noticed that the dog door is about five feet above the ground. We built a little ramp for our dog to go in and out. We just used an 2x10 and added some treads on it because it was steep and she would slide down. It took her a few days, but she gained confidence and would head outside whenever there was something to bark at (usually one of the neighbors out on a walk).

We never lit the fireplace, so I hope it still works. What with the asthma and all that, we didn't go to the effort. You can occasionally hear birds up in the chimney, but I'm pretty sure they're transients.

The air conditioner was replaced in 2012 and we just had it serviced. It's still under warranty, so let the folks know if something goes wrong before 2019 (paperwork in the desk drawer).

I hope you enjoy the whirlpool. Frankly, as we're getting a bit older, it got more and more complicated to get in and out, so we usually stuck to taking showers. There's a shutoff switch behind one of the doors on the bottom if it starts leaking and you need to turn off the electricity to it.

Watch out for wasps! Sometimes, they'll start building a nest under the eaves. If you can see it, they can see you, and, let me tell you, they hurt. You can knock the nests down with a broom, but then run like hell because you'll really piss them off. It might be better to let an exterminator deal with them, come to think of it.

What with all the trees, you need to clear out the gutters at least twice a year, or else they'll get all gunked up. The trees do make the lot beautiful, and the lighting adds a lot to that. For some reason, when we replaced one of the lights with LEDs, some of the other lights didn't seem to work as well, but we never figured out what the problem was.

The driveway and sidewalk have been pressure-cleaned and they looked really spectacular when we left.

You'll have access to the hiking trails and I recommend that you use them, except in the late spring when the mosquitos are out in full force.

Remember to trim that big thing in the corner by the front door. If you cut it back in the winter, it will bloom again by March, and grow healthy.

Enjoy the home. It's a great place.

Smart Locks

Wed, 16 Sep 2015 11:00:00 GMT

As we're preparing to move into a new house soon, I've been looking into "smart locks." These have been around for a while, and there are several that seem to be well-known in the industry.

A "smart lock" replaces (or supplements) your deadbolt and allows you to open your door via a Bluetooth connection. Nearly all of them let you lock or unlock your door from an iOS or Android phone, and some of them also have keyfobs that you can use as well. Most of them have an "autolock" feature that will automatically lock your door after a period of time. Some of them will automatically open the door if you're within range (and they claim to be able to tell if you're on the outside so that the door doesn't automatically unlock when there's an ax-wielding murderer on the outside and you approach the door with your phone in your pocket from the inside). Most of them will notify you (or keep a log) of comings and goings so that you can track activity through your front door.

Some of them allow you to give out "electronic keys" to visitors, and can even time-limit them. For example, you could give a key to a plumber that would allow him or her free access between 1-4PM, but lock them out otherwise. Or, if you have a house guest, you could send them an electronic key that would let them arrive during the day when you're not around.

The great thing about these features is that most of them are implemented in software, so you could potentially expect new features to be added even after you've installed the device.

Danalock ($179) is a Scandinavian device that's not too well-known in the USA, but they appear to have set the standard. It's a battery-powered cylinder that installs on the inside of the door, replacing the normal deadbolt handle. In addition to Bluetooth, it supports Z-wave, which gives you access over the Internet if you have a compatible home automation hub. The reviews on Amazon are generally unenthusiastic, with problems ranging from lag (i.e., it takes a bit of time from when you command it to unlock to when it actually unlocks) to incompatibility with various door hardware. Some reviews mention "likely require sawing off pieces from your existing lock" which is scary.

August ($249) is the newer, cooler, American big-brother to Danalock. It uses heavier batteries than the Danalock, and I'm guessing that it has a more powerful motor, since there are fewer complaints about that sort of thing. It's Bluetooth only, which means that you can't control it remotely unless you get the additional August Connect ($49) which is a WiFi-Bluetooth bridge. The scariest thing in the reviews is that people mention that it will sometimes unlock itself, randomly, in the middle of the night. Not exactly something to inspire confidence. August/August Connect will work with Nest which is IMHO a big advantage since it can, for example, turn your thermostat back on when you arrive from being out. August Connect will only control a single lock, so you have to have both if you want to control them remotely.

One of the nice things about both the Danalock and the August is that it merely replaces the deadbolt handle. Thus, your keys will still continue to function. If you have multiple doors in your house with the same key, you don't have to replace all of them (or deal with having different keys for different doors).

The Kwikset Kevo ($199) takes a different approach, in that it replaces the entire deadbolt assembly. It is Bluetooth only and, as far as I can tell, there's no way to connect it to the Internet. It's controlled from your smartphone and lets you send "e-keys" to people, though it charges for them. A big advantage of the Kevo seems to be that they kept the deadbolt handle on the inside, so you can see at a glance if the door is locked or unlocked. The Kevo will also work with a plastic keyfob that you can give to a child or a friend, but additional ones cost $25 each.

Check out this Forbes article (from 2014) on smart locks.

On Being Fat

Tue, 08 Sep 2015 21:00:00 GMT

Most of you who know me (except for perhaps the very few who met me in elementary school) know that I've always been fat. "Big," "heavy," "large"—these are some of the euphemisms I've grown up with. I never noticed my weight until junior high school. Until that point, I was just a big kid, and this was an advantage when I tried out for Little League baseball or play football.

In junior high, however, we had to "suit up" for PE, aka gym class. The first day of class, we had to go to the locker room, take off all our clothes, and put on the supplied jockstraps and gray woolen gym shorts. For the first time in my life, someone pointed at the little rolls of fat around by belly and laughed. Until that second, I had no idea that I was anything other than a perfectly normal kid.

Disclaimer: this is not medical advice, and I'm not advocating for any particular lifestyle, exercise, or medical treatment. I'm merely sharing my story in the hope that it's either interesting or useful for others.

When I was in high school, my interests were more in poetry and music rather than sports. I still rode my bicycle everywhere and was, I believe, in reasonably good shape, but my parents put me on a miserable 1500 calorie per day diet which didn't, as I recall, do much good. I rode my bicycle competitively a few times; I wasn't ever a winner, but I finished every race I entered and was never in last place.¹

When I went off to college, I bought a tuxedo (required for orchestra members) with size 44" pants. I wore that tux numerous times for performances as well as other formal events over the next four years. By the end of school, however, it was getting tight. While in college, I took the required four PE classes; for me, these included two semesters of cycling and another two of sailing. I went on long rides with other cyclists at Baylor, and even had a rather spectacular crash when I hit a small patch of water at the bottom of a very steep hill in Waco's Cameron Park. I had no broken bones, but I managed to scrape most of the skin off my entire right side, from the legs to the hips to the shoulder and even on my face. It was a spectacular-looking injury, but no major damage was done. When I left college to go to work in Austin, I sold my bicycle since I had moved to a house farther from campus and riding was not easy to keep up (and probably my as-yet-undiagnosed ADHD meant that I had new interests).

In Austin, I lived in suburban apartments and commuted by car to work. I had no concept, even then, of deliberate physical activity. That is, it never actually crossed my mind that I had to do something to be healthy. Fitness was something that just happened when I was doing things that I enjoyed. But photography and playing the guitar do not consume as many calories as riding a bicycle or hiking, and my weight was slowly creeping up, unknown to me, fueled by a steady diet of pizza, fajitas, and the best BBQ around.

In 1996, I moved to England. I was still a "big guy," but my weight was not out of control. Living and working in England (and much of Europe and South Africa) involved a lot of walking: you walked from the train station to the office, from the office to the pub, and so forth. So, again, of necessity, I was getting exercise without needing to think about it. I took up golf, too, and that was probably a healthy change.

In 2000, I left my job in the UK and returned to the USA: Silicon Valley, at the height of the boom. I went to work for a startup; this involved commuting (by car), and walking across the parking lot for those calorie-laden foods that I'd been missing in my four years overseas. In my first eight months back in the USA, my weight zoomed up 65 lbs. I only know this because I weighed in at the doctor and thought to myself, "Hmmm, that's a bit more than I remember from last time." I didn't, however, think much more about it.

My time with a startup was followed by several years of near-total unemployment. When you're unemployed, golf is not something you spend money on. Unbeknownst to me, my weight was slowly climbing. Several jobs later, I found myself with a bad back, sore knees, arthritis, and a profound tendency to breath deeply if I had to walk a slight upwards slope. Because of the back pain, I avoided walking. When I moved back to Texas to take a new job in 2010, I weighed about 420lbs (which I jokingly referred to as "a fifth of a ton") and wore size 62" pants.

When we moved to Texas, we got a new, larger, softer bed than we had ever had before. The effect on my life was amazing, as I've written about before.

In 2011, my brother Mark unexpectedly died of an aortic aneurysm. Doctors recommended that I and my remaining brothers get checked out, in case the condition was genetic. So I went off to the doctor for an ultrasound. It turns out that I did not have an aneurysm, but they detected a slightly enlarged liver. This turned out to be the early stages of Non-Alcoholic Fatty Liver Disease. My gastroenterologist recommended losing weight and, with the assistance of the new bed, I managed to drop down to around 350lbs.

Unfortunately, this wasn't really enough, and my doctor recommended bariatric surgery. I was not very inclined to give up eating; plus, bariatric surgery was, at that time, considered "experimental" and thus was not covered by insurance. That changed in 2014, when my employer added bariatric surgery to their list of covered treatments. Finally, in December 2014, I underwent a sleeve gastrectomy; in this procedure, about 80% of my stomach was removed.

There are several different types of bariatric (weight-loss) surgery. The first kind (popularized by Al Roker on NBC's "Today" show) was the gastric bypass. This involves removing the stomach almost entirely, and requires significant changes in diet and lifestyle for the rest of your life. The lap band is another surgery where they apply an adjustable band around the stomach to artificially reduce it's size. It has a bad track record of side effects (it's prone to infection, for example) and, once it's removed, your stomach returns to its original size.

The gastric sleeve, on the other hand, removes a large part of your stomach, but leaves a small "sleeve" of it behind. Because your stomach is still there and functioning, you can still take oral medication, and you can pretty much eat anything, though you can't consume more than about 4-5 ounces of anything at a time.

(Note: all these surgeries are valid, and offer different options for different patients. If you're considering this, talk to your doctor about what's right for you; there may be reasons in your case to choose one over the other.)

This is me in 2011 (left) and July 2014 (right)

Since December 2014 (when I weighed 360 lbs), I've lost a bit more than 100 lbs; last week, my weight was 254 lbs (fully clothed; at home, I typically don't wear clothes when weighing in). Coupled with a move to Seattle, I've been walking regularly, going to the gym, and working out at home with kettlebells.

Within a month after the surgery, I stopped taking high blood pressure medication and the cholesterol medications I've been on for years. I still use a CPAP for sleep apnea (according to the doctor, my apnea is mostly caused by a generic malformation of my palate, and not necessarily by my weight, though the obesity didn't help matters).

The surgery sometimes causes frustrations. I can't, for example, drink anything immediately after eating (that tends to make the food expand and lead to vomiting), so no more bagel+coffee. I have to wait an hour or so after eating before I can drink anything. Because I can't eat enough, I will have to take substantial vitamins for the rest of my life. I need to keep my protein up, so I usually have a protein shake for breakfast (my target is 85 grams of protein per day). But I can have a hamburger, even if I can't have a coke to go with it. I've also developed an occasional aversion to eggs, which is somewhat frustrating, too. I'm prone to cheating (such as grabbing some caramel candies in the evening) which certainly makes the weight loss go slower than it would otherwise.

I tell this story so that it will be documented. I'm not trying to prove anything to anyone, or recommend a particular course of action. If you can lose weight without surgery, that's probably a far better course to take if you can do it (and I'm supremely proud of my double-first cousin Jim, who managed to do just that).

I am looking forward to getting back on a bicycle soon, however.

I actually rode against Greg Lemond in a race in Houston when he was an up-and-coming youth cycling star. I'm pretty sure I finished behind him. ↩

Amazon

Sun, 14 Jun 2015 09:00:00 GMT

As those of you who follow me on the various social media platforms are probably already aware, I started a new job at Amazon.com on the first of June. I'm a software development manager with a couple of teams in the retail division. One team is a platform that's used by a dozen or more other major systems, and the other team maintains the user interface for one of those crucial systems.

Amazon is a fascinating, enormous company, and I'm just getting a glimpse of how it has evolved. I'm lucky in that I've actually been an Amazon customer since its earliest days (I even participated in the Beta launch of Amazon.co.uk when I lived in England in the late 1990's).

Since I started work on June 1, I'm slowly getting up to speed. One of the things that Amazon does well, however, is to scale things, and that includes the ability to hire very large numbers of people and get them productive rapidly. They have an exciting culture where software developers (in particular) take ownership of their systems; most of the work is performed by the teams directly, which means that they can move very rapidly, unlike many other large companies.

Stay tuned as I learn more about it.

Texas-Style Slow Cooker Chili

Wed, 14 Jan 2015 11:00:00 GMT

As everyone knows, chili was invented in Texas, probably as a way of consuming older, tougher, possibly rotten cuts of meat. By slowly cooking over a long period of time, the meat grows tender and absorbs the complex flavor of the spices.

Note that the red coloring of chili comes from, well, chilis. True Texas chili does not have tomatoes, nor does it have beans. (There is a remotely-related dish called "chili with beans," but it has no place in proper cuisine.)

1-1.5 lb lean ground meat
1 onion, chopped
5 T. chili powder
1 T. garlic powder
1 T. black pepper
2 T. smoked paprika
2 T. flour

Brown meat and add chopped onions, then move to the slow cooker.

Add all the spices and enough water to cover, then stir thoroughly.

Add salt if needed. (If you like it extra spicy, add cayenne pepper as desired.)

Cook all day on low, stirring occasionally and adding water if needed.

About 30 minutes before serving, make a paste with the flour and a little bit of water, then stir that into the pot (this helps thicken the broth).

Serve with toppings: fresh chopped onions, shredded cheese, jalapenos, crackers. If you're from deep east Texas, serve over rice.

Street Photography

Sun, 14 Sep 2014 12:00:00 GMT

This morning, I happened to see two of my Facebook friends' posts side-by-side in my newsfeed. Both of them are photographers with a heavy emphasis on street photography, and both of them are quite good.

Nia Maria Moilanen is based in Helsinki, Finland, and though her work focuses primarily on self-portraits, she also does some fabulous street work. Knut Sjærven is an old friend that I've known for many years. He and I used to work together on the Contax G pages, a site we ran that was dedicated to the Contax G series cameras. He's a huge influence in the world of street photography and is currently working on exhibitions in Europe and a street photography summit in Copenhagen next summer.

Our neighborhood by Glen Campbell on 500px

Street photography is a genre that I love; Henri Cartier-Bresson is one of my key influences for why I became personally interested in photography (along with Ansel Adams). The best street photography captures the accidental geometry and artistry that appears when large groups of people are together in an urban setting.

Alas, I am a child of the suburbs. I've never had much opportunity to engage in street photography except on those rare occasions when I get to travel. Quite frankly, suburban photography simply doesn't have the impact of life in the big city.

Please, allow me to rant a moment

Wed, 28 May 2014 17:00:00 GMT

We're using jekyll on some projects at work, so I thought that I would try it out on my laptop. I found the Jekyll Quick-start guide, and it seems pretty straightforward:

The problem, of course, is that it doesn't work:

Apparently, Jekyll wants you to install this as root. Or, perhaps, the writer is running on a different system that permits regular users to install new software without privileges. Or something else: who knows? The fact of the matter is, these simple "quick start" instructions are a complete and utter failure. At this point, I have two options:

I can walk away, knowing that if I try to fix this, I'm going to dive into a multi-hour, multi-day fiasco of repetitive trial-and-error.
I can try to fix it and hope for the best. And probably dive into a multi-hour, multi-day fiasco of repetitive trial-and-error.

You who develop software: is this what you want?

I use this as a simple, most recent example, but it happens all the time. People who write Java code assume that every single human being on the face of the earth has a Java development environment set up exactly like theirs. Folks who code in Python assume that you have the exact same Python version and installed libraries as they do.

Here's a hint: before you release any documentation, ever, spin up a new, clean standard server using a common operating system like Ubuntu or Microsoft Windows. Run your code examples there. If they don't work for you then, they won't work for anyone else using it.

Moreover, if they do actually work, they still probably won't work for a bunch of users.

Document your dependencies: if the writer of Jekyll's quick start guide had added a footnote with his or her assumptions about operating system, environment, and dependencies, then I would at least have had some idea that there might be problems.

An old rule of thumb is "Under-promise and over-deliver." Documentation like this takes the exact opposite approach, and it pisses users off.

Bags

Tue, 23 Jul 2013 11:14:38 GMT

Like many people in technology-related careers, I have long searched for the perfect carrying bag. Ideally, I would like to have a bag or backpack that can hold a weeks' worth of clothes, a full-size desktop computer and monitor, spare printer and paper, my camera and extra lenses, a full-size MIDI keyboard, and a small swimming pool, and still weigh under 2 lbs. when fully loaded.

Needless to say, such a device has not been developed yet, so I keep trying various luggage-type devices to see how close I can get.

This is a Lands' End Square Rigger attaché that I acquired around 1989. At that time in the remote past, portable computers did not really exist, and I used the case for mostly transporting notebooks, pens, and paper, to and from my work.

When I finally acquired a laptop for work, I also acquired the first of many laptop bags. I don't recall all the details, but I'm sure it was heavily padded and weighed a ton, because the laptop computers at the time were around 12 lbs. The Square Rigger was set aside, and a succession of laptops and their carrying apparatus followed, usually of ever-increasing sizes.

Around 1999, I reached my personal baggage capacity. At that time, I was using a Lowepro photographer's backpack. It could carry a full-sized SLR camera and 3-4 lenses in addition to the de rigeur 15-lb. laptop computer. At that time, I was commuting weekly to a job in Wuppertal, Germany, from my home in Ascot, England. I was seriously starting to have back problems, too.

However, technology kept advancing, and laptops started to get smaller and smaller, and my later bags (usually backpacks) also started to get to a more reasonable size. In 2010, I acquired an 11" MacBook Air which was so light and thin that it wasn't even considered a laptop by the TSA. The bag, however, was still fairly large.

These days, I occasionally use the 11" MacBook Air, but I'm usually commuting with an iPad Mini. The other day, I ran across my 25-year-old Square Rigger attaché and realized that it was just perfect. I usually commute with the iPad and occasionally throw in some connectors, business cards, and, on rare occasions, the laptop. The velcro on the outside had worn out, so I went to a local shop that does alterations and had it replaced. No, it's not heavily padded, but I can put the MacBook air in a padded sleeve when I need to carry it. While it doesn't meet my description of the perfect bag (above), it's amazing to me that the miniaturization of electronics has allowed me to bring these older artifacts back into play.

Doing It Right

Mon, 22 Jul 2013 12:00:00 GMT

Last week, I attended a meeting with many of my peers where one of the other managers expressed frustration at having to (re)build a configuration management and deployment system for each new project. Why don't we just do this once and be done with it? she asked.

It's an excellent question, and one that many organizations fail to recognize. I came back to my desk and tweeted my version of it:

My pet peeve in IT: "We don't have time to do this right, so we'll do it twice."
— Glen Campbell (@glenc) July 18, 2013

The tweet rapidly took on a life of its own; by now, it's been retweeted more than 100 times.

The reason it struck a nerve is because it's an all-too-common situation. Engineers quite often recognize that the proposed solution is a partial solution to the underlying problem, but management doesn't want to spend the resources (time, material, and people) to solve the whole problem; instead, they'll limit the solution to the immediate instance of the problem. This usually means that, until they decide to solve the original, deeper problem, they'll have to solve the same problem over and over again.

To engineers, this is "technical debt." It's called debt because it is an unrealized cost. At some point, the burden of maintaining multiple CI/CD solutions will be seen as expensive and the company will consolidate them, usually with a fair amount of pain. Like monetary debt, the pain may not be felt by the people who incurred the debt, but by their heirs: that is, whoever owns and has to maintain those systems somewhere down the line when they all need to be replaced.

Avoiding technical debt is not necessarily the right solution, however. Like monetary debt, technical debt can be used to leverage resources so that more can be accomplished in a shorter time period. Because we have a number of different teams implementing CI/CD solutions, none of them have to wait for a centralized system to be completed before they can proceed with their own deployments. Multiple, parallel implementations allow teams to be more agile and flexible in their development.

Moreover, it's almost a certainty that some of those solutions will be better than others; this leads to a situation where, by allowing development to proceed in parallel, we can actually determine which solution works best for us.

In addition, there's no guarantee that having a centralized, common solution will be the best for every group. For example, a web application might be perfectly happy with deploying every hour, since most of the changes are minimal and can be backed out if they have problems. A financial system, however, may have much more stringent compliance, security, and deployment requirements that necessitate a more rigorous, slower deployment cycle (for example, some changes may be required by law to wait for implementation until a particular date).

So, while my peeve about "let's do things twice because we don't have time to do it right" may be perfectly valid, it should be understood that simply avoiding duplication (in and of itself) is not necessarily optimal for the entire organization.

Like monetary debt, technical debt can be beneficial for an organization, especially if it is repaid in a timely manner. The key is that incurring such debt should be done with deliberation and planning, and not as a mere accident of circumstance.

Code for America

Tue, 02 Jul 2013 09:05:00 GMT

A number of years ago when I was an engineering manager for Yahoo! News, I hired a young engineer over the objections of nearly everyone who looked at his resume.

Frankly, his resume sucked—it was very poorly written, and it didn't do a great job of showing off his accomplishments. However, it showed that he had the skills we were looking for, so I did the usual phone interview. On the phone, he impressed me with both his technical depth as well as his passion for doing cool things. We had him in for interviews, and the reviews of that were mostly good, though some people still had concerns. I had already made the decision to hire him, however, no matter what the other folks thought.

It was one of those rare instances where my intuition, notoriously unreliable, was proven right. He ended up being a stellar performer on my team and grew to gain the respect of his peers.

Fast forward a few years, and we went our separate ways; I went to work for Rackspace and he joined a large media company and then a small startup in San Mateo. In 2012, I got an email from him; he was telling me that he had applied for a Fellowship from Code for America) (CfA), and he wanted to list me as a reference. It was an organization that I hadn't heard of before, but I agreed.

Over the next few months, I received a number of calls from people on the Code for America fellowship selection committee, and, towards the end of that year he was selected as one of 28 Fellows out of a highly-competitive group of more than 500 applicants.

When I congratulated him, I asked if he would be returning to the startup. I'm not sure, he told me; the startup couldn't guarantee him a job on his return. This is not altogether surprising, since most startups have very limited financial constraints. However, it stuck in my craw, and I wondered if we could do better.

A few weeks ago, I wrote an email to Lanham Napier and Lew Moorman, CEO and President of Rackspace, introducing Code for America and proposing a plan to let Rackspace employees apply for a Fellowship without penalty. They put me in touch with Henry Sauer, our VP of Human Resources, and, after a few weeks' work, we announced a plan where employees who applied for and were accepted for a Code for America fellowship could spend their year in service, knowing that they had a job upon their return and that there would be no loss of vesting in our 401K plan or participation in various other tenure-based programs such as the employee stock purchase plan (ESPP).

I'm very gratified to work for an employer like Rackspace that not only encourages service but also supports it in such a manner.

Quite possibly the most important management advice you'll ever receive

Tue, 07 May 2013 07:30:00 GMT

Shut up and let your people get stuff done.

The management transition

Thu, 25 Apr 2013 08:00:00 GMT

Most software development organizations have a fairly clear path for their individual contributors. Whether they call the job "Member of the Technical Staff," "Software Developer," or "Programmer," a young developer starts at a level 1 and moves up, usually to about level 4 or 5. At this point, successful individuals are usually faced with a choice: whether to continue up the technical path, or move into management.

This is not a discussion of the relative merits of either path (both are good, both are needed in the organization, but the technical side is not what we're talking about). This is about what happens when a superb, highly-skilled technical contributor moves from a programmer position into a management job.

In some cases, there may be a relatively smooth transition: as a developer gets more and more senior, she takes on further responsibilities as a technical leader, as a team lead, and finally as a front-line manager. It's an interesting situation, because what the organization is doing (whether it admits it or not) is saying,

Because she is a skilled technical contributor, we want her to stop doing what she's good at and start doing other stuff.

In some cases, it's done merely to help the individual proceed into a career path with more authority and money. However, that path is dangerous: I mean, you're telling someone who is at the "top of her game" to stop doing what she's valued for, and start doing something almost, but not quite, exactly different.

Smart organizations will say something almost, but not quite, exactly similar:

Because she is a skilled technical contributor, we want her to leverage her skills among a larger group of people.

See what I did there?

In the first case, the transition is done for the individual; in the second, it's done to benefit the team. It almost goes without saying that the first transition is often problematic for the organization, while the second can be much more beneficial.

In both cases, the individual is shifting roles; in the first case, however, there's not a clear expectation as to what the organization hopes to achieve in the transition. In the second, however, it's very clearly stated that the hope is to move the new manager's skills to a larger team.

It's vitally important that organizations understand this transition, and that they support new managers in their role. Being a manager is not simply being a programmer but suddenly having more authority; it actually represents a shift from doing to enabling. This is usually much more easily understood: most good technical contributors have already spent some time with the younger, less-skilled members of the team, helping them to learn quickly what she has had to learn by experience.

The biggest change for the new manager is that managing does not involve writing code. Sadly, some organizations want their top contributors to keep doing what they've been doing, but also take on management responsibilities. This, in my humble opinion, is a huge mistake. You've set the new manager up for failure by doing this; very few individuals can actually continue to maintain a high level of output while learning the new skills required in a management role. It's much better to make a clean transition; once a person steps into a management role, the expectation of deliveries shifts from the individual to the team.

The new manager now has to delegate, train, and support her team members instead of delivering. There's a huge temptation to jump in and "do things right," as she has been used to doing for so long. (And, honestly, if the situation is critical, it might still need to happen.) However, the organization will be better off in the long run if she can help her team take on the tasks that she was used to performing.

In this case, the move to management becomes a "force multiplier," to use a military term. Instead of one great developer, you now have five or ten developers who are all moving to that level. The team is correspondingly more productive, and the transition is happier for all concerned.

Happy Birthday

Thu, 18 Apr 2013 08:00:00 GMT

In April, 1991, lots of things were happening. My wife, Anita, was pregnant with our first child (due at the end of May), and I had two job offers in front of me. One was as a systems administrator for the University of Texas Balcones Research Center, and the other was a technical writer for BMC Software.

I ended up accepting the BMC job, and scheduled my last day of work (at the Texas Education Agency) for Wednesday, April 17, with a start date on my new job of April 22. That gave me five days in which to be unemployed; I planned on going fishing.

Plans were changed.

For several prior weeks, Anita had been having breathing difficulties. The doctors who examined her thought that she was having problems with her asthma, a known issue. On Tuesday, April 16, we had a sonogram with our regular gynecologist. She referred us to a specialist who examined her lungs. He determined that, in fact, she didn't have asthma, but had a build-up of fluid in her lungs. He prescribed a diuretic and sent us home.

The next morning, April 17, Anita was still having problems. Since she wasn't up to going to work, I left her at her parents' house while I went into the office to basically pack up my desk and get ready to move out. Anita's parents had business to take care of in west Texas, so they left to spend the night in Junction, TX, about 200 miles away from Austin.

When I reached work, I had a message waiting from the gynecologist. She told me that, after reviewing Anita's case, she was growing concerned. Anita had, as she put it, "a lot of little problems, none of which by itself was terribly bad, but, when put together, was a cause for concern." So I basically threw everything on my desk into a box, said a hasty goodbye.

I picked Anita up from her parents' house, told her what the gynecologist had said, and we drove to Seton Medical Center. They admitted her and put her into a room on the maternity ward. That afternoon and evening was a series of tests, x-rays, and just plain observation. I honestly don't remember a lot of what went on.

During the night, Anita's condition worsened; I had set up a folding cot in her room, and I remember her being taken for a chest x-ray at 2:00 o'clock in the morning. Around 3 o'clock, the gynecologist told me that she had, in essence, decided to take the baby early. The sonogram from the day before showed that the baby was about five pounds. Her decision, she said, was whether to take the baby now (at 3 a.m.), or to wait for the morning when a full staff would be available. She wanted to wait for the staff to arrive, of course, but she might have to operate sooner if Anita's blood oxygen level dropped below 85%.

If you're familiar with this, a blood oxygen level of 98% is normal; anything below 95% is bad, and it's really rare for someone to drop below 90%. At this point, Anita was on 100% oxygen, and she appeared to be pretty stable.

The decision was made to wait until morning so that a full staff would be available. Around 8AM, I called friends and family from work and let them know what was happening. I held Anita's hand as they moved her bed into the elevator to go down to the operating room, then went up to the waiting area on the maternity floor (I was not allowed to be present during the surgery).

Our friend Glenda showed up a few minutes later, and we waited together until a nurse came up to tell us what was going on. The C-section went well, and Elam was taken to the neonatal ICU (on the top floor of the hospital), while Anita went to the cardiac ICU (in the basement). Since we couldn't go to Anita's ICU, we went upstairs and met Elam for the first time.

Neonatal ICU has a very strict rules; you have to scrub your hands (and arms) for about five minutes before you put on scrubs and are allowed to go in. We finally washed up, and arrived in time to see him pee all over the nurse. "Well, we know that his plumbing is working," she said.

In the neonatal ICU, Elam was doing well. He had had some breathing troubles initially; they told me, however, that this was not uncommon in C-section babies. Typically, the compression of a normal birth helped to push a lot of the fluid out of the lungs. Once his lungs cleared up a bit, he was fine, though a bit small. He initially weighed about five pounds; the day after he was born, he dropped down to around 4 pounds, 9 ounces (again, this is commonly caused by fluid loss and wasn't a real cause for concern).

Once we verified that Elam was fully functional, Glenda and I went downstairs to see how Anita was doing. The short answer was: not good.

Once they let us into the cardiac/pulmonary ICU, we were escorted to her room. At the time we arrived, they were trying to take her off the respirator. I can recall seeing her thrashing around on the bed, her eyes frantically flickering around the room, and the monitor over her head indicated that her blood pressure was 295/180. Various alarms were going off, and it seemed like there were a dozen doctors and nurses in her room. The OBGYN saw me and hurriedly moved me back towards the waiting room.

Her initial explanation was that Anita "wasn't coming off the vent [respirator] very well," and that the team of doctors had decided to let her "rest for a while." Basically, they left her with the ventilator in place, put her on sedatives and Trachrium (a muscle relaxant), and left her to sleep for a while.

At some point, my brother Mark had arrived from San Antonio. Since Anita's ICU only allowed visitors every two or three hours (and then only for 15 minutes), he drove me home so that I could take a shower and change clothes. The rest of that day is still somewhat vague in my memory.

The next few days were a blur; visiting Anita (when allowed) in the basement, and Elam in the neonatal unit. On the Saturday after the birth, Anita had an "event"—Adult Respiratory Distress Syndrome (ARDS). This is where, because of the ventilator, the longs lose their elasticity and have trouble functioning. Luckily, one of the premier pneumatologists in the area was present, and he was able to adjust the ventilator.

Once past that crisis, she improved markedly, until she was able to be removed from the ventilator and moved to a private room, and ultimately discharged. Elam stayed in the neonatal unit for another few days, and he finally came home about two weeks after being born.

Sacred Spaces

Tue, 16 Apr 2013 14:00:00 GMT

Every organization has its "sacred spaces," those physical locations that help contain the identity of the organization. For decades now, for example, Silicon Valley prided itself on the "open" culture, represented by cubicles that even the senior management shared. When I worked for Yahoo!, for example, the CEO had a cubicle (he or she also had a private office, but we weren't supposed to know about that). This meant that the CEO was "one of us" and was supposedly approachable.

In reality, of course, different people have different needs. People involved in design or technical support need to collaborate; their workspaces should foster open communication and easily sharing graphic, visual elements. Sales people need to keep their energy levels up; they tend to rely on a team of people to help support them through sometimes challenging periods. (Of course, these are gross generalizations and do not apply everywhere, but that's the value of generalizations.)

Software developers (programmers) have different needs, especially while they are programming. Specifically, numerous studies have shown that software developers have maximum productivity when they have 4-6 hours of uninterrupted time in which to write code. Note that this applies only when they are actively writing code; when they collaborate (for example, to design things or review something), they need a more collaborative environment.

And note, too, that uninterrupted means, specifically, no visual or auditory distractions for the entire duration. Programming at a high level requires an intense, effortless concentration—what psychologists call a "flow state" and what most people refer to as "in the zone." It takes, at a minimum, 15-20 minutes (and often longer) for a person to reach this state. In an open-plan office, with conversations and other activities going on all the time, it is nearly impossible to go 20 minutes with no distractions. Thus, companies that force their software developers to work in an open-cubicle, group situation are guaranteeing that those people will operate at a vastly reduced efficiency.

In effect, those companies value the cultural artifacts (community, openness, collaboration) above the actual productivity of the individual developer. Their "sacred space" forces their employees to work at a lower level in return for some vague perception of cultural conformity.

Software developers are not prima donnas, nor do they think of themselves as somehow "better" than anyone else in the organization. In reality, they perform a highly-skilled activity that requires a very specific physical environment for them to perform at a maximum level. Imagine forcing premier athletes to run the 100m dash in high heels. In might look good, but their performance will suffer. Pay attention to the environment of your developers, and it will reward you with great results.

Is the Internet still up?

Sat, 06 Apr 2013 09:10:00 GMT

I know that you, like me, have often wondered whether or not the Internet is still running. Now you need worry no more. I have created the Internet status page:

http://internet-status.info

Simply point your browser to this site, and it will let you know if the Internet is still up after running an exhaustive series of checks, including verifying every single intermediate node (router, firewall, proxy, or cache) between your browser and the Internet.

Available in multiple languages based on your system's language settings.

Want to know how the magic happens? The source code is available on Github.

Frequently-Asked Questions

Why did you create this site?

So I'd know if the Internet was up.

How does it verify that the Internet is up?

By using HTTP over TCP/IP. Also, HTML.

Can I donate to this project?

The thanks of a grateful world is all I need.

What do I do if the Internet is down?

Press the RESET button.

Does it really verify that the Internet is up?

Yes.

Really really?

Yes.

The whole thing?

Technically, it only verifies the portion of the Internet that is visible to you. But, really, that's the only part that counts, right?

Do you ever add new features?

Of course; what software developer doesn't allow feature creep? You can check out the experimental version of the site for new features as they are added.

Is this an open-source project?

Yes. The source code is available on Github.

Will you accept pull requests?

Gladly. They may be subjected to a very high level of peer review and analysis, however, given the strategic nature of the Internet.

What languages is this available in?

Currently: English, Esperanto, Spanish, Finnish, Norwegian, Danish, German, French, Korean, Russian, and Chinese (Simplified).

Playing Around

Thu, 04 Apr 2013 09:40:00 GMT

I was with a number of musicians this evening; they were preparing for a rehearsal by playing around on their instruments. It's a common occurrence in creative endeavors; they weren't practicing scales, or harmony, or even trying very hard to make a tune. They were simply doodling around, getting ready to play.

In sports, I think this would be the equivalent of "loosening up" before a game or a practice session. People are recalling the muscle memory and the mental preparation necessary for engaging in a highly-skilled activity.

This happens with computer programmers, too. Programmers, especially when they're learning a new language, tool, or system, tend to "play around" and write code to help them figure out how it all works. It's a form of loosening their mental muscles before diving into the task at hand. And, more specifically, it helps them to identify "best practices" for the particular situation. For example, playing around with a database can teach a developer about the best ways to model data structures in code that can handle the data efficiently. Playing around with a RESTful API can help them to better understand the different mechanisms for executing and controlling HTTP sessions.

The best and most senior developers spend quite a bit of time just playing around because they understand that this is a crucial part of the creative process. To use something, you must be able to understand it, and playing around it is the best way to do that.

Junior developers tend to want to dive straight into the code; I think they feel that it's a sign of professionalism to be able to start and complete programming tasks in a timely manner. At least, I felt that way, too, when I was a younger programmer. However, the sheer usefulness of playing around with things almost always trumps the ability to dive in and write some code.

The fact remains that programming is a creative endeavor, and not necessarily a highly structured one. For any given problem, there are almost always multiple potential solutions, and playing around with them can teach the programmer a lot about the various pros and cons of them.

Of course, playing around can be taken to the extreme, where it actually passes the point of usefulness and turns into a pointless exercise in coding (sort of like how one link leads to another on Wikipedia, with everything ending up on "Philosophy" eventually). However, the actual constraints of the job (the necessity to deliver something by an agreed-upon date) will usually pull the developer back to reality.

As a manager, you need to direct your programmers; they should be encouraged to play around with things, but they may also need to be mentored as to how to analyze what they're doing and thus gain useful knowledge. Senior developers and architects, especially, need to be encouraged to play around with things; this will greatly improve their knowledge of the system or technology.

And, in some cases, that "playing around" can turn into something truly wonderful.

On Longer Days

Sat, 30 Mar 2013 21:00:00 GMT

Percussive sounds of rain
Accompany whistling gusts
That announce the arrival of a front.
Coffee in the morning, solitary
Browsing online, mist rising
Above the rain-slicked vegetation
And I think, "Bread."

Coffee requires toast.
Toast requires thought, and
Butter, and jam.
Coffee, toast, and jam,
On a rain-dark day, and this is
The nothing that is more.

On Tuesday, the television craps
And dismembers the news. Tanker
Truck demolishes a family. Pixels are
A falsehood on the screen; real flesh,
Real blood, real mourning, screams
That tear at throats and longer days
With tears and loss and empty mornings
Survived with coffee and no peace.

On Friday, the traffic increases,
People fleeing town, somewhere
Better lures them, hopes for
A longer day, rain-slicked chairs,
And coffee, perhaps, with toast
And jam and maybe
Eggs.

Chapter One

Sat, 30 Mar 2013 17:42:00 GMT

Karl lay flat on the damp leaves under the pines, trying to catch his breath. It had been a long struggle up hill to this point, and he didn't want to give away his position with his heavy breathing. The dozen or so deer were about 400 meters in front of him; all doe except for one annoying buck that was interested in more than food.

Once he caught his breath, Karl scanned the area. The deer were in a small clearing in the middle of the forest. Naturally nervous about open areas, they were hugging the edges but were attracted by the vegetation out under the sky. The smaller ones—yearlings—had less caution and advanced a bit ahead of the rest. Meanwhile, the buck was trying (and failing) to approach some of the older, larger doe.

Karl wasn't interested in the buck. It, too, looked like a yearling, with only a couple of short, spiky antlers. But several of the doe were at least 100 lbs, enough to provide meat for weeks if not months.

Still in his prone position, Karl unslung his rifle from his back, cautiously made sure that the shell was chambered and the safety on, and tilted his head to look through the scope. As the largest doe came into focus, he noticed slight movement in the trees beyond the far side of the clearing.

A gunshot broke the still morning air, and the deer immediately scattered, running in several directions. Karl didn't notice that, however, because his eyes were trained on the image in his scope: a man, his skull bloody and seemingly exploded, fell backward from the cover of the trees to land with a thump on the ground.

Karl watched, frozen with fear. Long training kept his rifle still, though his heart was suddenly racing. As he watched, another man, dressed in an orange hunting vest, stepped out of the trees, walked over to the body, carefully pointed a pistol at it, and shot three more times.

The man with the pistol lifted his head and scanned the area. Karl held his breath, sure that his own bright clothing would give him away. But, no, the eyes flickered past him, and the man turned and walked back into the woods.

Karl realized that he had been holding his breath the whole time; it seemed like minutes, but was probably only a few seconds. He let his breath out cautiously, still unwilling to believe that he was invisible. He wondered if he should try to help them man who had been shot: with four gunshot wounds from close range, however, it was unlikely that there was anything Karl could do.

He tried to get his bearings, and moved the scope slowly from left to right across the clearing. On the right side, past the tree line, he could see some distant power pylons, and he knew where he was. He had parked his truck on the road by the power-line cut, and had headed south in pursuit of the deer. They had apparently traced a semi-circular route, and he was now looking north back towards the same powerlines. That meant that his truck was only a few thousand meters in that direction, but that was roughly the same direction in which the unknown shooter had gone.

Karl pulled out his phone and checked the time; he decided that he wouldn't do anything for five minutes, and lay back down to wait. It seemed like an eternity, with every stick and rock beneath him making itself known. But he forced himself to watch the time on his phone and, when the five minutes was up, he cautiously stood up.

Again, he scanned the clearing and saw nothing. Before heading back to his truck, he headed over to check on the dead man.

Karl had seen blood before; he had killed and skinned many deer in his life, and he had even helped attempt to rescue a young family from a gruesome wreck he encountered on his way to college when he was only 19. Nothing really prepared him for what he saw when he reached the body, however. The head was nearly gone, with bits of blood and gray matter scattered around the ground. And there was a single gunshot wound to the heart.

Karl knew enough to not touch anything. He also knew that scavengers—birds, cats—would be here within minutes, so he very carefully took pictures of everything: the body, the woods where the two men had come from, the shell casings still lying on the ground, and the faint, indistinct footprints in the damp earth. He knew that the phone in his camera would record the location via its internal GPS, and he assumed that the police could use that to find their way back here.

Feeling like there was nothing more to be done, he turned and, giving the body a wide berth, headed back towards his truck.

Thinking about what he had just seen, he was scarcely paying attention as he drew close to the road and heard voices ahead. He instantly froze and warily peered through the trees. He could see his car where he had left it, parked by the side of the road about 50 meters in front of him. Immediately behind it was the local sheriff's cruiser, lights flashing.

Karl let out a sigh of relief and realized that he had been holding his breath. Someone had heard the shot, surely, and called 9-1-1. He moved forward another few steps and saw the sheriff standing behind the cruiser. He seemed to be talking to someone. As Karl approached, he suddenly realized that the person to whom the sheriff was speaking was the same man he had seen through his scope.

Continuous Integration for php-opencloud

Sat, 30 Mar 2013 08:30:00 GMT

This morning, I added the php-opencloud library to the Travis continuous integration service. Travis is a very cool service that automates continuous code testing. It hooks into the Github system and automatically performs tests whenever new code is pushed. If there are errors, it will send out notifications of the build status via IRC or email.

It makes it easy to do some things that have been a real pain for me, such as testing against multiple versions of PHP. It's difficult to maintain various versions of PHP for testing on my local laptop, so this takes care of that for me.

Setting this up is very simple; after you create an account using your Github login, you simple create a file .travis.yml in the root of your repository. The one for php-opencloud looks like this:

language: php
php:
  - "5.5"
  - "5.4"
  - "5.3"

This merely informs Travis that it uses PHP and that it should be testing against those specified versions.

As an example as how Travis has already helped me, I don't even have PHP version 5.5 on my laptop. I'm now getting test coverage there without having to install it.

Click here for the Travis data.

Today-Now

Sun, 24 Mar 2013 18:40:00 GMT

Your browser's home page should be something that is useful, even when viewed repeatedly. In my case, I wanted a page that would display the current time: a web clock, if you will.

I don't need it to be accurate to the second, but I do need it to be as accurate: it needed to conform to the NTP standard so that it was never running fast or slow.

The result was itime.io, a simple little site that displays the time and date. It has features for customizing the appearance, and though the time only updates every 20 seconds or so, it is as accurate as the server's clock.

The source code is available on Github.

P.S. It has kittens.

Boost your website performance

Sat, 23 Mar 2013 17:35:00 GMT

One of the reasons I moved this site away from Wordpress is because the performance was very poor. By using a static framework instead of having to dynamically fetch content from a database and re-render the pages with each view, the static architecture vastly speeds up the server-side rendering.

However, the biggest performance effects come on the client side. Specifically, there are a number of things that you can do to improve the performance of almost any site:

Reduce the number of HTTP requests. This is the single biggest problem with most websites. Each HTTP request requires an additional access over the Internet, and the browser has to do this for every resource it needs to render the page: every CSS file, image, Javascript file, and so forth. Some simple-looking pages need literally hundreds of HTTP requests to build them, and performance suffers because of it.
Put the Javascript at the bottom of the page, preferably below the </html> tag. When the browser encounters a <script> tag, all other processing ceases; it no longer downloads resources in parallel, and everything has to wait until the Javascript is finished parsing and running.
Cache everything. Resources load the fastest when they don't have to be fetched from the source each time.
Compress the content. Using GZIP compression can reduce the total amount of data transferred by 50% or more.

There are a number of other tips and tricks that you can do, but these will have the most impact. See the Yahoo! best practices for speeding up your site.

Click here for a performance analysis of the home page of this site.

For reference, here is the .htaccess file that I use:

# custom 404 handler
ErrorDocument 404 /404.html

# set expires headers
ExpiresActive On
ExpiresDefault "access plus 10 minutes"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType audio/mp3 "access plus 10 years"
ExpiresByType text/css "access plus 10 years"
ExpiresByType application/javascript "access plus 2 months"
ExpiresByType application/x-javascript "access plus 2 months"

# compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

# rewrite to break caches
RewriteEngine On
RewriteBase /
# rewrite versioning for CSS, JS
RewriteRule ^v[0-9]+(/.*)$  $1          [PT]
# redirect wordpress-style RSS feed
RewriteRule ^feed/          /rss.xml    [R=301]

# turn off ETags
FileETag None

From top to bottom:

Custom 404 page.
Set expires headers for CSS, audio, and other files to be some distance in the future. This ensures that the browser can cache them.
Compresses everything that can be compressed¹.
Funky custom rewrite rule that lets me version the CSS and Javascript files. See below for details.
Turning off ETags. (Read the Yahoo! best practices; ETags are only useful if you're running on a single server. I have redundant servers behind a load balancer.)

The real "magic" here is in the combination of the ExpiresByType and RewriteRule lines. The ExpiresByType ensures that CSS and Javascript files have an Expires: header set to 10 years in the future. This means that the user's browser will keep them in its cache, essentially forever.

However, through the magic of the Apache mod_rewrite module, I'm not renaming the file each time; I'm just giving it a different URL.

I'm using Wok, a static site generator written in Python. Wok allows "hooks"; small pieces of code that are executed at specific points in the generation pipeline. The site.start hook is called at the beginning, before anything is generated.

In the site.start hook, I have a little bit of code that creates a variable containing the current UNIX timestamp (the number of seconds since January 1, 1970). In the templates that create the base HTML for the pages, I insert that timestamp into the URL for the CSS and JS files.

So, for example, the CSS file that resides here:

/css/glenc.css

Gets turned into this when the HTML is generated:

/v1364262362/css/glenc.css

Note that the file itself is not moved; it's only the reference to it in the HTML that is modified. And here's where mod_rewrite comes into play. This rewrite rule:

RewriteRule ^v[0-9]+(/.*)$ $1 [PT]

strips the "version" prefix (a literal "v" at the beginning followed by a string of numbers) and continues processing the file.

The result is that the file gets a new version number (and thus a new URL) each time the site is published. Since the user's browser does not have this new URL cached, it fetches it again from the site, thus ensuring that any changes in styling or Javascript are seen. If the site hasn't changed, then the file is retrieved from the browser cache (or an intermediate caching proxy), thus preventing an extra HTTP request to the site.

This is done for all of the static assets on the site: CSS files, Javascript files, and even some images.

Note: if you're looking through the source code, you'll see that there's a bunch of other things that the links.py file does. This is mostly to support Wok's development server, which does not use Apache. On the dev server, the hooks create a symbolic link from the version directory to the top-level directory, thus resulting in the correct URL for the static assets. Those links are removed when the site is published.

Note that compression may cause problems on some older browsers. Frankly, I don't care. If you're still running IE5, then I don't need you as a reader. ↩

Using Cloud Files CDN for podcasting

Fri, 22 Mar 2013 10:00:02 GMT

While I've been rebuilding this site¹, I've gathered together all of my podcasts that I put together over the last few years. I didn't really want to serve all those MP3 files from my cloud server account, since the bandwidth charges are high, and large files like that could consume a lot of connections while they are downloaded.

Instead, I've pushed all the files to the Rackspace Cloud Files content distribution network (CDN), which is built on top of Akamai. In this case, the files can be served by a global network of edge caches, which means that the performance will be better for the users and I won't incur the bandwidth charges of serving them locally.

To push the files, I've created a fairly simple script that uses the php-opencloud library that I developed for Rackspace's Cloud SDK for PHP.

Click here to view the entire source code

This is pretty straightforward, but I'll point out a few details:

At the beginning, I have define('RAXSDK_TIMEOUT', 9999);. This ensures that the HTTP requests to transfer the data do not time out. Because the MP3 files are large, they would normally hit the hard timeout limit built into the SDK.
I'm using the SetUploadProgressCallback() method to establish a function that will intermittently be called during the upload. That callback function (upload_status(), at the end of the script) keeps a running total of bytes uploaded and provides visual feedback for the user. Otherwise, the script would appear to sit idle for long periods of time.
To avoid the wait, I'm only uploading new or modified files. The modified files are detected if the file size between the local copy and the CDN copy are different. New files are detected in the try { ... } catch() block that surrounds the initial creation of the object. If the attempt to retrieve the object from Cloud Files fails, it creates a new, empty one.

I hope this is useful to you; let me know if you have any feedback via the Twitter button, below.

See here for details. ↩

Macaroni 'n' Cheese

Thu, 21 Mar 2013 16:27:00 GMT

This is my variation of Alton Brown's Stovetop Mac'n'Cheese. I chose to modify his, not because I think I'm a superior chef, but because his recipe used strange volumes of ingredients; for example, his version calls for 10 ounces of cheese, but all the bagged shredded cheese in the grocery store comes in 8 or 12 ounce packages.

Ingredients

12 ounces elbow macaroni
6 tablespoons butter
2 eggs
12 ounces evaporated milk
1/2 teaspoon hot sauce (more to taste)
1 teaspoon kosher salt
Fresh black pepper
3/4 teaspoon dry mustard
12 ounces sharp cheddar, shredded

Directions

In a large pot of boiling, salted water cook the pasta to al dente and drain. Return to the pot and melt in the butter. Toss to coat.

Whisk together the eggs, milk, hot sauce, salt, pepper, and mustard. Stir into the pasta and add the cheese. Over low heat continue to stir for 3 minutes or until creamy.

Working with Wok

Thu, 21 Mar 2013 07:45:00 GMT

This site is built using the Wok static website generator. The source for it is mostly plain text files in Markdown format, and it is generated and then synced to the server.

This method of maintaining the site has several advantages over using, for example, Wordpress to dynamically generated the site.

Since all the pages are static HTML, there is a vastly reduce change of a security breach because of the underlying code.
Static pages load and render much faster in the user's browser, giving them a superior experience in many ways.
All the content is stored in GitHub, which makes it trivial for me to maintain and recover in case something goes wrong.
The server resources are much, much less than using Wordpress; I don't need an extra database, and the actual requirements of the server are much smaller.
If I need to scale to support huge traffic (not that that's likely here), then all I need to do is replicate the server and add a load balancer in front of it.
It has a local server where I can test the site before I publish it, which gives me a chance to fix errors before they go live.

Like any technology, however, there are tradeoffs. Here are some of the reasons you wouldn't want to build every site in this manner:

It's fairly complicated. You need to install a bunch of software on your computer, since the burden of rendering the site is shifted to your local machine from the server.
It's more difficult to add images; they need to be manually resized and stored before you can add them to pages. Wordpress has a number of very powerful features for image manipulation, even automatically pushing images to their content distribution network (CDN) so that they load faster in the user's browser.
There's no fancy user interface for building and maintaining the site content. I'm editing this using a simple, plain text editor; it's an experience that many users are not comfortable with.
Wok is an open-source project that's built using other open-source projects, and the documentation is poor. It's hard to find things; like many open-source projects, the authors really expect you to read the source code.
With Wordpress, you have access to a vast library of themes and lots of support. With a system like this, you're pretty much on your own.

Would I recommend this approach? In general, no. It's really much easier to set up a Wordpress site than it is to get something like this working. On the other hand, if you're a hacker like I am, it can provide a compelling experience for the user while making it easy for me to maintain.

Programmable DNS

Tue, 05 Mar 2013 11:59:38 GMT

I recently released a new version of php-opencloud that includes support for Rackspace Cloud DNS. This is a free service for managing your DNS (free if you have a cloud account). I've used numerous DNS services before (and I've even hosted my own BIND server), and most of them operate in a similar manner: there's a control panel on the web, and you use it to make changes as needed. Some of those services go further by providing reports and other operations, but Rackspace Cloud DNS has a fully programmable API.

It's been quite handy, for example to make mass changes to my domains. For example, let's say I want to change the email address associated with all of my domains.

In this example, it simply loops through all the domains and updates the email address. This is much easier than logging into a control panel and manually updating dozens of domains.

I accidentally my servers

Mon, 04 Mar 2013 11:14:46 GMT

As you long-term readers of this blog know (both of you), I work for the Rackspace Developer Relations Group. I wrote the php-opencloud language bindings that are used in the Rackspace Cloud SDK for PHP. As part of this development process, I create an awful lot of cloud objects: servers, blog storage volumes, virtual networks, load balancers, etc. So one of my steps is a script called cleanup.php that deletes everything in my cloud account. And I do mean everything: every server, every modicum of storage, every load balancer: EVERYTHING.

On Friday, I ran this script whilst signed on under my personal cloud account, thus deleting everything, at least in the DFW data center.

Needless to say, this was not A Very Good Thing.

Luckily, I am fairly religious about backing things up, and I was able to rapidly recover nearly everything within a few hours. The biggest single loss was my mailing lists[1. The reason that the mailing lists were not backed up was because of the size; I meant to get around to backing them up soon, but I should have done it sooner. It's totally my fault.] that I've been running since 2001—some of them had hundreds of members and tens of thousands of messages, and they're still gone. I think I have backups on CD somewhere in the house, but I'll have to dig them out.

Oh, by the way, are you familiar with Rackspace Cloud Backup? This service does automated, file-level backups hourly, daily, weekly, or monthly, and at a very reasonable cost. It's now running on all of my systems; if I had been running it before this incident, it might have helped me recover everything.

And cleanup.php has been modified so that it will only run in my test account.

My apologies to those of you who tried to access this site during its unscheduled downtime on Friday afternoon.

Vanity nameservers with Rackspace DNS

Thu, 28 Feb 2013 13:34:12 GMT

The Internet domain-name service (DNS) can be a complicated, convoluted thing to try to understand. Moreover, because people use names and not IP addresses to access websites, it has to be highly secure; someone hijacking a nameserver can damage vastly more sites than someone who merely hijacks a website.

There's also an issue of credibility, at least for technology companies. If someone performs a whois search on your domain:

$ whois some-domain-or-other.com

It will show them the primary name servers for that domain. For example, if I perform a whois techcrunch.com at the command line, it shows me this:

Name Server.......... ns3.wordpress.com
Name Server.......... ns1.wordpress.com
Name Server.......... ns2.wordpress.com

This lets me know that TechCrunch is hosted by WordPress; if I know of a vulnerability at WordPress, then I can use that information to attack TechCrunch.

If I perform a whois search on yahoo.com, however, all I know is that the DNS is handled by Yahoo! I don't have any information that I can exploit to attack them, and I know that Yahoo! is a big enough company to handle its own DNS.

If you perform a whois search on glenc.co, you'll see this:

Name Server: NS1.XLERB.COM
Name Server: NS2.XLERB.COM

What the heck is XLERB.COM? A further whois query on that leads to:

Name Servers:
  ns1.xlerb.com
  ns2.xlerb.com

Well, whatever XLERB.COM is, it does it's own DNS, right? Nope; the DNS for XLERB.COM is actually hosted by Rackspace. Here's how I did it.

First, your domain for the name server needs to be hosted by Rackspace. I won't get into the details of how to do that (they're available online), but Rackspace DNS is free if you have a cloud account. Since all my servers are hosted by the Rackspace Cloud, I get the DNS service as a bonus.
When you add a new domain to the Rackspace DNS system (via the control panel, it assigns two default name servers: ns1.stabletransit.com and ns2.stabletransit.com. What you're going to do is to find the IP addresses of those two servers and create new A records in your domain that point to the same IP addresses. Use nslookup ns1.stabletransit.com (or dig) to find the IP addresses of those two domains.
Create two A records in your domain that point to those IP addresses. In my case, I used NS1.XLERB.COM and NS2.XLERB.COM.
Go to your domain registrar (in my case, it was the registrar that handles XLERB.COM) and look for something like "register nameservers." You'll have to dig through the site, and it may be under "Advanced Options" but all of the registrars should have it available.
Register your new name servers there and use the same IP addresses you used for the A records, above. In my case, this was (again) NS1 and NS2.XLERB.COM. This is required so that DNS can get the IP addresses from the top-level domain (TLD) servers and ensure that they're trusted, and not have to rely on the lower-level name servers, which might have been compromised. However, the records must match at both levels.
Having registered the name servers at both the DNS provider (Rackspace) and at the registrar, you can now point your domains at them. This is the trivial part; unfortunately, you still have to do it twice. At the registrar for a domain, change the name servers to use your two new name servers; at Rackspace, edit the NS records and change ns1 and ns2.stabletransit.com to use your newly-defined name servers.

Voila! Now, someone performing a whois query on your domain will find your customer name servers, and not the Rackspace ones. For example,

whois unpretentious.org
....
Name Server:NS1.XLERB.COM
Name Server:NS2.XLERB.COM
...

Note, however, that there are certain risks associated with this; if, for example, Rackspace changes the IP addresses of its name servers, you'll have to modify both the registrar's name server records as well as the A records you defined in your domain.

Music performance apps for the iPad

Mon, 11 Feb 2013 10:16:31 GMT

The iPad is a marvelous tool for musicians. There's a huge quantity of apps for performers; unfortunately, they're all mixed in with apps for playing music, so they can be hard to find. This is my personal list of favorite musical tools. These are the ones that I use often, once a day at least or more.

forScore by MSG Development. This app lets you display PDF files. I use it for holding the chord charts that we use in my church music group. It can access files stored in Dropbox and it lets you annotate those documents. For example, if we decide we need to use a capo on a song, I can write that on the chord chart and it will show up the next time I view it. In addition, it lets me resize and crop documents so that they're easier to read.

AudioBus by A Tasty Pixel. This app is nothing short of miraculous. It lets you link together the audio inputs and outputs of other compliant apps into a seamless whole. See audiob.us for a list of the apps that support it (there are a ton of them). For example, I can set up a drum machine, a bass line, and a synthesizer as inputs, pipe it into an effects unit, and then route everything to a multi-track recorder for mastering. It was only released last November, and it's been hugely popular since then. You can think of this as the cabling that lets you run multiple music apps simultaneously.

Auria by WaveMachine Labs, Inc. This is a 48-track studio-quality recording system. It's Audiobus-compliant, to you can pipe the audio from other iOS apps into it. It's truly an amazing app; when I was first in the studio (in the early 1980's), a 48-track recording system would have easily cost $500,000 (in 1980's dollars). Here it's available for $50. (There's also a "light edition"—Auria LE—that only costs half as much.) It doesn't have all the sophisticated effects, etc., of Apple's own Garageband, but in many ways it's much more flexible and powerful. With Audiobus, you can add all the effects you need as part of the audio chain.

Animoog by Moog Music Inc. This is superb synthesizer built for the iPad from the grandfather of all synth companies. The user interface takes some getting used to, but you can create some wonderful tones with this.

Guitar Toolkit by Agile Partners. This app combines a tuner, chord reference, and metronome along with support for various guitars, ukulele, mandolin, banjo, and other string instruments.

There are a ton more of great apps out there, but these are the ones I most frequently use.

How to talk about gun control

Fri, 21 Dec 2012 13:51:59 GMT

In the wake of the Newtown, Connecticut, school shootings, there has been a vast, seething discussion on gun control on the Internet, as well as in our homes, offices, and places of worship. Much of this discussion, in my humble opinion, is utter rubbish and serves only to enhance the speaker's feelings of superiority and self-worth. If you're interested in an honest, open discussion on the tragedy of gun violence and how to solve it, I humbly suggest a few guidelines.

Do not use the term gun control

There are probably at least 100,000 different definitions as to what this term means; so much so that it is, in essence, utterly meaningless. If you find yourself saying, "we need gun control," it might make you feel better, but it adds nothing to the conversation. Instead, try to focus on concrete proposals backed up by hard evidence, not pure speculation on your part. "If we prohibit gun magazines from holding more than five rounds, it would force gun owners to purchase more and slow down shooters whilst they reload," is a much better statement than "We should stop people from owning assault weapons."

Do not use the term assault weapon

Why? Like gun control, this is a vague and ambiguous phrase that had a very clear definition in the Federal Assault Weapons ban, and is misused nearly everywhere else. Under the now-expired assault weapons ban, an assault weapon is defined as a semi-automatic rifle that has a place to put a bayonet, a collapsible stock, a flash suppressor, and a removable magazine. If it only had three of the four, it wasn't an assault weapon. If was a .22 caliber (very small gun) but had those four items, it was still an assault weapon. Thus, the assault weapons ban was trivially easy to get around; in most cases, the manufacturer would leave off the bayonet lug, since that's the easiest thing to do. Instead of using "assault weapon," use specifics: "I think we should ban all guns that have a removable magazine."

Do not dismiss your opponents

Sadly, political discourse in this country has reached the point where people on differing sides of an issue simply ignore each other. When you start out a statement by saying, "Anyone who supports gun ownership is a killer," you're a fool and you're only trying to make yourself feel better. Your opponent (in both direction) has been around for years and at least deserves the respect of a worthy opponent. The NRA has, to this date, been vastly more successful than the disjointed voices of liberals whining about this or that. It will take a concerted, heavily funded effort to counter their resources and the culture they represent. Dismissing the people from the other point of view as "idiots" and "lunatics" serves no purpose and will only ensure that the status quo continues. Ask yourself if that's what you want.

Talk about the Second Amendment

Ultimately, any law about gun control will be judged in the courts against the US Constitution's Second Amendment. You cannot simply dismiss it with "That was valid when we used muskets; it's not valid any more." Yes, it applied to muskets, the highest-quality weapons of the time, and not just to flintlocks, which is what most farmers and rural people used for hunting. The purpose was to establish a standing army from the citizenry and, if you read the writings from the period, was to ensure that citizens could overthrow their government if it became corrupt. Using those standards, courts will continue to uphold private gun ownership, and no meaningful progress towards gun control will be possible without addressing them.

Ask yourself if your proposal would work

Seriously. I've seen some of the stupidest things come out on the Internet; ideas that would have had zero impact on the Columbine or Newtown killers. Background checks would not have stopped them, since none of those killers actually purchased the weapons used. Nor would requiring registration; criminals and the criminally insane can steal registered weapons as easily as they can unlicensed ones. Ask yourself: would this have stopped the killer in Newtown? If not, then it's going to be a lot of work to justify further restrictions of civil rights without showing a benefit.

Don't cherry-pick your data

People are not idiots. If you have a graph showing gun deaths in the USA vs. Denmark, Switzerland, Findland, Germany, and England, then the USA comes out way behind. But Mexico has some of the strictest gun control laws on earth, and yet Mexicans are far more likely to be killed by guns than are US residents. Any discussion needs to include a spectrum of examples, and not merely the ones that make our case. Failing to include other examples proves to thinking people that you're an idiot and your ideas can safely be dismissed. I don't think that's what you're intending to do.

This is not an easy problem to solve, given the American culture and history. At the very least, we should be able to have a civil, thoughtful discussion of the issues without recourse to slander and slimeball tactics.

I want to die in Autumn

Tue, 09 Oct 2012 14:51:49 GMT

I want to die in Autumn with my knees
pulled up to my chin and fallen leaves
crisp among the fading grass
as night falls and constellations wax
and the air grows cold; outside, wind slacks
and fades, and people pass
outside, unaware of the ending. Surprised,
maybe, of the way it ends, my life,
I grieve, of course, and mark
the time to the minute. They
have their lives; they can choose to say
what they will, but dark
is the ending, dark and cold and stale.
There is light, too, pale
gleams from distant points, and sounds
of music (music! for all love) around
and about and inside and out
and joyful shouting and helpful hands.
The end is the beginning, and stands,
not separate, but entwined, routed
between the knowing and the unknowing
signs, that long tunnel leading
from water into air.
I'll arrive, knees bent, crying loud,
fearful and joyful and tearful and
hopeful and light of heart, where
knowing and unknowing
and becoming are one.

The best luggage I ever owned

Wed, 03 Oct 2012 17:18:06 GMT

I have been traveling on business fairly regularly since 1993, when I became a consultant for Evolutionary Technologies International, an enterprise software vendor. When I first became a consultant, I went out and spent $50 on a wheeled carryon bag. After a month, it was utterly decrepit, so I replaced it with another $50 wheeled carryon, but of a different brand. After another month on the road, that bag, too, was destroyed.

Instead of spending another $50 on a wheeled carryon, I asked my fellow consultants what they were using. Six of the seven were using Briggs & Riley wheeled carryons. The B&R carryon cost $250, but it's hard to argue with results.

I can take a hint and, twenty-one years later, my Briggs & Riley wheeled carryon is still going strong. A few years ago, one of the wheels broke, but the company replaced it for free under their unlimited lifetime warranty. Between 1996 and 2000, I lived in Europe and averaged 140 flight segments per year. I don't travel nearly so much these days, but I can still reply on my luggage.

I am not a paid spokesperson, but simply a very happy customer. I have not performed an exhaustive comparison between B&R and other brands, and I'm sure that the price has gone up since then. All I know is that their products perform superbly.