Devlico.Us
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @devlicious

Tim Barcz

Why use nails when a screw is the more reversible choice? Have Twitter, follow the conversation there at @timbarcz

November 2008 - Posts

  • Developer Book Club - Recommendations Needed

    Today I tossed the idea of a developer book club out to the rest of my team.  They all seemed to be on board with varying degrees of enthusiasm.  I know that we won't be the first to try this and so I'm hoping some of you out there can share some stories/ideas of what worked for your team.

    The goals are three-fold:

    • Team/community building
    • Common knowledge
    • Knowledge building/sharing

    Specifically I'm looking for three things:

    • What books would be on your short list?  Which book should we start with?
    • What works well to keep people excited/enthusiastic?
    • What are the things we should absolutely stay away from, whether they be specific books or implementation details?

    So let me have it, what advice can you share?  What can we do to make our book club a success?

    Posted Nov 18 2008, 07:37 PM by Tim Barcz with 27 comment(s)
    Filed under:
  • Windsor Components, the ASP.NET MVC Framework, and Bug Verification Tests

    Shhh...don't tell anyone but we don't unit test all of our code.  We're striving to get all developers and managers on board with unit testing but we're not there yet.  Despite our delinquency in writing tests one thing we do try our very best to do is keep mistakes from happening again.  If we find a bug in the system, before fixing it, we go and write a unit test for that problem.  We verify the test fails, the go and write the code that fixes it.  This recognizes that bugs will appear in the system, but once fixed we'll insulate ourselves from that bug happening again.

    We had one such case last week.  We were getting a yellow-screen error after a bunch of commits by developers.  The error stemmed from a component in Windsor that did not have all of it's dependencies met.  In other words, we registered a component which relied on another component which was not registered.  We already had written a test to compile and test our Windsor configuration, however that test was not mature enough and needed some tweaking. 

    In our application we leverage the new ASP.Net MVC.  We also take advantage of the ability to leverage an IoC container, Windsor, to create controller instances when a web request comes in.  When the application starts, we register all of the controllers in the application into Windsor using reflection.  Therefore our Windsor configuration at runtime is made up of two things, the XML configuration and the controllers which are registered on startup.  The "bug" here was that one of our controllers had a dependency on it that was not registered in Windsor.  When you ran the test by itself, the test would pass, since it was only loading up the components from the Windsor configuration.

    Wanting to protect us in the future, we acknowledged there was something missing from our test and set out to find it.  To create the failing test was relatively simple.  All that we needed to do replicate in our test what we were doing at runtime.  Therefore we needed to register all implementers of IController, just like we do on application startup.  Below I've

    Before:

       1: IWindsorContainer container = new WindsorContainer("windsor.config.xml");
       2:  
       3: foreach (var handler in container.Kernel.GetAssignableHandlers(typeof(object)))
       4: {
       5:     Console.WriteLine("{0}\n\t- {1}", handler.ComponentModel.Service, handler.ComponentModel.Implementation);
       6:     container.Resolve(handler.ComponentModel.Service);
       7: }

    After:

       1: IWindsorContainer container = new WindsorContainer("windsor.config.xml");
       2:  
       3: var assm = new HomeController(null).GetType().Assembly;
       4: //add all controllers
       5: foreach (Type type in assm.GetTypes())
       6: {
       7:     if (typeof(IController).IsAssignableFrom(type) && !type.IsAbstract)
       8:     {
       9:         container.AddComponent(type.Name.ToLower(), type);
      10:     }
      11: }
      12:  
      13: foreach (var handler in container.Kernel.GetAssignableHandlers(typeof(object)))
      14: {
      15:     Console.WriteLine("{0}\n\t- {1}", handler.ComponentModel.Service, handler.ComponentModel.Implementation);
      16:     container.Resolve(handler.ComponentModel.Service);
      17: }

    Now that this test is in place, I am much more confident that we won't see the error we were seeing in product again, we've got a test which warns us if something isn't quite right.  Our initial test didn't quite get it all right.  Mistakes/bugs in code will happen, hopefully few and far between, but when a bug does show up, go write a test that verifies the bug before going off an fixing it.  Then make the test pass, which should fix the bug.

  • How To Approach Development

    I don't typically link blog and I do my best to write substantive original material, but the following is too good to pass up.  It's how I feel and how I've approach work in the last year or so.  From Ayende's Reducing The Cost Of Change blog post this morning:

    That mindset, at least for me, starts from the first line of code. I treat each piece of the project as utterly disposable. Since I don't really care how each individual piece works, I am able to roughly sketch a fair amount of the application very rapidly, and then focus on each of the items in isolation, and replace that with a much better implementation. I think that I stated before that I tend to rewrite most of my application core at least two or three times before I am happy with them.

    When you have disposable pieces, it is no big deal if you mess up and need to start over, because the whole project is structured in a way that allows you to do so. Going back to using my current project as an example, the algorithm used for the core part of the system is crap. I thought it up while being on a coffee break, and it is enough to demonstrate what the software is supposed to be doing. I don't really care, because the moment that I do need the real algorithm, I can drop it in (need to change the implementation of a single method).

    I can't improve on that, so I won't try.

    Posted Nov 13 2008, 09:50 AM by Tim Barcz with 3 comment(s)
    Filed under:
  • Iowa Code Camp 2 - In Review

    image This past weekend in West Des Moines, Iowa I attended the Iowa Code Camp.  This was the second such event this year and it amazes me how well these events have gone given they are in their infancy.  The leadership deserves a huge round of kudos for pulling off such a great event.

    Recap:

    This was a big day as I was leading four session, two by myself, and two fishbowl type sessions.  Below is my recounting of an awesome day!

    Open Source Tools for the .NET Developer

    This was my only open session where I was not helping or giving the talk.  So this was a good time to soak in some knowledge.  Javier Lozano did a great job introducing some of the open source tools that he considers a must.  I use everything he was saying, so I was hoping to catch a nugget here or there that I could take back to work with me.  In general I think this was a very good talk.  Covered a lot of ground in a short amount of time but attendees could see by the interaction from a few in the crowd that many of these tools are mature and being used quite heavily with a lot of confidence by other attendees.

    Fishbowl Session(s)

    Chris Sutton has had a vision of bringing open discussion to the Iowa Code Camp since the last go around in May.  He tapped Nick Parker and myself to facilitate.  We weren't sure how the idea of dynamic selection of topics for group discussion would go, but we were very surprised and pleased with the outcome.  We had two of these "sessions" during the day and both of the discussions were very good.

    Easing Your Testing With Rhino Mocks

    This was my talk.  I've given this talk before internally but I was a little skeptical of how the talk would go given that I didn't know who would attend, their familiarity with testing and/or mocking, and what they're knowledge level was in general.  I had struggled with where to take people.  In preparation my talk went from "way too much" to "too trivial" at times.  By Friday night I felt like I had the kinks worked out.  Overall though I think this talk went very well.  I first introduced code that does not lend itself to be easily tested.  I wanted to address testability as a design time idea.  After going through what made this code not easily testable we refactored the code to allow us to get in there are test what we wanted.  We created some stubs and mocks by hand to test both state and interactions.  After showing you could test by writing your own mocks I wanted to show that it's much easier to leverage a framework.  Given the amount and type of questions, I feel pretty good that the attendees understood why you would want to mock and how you would do so.  I'm confident attendees walked away with something they could take to their jobs on Monday morning.

    TDD: A Workshop in Driving Your Design with Tests

    This was my second, self-led session of the day.  I'm not a TDD expert by any means.  Quite frankly, like many out there, I too am learning what it means.  As I've learned and studied, I find that many people classify TDD wrongly.  I often hear something like, "We write unit tests and do TDD" or "We add tests to our code using TDD", which seem to blur the lines between TDD and unit-tests.  I wanted to clear the air and share what I knew.  Rather than doing a talk where I stood up in front of the group and they watched me do something, I wanted to get them involved.  TDD is hard, and I wanted to people to get a true sense of what TDD feels like and how it takes discipline to accomplish.  The idea for this was to have a workshop and as a group solve a problem using TDD.  I think the the knowledge transfer was good and people saw what TDD really is.  The downside was getting people to get out of their seats and code.  The idea was to have a person write a failing test, then someone else write the code to make it pass.  Out of a very good crowd of about 30, only about 7 were willing to interact which was somewhat disappointing.  I think the idea of an interactive workshop is still a good one, however, as someone suggested, I would structure it quite differently, possibly keeping someone at the computer for a few minutes at a time.

    Conclusion

    Overall the day was awesome and I look forward to the next.  If you have access to a code camp they really are a great way to learn.  Imagine trying to learn something new and having someone right there begging you to ask them a question.  I look forward to the next Iowa Code Camp, which will be next spring.  Leading four sessions was a lot but come May I will probably be pushing myself to present again as much, ever hoping to help someone be better than they were the day before.

  • Exercise Caution When Using Floating Point Numbers

    I understand floating point numbers can be somewhat imprecise but I'm a bit bothered today when I see the following evaluates to false:

       1: float f = .16f;
       2: double d = .16d;
       3:  
       4: Assert.That(f, Is.EqualTo(d))

    Annoyingly I wanted to see what the two values are:

       1: Console.WriteLine((double)f)
       2: Console.WriteLine(d);

    produces the following respectively:

    .159999996423721

    .16

    What bothers me about this, and I'm hoping someone can eloquently explain this, the MSDN docs say this should be implicitly converted.  From the MSDN doc article on implicit numeric conversions:

    • From float to double.

    Float is 32-bit and double is 64-bit, so why can't the float fit nicely inside the address space for the double?

    Hell, if you're not going to respect the integrity of the number what's the point of the implicit conversion?

    Posted Nov 05 2008, 02:13 PM by Tim Barcz with 10 comment(s)
    Filed under: ,
  • Test First or Test Driven, Who Cares?

    image This past weekend I attended the Continuous Improvement in Software Development Conference in Austin, Texas.  This conference brought together many brilliant minds in the .NET community for the expressed purpose of continuous improvement.  The conference was very good, but some of the best chances for learning happened outside the conference sessions at dinner or sitting around a table at the hotel bar.  One such discussion seemed to point out one problem we have in our community, minutiae.

    I will preface the remainder of this post by saying I tend to be a purist at times and must always remind myself what the ultimate goal is.  Acknowledging my tunnel vision, sometimes purists, can miss the point if we're not careful.  One evening a few of us got on the discussion of test-driven development.  Someone at the table used the phrase test-first development in the conversation.  That person was quickly halted by others at the table because the terms, in their opinion are quite different and should not be used interchangeably.  If I were to ask you define both, could you adequately define the difference?  Should you be able to?  Does it really matter?

    I would say that for the development community out there that the differences, if in fact they do exist, don't matter.  A quick and informal poll revealed that 8 of 10 developers I know aren't unit testing at all.  I readily admit that my sampling is probably an inaccurate representation of the total developer population.  I don't think though that my sample poll is off by an enormous amount.  Think of the developers you know; are they testing at all?  I'm not talking TDD, but plain old unit tests?  Chances are good that you know a few that aren't testing at all.  Are they served by the bantering back and forth about differences between TDD and TFD?  Absolutely not.

    The important thing to remember is that fundamentally the TDD and the TFD practitioner believe the same thing, that is, you need to be testing your code. They may disagree about small things, but those small things should take a back seat to the fundamentals.  We don't have to look far to see another example of this type of behavior.  Think of two Christian denominations, both of which are trying to convert nonbelievers to Christianity, bickering among themselves about whether children should be baptized or not.  The debate becomes so ardent, that neither camp accomplishes their original goal or converting nonbelievers because they're too focused on each other.  I fear the same outcome will befall those of us preaching testing.  We get so religious about the non-essential aspects of testing that we miss the people we intended to target, the people who aren't testing their code at all.

    I think we could all take a page from St. Augustine who had it right over 1600 years ago: "In essentials, unity; in non-essentials, liberty; in all things, charity."

  • Alt.NET Austin - Workshops Day 2, Conference Day 1

    Yesterday was the first day of the pre-conference workshops at the Kaizen Continuous Improvement Conference.  Day two was a bit more invigorating for me since I attended two topics (Opinionated MVC and Fluent API's with C#) which got my head spinning nearly immediately.  Both talks were very good and rather than writing my own thoughts on the subject I'll defer to Derik Whittaker and his thoughts on the day.

    Posted Nov 01 2008, 03:52 PM by Tim Barcz with no comments
    Filed under:
  • Alt.NET Austin - Workshops Day 1

    I'm in Austin, Texas for the Kaizen Continuous Improvement Conference this weekend.  One of the very cool things the organizers did for this event was offer two days of workshops before the conference.  While I'm excited for the conference itself, much of my excitement for the conference stemmed from these pre-conference workshops.  Yesterday I went to two workshops, both of which should be online at some point.

    Advanced NHibernate - with Ayende Rahien

    I was a little leery of this one given our seemingly trivial usage of NHibernate.  I was pleasantly surprised to see how much of this was perfectly timed for where we are at.  Oren went into great detail on various parts of the NHibernate and it's contributing projects.  He spoke a bit on caching and performance optimizations/pitfalls that you generally have to watch out for.  Quite possibly the coolest feature was getting to see NHibernate profiling application that Oren is working on.  This won't be a free tool but the price from what I've heard from Oren will be very reasonable (I am not saying the price since it may change).  With NHProfiler you can see all the queries that get executed from you application.  It even has alerts built in, such that if it detects a problem (ie. Select N+1) it will let you know.  Without hesitation, if you're using NHibernate, buy NHProfiler when it comes out, it is easily worth it.

    The most important concept that I got from this session is how powerful NHibernate is.  People can fight ORM, roll their own solution, or write their own T-SQL but when you see what NHibernate has to offer it seems ridiculous to choose any of those options.  Two little known NHibernate features you may not have known about that I've found very cool:

    • NHibernate Search : Leverages the open source Lucene.NET implementation and keeps allows you to do search which have performed poorly in the database against a very fast Lucene index.
    • NHibernate Shards : Written by Google this allows you to scale across a number of databases. I won't delve into sharding here but you can read up on it on wikipedia.

    DDD Chalk Talk - David Laribee

    I was very interested in this chalk talk since the name seemed to indicate we'd get a chance to have an open discussion about DDD and how one would approach DDD in their domain.  This talk seemed to have peaks and valleys.  It was no fault of anyone in the talk, but DDD seems to be one of those topics where it becomes extremely tough to follow once you get outside of what you know.  The topic of aggregate roots and contexts were quite helpful.  I found it encouraging that ideas that I have interpreted from the book seem in line with what David Laribee demonstrated on the white board.  I'm only a few chapters into the book and am absorbing as much of the DDD concepts from those who are ahead of me on this path.  I'm encouraged to see where others have taken it, the value they have found in it, and what it could mean for our application(s) in the future.  Just have to keep reading and learning.

    Quite a lot for only the first day of a multi-day conference.  For those of you who aren't here in Austin but wish you were, keep an eye out for videos of the many presentations that my pop up.  I will update this blog if/when I see them appear online.  There was a lot of good content coming out of these workshops and it'd be a shame to have the content limited only to those in attendance.

More Posts

Our Sponsors

Proudly Partnered With