Derail

So the 30 day meditation challenge did not go so well. It turns out that if you leave the house at 7AM and don't get home until 10PM (welcome to my Mondays and Wednesdays), it's hard to find any time in a quiet place, and when I do find that time, I fall asleep. Off the bat, I lost the challenge on the first Monday, but then the next day I had too much schoolwork to do, so I had no time that day... and so on.

A more realistic goal for myself would be to meditate three times a week. That way, I can make plans to meditate on certain days, and if the plan doesn't work out, I have time to make it up. Good idea, Ed, let's do it!

The lesson I'm taking away from this is that it is unrealistic for me to attempt to force myself into a difficult arbitrary structure simply will not work. I'm too much of a "seat of my pants" kind of guy (on the MBTI scale, I'm definitely a perceiver).

Next Stop, Meditation Station!

I've been meaning to try meditation for a long time. I read a fair bit about it (starting with The Relaxation Response and moving to the Internet), and after talking with a few people, decided now would be the best time for me to try it.

So I challenged myself. 30 days, every day, meditating. Just 20 minutes (with a few minutes on each side) a day, I can do this, right?

Well, it took me about a week from when I said that to when I first meditated. But that first meditation was yesterday! So that's good. What about today?

I decided the best way to help me continue to meet this personal challenge would be to post it online and give daily updates. This would both A) get me blogging again, and B) provide me with extra incentive. After all, I can't let my (two or three) readers down, can I?

Nitpicking a House of Cards

I love the movie The Mummy. It's just a fun movie, and I'm not alone in liking it. The combination of horror and action and comedy (and even zombies!). But there are several bits of it that always piss me off.

• In the beginning scenes with Ardeth and the Medjai, there are like hundreds of Medjai. But once Ardeth and Dr. Bey confront Rick, Evelyn, and Jonathan about awaking Imhotep, all the other Medjai disappear, off doing who-knows-what. It should would've been useful to have even a dozen scimitar- and rifle-wielding warriors helping out. (At least in The Mummy Returns, they mentioned the other Medjai had to get ready to fight the Army of Anubis.)
• After Imhotep has "absorbed" three of the Americans, leaving only Mr. Daniels, the party is driving in car to get away from Imhotep's zombies. They know they need to protect Mr. Daniels to prevent Imhotep from getting fully regenerated (another case when more Medjai would have been nice). So why do they leave him unprotected at the back of the car? Dumb.
• And then after the zombies pull Mr. Daniels off of the car, the party keeps driving on, knowing full well that they are letting Imhotep get fully regenerated. Sure, there were plenty of zombies, but Ardeth, Rick, and Dr. Bey were all pretty badass fighters. You'd think they could've held off the zombies while Mr. Daniels got back in the car.

But this whole blog post is a waste of bytes. It just bugs me every time, probably because I enjoy the movie so much. 

Oh, By The Way, New Baby!

Yeah, so my lack of posts recently was first a result of pregnancy (Pregnancy: not just for expectant mothers!) and now a result of our firstborn, Mia MacKenzie!

You can find more photos of our beautiful daughter at Flickr. Mia is more important than just about anything I've ever done, but I will attempt to get back to posting a little.

What is a TypeLoadExceptionHolder and What Should I Do If I Have One?

Recently at work I was creating a new branch in Subversion for one of our projects when I ran into a little error on one an integration test called "Should_Send_Data_From_File_To_Server":

Object of type 'System.Runtime.Serialization.TypeLoadExceptionHolder' cannot be converted to type 'System.Collections.Generic.List<companyname.framework.persistableobject>'

TypeLoadExceptionHolder? What the crap is that? I tried Binging it, and after pouring through results, found this post by Michael Freidgeim:

Binary deserialization doesn't throw exceptions, but just replace some members(in my case it was enum, that was moved from one namespace to another) with this undocumented TypeLoadExceptionHolder class.

OK, so why was my binary deserialization failing? I wrote up a quick integration test to simply serialize and deserialize a file and it worked fine. But the sample serialized file just wouldn't deserialize in this branch, even though this exact code worked fine in the source branch.

I was nearing my wits end when I realized Michael had already nailed it for me: namespaces. One of the reference assemblies, "companyname.framework", had changed names in this release branch. It used to be "companyname.framework.core". And so the sample serialized file had the old namespace and couldn't properly be deserialized. The mystery is solved.

The moral of the story is Never trust canned data in your integration tests. Always suspect it when sometime goes wrong.

Force Feeding You Change

Google loves to just drop new features in your lap. I remember when I first noticed Google Talk; I came back to my computer and Graham had dropped me a line, "yo fezzik, whats shakin bro?" (of course, Eric was the second person to send me a chat). I was all "WTF is this? Get out of my inbox!" But I got over it.

It reminds me of the way Blizzard would work their betas. For the Warcraft 3 expansion beta, when they added a new unit, they would make that unit overpowered so that everyone would use it (When they added "fragmentation shards" to the mortar teams, they made the effects so loud and big that they were impossible to ignore). That way Blizzard could see how people reacted to it, how they used it, etc. They would use that data to find the right balance.

That's just like what Google has done with Talk and Buzz. They just throw it right at you, in your face, in Gmail. You have no choice but to deal with it (yeah, sure, you can disable them both, but how long did it take you to find that little link?). And so now everyone is talking about Buzz, using Buzz, and Google can use all this feedback to flesh it out properly. Nicely done, Google.

Google Buzz: The Facebook-ization of Google

Google surprised me when they suddenly launched their latest endeavor into the social networking world, Buzz. After one look and their introduction video, it seems clear they are targeting one competitor: Facebook. Sure, Buzz includes features from Yelp, Foursquare, Gowalla, and others, but those aren’t the main targets.

Think about it. Facebook is working on a new email feature. Facebook’s goal is to have you on their website for as much time as possible. I know plenty of people who would almost never leave Facebook if they could get their email there. Sure, there would still be users like me who actually post content into Facebook via Twitter linking outside content. But for probably 80-90% of users, Facebook becomes the Internet.

Google doesn’t like that future. Google’s business model is predicated on having users, well, use Google. They want users to experience all the web has to offer, and to find it all through Google Search. There are two parts to that strategy: pushing the openness of the web and empowering users, and then showing them relevant advertisements. Google cannot do all the cool stuff it does without the huge revenue base it has, but more importantly, all these cool things are there to keep you on Google and learn about you so they can keep showing you relevant advertisements.

So what is Buzz? It’s a reason for people who use GMail a lot to stay on Google servers. It’s an attempt to keep users from, once they’ve read their mail, leaving the site and going to Facebook. Will it work? I don’t know. I only have access to Buzz on my Android, in the Maps program, so I can’t say how useful it is. I agree with Eric that the technology involved is cool, but that goes back to part one of the strategy: pushing openness and decentralization. (Think about Google pushing decentralization. If everything isn’t in one place, how do you find it?) But the takeaway of this is that Google is reacting to the Facebook-ization of the Internet, and it seems to be a pretty cool reaction.

Building Integration Tests With Workflow Components

A lot of blood, sweat, and tears have been shed over the use and design of unit tests, but what about the red-headed stepchild of automated testing, integration tests? They have fallen out of vogue lately in popular discussion, but they can be just as useful as unit tests. Just search for unit test best practices and integration test best practices; the unit test search has almost twice the results.

One of the biggest stumbling blocks I have found with integration tests is internal dependencies (external ones, like databases and webservices, are also a pain, but you’re on your own for them). If you have to test an “Approve” action, you probably first need to “Create” the object before you can approve it. You’ve written your “Create” integration tests, so do you make your “Approve” tests inherit from the “Create” tests? That seems kind of ugly. But you don’t want to have duplicate code, even if it’s just in the tests.

A better solution is to split your integration tests into “workflow” classes. Each workflow class represents an action you want to test, “Create” in this case.

public class CreateResults   
{
  //data to return    
}    

public class CreateWorkflow    
{    
  public CreateResults DoAction()    
  {    
    //Do the action, return the results    
  }    
}

You can use this code for your “Create” tests, but even cooler, your “Approve” workflow can consume the “CreateResults” object:

public class ApproveResults 
{
  //data to return  
}  

public class ApproveWorkflow  
{  
  public ApproveResults DoAction(CreateResults results)  
  {  
    //Do the action, using the data from the create test, return the results  
  }  
}

How cool is that?

Well, what if you want to have a workflow with various options? We can do that:

public class CreateOptions   
{    
  //inputs to the workflow
  
public class CreateWorkflow   
{    
  public CreateResults DoAction(CreateOptions options)    
  {    
    //Do the action using the provided options, return the results    
  }    
}

You can experiment with using the “Options” and “Results” objects in different ways. YMMV. This may not solve all the problems with integration tests (and it’s not revolutionary, and someone else probably already did it), but it can make for some pretty modular tests and make your life easier.