Shane Courtrille's Blog

We recently ran into a fun little problem at work after adding a new operation to our WCF service.  The first step for us after adding a service is to make that service call available to our client by regenerating the proxies it uses.  We do this by running our service and using SvcUtil against it.  Today though we ran into an interesting little problem where SvcUtil was telling us that the machine was not accepting connections.  We checked back and our service (self hosted I should point out) was still running fine. 

So at this point we started the debugging process.  First step was to check all our log points which turned up nothing.  The SvcUtil error message mentions checking for an inner exception but it doesn't mention how to go about doing that.  The fact our service wasn't throwing an error made this even more difficult to debug.  So now we started the process of elimination.  Taking a look at the code the one thing I did notice was that the only "different" thing the new code did was return an enum as part of the [DataContract].  I looked at the enum and everything looked fine (yes that was foreshadowing..) but I still thought it was the most likely candidate so I commented it out and tried again.  Everything worked fine.  At this point I went and looked at the enum declaration again.. it actually looked like this..

    [DataContract]
    public enum AuditType
    {
        [DataMember]
        Insert = 1,
        [DataMember]
        Update = 2,
        [DataMember]
        Delete = 4
    }

Now if you've done any WCF work hopefully the [DataMember] will pop out at you immediately since that is typically used to identify properties.  A quick search on Google identified [EnumMember] as the proper attribute and we were off to the races.

So first off I'm hoping someone somewhere finds this and saves themselves a little bit of hunting.. but most importantly I'm hoping someone can help me identify a better way to have figured this out.  The service compiled and ran fine.  I could not find a single error anywhere but this just seems very wrong.  So to you I ask.. what would you have done differently to have found this quicker?

* I wonder if tracing would have helped?

Recently on my current project we decided to sit down and take a look at performance problems that we were having.  The main cause for concern was actually our most common and important operation since it would take anywhere from 20 to 40 minutes to complete. 

The first obvious step was to run a profiler against our code to see where we were actually spending our time and for this we choose DotTrace by JetBrains.  I really liked the ANTS Profiler time line view but for reasons that I can't recall right now we decided DotTrace was a better fit for our needs (I think it had to do with ease of comparing different runs).  So with DotTrace in hand we quickly found out that most of the time in our application was actually being spent in NHibernate (specifically in analyzing entity relationships).  This came as quite a shock to me since I know NHibernate is widely used and I had never heard of anything even approaching what we were seeing.

To cut a long story short while I did look into the NHibernate code it was eventually a bit of experimentation in our own code base that helped resolve the issue.  You see in our code it's very important that we track every step in our main process and to do this tracking we were using the actual entity Db Ids and the only way we knew to do so was to tell NHibernate to save the entity and then force a flush.  By removing the flush I was able to cut a 40 minute process down to 4 minutes!  The theory I ended up with is that each time we called Flush we were creating more and more stuff that NHibernate had to parse through each time Flush was called.  By only calling it once at the end it started with a nice clean slate.

So with all that said my advice to those of you who want to manually call Flush is.. DON'T! Not unless you really really need to and even then you should seriously consider other options/designs.

Oh and as for the whole Id thing we ended up using Session.Persist(entity) to get the Ids we need.  There is a bit of confusion around this method and if it's guaranteed to provide an Id but so far with our mappings we haven't had an issue.

Some of these I’ve done.. some I’ve just seen.. but they are all now things I watch for…

1. Never talking to someone who is going to physically use your solution…
2. Not having acceptance tests…
3. Showing up for your new job and being handed a few binders worth of the design that someone who has already quit did…
4. Working at the same job for so long that it makes you think about becoming an electrician…
5. Not practicing TDD…
6. Having only half a team that understands DDD but trying to do it anyway…
7. Not listening to your gut for a hiring decision…
8. Writing integration tests to do the job of acceptance tests...
9. 3 BAs for 10 developers..
10. 2 QA people for 10 developers…
11. Not understanding your audience…
12. Listening too much to others…
13. Too much reading.. not enough doing…
14. Thinking that you know everything…
15. Believing that you know nothing…

I could keep going but this seems like a good enough place to stop for my upcoming rant…

Recently I ran into an interesting problem on a small project I was working on.  The problem was on the surface fairly simple.  Take a currency amount and round it up to the nearest 0.05.  While the solution is not earth shattering it took long enough to figure out that I figured it was worth recording for my future self. 

The first part of the problem is to round to 0.05 which is accomplished by doing this (thanks Google..):

decimal initialValue = 0.56;

decimal value = Math.Round(initialValue / 5, 2) * 5; 

But the problem is this code will actually round to the nearest 0.05 as opposed to only rounding up.  So 0.62 will round to 0.60 where as our requirement is to round to 0.65.

But that part of the problem is actually fairly easy to solve..

 

if((value - initialValue) < 0)
{
     value += 0.05m;
}

And there you have it.  We can now round up to the nearest 0.05.

So this weekend I had the chance to give a presentation at the Edmonton Code Camp.  I’ve done this every year for the last few years now (and I’ve done a few presentations elsewhere) and I have to say that this by far was my…. worst presentation ever. 

So what went wrong?  Well the primary problem I think was based on the fact that my original presentation idea was going to be a fair bit more advanced then the talk I ended up giving.  Originally my idea was to talk mainly about the differences between Unit and Integration tests.  While there are some fundamental differences between the two I honestly don’t know that I could spend over an hour talking about them.  As I worked on my presentation though I realized that there was probably a lot of value in talking about some more basic testing stuff first.

So this is where my mistake happened.  At this point I should have probably thrown out all of the advanced stuff I wanted to talk about and started fresh.  Instead I tried to walk this line of keeping in line with my original idea while trying to talk about the basics of testing first.

BAD IDEA…

I found the talk quite dysfunctional because it tried to bounce between intro level and advanced level which never works well.  So with that said here are a few things I take away from this..

1. Intro and Advanced level talks have totally different audiences.  Pick one.

2. If your original idea is wrong.. that’s fine but throw it out and start fresh.  You may bring some stuff forwards but it’s good to start with a fresh mind.

3. Semi unrelated but I really need to get started on my blog series on testing I wanted to write.  Good news is I mentioned it while talking to a few people after my talk so now I have no choice.

Living and Learning…

Recently I ran into a situation where one of our WCF Operations was taking a long time to complete (in the range of a few minutes).  The problem was that while this was going on the server stopped responding to all other responses. 

After a bit of time with Google I was able to find a post that seemed to explain the problem we were having WCF Threading Internals (Updated). 

At the end of the day the solution (which took a bit more work to find) turned out to be fairly simple.  It involves making your Operation asynchronous via the AsyncPattern contract parameter (and a bit of other stuff).

So lesson of the day is.. if your WCF Operation is going to take a long time.. Asynch it.

I’m happy to announce that the “My Job Went To India…” book I talked about in an earlier post is being re-released.  This time the title has been changed to The Passionate Programmer: Creating a Remarkable Career in Software Development. 

I’m quite happy to see the re-release and name change.  I think the earlier name cast this book in a way that might have limited its audience.  This is quite unfortunate when you consider how valuable this book is for every developer to read. 

I’ve got the earlier version but I’m definitely going to pick this one up as well since I found the first one so valuable.

Well the last month has been a bit hectic around here.  Between moving and being sick twice I’m just getting to the point where I’ll have some time to type out some of the random thoughts and maybe a few more book recommendations….

Gregory Beamer is writing an interesting series on Linear thinking.  I think the PoEAA name for what he’s talking about is Transaction Script and boy have I seen a lot of it. 

One of the problems that Gregory brings up is large classes.  Now I haven’t seen the classes in question but to me it seems smelly that the class is complex enough that Gregory would need to use screen splitting to see the variables that exist for the class and the rest of the code.

In following with some fairly common advice I’ve switched to the small method style.  I try to refactor all my methods so that they are around 10 lines or less and then name things appropriately.  I’ve talked with co-workers and they do agree that it helps make the code more understandable. 

One of the other things that I do though is to try and keep my classes small.  I obviously don’t always succeed at this but if I see a chance to take a piece of functionality in a class that can happily live on it’s own I will let it by creating a new class.  I then move all the variables and methods into that class.  I was going to mention this on Gregory’s post but while writing my comment something struck me.  The one problem with this method of working is that it does create a lot of classes.  Now to some people I’ve ran into this is a big deal.  To me it’s not a big deal at all and when I really think about it a large reason that it’s not a big deal for me is that I can use ReSharper as easily as I can use notepad.  After years of usage ReSharper has just become a natural extension of the IDE for me that allows me to quickly my code. 

So the question then is is this valid?  I find that the classes make a lot more sense, have a higher cohesion and lower coupling then otherwise.  These things obviously are good things.  But is the increased cost of navigation and potentially understanding worth it? 

As I look at my list of projects I consider as being active in my life ala Getting Things Done I realize now that I am…

1. Trying to do way too much at once.
2. Focusing way too much in one area.

These are really important things to realize.  So even if you don’t go full blown GTD I suggest taking 10 minutes and writing down every ‘project’ you are thinking of right now.  Once you’ve got that list, evaluate it and make sure that you’re being realistic with yourself about how much you can do (Currently I think I’m equivalent to a single core with 50 apps running). 

And then make sure that you’re not focusing too much in one area.  If all you’re working on right now is code make sure you do something to improve your soft skills (oh that’s right.. I need to add Toastmasters to my @Someday list) and if you’re heavily into soft skills make sure you find some time to read about what new techniques the kids are using. 

Well rounded people are just as nice as houses with rounded corners.. or something like that (Funny what seems funny at this hour..)