Despite his lack of elaboration on his reasons, despite the fact he has been identified as someone whose actions are necessarily irrational, despite the fact Giffords was one of the survivors, commentators have blamed his action on political rhetoric from a number of sources, including Sarah Palin — based solely on the fact that his most famous victim at the scene was Giffords. Political commentators waste no opportunity to fold, spindle, and mutilate every tragedy, to force each of them into a shape that supports the conclusions they've chosen before ever examining the evidence. The perpetrator has been simultaneously identified by different pundits as a Marxist, a Nazi, and a Tea Partier, among other political affiliations. Those are three mutually incompatible political positions, which highlights the absurdity of this exercise.

I have personally gotten to experience some of the knee-jerk political response to this event. I do not know why (I could probably find out — I just haven't bothered looking at site logs yet), but Statistics 101: US Gun Crime vs. UK Knife Crime has seen a minor resurgence of comment traffic since 5 January. It has been getting off-and-on comment traffic since it was first posted; this is just the most recent such surge. It feels a bit more fast-paced this time, especially since Saturday. Maybe there's a connection.

I know there is a connection between Saturday's tragic events and at least one comment, though, that tries to blame the entire event on US gun laws. This facile rhetorical posturing follows exactly the same pattern as the majority of comments on Statistics 101:

1. Someone skims the original entry, and maybe some of the discussion that follows it.

2. That person ignores the point of the entry — the prohibitive complexity of the complete, largely unidentified factors involved in producing the "gun crime" statistics people try to use to prop up one side or the other of an argument.

3. That person makes some insipid statements about how drawing a straight line between two cherry-picked points among millions "proves" a causal relationship between those two points.

This one comment to which I refer tries to use the Tucson shooting as "proof" in and of itself of the evils of guns. My point all along has been that:

1. I find the evidence unconvincing, given that there is contrary evidence as well and there are logical reasons to believe popular accessibility of firearms may actually make the world safer for good people.

2. There's no evidence that convincingly proves either side of the debate — which is why I don't so much argue what I believe in such discussions as I argue against the overly simplistic declarations of people whose arguments are little more than demonstrations of confirmation bias.

There's cockamamie nonsense on both sides. People start with a bias, then set out to confirm it, and they interpret everything from the perspective of that bias such that they become blind to the facts staring them in the face. The only thing I can truly prove is that when it comes to a gun, I would rather have it and not need it than need it and not have it. The only thing someone who wants to outlaw all guns can truly prove is that they hate the thought of people having guns. Everything else is speculation and imagination — and, occasionally, a little bit of logical reasoning that has yet to be properly supported by an analysis of isolated variables.

You cannot convince someone who possesses the power of objective reasoning with facts that prove your side of the argument, because if you truly believe the available facts satisfy the requirements of proof you simply do not understand the facts available to us.

In the midst of all this, people are using their confirmation bias to cast the shooting in Tucson, Arizona as "proof" of their points. People's lives and deaths are being perverted to serve the purpose of counterfeit proof in their self-centered campaigns to be "right", regardless of the consequences. It's frankly disgusting.

There are cases where someone dies — or someone lives — and we can draw simple conclusions. In 2009, a couple in Tennessee had to leave a gun in their car because of a state law that made it illegal to carry in the restaurant; a man who had been stalking the woman killed her husband between the restaurant and their car. We can reasonably assume, based on this event, that the state law was bad for the husband's survival chances in this one instance. We cannot draw a reasonable conclusion from this one incident that repealing that restriction on carrying firearms would result in fewer deaths overall. In fact, even in this one incident, the death toll may have been identical: one dead, but the assailant instead of the would-be victim. It is perfectly reasonable to draw conclusions that are supported by the evidence at hand. It is perfectly unreasonable to draw conclusions based on gross generalizations and willful ignorance of the myriad factors you find inconvenient for supporting your preconceived notions.

It goes beyond reasonability, and into the realm of unconscionable barbarism and opportunistic dishonesty, to use gross generalizations and willful ignorance to confirm your preconceived notions with the victims of a tragic massacre as game pieces in your pathetically childish game of checkers.

I disagree with Jon Stewart on a lot of political subjects. He's unapologetically left-leaning, and regularly uses the kind of shoddy reasoning I've decried when it is used in the analysis of the public safety effects of firearms laws, but for other subjects like socialized healthcare, economic regulation, and governmental privacy policy. In general I agree with him on privacy and free speech issues, but not on the other two subjects: I disagree with his methods of supporting his positions on those issues from time to time, whether he's using them to support issues with which I agree or with which I disagree. Among political commentators, however, I respect him far above and beyond the vast majority, for one simple reason:

He draws the line at using the lives and deaths of other people in simplistic rhetorical games, dishonoring the memories of the victims of an event like the Tucson shooting by suggesting that, for instance, Sarah Palin made the lunatic in this case go on a shooting spree by using symbolism to illustrate her opposition to the political positions of people like Gabrielle Giffords.

Jon Stewart opened his Monday, 10 January 2011 broadcast of The Daily Show with a nine minute monologue addressing his disappointment in political pundits who do not stop at the line of common decency when spewing ever-more vitriolic rhetoric to push their agendas. He articulated his (correct) belief that the world is not nearly so simplistic and absurdly dichotomous across the left/right divide as others pretend. It was rambling at times, and clearly not the most eloquent commentary on the subject — but it was quite probably the most honest, reasonable, and intelligent. If your browser has the ability to display Flash video widgets, give it a viewing:

I then said:

At first, the main focus is likely to be on writing weblog software, since the idea of this spin-off is that I will be writing a weblog application, and will be using it as I write. It'll be the ultimate expression of the concept of "eating my own dog food", as the expression goes.

It has taken me almost three and a half years to get around to it. I've had other things on my plate and, as I mentioned in The Virtues Of Lump — the inaugural entry at blogstrapping — laziness has served as the key motivation behind my procrastination. Perhaps ironically, I think that procrastination was probably for the best; I think I am actually in a better headspace for this project now than I was at the time.

Anyway . . . the wait was long, but it appears to be over. I'm working on development of the CMS application I use for blogstrapping at a pretty good clip so far. You can see the blogstrapping version of this entry, the "hello world" of the new development Weblog, if you like: Blog Strap Ping

. . . or just check out the main page of blogstrapping and follow links from there. There's an RSS feed, too, complete with autodiscovery that should be recognized by modern browsers like current versions of Firefox. I still need to work on perfecting the generation of the RSS feed, but I believe it should work with (most?) RSS readers.

That's where I'll likely be sharing most of my thoughts about software development from now on. Of course, I'll also be contributing a couple times a month to the Programming column at TechRepublic from now on. The subject matter of such articles will likely vary (perhaps subtly) from that of my blogstrapping entries, however.

Thanks for reading. I hope you like the new venue.

Speaking on behalf of software engineers who have to interview prospective new hires, I can safely say that we're tired of talking to candidates who can't program their way out of a paper bag. If you can successfully write a loop that goes from 1 to 10 in every language on your resume, can do simple arithmetic without a calculator, and can use recursion to solve a real problem, you're already ahead of the pack!

My question is simple: What counts as "a real problem" one can solve with recursion that would be small enough to be a quick job interview question (like the FizzBuzz question)? I don't seem to run afoul of problems that call for recursion very often. When I do, it seems like it's always a "toy" problem like a Fibonacci number generator or factorial calculator.

I'm pretty sure I could solve a "real problem" using recursion, at that level of complexity at least, if I ever ran across one.

I think of myself as a worse programmer than I actually am.

I don't get as much code written as I would like. I run into a wall a lot of the time when trying to get something done, and it feels a little like I'm running up against the edge of my own competence. I know I'm no expert, nor even "proficient" in the Dreyfus model, but I might be better than I tend to think when I have those moments of incompetence.

I've realized that one of the biggest problems I have with making progress on my own projects is figuring out how I want to build them — to some extent, even figuring out what I want them to do. Once I have a clear idea of some piece of functionality that needs to be built, I tend to build it; once I know how I want to organize the architecture, I put it together; once I have a theory for the project's concept, I design it. Reverse those steps, and you've got a path from concept to completion.

The biggest problem for me is, apparently, developing that theory for the project's concept. When working on a fairly clear-cut project, such as when doing something for a client who has more than a vague notion of what (s)he wants, everything flows easily, but a lot of the time the vague notion is mine, and it's up to me to come up with something clear-cut from there.

I've never been a cubicle-based developer. My information technology related dayjob employment has always been focused on things like network administration, data center support, and on-site client system recovery. I have not had a straight-up development job, per se, though I have done a fair bit of lightweight development for clients (Web development, software tool maintenance, integration, and actual — le gasp! — consulting). It occurs to me that if I had at some point had a desk-and-beige-box, cubicle-embedded, corporate development job I'd probably have a more positive view of my own programming skills.

In a cube farm, doing development scut-work, expanding the code base of some Enterprisey bloatware system by working on some micromanaged little segment of it, I would have realized much sooner that I do seem to have the ability to churn out code to meet the well-defined goals set before me — and do a better job of it if I understand how it fits into the big picture. In short, while I've spent a long time rating myself somewhere around the level of a low-level Advanced Beginner in the Dreyfus model, I think I might actually land squarely in the Competent category. It's just difficult to see that from where I'm marooned on the far fringes of development, well outside the kind of programming work most developers do.

Maybe tomorrow I'll change my mind, but for now it looks like I've suffered under a delusion that is the diametrical opposite of the Dunning-Kruger effect.

I've been thinking about the Dreyfus model of skill acquisition a lot lately (I blame Andy Hunt, and his book Pragmatic Thinking & Learning). It is in part because of this fact that I've come to realize that my own cognitive bias in the case of rating my development skills lands me squarely in the self-underestimating camp.

Now I just need to spend a few more days thinking about it to make sure my epiphany is not just a flash of ignorance, rather than insight. If it turns out this realization is not, itself, a misperception, I then need to start working on believing it. Long habit of belief in my own relative incompetence will be difficult to break.

One of these things is not like the others. Maybe you can explain why it showed up.

I ran across an old article at Business Insider: 15 Google Interview Questions That Will Make You Feel Stupid. In short, they did not make me feel stupid. They did, however, make me hope that the smart people at Google are smart enough to not take someone being stumped by a single question as a black mark on their interview, since anyone can be stumped by something that might appear simple in retrospect later.

Without further ado, here are the questions:

How many golf balls can fit in a school bus?

This question is evidently asked of applicants for a product manager position.

The answer is actually really simple. Develop a mathematical expression used to estimate. If they want a more exact number, tell them "Give me a school bus and an effectively unlimited supply of golf balls, and I'll tell you." Otherwise, your expression should allow for variable input based on the internal volume of the school bus. You may need to tell the interviewer that you need to look up something about how roughly spherical objects pack together, and you may have to ask whether you're allowed to grind the golf balls into dust to fit more of them inside the school bus.

How much should you charge to wash all the windows in Seattle?

This question is also evidently asked of applicants for a product manager position.

$50 per window (then pay other people $30 per window to actually do the work). Tell them you want to double-check the market standard rate for window-washing before giving a final answer, though.

In a country in which people only want boys every family continues to have children until they have a boy. If they have a girl, they have another child. If they have a boy, they stop. What is the proportion of boys to girls in the country?

This is evidently yet another question asked of applicants for a product manager position, though I think it's probably a good one for "software engineers".

It's time for another simple mathematical expression. This one might benefit from a little recursion. No, I'm not doing your work for you. The end result will, however, be very close to 50% each, with a negligible edge for boys — assuming a 50% gender split for birth rate.

How many piano tuners are there in the entire world?

How many of these target product managers? Here's another one.

"I need more detail for project requirements. Let's start with your definition of 'piano tuner'. For instance — is every person who has ever tuned his own piano a 'piano tuner' for purposes of this? If you're only talking about professionals, tell me how much money the person has to be making to be a 'piano tuner'. Do we include out-of-work piano tuners? Details, man! I need details."

That, or: "As many as there needs to be. There may be a few extra, or slightly fewer than there 'needs' to be, depending on externalities if people are trying to 'manage' the piano tuning economy, or something like that."

One could always just start doing math based on assumptions of how long it takes to tune a generic "piano", what constitutes a "piano tuner", and what percentage of pianos actually get tuned, among other things. Such assumptions will almost certainly lead to inaccurate results, though.

Why are manhole covers round?

Hallelujah, this one is not for product managers. It's a question for software engineer applicants. Funny how the first "software engineer" question strikes me as a "reverse engineering skills test" question.

If they were square, they might fall through the hole and kill someone working in the sewers.

Design an evacuation plan for San Francisco

Google must hire a lot of product managers. This is another question for such job applicants.

The way I thought of it was this:

"I'd just start working on details and ideas, and let them watch, since I'm sure what they want to see is how I work." As a friend of mine put it when I posed the question to him, though, "Sure." Poe-tay-toe, poe-tah-toe.

In any case, a number of questions would have to be asked (or assumptions made) at the start of the planning stage. I'm sure the questions you ask or assumptions you make (if questions other than basic question clarification aren't allowed) are what they really want out of your "answer".

How many times a day does a clock's hands overlap?

Here we go again. Product managers galore.

"22, assuming a twelve hour circular analog clock with an hour hand and a minute hand. Let me know if the requirements differ, or if you want a mathematical expression that can take variable inputs for other clock designs." The minute hand doesn't cross the hour hand in the hour leading up to one o'clock, nor in the hour leading up to twelve, but it does cross at twelve. Thus, you have one overlap per hour on the clock, minus one.

Also: s/does/do/

Please make your interview questions grammatically correct.

Explain the significance of "dead beef"

Applicant type: Software engineer! There's another one that isn't a product manager.

I have two answers to this:

1. Dead beef doesn't fight you as much as live beef when you try to throw it on the grill.

2. It's a hexidecimal representation of a fairly big number. If you lop off two of those characters, depending on which pair (assuming you're counting in twos rather than just picking characters at random), you also get the hexadecimal RGB code for one of several shades of nearly-gray.

The most annoying thing about this question is that they're probably not really testing your abilities so much as your exposure to certain cultural phenomena — particularly the once-traditional use of 0xDEADBEEF as a test memory address. I'd fire the fucker asking this question of interviewees if that was his reason for asking, or at least ensure that he doesn't get any say in who's hired, because letting him keep good people out based on their lack of exposure to this one cultural tradition or let people in based on their exposure to it is a great way to get false positives and negatives in the interviewing process, and thus result in a lower overall value of employee pool.

A man pushed his car to a hotel and lost his fortune. What happened?

This is a question for people applying for a software engineer position.

My first question was "What the heck do these two things have to do with each other?" It occurs to me, after a little thought, that they might be completely unrelated.

You need to check that your friend, Bob, has your correct phone number, but you cannot ask him directly. You must write the question on a card which and give it to Eve who will take the card to Bob and return the answer to you. What must you write on the card, besides the question, to ensure Bob can encode the message so that Eve cannot read your phone number?

This question is evidently asked of applicants for a software engineer position.

First, I'd offer to rewrite the question so the interviewer doesn't embarrass himself when giving it to other applicants. Then, I'd probably just send Bob a note that said something like "Call me on my cell, or have Eve tell me if you don't have my number." It's not technically a question, but I suspect the interviewer wouldn't complain. If he would, I probably don't want to work for him. This is problem solving, not Jeopardy. Anyway, out-of-band confirmation if you're trying to avoid letting Eve in on the secret seems like the most reasonable answer, so I'm pretty sure I win the prize here.

You're the captain of a pirate ship and your crew gets to vote on how the gold is divided up. If fewer than half of the pirates agree with you, you die. How do you recommend apportioning the gold in such a way that you get a good share of the booty, but still survive?

This question is evidently asked of engineering manager applicants.

"Figure out how to give everyone exactly even shares — but don't do it. Now take the money from the shares for a number of crew members equal to half minus two, and spread that money amongst the rest of the crew, so that more than half of them are happy with you. Take the share from the last guy, and put it in your own pot, just for a CEO golden parachute. Since we're apparently being asshole CEOs about this, follow that up by asking Uncle Sam for TARP funds, then retire."

The answer they actually want is probably to split the dough evenly amongst the smallest number of crew members that is more than exactly half. That's slightly safer than my answer, but I think the difference is negligible and if you're going to be an asshole about it you might as well make out like a bandit.

I wouldn't give anyone who answered this question this way as if it's how he actually does his job any kind of management position. Sociopaths need not apply. Nobody who actually believes they should conduct their personnel management duties like this should be let within a hundred miles of an engineer manager position.

You have eight balls all of the same size. 7 of them weigh the same, and one of them weighs slightly more. How can you find the ball that is heavier by using a balance and only two weighings?

This question is (again) for project manager applicants.

Ooh, sorting algorithm stuff.

• Weigh three of the eight balls on each side of the balance.

  1. If one side is heavier, weigh one of the three on each side of the balance.

     • If one of them is heavier, you win.

     • If they're the same, it's the other ball, and you still win.

  2. If neither side is heavier, weigh the other two balls, one on each side of the balance.

     • One of them will be heavier. You win.

No matter how it works out, you've only done two weighings. I notice, after writing this answer, that it's damned near pseudocode already.

You are given 2 eggs. You have access to a 100-story building. Eggs can be very hard or very fragile means it may break if dropped from the first floor or may not even break if dropped from 100th floor. Both eggs are identical. You need to figure out the highest floor of a 100-story building an egg can be dropped without breaking. The question is how many drops you need to make. You are allowed to break 2 eggs in the process.

Get ready for something different: a question for project manager applicants.

I really hope the problems with the clarity and grammar in these questions is a Business Insider problem, and not a Google problem.

This is another sorting algorithm kinda thingie. I'm less certain of this one, off the top of my head. I guess I'd start by dropping one from either the 13th or 14th floor, depending on which I figured would take less time to get to my goal (I'd have to do math for that, or guess based on my mood at the time, and I'm not doing much math today). Then, I'd do something like this:

Given N = (14 or 13) and n = N:
until N > 100,
set N = (current + (n -= 1))

Thus, if we assume N is 14, we drop first from the 14th, then from the 27th, then from the 39th, and so on, until the egg breaks or we get to 100 without it breaking. If it never breaks, our answer is 100. If it breaks, take a step back to the last floor where we dropped it and it didn't break and start going up one floor at a time until the second egg breaks. Intuitively, I'd say that with either 13 or 14 as the starting value we shouldn't end up with more than about 15 tries before we figure out which floor, and we'd end up breaking either two eggs total or no eggs. I think.

Explain a database in three sentences to your eight-year-old nephew.

Why does a product manager need to explain a database to his eight year old nephew?

"Say you have a bunch of checkerboards and a crapton of checkers, each of which has a different piece of information on it, and you store your checkers with their information in the squares of the checkerboards. Each board is sort of a categorical topic area, with each column and row corresponding to a value type so that when you combine the value types you get unique values that correspond to each piece of information. There, I did it in two."

Yes, any eight year old nephew of mine that would get my explanation of a database would be pretty smart. If he was dumb, I'd say "It's like a well-organized bucket that you fill up with things you know."

Note that nobody said it had to be a relational database, and I went beyond the call of duty assuming it was a technical implementation of a database as one uses with a DBMS anyway so that there'd be something to explain (otherwise it really is just a bucket of information).

I'm sorry. This is really just an incredibly stupid question. Maybe I should have used one sentence: "Here's the URL for the Wikipedia page for 'database'." Yes, a question that tests one's ability to explain technical things in simple terms can be very important, but there's not nearly enough context here to actually give an answer that will suit the needs of whatever scenario the interviewer has in his head.

You are shrunk to the height of a nickel and your mass is proportionally reduced so as to maintain your original density. You are then thrown into an empty glass blender. The blades will start moving in 60 seconds. What do you do?

What do questions like this have to do with being a product manager?

Considering the dimensions I'd have at that point, I might just try lying down and letting the blades whir over my head. I'd hold on tight for good measure. This is assuming I couldn't disable the blender, of course. This is a terrible question. Maybe they'd be happy with the answer "fire the guy who shrank me and put me in the blender, and get his replacement to get me out," since this question is so stupid.

The Rest of the Story

I looked at the provided answers after I wrote the rest of this SOB entry. The answer to the question about the guy pushing the car is an even stupider, more culturally dependent answer than the thing about dead beef, and if getting hired depends on the answer to that, there's something deeply fucking wrong in Google's hiring process. Seriously. What if I pushed my wookie, instead of my car? Maybe I'm playing the Star Wars Edition, numbnuts.

Before the list of fifteen questions from Google interviews that are supposed to make you feel stupid, the Business Insider article offered three criteria for getting hired at Google that have nothing to do with these questions:

• Google prefers Ivy Leaguers.
• It cares about your GPA, even if you're in your 30s.
• It wants people who want to change the world.

I'm okay with the last item in that list, but the first two are ridiculous. Seriously? This is another case of that tendency hiring managers and HR people have to believe that something that narrows the field is good even if it doesn't actually test for something particularly relevant to job performance. Sure, a higher GPA may correspond to a slightly higher tendency toward good job performance, but by throwing out anyone whose GPA sucked (or may not have attended college at all), you may be ignoring a completely different, more directly relevant metric that could have a much more important and reliable impact on your ability to hire the very best. Don't even get me started on the Ivy League school preference. Remember that correlation does not imply causation, and you'll avoid these asinine mistakes that major corporations all seem dead-set on making.

I'm also not sure the last item on the list has led to good things. How exactly do these people want to change the world? Judging by Google's performance, this requirement has resulted in better-than-average outcomes for the "don't be evil" motto, and for the corporation's success, but "better-than-average" for a major tech corporation isn't saying much when you're comparing it against examples like Microsoft and Oracle. If average is somewhere south of -85% on the Goodness Scale, I don't think a "better-than-average" result of -80% is a "good" outcome. Maybe Google should change that motto to "Don't be as evil as Microsoft." At least then it'll probably correlate more strongly with results.

A few weeks ago (three? four?), I put an end to a seven-year famine in my life. It has been seven years since I moved across the country and, as part of the move, sold my motorcycle to a friend (since I had no reasonable way to either transport or store it, and it wasn't terribly valuable). This month, I got a new motorcycle.

The new bike is a 2000 Buell Blast. That's the first year Buell made the Blast. Buell has been a subsidiary of Harley Davidson ever since HD bought the company in the '90s, until HD closed down its Buell division last year "to focus on the Harley Davidson brand." As you should be able to see from the pictures, a Buell is not a gigantic cruiser. Buell started out making racing bikes and their street-legal equivalents. The Blast was created for the express purpose of having a Harley Davidson built "starter bike" that was suitable to use in Harley Davidson motorcycle classes, so HD wouldn't have to buy little Honda 250s for its own bike classes.

Of course, Harley Davidson's idea of a "small starter bike" is somewhat different from what you'd expect out of a Japanese motorcycle company. The 2000 Blast is a 492cc single-cylinder engine. It's a zippy thing, too. Best of all for my purposes, it's about the closest thing you can get to a UJM these days.

Back in the '80s, the major Japanese motorcycle companies all made a class of street bike that came to be known colloquially as the UJM, or Universal Japanese Motorcycle. A UJM was smaller than a touring bike. It did not recline like a cruiser, with the foot pegs out in front. It did not require the rider to fold his legs under himself to reach foot pegs that were high up the sides and back somewhat. Instead, the rider would just sit upright on a UJM with the foot pegs a comfortable distance pretty much straight down below his hips. My first motorcycle was a UJM, and I found it quite comfortable and well-suited to riding around town.

The Blast is built kind of like an old UJM, in that it's not huge, it doesn't recline, and it doesn't "encourage" the rider to hunch forward over the tank all the time. Unlike the general run of UJMs (including my old XJ650 Midnight Maxim), the Blast doesn't have a transverse mounted four cylinder engine — it has that single-cylinder pounder instead. It also has a somewhat smaller engine than my 650 had (about 150cc smaller), but it feels a lot more zippy and powerful, probably because my first motorcycle was in terrible shape. It was, in fact, in such bad shape that it rapidly became apparent it could prove downright dangerous, and as quickly as I fixed stuff, other stuff broke. My favorite was when I was pulling up to an intersection, squeezed the hand brake on the right handlebar, and got brake fluid squirted out of the reservoir across my hand.

I found out that day that it's really difficult to stop a motorcycle using nothing but the engine and the soles of my boots. Thank goodness I had a really solid pair of sturdy motorcycle boots, and nobody drove through the space in the middle of the intersection where I managed to get the thing to stop.

The Blast, by contrast, is in excellent shape. It has been well-cared-for by owners who have loved and ridden motorcycles for decades, and used as an occasional fun ride, secondary to their primary motorcycles — cruisers (they were Harley guys). The man who sold it to me said he was getting too old and slow to handle this bike, and needed to sell it basically so he wouldn't be tempted to ride it sometimes. He's sticking to his touring-cruiser Harley now. He's an awesome old life-long biker with a very impressive white beard and an infectious, laid-back, happy attitude. I should give him a call and let him know how much I'm enjoying the bike; I'm sure he'd be happy to know it's in the hands of someone who appreciates it.

Life has been busy lately, which is basically why I haven't been doing much (any) writing here at SOB lately. The motorcycle is actually one of the things that makes it more busy, though definitely among the least busy-making of those things, and among the most fun. Soon, I'll be getting new boots for motorcycle riding (amazingly, I don't have much in the way of good biking boots right now), and a new motorcycle jacket (not so amazingly, my old leather jacket is falling the hell apart — a zipper actually came apart in my hand recently). The SigO is going to get a helmet, both for times when she might be a passenger and as part of her plan to get a motorcycle endorsement on her driver's license again (she lost hers moving to Colorado years ago).

Hopefully, within a year or so, she'll have a motorcycle too. I'll probably post pictures when the time comes.

note: Those pictures were from before I got the Blast. I haven't changed much, but the license plate has certainly changed.

More Details Here

As of today, my first article at Troll in the Corner has been published: Finding Inspiration for NPC Concepts. Hopefully you'll like it as much as the enthusiastic first commenter did.

I have vague plans in mind about topics for other articles soon, including a stat block and description for a new critter, some stats and background for NPCs in support of a module, and maybe an overview of what niche Pathfinder RPG fills.

I've been kicking around the idea of starting up an RPG-focused Weblog of my own, but I don't think I'd get around to it any time soon, and might not maintain any kind of writing schedule at all, so a gig writing for someone else will probably prompt me to write more often and has already prompted me to start writing much sooner than I probably otherwise would have started writing. So . . . there.

I can't fucking stand it.

The incident that precipitated this comment from me is in one of my least interesting articles (in my opinion), Avoid ambiguity when referring to account names. The incident in question occurs with these words:

that value is greater than the cost of the added effort involved is difficult to answer in the general case; but for a person whose login information management procedures easily handle this behavior

This article was also a case of a list turning into a series of subsections, so that there's now no point of differentiation between the last paragraph of the final list item (or subsection) and the first paragraph of the rest of the article. Argh.

Oh, well. It wasn't really one of my best articles anyway. At least this time it wasn't a great article turned into a mediocre article by someone else's meddling.

The last time I tried talking to an editor there about introducing errors into my articles, it was about the UNIX trademark. UNIX is a trademark; Unix is not. Thus, when I say BSD Unix, I'm talking about the BSD branch of the Unix family of operating systems. When a TR editor changes that to BSD UNIX, the sentence now refers to . . . what? Some nonexistent Single UNIX Specification conforming and certified variant of BSD Unix that is called "BSD UNIX" . . . ? Who knows?

When I brought this up, I was basically told to keep my correctness to myself because that's the way TR does it, has always done it, and will always do it. Since then, I've just quietly kept using terms correctly and, when people complained to me about misuse of the term UNIX, I have explained how the term got misused. That's it. C'est la vie. The lesson I learned from that experience is that I shouldn't argue about correctness with the editors, because they don't care.

I won't bother pointing out to them that "; but" is a sure sign you don't know how to use a semicolon correctly.

The Set-Up

There are at least two types of open source development projects in the world.

1. There's the fakey-type open source development project, where someone writes code in a closed team (perhaps a team of one) and makes that code available to the world under an open source license, but there isn't really any way for anyone to actually contribute to the project.

2. There's the for-realsies type of open source development project, where anyone can contribute — though contributions may of course be rejected if they aren't "good" (by whatever definition the core team uses to use).

The Documentation

It's a pretty generally accepted truism that documentation is important. People argue about whether their pet projects have good documentation, what constitutes good documentation, and so on, but they tend to agree that documentation is important.

A key part of most open source development projects is openness about accepting contributions to documentation. Accepting documentation contributions can help improve documentation without taking time away from actual coding by the core team. This is a good thing.

The Problem

It is often the case that there is a very clear-cut, easy way to contribute code to a project, but someone who wants to contribute documentation is left wondering "What the hell?"

The Solution

If you run a Type 2 ("for-realsies") open source development project, stop right now and look at the documentation your project has for documentation. How well documented is the procedure for contributing improvements to documentation? How easy is it to find?

Seriously, this should be one of your top priorities when running an open source project that actually wants contributions from the user base. If you have a core development team, it is actually more important, most of the time, to encourage documentation contributions from the general public than code contributions. The only time code contributions should take precedence is when you no longer have anybody (competent) on the core team.

If you don't have clear, useful, fairly complete documentation documentation (that is, documentation for the process and standards of creating and contributing acceptable documentation improvements), start working on it now. Please.

Please?

Basically . . . one of the things I dislike about XTerm is the way it handles multi-click text highlighting by default. Another is the fact that it doesn't do Unicode by default. Of course, XTerm does everything, one way or another — or so it seems. It just takes working around the defaults somehow.

To solve the Unicode problem, just set the "UXTerm" X resource, which includes applying the effects of XTerm's -class and -u8 options. On at least most systems, entering the command uxterm (instead of xerm) should do the trick there. It seems that someone somewhere along the way came up with the brilliant idea of providing a standard UXTerm resource-active wrapper for XTerm.

To solve the multi-click highlighting problem, your XTerm app-defaults file (on FreeBSD, that'd be /usr/local/lib/X11/app-defaults/XTerm) can be edited to include some lines to specify exactly what characters are considered valid highlighting characters for a given number of clicks. Anything up to five clicks can be defined this way.

There are specific terms with specific meanings that can be used here, and the default for two clicks is XTerm's concept of a "word" — which is fine by me. The defaults for three through five clicks, however, don't work so well for me. In fact, by default, three clicks will match a "line", and both four and five clicks have no default at all. Other than "word" and "line", though, none of the options (which are listed in the XTerm manpage under the on5Clicks resource) match any of the things I'd really like to see highlighted on a given number of clicks. Luckily, the XTerm app-defaults file also supports a (limited) regex syntax for the onNClicks resources, where N is the number of clicks.

Keeping the on2Clicks default, the configuration I use to customize multi-click highlighting is:

xterm*on3Clicks:  regex [^ \n]+
xterm*on4Clicks:  regex .*
xterm*on5Clicks:  line

So. That's the long and the short of it. Other than that, all I use that isn't an XTerm default on my FreeBSD systems is a pair of options — specifically, the -r and -sb options (for "reverse video" and "scroll bar", respectively).

addenda:

If you wish these changes to apply only to UXTerm on FreeBSD, the appropriate file to edit is /usr/local/lib/X11/app-defaults/UXTerm. The proper location for this file may vary among Linux distributions.

So, anyway, as I was going through logs from last week's session in preparation for this week's, I found some amusing little exchanges over which I had a chuckle, and one in particular that boggled my mind.

Setting the scene: It took us (no shit) 31 minutes and 49 seconds of fucking around with Pidgin to get a chat session working. Once we finally got one working so everybody could participate in the game, it was apparently too late — I had already lost my tenuous hold on sanity. This is what I said (names changed to protect the guilty):

(21:34:50) n8 entered the room.

(21:34:50) SigO entered the room.

(21:34:50) @ entered the room.

(21:34:56) @: fucking fuckfuck the fuck

(21:35:24) @: Someone on the Pidgin team needs to die by soaking in strong vinegar.

(21:35:31) n8: agreed!!

(21:36:21) @: SigO informs me there's a Pidgin chat bug that might pertain to this problem that has been around for three years without getting any attention from those sea cucumber fuckers.

(21:36:34) @: "The Sea Cucumber: Nature's Pocket Pussy"

(21:37:03) @: I imagine they probably said "That's how it's supposed to work. You're just too stupid to appreciate its beauty and utility."

I got over it in time to run the session, though.

"Nature's Pocket Pussy"? What the hell was I thinking?

How does someone die by soaking in strong vinegar, anyway?

I'm biting my nails in anticipation of the day a decent multiprotocol IM client with a development team that wasn't born with too many chromosomes in its collective rectum actually supports OTR encryption across the board so I can stop using Pidgin. I'm half-expecting the Pidgin team to somehow permanently break compatibility with the OTR plugin first, though. Well . . . I guess that'll be one way to get me to switch to a different IM client.

What you get is, in addition to the knowledge you contributed some money to a good cause, $1481.31 worth of roleplaying game PDFs from DriveThruRPG. Of course, that's as measured by their usual prices — your personal estimation of what these things are worth might differ.

Anyway, if you have any interest in RPGs and want to donate $20 to relief efforts in Haiti, this is a pretty good deal, I think.