Monday, August 23, 2010

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?

Wednesday, July 28, 2010

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. 

Wednesday, May 12, 2010

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.

Thursday, February 18, 2010

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.

Friday, February 12, 2010

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.

Wednesday, February 10, 2010

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.

Wednesday, February 3, 2010

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.

Monday, November 9, 2009

Unexpected Benefit

My sense of smell has always been somewhat lackluster, which has led me to on occasion eat spoiled meat and drink spoiled milk (explains a lot, right?). Fun times. But one of the pregnancy "symptoms" Annie is experiencing is an enhanced sense of smell. I've been able to use this to my advantage :)

"Hey honey, is this milk bad?"

"Babe, can you smell this deli meat? It looks a little... funky."

Alternatively, if I cook something good, to her the whole house will smell like it for a while, so it's in my best interest to cook as much deliciously-smelling stuff as I can. Look out world, here comes Chef Ed!

Saturday, October 3, 2009

Get Busy Living, or Get Busy Setting Up Your Workspace

For a long time now, I’ve been trying to make my work-from-home setup more usable. Or, more accurately, I’ve been complaining that my work-from-home setup is inadequate and then not doing anything about it. See, I have a desk in the basement, but it’s not really a computer user’s desk. Sure, it has a keyboard drawer, but there is no room on that drawer for a mouse, so my mouse-hand always ends up in an awkward position. Couple that with the fact that my desktop PC just croaked and I have no USB keyboards to plug into my laptop, and the desk became darn-near unusable. I tried using my laptop on the couch, but I either end up nearly burning my lap or hunched over the coffee table.

With the bare minimum in mind, I set out to Staples (just about the only tech retailer within walking distance of my job) to get a USB wireless keyboard. I figured $35, maybe $40, and my desk would be back in action AND I could use the laptop just about anywhere in the house.

I managed to get lucky; Staples was having a sale on the Microsoft Wireless Desktop 3000 (keyboard and mouse combo). $50 seemed like a good price for both devices.

Well, the keyboard is great, though nothing special compared to other keyboards (well, it’s no Microsoft Natural Ergo Keyboard 4000). It just works. The mouse is the real winner. The bundled mouse is the Microsoft Wireless Mouse 5000, and it comes with “BlueTrack” technology. I don’t know what that means, but I do know I can use the mouse on just about any surface. Anything. I just flopped it down on the fleece that’s piled right next to me and it worked perfectly. I’m not sold on the location of the “forward” button, but I rarely use that anyway, so it’s not a big deal.

This is coming off like a shill review, so I’ll stop talking about the devices themselves (I have no relevant experience with wireless keyboards or mice to compare these to anyway). I’m sure Logitech’s offerings are awesome too (their MX500 mouse has been my faithful companion for years).

The point is that now I’ve got a very comfortable working environment at my desk OR on the couch. The nice side benefit is that using a wireless keyboard just makes me feel like a badass hacker too.

Monday, September 21, 2009

You Should Listen to Me: I Placed First in a Private Make-Believe World

So all my waiver-wiring and managing risk and whatnot landed me a league title in one of the two leagues I cared about (and I came in second in the other one). Booya!

Mostly though, I'm excited that fantasy baseball season is over so I can focus on (fantasy) football, as well as the baseball playoffs. Fantasy sports really enhance my spectator experience, but it's also nice to watch a game and not worry about every at-bat and how it will affect me. Here's hoping the Yankees go deep into October baseball!

Monday, August 10, 2009

Not Even a Magician

















"I don't know. I'm not a magic person. I just play second base."

Thursday, August 6, 2009

It Ain't Over 'Til It's Over

Fantasy Baseball has been good to me this year. In the two leagues I actually pay attention to, I'm in first place, one team by 4 games, the other by 19. And it's not that I draft well; I know I'm pretty bad at that sorta thing, and this year was no different (1 of the 10 guys I drafted in the last 5 rounds of these 2 leagues is still on my roster). No, it was all thanks to free agent pickups and waiver claims.

You don’t want to be Cowboy Jon praying Matt Wieters comes up in June while you sit in 8th place not even needing a catcher.   Or are you holding your waiver claim because you’re afraid someone is going to drop Prince Fielder?  Who are you, John Q. Law?  This is your job, why?  Wait, even better.  If you’re in a league with a guy who wears fancy dungarees and who would drop Prince Fielder, you shouldn’t be in that league.   If you need a guy for your roster, then claim him.  While your leaguemates are waiting for someone they deem worthy of a pickup, you’ll be grabbing all kinds of other players that are immediately useful.
That advice goes for free agents too. And better yet, free agents don't cost you anything other than the worst player on your roster.

Key players that I picked up off free agency/waivers this year:
  • Ben Zobrist
  • Mark Reynolds
  • Jon Lester (an impatient owner dropped him)
  • Andrew Bailey
  • Jordan Zimmerman (traded to get Casey McGehee)
  • Jake Fox (traded to get Leo Nunez)
I'm 19 games up in one league pretty much solely on the shoulders of Zobrist and Reynolds. Drafting is super important, as the basis of your team is formed in those first hours of the fantasy season. But even if your draft doesn't go according to plan (like drafting Garrett Atkins in the 4th round), you can still recover if you keep an eye on the game. 

Wednesday, April 29, 2009

Did Anyone Else Hear That?

I'm watching the Yankees @ Tigers game tonight on ESPN, and these commentaors have got to be the worst I've ever heard. They just seriously suggested that the 1-2 2 out pitch the ump called a ball was a good call because other umpires might've phoned it in and called it a strike just to get out of the inning. Seriously? Seriously. 

Thursday, April 9, 2009

Love-Hate Relationship




Look At the Time Stamp

Seriously, just look at when I posted this. Not doctored at all.

I just finished a daily merge for work. Yes, I took time off when I got home to eat dinner and watch a little TV. I still spent a whole day + some on a single daily merge. 

Sometimes, I just hate source control.

Sunday, March 29, 2009

Fantasy Baseball: Players I Own

I always end up have the same players on many of my teams. I try to avoid it, but my research always ends up pointing me at the same players. This year I did a little better in avoiding repetition:
  • Carlos Guillen: Tampa4, Work League (WL)
  • Albert Pujols: Nine Bo Jacksons (NBJ), Tampa4
  • Nick Markakis: Garrett Anderson (GA), Tampa4
  • Chris B. Young: GA, Tampa4
  • Josh Beckett: WL, Tampa4
  • Gil Meche: WL, Tampa4
  • Ted Lilly: GA, Tampa4
  • Brian Wilson: GA, Tampa4
  • Rich Harden: GA, Tampa4
Hmm, on second thought, my GA and Tampa4 teams are pretty similar. Those are the two leagues I paid the most attention to, so I guess I didn't really succeed in spreading my risk. Oh well.

Saturday, March 28, 2009

Programming Update

Today was New England Code Camp 11: Developer Stimulus Package. What an awesome name. Thanks to Chris Bowen for organizing it. Unfortunately for me, I could only stay for the first four sessions. Got to learn about Silverlight, F#, and .NET 4.0. As always, Richard Hale Shaw was excellent, and Andy Beaulieu was also quite good. Fun times for all.

These programming conventions always give me extra energy for working on projects. This one came at a great time, because I had stopped work on Walrus since all of my fantasy baseball teams had already drafted. I now know (thanks to RHS) how F# really fits in, and how to use it as a library extension to my C# projects. Yay!

I also need to work on smaller projects. Things I can build quickly and learn small things at once. I plan to build an ASP.NET MVC app soon, but it has to be super simple so I can get it out the door fast. Maybe I'll build a blog. Easy, but somewhat boring. I haven't thought this through yet.

Nick is also urging me on, mostly by blogging and conversations on the train. He's on Twitter now at @nswarr, so you can follow him if you want. Eric always gets mad points for energy boosts. 

Any ideas for what to put on edschwehm.com?

Thursday, March 26, 2009

Why I Don't Like SOLID Principles

SOLID princples:
  • Single responsibility principle
  • Open-closed principle
  • Liskov substitution principle
  • Interface segregation principle
  • Dependency inversion principle
This topic has been discussed to death in the tech circles, thanks to the whole tiff started by Jeff Atwood and Joel Spolsky. I'm just throwing my piece in the ring:


SOLID is good.
SOLID is not gospel.

The first rule of programming should be "use your brain." The first answer should always be "it depends." SOLID is not a silver bullet (because, as we know, there is no such bullet). There are going to be times where you need to write some code that is not pretty. Sometimes we acrue technical debt for valid reasons. Usually the reason is we need to implement some feature or bug fix fast, possibly because we're losing customers.

It really comes down to what Jeff said: "Quality really doesn't matter that much, in the big scheme of things." What matters is what we deliver to the customer. Of course, good code quality helps you deliver more and better apps to the customer. But the customer does not care that you followed the SOLID principles to the letter as long as the product is right.

Tuesday, March 17, 2009

Managing Risk With Bench Spots, Part 2

In Part 1, I discussed how you can use a bench spot as a hedge against a risky player you drafted. In this part 2, I'll discuss how to decide what to do with each of your bench spots.

You basically have four options when it comes to bench spots:
  • Platoon: One guy who mashes right-handed pitchers, one who wails on lefties.
  • Upside: Younger guys who might outperform expectations
  • Pitchers: In daily leagues, you could have extra pitchers to try to rack up counting stats.
  • Injury risks: As mentioned in part 1, you can backup your risky players.
Platoon players can often be had for cheap. Their season stats and projections are not going to look good because they hit something like .200/.300/.300 against opposite-handed pitchers. If you keep one guy who mashes righties and one you matches lefties, you can get the best of both worlds. The downside is that you have to check the matchups every day. Also these guys tend to be less-than-stellar players who could lose their job at any point. 

If you're reading this blog, you know about upside players. It's like drafting Evan Longoria or Colby Rasmus last year. Sometimes, you strike gold (see Longoria, 2008). Sometimes, the guy sits in the minors all year (see Rasmus, 2008). This category also includes guys like Elijah Dukes who have talent and always seem on the fringe of a breakout year.

In daily leagues, many managers will carry extra pitchers to try to rack up wins, saves, and strikeouts. This may not work as well with a Roto league (IP limit), but if you decide to draft pitching late, running extra pitchers out there can help offset the losses you made.

And finally, you can draft a backup for any of your risky picks. Better grab a backup 3B if you intend to draft Chipper Jones.

How do you decide what to do? By the time you're drafting bench players, you should already know how many injury backups you need. A good rule of thumb is that you want no more than half of your bench players as injury backups. You should also know if you need any platoon mates. You need to take care of these two cases first.

Once you've filled your obligations, then you can pick between upside players and extra pitchers. Make your picks based on your overall strategy (take pitchers if you need them, upside if you can). 

And finally, remember that players can fit into more than one category. Andy LaRoche is both a backup 3B and an updside player. You want all your bench players to be as useful as possible, so keep an eye of for guys that fill multiple needs.

Sunday, March 8, 2009

Managing Risk with Bench Spots, Part 1

Derek Carty at Hardball Times had a great three part series on injury risks and how they can lead to great rewards. The basic premise is that if you combine a partial season of a good talent with a partial season of a replacement level player, the combined value is much greater than the sum of the parts. I totally agree with this premise (you can see me arguing in favor of it in the comments).

You can use this strategy for any player who is expected to miss time:
  • Matt Wieters will start the season in AAA, but is expected to be called up as early as May.
  • Chase Utley will start the season on the DL, and should be back within a month or so.
  • Rich Harden is currently healthy, but you never know when he'll be injured.
  • Max Scherzer will be the 5th starter in Arizona, but if he's ineffective they might send him to AAA for some work (unlikely but possible).
Clearly the Utley situation is the most valuable; you know how long he'll be out, and you can reasonable guarantee he'll be great when we returns. The Harden situation is the worst; you don't know when/if/how long he'll be out and if he'll be effective when he returns. You need to make sure to balance your roster with these risks. 

Your bench spots are one of your greatest resources for managing risk. Instead of replacing an injured or ineffective player with a replacement player (i.e. free agent), you can replace him with a bench player. You chose your bench players based on your starters. If you draft Chipper Jones as your starting 3B, you'll likely draft another 3B sometimes in the late rounds. That 3B will be better than a replacement 3B. When you do this you're using a bench spot to hedge the risk you took by drafting Jones. (You can use DL spots in this fashion only if the player is starting the season on the DL, like Utley). 

One of the greatest arguments against this strategy is that each replacement player requires a bench or DL spot. Some leagues have as few as 3 bench spots and no DL spots. Thus you have to decide whether to use you bench spots for extra starting pitchers, high-upside players, platoon mates, or injury risks. When planning to draft a risky player, mark off on your draft sheet that one of your bench spots should be reserved for a backup. 

Next post I'll look into how you should decide to use your bench spots.
All rights reserved. Take that!