by Suzanne Collins (at the recommendation of i3ears). This book filled me with that rare combination of delight and rage. Let's start with the delight.
Incremental innovation leads to small improvements to existing products and business processes. It can be thought of as an exercise in problem-solving where the goal is clear but how to get there needs to be solved. At the opposite end, radical innovation results in new products or services delivered in entirely new ways. It can be thought of as an exercise in exploration where there might be something relevant in a particular direction but what will be found is unknown.However, what really has bothered many of us CoD gamers is that each new CoD title brought with it a substantial set of negatives along with the innovations. World at War had severe balancing issues, MW2 had hackers and its own balance problems, Black Ops had terrible lag/network and balance issues, and now MW3 suffers from challenging spawns, lag/network issues, and, again, balance issues. Why can't each version of the game be better and stronger than the last? Why does each title have to take two steps forward and two steps back at the same time? It's gotten to the point where people still play older versions of CoD because they can't stand the newer versions*. In fact, Black Ops, MW2, and CoD4 all appear regularly on the top 20 weekly Xbox Live titles list.
and moving to the Internet), and after talking with a few people, decided now would be the best time for me to try it.
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.
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.
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 ApproveResultsHow cool is that?
{
//data to return
}
public class ApproveWorkflow
{
public ApproveResults DoAction(CreateResults results)
{
//Do the action, using the data from the create test, return the results
}
}
Well, what if you want to have a workflow with various options? We can do that:
public class CreateOptions
{
//inputs to the workflowpublic 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.
