November 2011 Blog Posts

The Problem with UltraViolet Digital Copy

I have, so far, mostly enjoyed the whole "digital copy" thing movies provide. It saves me time ripping DVDs and running them through Handbrake, plus it's "legal."

Which isn't to say l have any moral qualms ripping discs I own and transforming them into formats I require for personal use. I don't condone piracy and own a lot of discs.

I recently picked up Harry Potter and theĀ  Deathly Hallows Part 2 and it came with this new "UltraViolet Digital Copy" which promises to be the latest and greatest thing to happen to digital copy.

It is The Suck.

To get your digital copy, you first have to visit the Flixster site, where you get to create a new account. Because I needed another set of credentials to remember.

Next, Flixster asks to link to your UltraViolet account. Don't have one? Sign up now! That's a second set of new credentials. Thank God for LastPass.

Once you do that, you finally get to enter your secret code to get your digital copy. Entering your code allows you to stream from their web site.

If you want to download the movie for travel, you can do so by downloading the Flixster Collections app to your computer and downloading through that. Keep that app around - you can only play the downloaded copy with it.

My use case is getting the movie on my Android phone and my iPod Classic, so this doesn't help.

To get it on Android, there's an app for your phone to install so you can download and play there. Great - so the time and bandwidth you spend downloading to your computer is wasted. Re-download that bad boy just for your phone, baby.

It's the same for iPod or iPhone. Want to watch? Install the app and download.

Guess what, though - iPod Classic doesn't run apps and doesn't have network connectivity. There is no way I can see to get this thing into iTunes so I can sync it onto my iPod. (You let me know when they have a 160GB iPod Touch and I'll look at switching.)

This all boils down to me having a "digital copy" but still having to rip the disc and play the Handbrake game.

Way to go, Hollywood. You obviously have it all figured out.

Happy First Birthday, Phoenix Aeralynn

Friday was Phoenix's first birthday, so on Saturday we had her party.

Phoenix with her cake.
From 2011 Phoenix's First Birthday Party

The party was supposed to start at 12:30p, but everyone seemed to be there about an hour early, so it was anarchy from the get-go. Phoenix didn't seem to mind getting passed from person to person the entire time. It took a bit for her to get into the gift opening spirit, not quite being sure what to do with the wrapping paper, but after being shown how easily it rips, she figured it out.

I'm pretty sure her favorite part of the whole thing was the cake. She really dug into that and ate an entire piece.

Phoenix eating birthday cake.
From 2011 Phoenix's First Birthday Party

We wrapped it up by a bit after 5:30p and cleaned the house for most of the rest of the night. I'm guessing that's the signs of a successful first birthday party. Right?

It's pretty amazing what a kid learns in just a year. From being pretty much motionless in a cradle to walking around the house at full speed, opening drawers and cabinets. From not being interested in anything to pointing and being interested in everything. She doesn't talk much yet, just "ball" and "hello" (she puts her hand up to her ear like she's holding a phone every time she says hello - that's Grandma Illig in action, there). She's not afraid of anything.

After everyone left, she ran over to the stairs (she's normally kept in an area without stairs, blocked off by baby gates) and climbed all the way to the top by herself (with Daddy on her tail, just to be sure). She did that three times.

Such a big girl now, and a total maniac. She is everywhere, all the time.

Happy birthday, miniature baby. Mommy and Daddy love you.

Holiday Fun at ThinkGeek

I'm going to be doing most of my holiday shopping online (again) because crowded Black Friday malls stress me out (still).

For that geek on your list, may I recommend ThinkGeek:

ThinkGeek Holiday Gift Station

It might be a good time to get a BigTrak Jr. or some Star Wars glassware...?

WCF Fails to Build or Update Service Reference When Path Too Long

I was working yesterday on a solution in Visual Studio and noticed that every time I'd rebuild VS would report the build as failed... but without any error messages.

I thought it was just a fluke, but then I had to update a service reference. When I tried, I got the following error message:

Could not resolve mscorlib for target framework ".NETFramework,v4.0". This can happen if the target framework is not installed or if the framework moniker is incorrectly formatted.

I searched all over and verified the TargetFramework settings on every project. No luck. Tried removing the service references so I could re-create them. Got the error and couldn't remove the references. Rebooted the computer, you know, because that's what you do. Still got the error. At which point I was like...

Fuuuuuuuuuuuu

And then I found this blog entry that saved my life. I was hitting a maximum path length error.

I'm on Windows 2008, not XP like in the article, but MAX_PATH is still 260 characters. I was working on a project that was only about 100 characters deep, but if you look at the files that VS generates when updating a service reference, you see filenames that can be 100 characters long with the fully qualified type name of the proxy type being generated and a suffix of ".datasource" (e.g., "Some.Really.Super.Long.Namespace.That.May.Be.Inside.Your.Project.datasource"). All of that put together and I was bumping up against the max path length.

Moving my project closer to the root of my drive resolved the issue(C:\project rather than C:\dev\project\tasks\taskname\trunk sort of depth) and I was able to build again.

I'm guessing that something in there isn't using the Unicode path extensions that would allow for a 32,767 character max path length. Hopefully that will be fixed in the next VS... but I'm not holding my breath.

Xbox Live Blocked by Wireless Bridge

I spent far more time than I'd like to admit in troubleshooting this issue so I figured I'd at least blog it.

Symptoms: When you run the "network connection test" on the Xbox it consistently succeeds. When you try to connect to Xbox Live, either to sign in with your profile or do a "Recover Gamertag," it fails and tells you to go run the network connection test.

Let me tell you how frustrating this behavior is. The connection test says fine, but when you try to connect it says it can't - go run the test?!

My network is set up right now so I have my wireless router downstairs feeding a wireless bridge (DAP-1522) upstairs in the game room. The Xbox is connected through the bridge. Everything was working wonderfully until around two weeks ago. Nothing changed on the network to my knowledge, no configuration changes or devices added/removed. Just... magic. Things are failing.

The first thing I did was disconnect the wired connection to the bridge and connect using the Xbox onboard wireless adapter. Same symptoms, only this time I could occasionally connect to Xbox Live if I tried signing in five or six times in a row. Not a lot of progress, but progress.

I rebooted and reset every network device I own with no luck.

I contacted Xbox Support via email and they directed me to this page about troubleshooting connection issues. None of the items here helped, but it's understandable - there's no way they could have guessed what was wrong.

The breakthrough came when I powered down the bridge and then connected to Xbox Live via wireless. Instant success. Something about that wireless bridge was interfering hardcore with the rest of the wireless network.

I ended up resetting the DAP-1522 bridge to factory defaults, doing a firmware upgrade (not sure if that was necessary, but there was a minor-version update available, so I figured why not), and reconfiguring the whole thing from scratch.

The Xbox is connected through the bridge once more, but now it signs in correctly.

This isn't the first time that DAP-1522 has given me grief. When I was using it as an access point rather than a bridge it also had a couple of times where I had to reset it to factory defaults and start over. Like running for an extended period of time causes some sort of "buildup" that has to be flushed out. I may have to replace it with something more reliable.

Why I Didn't Get Modern Warfare 3

Now that Call of Duty: Modern Warfare 3 is out, I've had some folks asking when I was getting it.

I'm not. At least, not yet.

Why not?

I'm a single-player campaign guy. I like the stories that go along with those campaigns. I like being able to pick it up in the 17 minutes I have between getting home from work and the arrival of my wife and daughter, which indicates it's time to get back to work around the house.

I also like co-op play. Borderlands was really spectacular for this. Modern Warfare 2 was OK with its "spec ops" mode, but I really want a co-op campaign. I like working with my dad, uncle, and friends toward a common goal. "Spec ops" only being two-person... was limiting.

Battlefield 3What I'm not interested in is what is widely termed "multiplayer" but basically boils down to "100 different free-for-all modes." Deathmatch and Team Deathmatch are roughly identical - the only difference is that in the latter, half the people aren't shooting at you. "Horde mode," "Capture the Flag," and other almost-goal-based modes are only tolerable (to me) for a little while before I get really bored. I want a reason to do what I'm doing, not just endless waves of guys to shoot.

I did get Battlefield 3, which I was led to believe by various previews and things would have a decent co-op mode.

Eh.... not so much. I did a separate review of that and discussed my thoughts there, so I won't go over that again.

Anyway, I'm starting to feel "done" with the whole military-based first-person-shooter. They're all starting to feel "same-y" to me. The single-player campaigns get shorter, the "multiplayer" gets larger, and co-op gets the short end of the stick. New features get added that are totally things I'm not interested in (I don't need "battle log" integration to track my friends' kills) but none of the stuff I would like (better co-op?) shows up.

At some point down the road, I may pick up MW3. I'm not saying I'll never get it. Right now, though, I'm wading through Battlefield 3, Halo: Reach, and LA Noire. I haven't finished the new Portal 2 co-op levels, either. And when Borderlands 2 comes out... I'll definitely be on that.

Does Automation Create Laziness?

I'm working on this theory that the more automation you wrap around a development environment - testing, static analysis, etc. - the lazier the developers in that environment get due to increased reliance on the automation.

That's not necessarily a bad thing, but I'm not so sure it's good, either.

Let's say you have a .NET project and you've got it totally wired up with automation.

  • You have a continuous integration server running the build on every check-in.
  • You're running unit tests and failing the build if the test coverage levels fall below a certain limit.
  • FxCop runs with almost all the rules turned on to check for consistent behavior.
  • StyleCop runs with almost all the rules turned on to ensure the code is consistently formatted.
  • NDepend runs to check your dependencies and ensure other custom project-specific standards are met.

You even run your code through code reviews to ensure you get a second (or third, or fourth) set of eyes on everything. (No, that's not automated.)

The point is, you've got all of these checks and balances in place so, ideally, the automation will catch a lot of the stuff before it even makes it to code review.

Somehow, though, you still see things creeping through. Things that should have been caught somewhere along the way. Things that don't make sense.

Maybe it's a bad naming convention that's started that encourages the breaking of the Single Responsibility Principle... like HtmlHelper. (If you have to name your class with "Helper" or "Utility," I'll also put good money down that you don't really know what it's supposed to do and that you've totally broken SRP. But even if you disagree with my example, stick with me.)

So you add some automation around that to try and head off that bad naming convention. The build will break or give a warning or something if the bad convention is used. You educate the team on why the rules were updated and folks agree to amend behavior. Fixed, right?

Nope. There's always a way to game the system. Now there's a new convention where instead of "Helper" or "Utility" it's "Service" but the point is the same - it's a dumping ground for random, only loosely related functionality. But now everyone thinks it's OK, it's not a problem. Why is that?

The automation didn't catch it, so it must not be a problem.

The automation only catches the exact rule being broken, but can't enforce the principle. If a person doesn't catch it - you, the developer - that doesn't mean it isn't an issue.

Another example: You have your test coverage requirement cranked up to 95%. That's pretty high. It's not 100% because in some cases that's not even possible, but 95% gives you some wiggle room to leave things uncovered but have full coverage on those things you are able to cover.

The thing is, once you have a significant codebase, that 5% can potentially be pretty big. It might be several [small but important] classes.

How come there aren't any unit tests for this code? "Well, the build didn't fail, so isn't it OK?" No, it's not OK to not test your code just because you found a loophole in the automated rules. I mean, the cops may not have caught you for robbing the bank, but does it mean you didn't break the law?

The automation didn't catch it, so it must not be a problem.

The thing is, there's not even always a way to catch this in code review. The naming convention thing can be caught... if the reviewer is familiar with the team's past history and why the convention is in place. The coverage is actually harder to catch, especially if there is a lot to review all at once. You have to have a lot of discipline to mentally follow through the various execution paths and see how the tests exercise it. You also have to trust that the developer submitting the code for review did their due diligence and actually wrote the tests.

Missing it in code review can sometimes even mean worse things. Now, not only did the automation let it slide, but a fellow developer also missed it. Must mean you never have to fix it if someone else runs across it and does catch it, right? Why do you have this 3000 line method? "It made it through code review."

Sometimes this means you update the automation to try to catch these things. Cool, now you can't have a 3000 line method. But that 2999 line method is just fine because the automation didn't catch it.

That's why I'm starting to think automation makes you lazy. You can rely on the automation to catch so much, you stop trying to preemptively catch it yourself. You stop using your own heuristics to detect issues with your code and you fall back on the automation. And that's sort of the point of automation - to help you catch things you'd otherwise miss... but it doesn't entirely remove your responsibility for being the developer.

Be a professional developer. Use the automation, but also use your brain. Work with the automation. Understand that the automation around your build is a tool there to help you, not robotic police trying to enforce the law. Collaborate with your team and ask questions if you don't know. Be amenable to refactoring - or rewriting - if something gets discovered after the fact.

Don't let the automation make you lazy.

189 Trick-or-Treaters

We were down quite a bit this year, back into the range we were at in 2006 - 2007. Again, it was a school night, but Halloween being on a Monday, we weren't coming off a weekend (like last year when Halloween was a Sunday). It's looking like when Halloween is in the middle of the week, we get a dip in visitors. Last year I mentioned I thought we'd be down this year and I was right.

2011: 189 trick-or-treaters.

Cumulative data:

Time Blocks
6:00p - 6:30p 6:30p - 7:00p 7:00p - 7:30p 7:30p - 8:00p 8:00p - 8:30p
Years 2006 52 59 35 16 0
2007 5 49 39 25 21
2008 14 71 82 45 25
2009 17 51 72 82 21
2010 19 77 76 48 39
2011 31 80 53 25 0

We shut down at 8:00p this year rather than running until 8:30p for a couple of reasons:

  1. The visitor count was really dwindling. The majority of the kids in that last half-hour block showed up closer to 7:30p than 8:00p.
  2. Phoenix needed to go to bed. She goes to bed around 8:00p and if we have people ringing the doorbell and knocking, she'd never get to sleep.

The costume this year was The Mad Hatter. Phoenix was Alice, and Jenn was The Queen of Hearts.

Travis as The Mad Hatter and Phoenix as Alice.

My biggest peeve this year was one I already mentioned last year: "If your kid can't walk and/or talk, they're not old enough to trick-or-treat."

I actually declined putting candy in the bucket a parent waved in front of my face that was intended for a sub-two-year-old sleeping in the stroller. They already had four kids with them, and then this fifth bucket pops out. "Who's this for?" I asked.

"It's for him," said the mother, pointing at the sleeping kid.

"What? Is he really going to eat this? Really?" I held up a Snickers bar from the candy bowl. The mother stared at me with this guilty look on her face but remained silent. "Yeah, I didn't think so. Happy Halloween!" I put the Snickers bar back in the bowl and shut the door.

I'm the Candy Nazi.