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.

• Apply In Person: We'll tell you the position has already been filled if you are old, fat, ugly, or tattooed.

• Career Minded: Female applicants must be childless, and pregnancy will not be tolerated.

• Casual Atmosphere: We don't pay you enough to buy nice ties and shoes.

• Competitive Salary: We stay competitive by paying less than our competitors.

• Duties Vary: You will be asked to serve coffee, handle the boss' dry cleaning, or wash an executive's car, from time to time.

• Fast-Paced Company: We have no time to train you.

• Good Communication Skills Needed: When management fails to communicate effectively — which is often — you will be expected to listen carefully and figure it out on your own. If something goes wrong, you will be blamed.

• Must Be Deadline Oriented: You will already be six months behind schedule the day we hire you.

• Must Have an Eye for Detail: We have no quality control, so if something goes wrong, we'll blame you.

• Must Have Leadership Skills: You will get the responsibility of management without commensurate title, pay, or respect.

• No Telephone Calls Please: We've already filled the position. This posting is just a legal formality.

• Problem Solving Skills Critical: The office is in perpetual chaos, and nobody knows how to prioritize.

• Seeking Candidates with a Wide Variety of Experience: You will be expected to do the jobs of three people who just left.

• Some Overtime Required: . . . each night and every weekend.

• There are times when silence has the loudest voice.

• It's what you learn after you know it all that counts.

• Most of us can keep a secret. It's the people we tell it to who can't.

• People may doubt what you say, but they will believe what you do.

I most recently ran across it in two places. One was the Ruby Best Practices book (great book so far, by the way). The other was a Weblog post by John Nunemaker called Class and Instance Variables in Ruby. In the latter, he explains that this idiom can be used to create class instance variables which — unlike class variables — are per-class specific. By contrast, the scope of a class variable (not a class instance variable) extends across the class in which it is defined and its subclasses. Anyway, his example of creating a class instance variable with accessor methods looks like this (with an extra semicolon added by me for clarity):

class Polygon
  class << self; attr_accessor :sides; end
  @sides = 8
end

After playing in irb, I discovered that the fact everyone else in the world seems to want to do this in one line isn't a result of not being able to spread it across multiple lines. Considering the one-line construction in this case looks ugly as hell to me, I'd rather have written that code like this:

class Polygon
  class << self
    attr_accessor :sides
  end
  @sides = 8
end

I don't, in fact, see any reason to cram it all into one line like that. There are times when something with a clear multiline form like this probably should be done in a single line — such as when you want to create an iterator block that only contains a single line of code:

array.each {|x| puts x }

The multiline approach would of course look like this:

array.each do |x|
  puts x
end

I think that, in a case like this, the single line form is clearer. There's a distinct single line form for a block in Ruby, though. The example of the class instance variable's accessor, on the other hand, does not have a distinct form well suited to a single line. Rather, one has to just manhandle code line terminators (the semicolons) so that Ruby won't throw errors when cramming everything onto a single line — and it ends up looking cluttered, especially when there's a symbol involved with its leading colon.

Am I the only person that thinks this way — that the class instance accessor is clearer in a multiline form than strung together on a single line? Is there some benefit to doing it all in a single line that I just haven't seen?

Release Date:^M
2010-01-14^M
^M
Product: ^M
OpenOffice^M
^M
Tested Vulnerable Versions: ^M
3.1.1 and 3.1.0^M
^M
Vulnerability:^M
Null Pointer^M
^M
^M
Description:^M
Hellcode Research discovered a null pointer vulnerability in Openoffice for Windows.^M
^M
Opening a malformed ".csv" file with Openoffice, causes a crash on "soffice.bin"^M
^M
^M
PoC:^M
http://tcc.hellcode.net/sploitz/csv.rar^M
^M
^M
Credits:^M
Hellcode Research^M
The Computer Cheats (TCC)^M
Natal Networks^M
^M
^M
Urls:^M
tcc.hellcode.net^M
forum.hellcode.net^M
www.natalnetworks.com^M
^M

I wonder how things like this happen. It looks like someone might have composed an email in Notepad then used some Unix tool to send it to a mail user agent of some sort. This is something I have seen before, a couple of times. Is there some email client that does this crap?

If you have an explanation that escapes me at the moment, I'd love to hear it. If they're composing emails for the bugtraq list in Notepad, though, I'm pretty sure I wouldn't ever want to work for them.