Halo Reach - This Is the Halo Game I've Been Waiting For (very minor spoilers)

I completed Halo: Reach (on normal).  For once, it didn’t disappoint.  No giant monkey hammer reverse Donkey Kong boss battle this time.  A real, satisfying ending that wasn’t just a rehash of the now-iconinc race to get away from the self destruct from thehe first Halo.I only remember two escort missions, but they were very short.  One wasn’t so much an escort mission as a “kill the big boss to allow someone to get away from it” and the single “follow this NPC and protect him” mission involved my favorite thing about Halo: ODST, so I was grinning instead of cursing during that brief section.I really like the commendation system which, while having been done before in previous titles, is well thought out and gives the player feedback and statistics that are interesting and give the player targets to try to hit.  Oddly, it reminds me of one of my favorite D&D modules, in which the players were “scored” based on how well they did, and after the game was over, you could go and look and see how you did relative to other people, and what you could have done differently.  It and the modules like it made for extra fun, and helped us to improve our playing skills.Now that I’ve finished playing on normal to get through the story, it’s time to start slogging my way through Legendary.  It’s often frustrating, and it will take me a long time, but the satisfaction to beat a level on solo Legendary (at least in the first one, and I expect on this one, too) is worth it.Wish me luck…

I've Heard of Hard Sales Tactics, but That Was Ridiculous

So I picked up my new glasses yesterday.  I’m told they don’t look too bad.  Which is good - it means I got lucky.So I was at my optometrist last week, and I looked at the machines that measured my eyes, and then did the “which is better, 1 click or 2, click 1, or *click 2?” bit.  Nothing unusual.So then he says he’s going to dilate my eyes.  Fine, happens every time I go to the eye doctor.  Puts the drops in my eyes, but then the fun thing happens.  He opens the door and tells me that it will take a few minutes for the drops to finish dilating my eyes (it usually does), and there is a lady standing at the door.  The doctor tells me she will take me to where I can wait until my eyes are finished dilating.So, not suspecting anything, I follow her, and she leads me directly to the part of the office that has the eyeglasses, and starts asking me, casually, what kind of frames I like.  So, I start talking to her about what I like about my current pair of glasses, and what I wish was different, and before long, she’s handing me frames to try on.“Hmmm”, I said, looking in the mirror, “I think I like these best of the ones I’ve tried on, but it’s kind of hard to tell, because my eyes are blurry and itching like crazy from the drops.“I even tried “I don’t want to pick out frames now without my wife here to give me her opinion.”  But the lady just kept blindly going on as if I wasn’t objecting (granted, I wasn’t objecting forcefully enough), asking me about whether I liked anti-glare coatings and what-not.So the doctor comes back to get me, does the last part of the exam and lets me go.  I go to the front desk to pay, and the bill is about $150, because my doctor’s appointment copay and new glasses have been combined into the same invoice, and the poor clerk at the front desk can’t seem to figure out how to get the computer to split them back apart.So, I give up and, rationalizing to myself that I needed to get new glasses anyway, I just pay for the whole thing and leave.A few days later, I get a call that my new glasses are ready and, like I said, I’m told I could have done a lot worse.But I’m going to be switching optometrists…

Sometimes it's good to be wrong. I'm really enjoying Halo: Reach

I had said that I wasn’t going to buy it, but, after being disappointed with the game I expected to be playing now, and being stressed out recently, and since my wife and daughter are out of town, I decided I needed something to do for fun.  So I caved in and bought Halo: Reach.

I’m really enjoying it.

I’ve gotten through Mission 6 at this point, and I’ve enjoyed it so far.  One mission reminded me of the Truth and Consequences level of Halo 1 (the night time creeping around sniping one), which I really enjoyed (both in Halo 1 and Reach).  The Space Combat mission was surprisingly fun (although I lost my bearings several times - I expected more from the HUD), but easier than I expected.

The Value of Slow: Lessons Learned via the Golf Course

Once upon a time, I was working on a project at a high tech company in an LA suburb, and I was working for a manager that I’ll call Mike (because that was his name).Mike had once worked managing a group that put satellites in orbit, and from that experience he gathered some great wisdom, some of which he attempted to impart to me, and some smaller amount of which actually sunk into my young (at the time) head.The most valuable thing I remember was that he always insisted we built what he called “golf course time” into his projects. It was calendar time (as opposed to time on task) for the folks working on the project to be doing something besides work (golfing, in his casef) and have that “Oh, wait, we didn’t think about X” thought that can be the difference between a project going off the rails or coming in under budget.We worked just as hard as the other groups, and got just as much done, but we would interleave tasks, so that everyone had some extra calendar time to come up with those effort-saving and project-saving ideas. And when someone did think of something, Mike would make a point of highlighting it, so that the rest of us would recognize those thoughts when we had them.I don’t always succeed in building extra calendar time into my projects these days, but I do occasionally come up with one of those ideas; for me it’s usually while I’m reading, or working out.More often though, I remember what Mike tried to teach me because I just got caught by surprise by a nasty little corner-case that I wouldn’t have painted myself into - if only I’d managed to have had the time to have thought of it beforehand…

Please Stop This Thing, I Want to Get Off: Living the Merry-Go-Round of FAIL

There’s this pattern of application failure I’ve ended up dealing with a lot over the years. Stop me if you’ve heard this one before.

Our scene opens with a multi-tiered client-server application, let’s say, for the purpose of argument, that it’s a web app. There are web servers in the front, usually with some sort of load balancer in front of them, then maybe a middle tier application server (SOAP, J2EE, that kind of thing), and some kind of shared state/storage at the back, let’s call it a SQL database.

The Hard Stuff - iPhone App Design Edition

I was talking to my latest iPhone App customer today, and now that we’re both able to look at the prototype, we were talking about the features that we could add before the shipping version, or not.  We talked about trade-offs, and I heard myself saying the same thing I’ve said many times before, so I thought I’d write it down.

There are three really hard things about iPhone Apps (at least to me - I have a background Enterprise and Web Apps).

What a Difference 2 Years Makes - a Study in Contrasts With iPhone Ad-Hoc App Distribution

The first iPhone App that I worked on was submitted in October of 2008. The month before we submitted, there was a flurry of emails between me and my customer, a sample of which are reproduced below:

Begin forwarded message:

From: Customer

Date: September 16, 2008 12:58:19 PM CDT

To: Carl Brown 

Subject: Re: iPhone project status

My Identifier is XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Emails omitted for brevity.

Begin forwarded message:

**From: ** Customer

The Rules - At Least As I See Them (Well, the First Two)

Since I’ve been dealing with computers, I’ve developed some rules of thumb.  The first rule seems obvious, although I’m constantly surprised by the people that break it.  It is:Rule 1: Never run a command on a computer that affects the communications path through which you are connected to that machine.This is slightly more complicated than it sounds - especially when configuring routing protocols in routers.  You change things such that you lose your routes from where you are to that machine, and it’s time for Plan B.  However, for the most part, it’s straightforward, which is why it became the first rule.The second is less obvious, and more controversial, although it’s potentially more important.  It is:Rule 2: System add-ons included solely for the purpose of reducing downtime by means of failover or redundancy will cause more downtime due to bugs or misconfigurations than would have been caused by hardware failures if those add-ons had not been included, unless the level of diligence and effort is greatly increased.Let’s take that a piece at a time.  There are a lot of pieces of tech in the world that people use to protect against hardware failures, like SANs and clusters.  That function, protecting against hardware failures, is inherently complicated, and that means that those pieces of tech have to be inherently complicated.  And Murphy’s Law (and experience) tell us that the more things there are that could go wrong, the more likely something will.  In fact, I contend that, unless you go to extraordinary efforts to test every last possible thing that can go wrong, problems with those many complicated bits will cause more problems than would have been caused if you’d just left them off.I’ve seen a lot of network outages in my time that were caused by routers that got confused and sent out (or listened to) the wrong routes.  Network engineers have many names for this phenomenon - my favorite is “flapping”, and it’s a very common happening.  I have seen many fewer network outages caused by router hardware that just dies - and most of those have been routers that spent time in places with very dirty electrical power.  Now of course, I have seen networks that lose routers without any hiccups at all, but those are generally the networks that require “pull tests” (where you unplug routers and make sure things fail over as you expect) after every non-trivial configuration change and periodically on a regular basis.Likewise, I’ve dealt a lot lately with a network that has regular issues due to “automatic spanning-tree reconfigurations” and a database cluster that blue-screens when the underlying SAN hiccups.Think about it for a second - there are many different ways that a system can go wrong - many different pieces that can fail in different ways.  What are the odds that the code that is supposed to deal with that specific failure is going to behave exactly as you want it to the very first time that section of code is executed in your environment?I’m not saying “never use any High-Availability add-on”, I’m saying “if you use an High-Availability add-on, either spend far more effort configuring and testing it than you would spend on the non-HA version, or expect it to cause you more problems than you would have had if you’d gone with the non-HA version.“It’s okay if you don’t believe me.  A lot of vendors have spent a lot of money trying to get you to believe that it isn’t true.  But think about it, and start paying more attention to what’s causing your enterprise more problems.  After that, I think it will become clear.