Archive for February, 2008

links for 2008-02-29 »

  • The comments here are amazing. “My 5 year old son pointed out that the passenger’s shoes cannot be removed. Then, we placed a deadly fingernail file underneath the passenger’s scarf, and neither the detector doorway nor the security wand picked it up.”
  • “The people who handle our website set up mock pages. It’s as simple as that. A third party was preparing something in case (Favre’s retirement) happened. They’ve done that the last five years.” Your web site folks are idiots and should have a test site.
  • I didn’t know Marissa Mayer is from Wisconsin. Yet another person I’d love to talk to for an hour.
  • This is the dumbest advice ever. Typos are mistakes. Mistakes are bad. If they aren’t mistakes they aren’t typos. If the only way to get attention is to be an idiot and misspell something then you are in trouble.

Misspellings Are Bad »

I just read “Engage Your Readers With Typos and Misquotes” over at Copyblogger. Given that the post is the single worst post I’ve ever seen on Copyblogger I was going to refuse to be engaged, but then I thought that I don’t want people to be encouraged to be idiots. Hence this post, combating stupid advice.

1. Typos are errors. Errors are things you didn’t want to happen. I argue that if you intend to misspell something it cannot be a typo, for it is not an error.

2. Misspellings make you look stupid. Taking a few seconds to check your work with a spell checker helps you avoid looking stupid.

3. The attention you will get from misspellings and misquotes will be from people that want to point out the mistake. Don’t confuse comments pointing out your mistakes for actual conversation. It isn’t. Whatever point you were making is lost on those people, because they already judged you by your mistakes, not by your content.

4. Though the strategy works okay for Will Farrell, I contend that if the only way to get people to notice you is by looking stupid you are in trouble. Get better content.

Fabricated words can be fun, and misquoting a saying in a cheesy way might be okay. Most of Nick Cernis’ post seems designed to drive up comment counts without adding any value, though, and in the process it makes you, the author, look dumb. Where is the value in that? My advice is to write something worth reading, use proper grammar and spelling, have a real conversation with your readers, and seem like someone worth reading again.

Get To Know Your Systems, But Not Too Well »

To me, it seems that a system administrator’s knowledge of a system, application, or technology follows a curve similar to the 80/20 rule. 80% of what you need to know comes in the first 20% of the time you spend on the problem:

Time Spent vs. Knowledge Gained

“So what?” you ask. Well, I think about this when I see folks spend hundreds of hours to design the perfect system. Or when they absolutely must tune a server to its peak performance. Or lay out LUNs on storage arrays. The list of examples is enormous, but I only ever have one question: was all that time best spent on that one system, that one task, that one goal?

The inverse of this is when I see a system administrator that doesn’t know anything about their systems. They bumble around, messing up applications, disrupting operations, and generally causing mayhem just because they took or had no time to learn about the systems they are maintaining. Their systems are black boxes, and the symptoms of this are often systems going years without patching or upgrades, outages, security problems, and lots of blame shifting. To these folks I only ever have one question: of all the time spent worrying, panicking, and blaming, could you not take a little bit of it to learn about a system, so you wouldn’t have to worry, panic, and blame so much?

As with most things, the right balance for an individual, for an organization, and for a system is somewhere in the middle. While the optimal mix might not be 80/20, but instead 60/40 or 90/30, it is almost never 0/0, or 100/100.

links for 2008-02-28 »

  • Clinton is trying to steal the Democratic nomination by convincing delegates to vote for her against the public will, and against the automatic delegate provisions. Is this supposed to make us think of her as something other than a dirty politician?
  • “Who would have guessed that when you remove Garfield from the Garfield comic strips, the result is an even better comic about schizophrenia, bipolor disorder, and the empty desperation of modern life?” OMFG, awesome, I hate that cat anyhow.

Don’t Store Things You Care About In /tmp »

“Hey guys,” he says, stepping into our office. “I have a problem.”

“What is it?” we reply.

“Now that I’m back from vacation I find all the data for a project I was doing is missing.”

“Restore it from backup.”

“It doesn’t seem to have been backed up, either.”

“Where was the data?”

“/tmp.”

“Ever heard of tmpwatch?” It’s now obvious why it’s missing and why it didn’t get backed up.

“No…”

Moral of the story: /tmp is for temporary stuff, not your big project’s data.

Underpromise, Overdeliver »

“What are you? Mr. Scott?”

“Excuse me?” I reply. Did he just compare me to Scotty?

“You scheduled your last few changes for way more time than you needed.”

“Yeah, I guess so.” So what? I’m busy here.

“Didn’t you ever watch Star Trek, where Scotty would tell Kirk that a fix would take a day and he’d do it in an hour?”

“Yeah, underpromise and overdeliver…”

“Wouldn’t it just be easier to get a 30 minute outage instead of always asking for two hours?”

“Sure, but if things go wrong I’ll need that whole two hours to fix them again. If you want to compare me to Mr. Scott that’s fine, but the difference is that Mr. Scott was usually starting with something that was in a known state: broken. Me? I’ve got twice the work. I’m breaking things, hoping they break the way I think they will, and then fixing them again. Apples and oranges.”

“Are you saying you’re better than Mr. Scott?”

“I think a better comparison would be developers and Romulans, both looking to destroy my ship.”

links for 2008-02-26 »

Book Smart vs. Street Smart »

Book Smart: Knowing that separate development, test, and production environments should be as identical as possible.

Street Smart: Realizing that depending on the purpose & goals of the development and test environments, “identical” may only refer to the OS, and you might only need physical hardware for production, if even that.

Book Smart: A vendor says a software upgrade on a storage array will take two hours.

Street Smart: The vendor is only talking about successful, optimal upgrades, and you schedule additional time for handling whatever goes wrong.

Book Smart: Operating system patches don’t change functionality.

Street Smart: The people that put OS updates together are human and make mistakes, like overwriting configuration files, messing permissions up, or omitting a package dependency.

Close
Powered by ShareThis