This sound really great in theory.  But if it was all gravy I wouldn’t be writing this post.  So here’s the rub – it has to be crystal clear exactly what is being proved.  If management is vague and just wants to see some documents or a demo, the risk in moving from POC to a production project becomes very high.

Let’s look at an example.  A project that I’m involved in right now is proving that legacy code can be taken from the outdated, purchased system with a proprietary-language and migrate core functionality to .NET – specifically WCF services.  Sounds simple enough, right?

The code in the existing system is a tangled mess, as one might expect, and all the logic is buried in the 3GL-type forms.  The database is also a rat’s nest and the converted code must use the legacy database.

The project is moving along and things are working, but an all too common dismissal for the quality of code that’s being written is “hey, it’s POC code”, which leads me to the point of this post.

Because the goal of this POC is only to see that it is possible to move legacy code to C# on WCF, it’s acceptable to the team that the code being written is a house of cards.  It is so brittle and hard to test that the smallest change could send it tumbling down.  My worst fear, however, is the possibility that a number of bugs and issues that result from a change could go undetected.

I don’t believe, in this example, that the concept is truly getting proved.  By not specifying that the project should prove the concept in a manageable way, following established practices for creating highly cohesive and loosely coupled code that is testable and continuously integrated with automated testing, the project sponsors have essentially said “build a house of cards” – hence the attitude that quality doesn’t matter because it’s just POC code. 

It’s my opinion that if one wants to prove a concept like the one I’ve been talking about, it has to be proven to be a viable solution in some real world capacity.  At the end of the project, the POC may be deemed a success but few will know if it is actually possible to build with a sense of confidence and stability.  The other angle is that management may expect that since the POC has already been completed, it shouldn’t take much more time to get it ready for prime-time, which is this case would be a fantasy.

In conclusion, when drafting POC project document, make sure to specify some degree of real-world expectations.  Build in the extra time to ensure that the concept can be built to withstand the pressures of real-world change.  Otherwise, you may not know the truth until you’ve either deployed a fragile system or found yourself sinking more resources into a project than you ever would have expected. This may not be applicable to the smaller projects, but for larger ones, I think it’s worth the investment.

That brought me to David Ridgway’s blog, where he has a post about how to get 10% off and an extended 60 day trial license key.  The blog says to email him and he’ll send the info.

If you’re like me, this sounds a bit fishy and I was apprehensive to try, but the blog looked legit so I gave it a shot.  To my surprise, I received a response within 10 minutes at 1:30 AM.  The details were there and they are right on.

If you are thinking about buying or trying ReSharper 4.5, definitely send David an email and ask him for the scoop.  You’ll save some cash or get the longer trial (or both).

http://web2asp.net/2009/01/resharper-extended-trial-period-and.html

In his post, How Mainstream Lost Software, Scott really said some things that hit home for me.  He talks about Eggheads in the following way:

Eggheads write and speak for other eggheads. The language they chose and the names given to design principles, as well as practices and patterns are stimulating to other eggheads and yet utterly obstructive to the other part of the software development population. When you measure the Egghead population against the mainstream population, the Egghead population doesn’t appear to be much more than a rounding error. There’s a lot of work to do, and we can do it much better.

Eggheads preach to the choir, and this is often so stimulating that they never leave the echo chamber. They don’t learn how to reach the mainstream. They hope that the people they do reach will somehow reach the mainstream, but those people usually end up emulating their egghead heros and become eggheads themselves. The circle expands slightly, but not merely enough to have the meaningful effect on software development productivity that their knowledge and understanding should already have had.

The other end of the spectrum is who he called Shills.  It takes only one meaningful sentence to convey what a Shill is:

Shills convince the mainstream to buy snake oil solutions to problems that could be easily solved with plain old soap and water.

So why did all this hit home?  The fact is, I’m an aspiring Egghead.  I absolutely love this stuff and am passionate about all things Egghead.  I work all day.  I work at night.  When I’m not working, I’m thinking about this stuff.  When I’m not thinking about it, I’m reading about it and wondering how I can improve my craft.  I try to emulate my Egghead heroes like Jeremy D. Miller, Ayende Rahien, Udi Dahan and many others.  I know I’m not even on the same planet and probably never will be, but I’ll never stop trying.

Scott says that people who really care about this stuff are nothing more than “a rounding error” compared with the mainstream development community, who has bought into what the Shills are selling.  I see it all the time.  “Why write unit tests first, or even by hand, when I have a wizard to generate them for me when I’m done?”.  “Why write my own decoupled, testable authentication scheme when I have the AspNetMembershipProvider?”.  It’s tough to win those debates because this is just not how most people understand things.

The impending doom of the Northeast WI Alt.Net User Group is what really brought this home.  It’s not officially over yet, but I was very surprised to find out how very little of the local population is in learning about things NOT mainstream Microsoft. I advocated the group to almost every developer I met but nobody ever showed any interest.  They show up at the INETA sponsored .NET User Group to learn about SharePoint and Silverlight RIA, but not Alt.net.  In my opinion, we were talking and learning about things that could be implemented right away to.  Things that had immediate benefit.  Why wouldn’t this interest people?

Scott Felder covered NServiceBus to an audience of 5.  I prepared a presentation on the Spark View Engine, which was supposed to be for an audience of 7.  Unfortunately only one person was actually going to come so I called him from the parking lot to let him know not to bother.  Other topics were going to include SRP/S.O.L.I.D., StructureMap, S#arpArchitecture, NHibernate and so much more.  The fact is, people just weren’t interested.

There was a bunch of discussion on our group about marketing and branding to generate interest, but it honestly seems like too much work.  I am a very busy person and time is so precious to me that it’s really hard to justify investing my time and energy into getting people interested in improving their craft.  We are in charge of our own path as developers – nobody else.  If they aren’t willing or interested in seeing what else is out there, it’s their loss, right?   Right?

So that’s the nerve that was touched.  Scott’s closing words included this:

What’s needed is a new generation of productivity missionaries who are willing to master the field of knowledge and are willing to learn to connect with the mainstream.

Again, I am not claiming to be elite or even in the top 50%, but I do admit to understanding a lot of this stuff.  Reading his post makes me feel a little guilty for wanting to bail on the Alt.Net user group.  It really made me look at that decision and reflect on the current state of the mainstream development community and ask myself if I’m happy with where things are.  The answer is no.  It takes too much energy to get people to even consider possibilities beyond 3 Tier architectures with so-called BLL’s that act as a pass-through to a DAL.  I don’t want to explain why breaking a God class down into 10 separate classes in the name of SRP really isn’t “a lot of extra work”.  Yes, IoC containers use reflection, but most of it gets done upfront and you have to consider everything you get… etc…

Thanks Scott for giving me more to think about.

I can certainly see where he is coming from with this post. The part that really grabbed me was the last paragraph:

“Also, why do you need to verify that “verify(manager).createCredential” was called? If you really get the credentials you’re expecting from the Authenticator, why would you need to check where they come from? Isn’t it one more way to couple your test to the implementation?”

I think this is the single most common pitfall of anyone who has been doing TDD with mocking for a short period of time.  The initial tendency is to test each and every interaction between the objects.  It usually starts out with large tests that make too many assertions.  It’s not uncommon in these tests to see the developer assert that:

1. The application service layer gets called
2. A transaction is started
3. The appropriate repository method[s] are called, which can be multiple repositories
4. Some business logic is executed
5. The right value is returned

Such a test is going to be very brittle and break upon any serious refactoring.  As Uncle Bob points out, do we really care about each of these interactions?  Sure, in some cases it may be important to make sure a transaction is started, but in most cases all you care about is that the right value is returned.  This is the natural progression of implementing TDD, especially when mocking gets introduced.  I think it takes the pains of these brittle tests to discover that asserting all those interactions is really not necessary.

The next progression starts is when the developer begins to understand what one assertion, or logical assertion group, per test really means.  This phase is a little less painful because at least now there is a separate test for each interaction, which is still typically unnecessary.  Now that the tests are broken up into logical units, the tests are easier to fix when refactoring breaks the interactions.

Now the final progression – the pains of these fragile tests lead to the notion that all these tests really don’t matter.  They really don’t prove anything about the quality of the software.  The tests match the implementation and the system depends a set of very brittle tests that could make refactoring too painful.  That’s when the tests get simpler.  That’s when the realization that a mock isn’t needed for everything and ever interaction doesn’t need to be tested.

If you are reading this and it sounds like you are in phase 1 or 2, I highly recommend you read the post “Three simple Rhino Mocks rules” by Jimmy Bogard.  It really influenced the way I write tests.

I’ve been swamped with side work which has been consuming 20-25 hours/week of my time. I’ll always choose billable hours over my blog, but hope to find time to write my next post soon.

Happy Christmas and Merry New Year since I missed my opportunity a few weeks back.

Till then,
Corey

Rhino Mocks 3.5 Public Key, Rhino Mocks 3.6 Public Key, Rhino Mocks Strong Named Mocking

When you design your code to be testable with a mocking framework like Rhino Mocks, you typically end up marking otherwise private classes as Internal.  This allows you to share your internal classes with test project[s].  To do this, you have to use the InternalVisibleTo assembly attribute in the AssemblyInfo class that you want to share.

[assembly: InternalsVisibleTo(“S2sol.ProjectA.TestProject”)]

This attribute is essentially doing what it says, “Make my stuff that is marked internal visible to the specified class”.  When the project under test is strongly named, for whatever reason, it is also required that you put the public key (not the public key token) of the test project in there with the assembly name.  This to ensure that the internals that are being exposed are only exposed to an assembly that is known.

Rhino Mocks uses Castle’s Dynamic Proxy for mocking.  It creates classes at runtime to act as proxies, or interceptors, whenever you create a mock or stub using MockRepository.Create…  This means that the project under test must verify the dynamic proxy class via the InternalVisibleTo attribute, which means we’ll need the PublicKey for the dynamic assembly. 

I found this somewhere on the web over a year ago and took it for granted until I needed it again today.  After I hunted in some of my old code and found it, seemed like a great post that will surely help someone else out there.  So when you are in this scenario, using Rhino 3.5/3.6, add this to the AssemblyInfo of the component you want to test and you will be good to go:

NOTE: breaks in the public key are intentional for rendering.  It works like this or if the key is one line.

//required for Rhino Mocks
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=00240000048000009"+
"40000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f" +
"3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cd" +
"cf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74" +
"c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]  

First, an article on NHibernate from Ayende (Oren Eini).  It’s great to see MS embracing NHibernate and this looks to be a great article (although I haven’t read it yet).

The second article comes from David Laribee, he who coined the term Alt.Net.  He’s written an article on paying back technical debt with Agile techniques, which I’m also looking forward to reading.

Go check it out!

UPDATE: As pointed out by Mark Nijhof in the comments, Greg and Udi have slightly different philosophies.  We’re talking about Greg’s flavor here.

The gist of CQRS is that you access your domain model for updating via commands and a separate service from the reads (queries) and reporting.  Reading from your database happens without going through the domain layer and can be performed against a denormalized database by passing simple and complete DTO’s to the UI.  The updates to the domain eventually update the read-only database when the published event messages get picked up and acted upon.

Thanks to Mark Nijhof, I have something more in depth that I can read and also a code base I can examine.  Anyone who is interested in this architecture should read this post now.  It is pretty well written and really helps solidify the essence of what CQRS looks like the problem it is trying to solve.

This post, however, is less about technical stuff and more about getting what you want where you want it, and that is calendar and contact synchronization. I’m not saying that this is the only way, or the best way, but I dug around for several hours and tried all sorts of free and demo software and this is what ended up working for me with the least amount of pain.

First, some back story on my situation. I’m an avid Yahoo Mail user and have been for about 10 years. I like Yahoo mail with all it’s Ajax goodness and sleek interface. GMail on the other hand, seems clunky. As a coworker of mine put it, “it looks like something that was designed by programmers”. I have a GMail account to use for all the wonders that Google offers, like analytics and other services. Being that the Droid is heavily integrated with Google, the calendar and contacts functionality on the phone depends on the Google Calendar and GMail Contacts. So now I was faced with the problem – how do I get my events, appointments, reminders and contacts from Yahoo to my phone?

NOTE: I’m running Office 2007 on Windows 7 64bit

How I am Synchronizing Yahoo! Contacts and Calendar with Outlook and GMail

1. First I am doing 2 way synchronization between Yahoo and Outlook for contacts and calendar.  This is very simple using Yahoo’s AutoSync addon for Outlook/Outlook Express.  You can install the bits for this program by first going to Calendar and then clicking the “Sync” link in the top right.  You can also get more info from VersionTracker.  This addon isn’t 100% rock solid and sometimes won’t fire up, but not sure what the circumstances are.  I don’t think it’s officially supported in Windows 7, but it’s been working good enough for now.
2. Now that I have all my Yahoo contacts and calendar entries in Outlook, it’s time to find something to synchronize Outlook to Gmail.  I went into this thinking this would be a simple task, but let’s just say there’s a lot of crap software out there both for free and for pay.  What I ended up using was the addon from Soocial.com, which a contact management service that helps keep your contacts organized.  They offer tools to sync several providers, but the Yahoo sync is only one-way, which is why I am using AutoSync to handle that.  Their GMail sync tool only works for contacts, which leads me to item 3.
3. To keep my outlook calendar synchronized with the GMail calendar, I am using Google’s Calendar Sync Tool.  You may be as surprised as I was to find that Google offers a tool to sync the calendar but not contacts.  I think it has something to do with the Apps Synch product that requires an Enterprise license.
   Note: Google does offer a way to sync iTunes contacts with GMail, but that seemed like a whole other can of worms.

At first I had reservations about putting all my contacts on Soocial.com, but I couldn’t find anything sketchy about them in the public domain.  If you have any knowledge about this service, please share.

So what I’ve ended up with is this:

Yahoo -><- AutoSync –><- Outlook –><- Soocial.com -><- Gmail Contacts
GMail Calendar -><- GMail Calendar Synch –><- Outlook

Now when I add a contact or calendar entry in Outlook or Yahoo, I will see it on my Droid.  Conversely, if I’m on the road and add something in my Droid (Gmail), I’ll see it in Yahoo and Outlook within 90 minutes (configurable).  It not as seamless and I’d like, but it works pretty good for now.  I’ll update the post if things start to get dicey or ifwhen something better comes along.  Based on the number posts and questions on the web regarding this topic, I’m sure this will help at least a couple people trying to mesh into this new fangled era of being constantly connected to the world from your powerful little handset.

_Broker.Raise(x => x.GetData += null, this, EventArgs.Empty);

This is representative of the most typical examples you’ll find on the web and this is all fine and good.  However, sometimes the scenario that you need to test is a little more complicated and this method of raising events on a mock object simply won’t work without too many hassles.

A More Complicated Scenario

A common scenario may be where you are testing something that is subscribing to events that are actually fired by an object a couples levels deep.  For example, you may have an object that sends messages to another object, which is responsible for raising the event.  Hopefully this very simple textual sequence figure will help make things more clear.

Proxy.Execute() -> Broker.HandleMessage() -> Broker.RaiseEvent() -> Gateway.HandleEvent(eventArg)

I want to test that when the Proxy publishes a certain message the Gateway handles the event properly.

Mocking The Old Fashioned Way

My first instinct was to look at how I could accomplish this with Rhino.  After a couple minutes, I realized that this would not be a good way to spend my time.  A better option for me was to mock the old fashioned way.  To do this, I created a MockProxy and MockBroker class that implemented the IProxy and IBroker interfaces.  I can now just write regular C# code to handle how/when to raise those events.  It took only a few minutes to write the code, is intention-revealing and works like a champ.

NOTE: I tried to figure out how I could show some sample code without getting into all the gory details but couldn’t find a simple way, so I’ll just get right to the moral of the story.

When it comes to mocking, follow the KISS principal.  Rhino and other frameworks are there to make our lives easier.  If you are spending time and effort trying to figure out how to mock something in a framework, stop and think about doing it old school.  You’ll save yourself a load of time and your simple solution should be more readable to others.  You can still create a Rhino mock of your old school mock object (assuming you used virtual methods) for the purpose of asserting expectations, which will provide the best of both worlds.