Unnoticed Improvement

I ripped my rotator cuff playing racquetball. It’s a small tear, no surgery needed. I did it back in March. It took me a while to get to physical therapy for it for a lot of reasons that aren’t important, but mostly relate to my being stubborn and still thinking I’m invincible with Wolverine-like healing powers. So, long story short, I’ve been in PT for about 5 weeks.

Yesterday, my physical therapist asked me if my shoulder was getting better. I of course said, “no, not really. Well, maybe a little”.

Then she did the measurements of my range of motion. And in fact, my shoulder is a lot better. It still has a long way to go, but it is much improved. And I hadn’t noticed.

I hadn’t noticed because I use it every day. I don’t give it a lot of thought. It’s just a part of my existence. The same way you never noticed getting taller until you saw that relative you only see twice a year, and they couldn’t stop exclaiming how much taller you had gotten. You look at yourself in the mirror the same every day, pull on your pants the same way every day, so those microns and millimeters never had much impact on your perception. But that doesn’t change the fact that you had gotten significantly taller.

Weight loss is the same way. I could go on…

The point is, change happens slowly. You don’t notice that you are becoming a better coder, a better tester, a better coach, a better team, whatever. You don’t notice the improvements that have taken place. And so it’s easy to say, “this %$#@ place, it’s no better today than it was a year ago”. And in fact, you’d be completely wrong. It is better (and probably worse in other ways, such is life). You just never took the time to notice. There is no crazy aunt that shows up one day and says “wow, look how you’ve grown”.

So, take a few minutes. Maybe once a sprint, once a month, once a quarter. Whatever timeframe works for you. And reflect on how you’ve improved. How your team has improved. Do it with your team – you’ll probably find it to be a fun positive feedback loop. Enjoy the successes.

Posted in Improvement | 1 Comment

MassTransit and Ninject

My DI container of choice is Ninject. The reasons aren’t overly important, other than I hate, hate, hate XML. If I wanted to program in XML, I’d use Java. Fortunately, there are DI containers in the .Net space that don’t require all that XML, and Ninject is one of them. The Ninja connections kinda bug me, but I actually had it in my head as NINject first, so Trent trumps stupid martial arts posing.

The first thing I came across while trying to get into MassTransit, though, is that Ninject support, while advertised as existing, is a little lacking. It could just be me, but I found a problem with using any of the non-default constructors in MassTransitModuleBase, which is derived from NinjectModule. NinjectModule is the base class from which you derive to set up your bindings, and then your derived class is passed into a Ninject Kernel, which does the binding resolution. Ninject isn’t really ready to set up bindings until the Load() override in your derived class is called, but MassTransitModuleBase tries to set up bindings in the non-default constructors using the values that are passed in.

This makes sense, because the other significant non-XML based DI container, StructureMap, appears to allow this, and clearly the MassTransit guys have used that container and used it as the model for the Ninject support. Dru Sellers, one of the original authors, told me in a tweet that they weren’t all that familiar with Ninject. Its understandable – how many DI containers do you really need to know how to use?

So, I had managed to make it work by not using any of the non-default constructors at this point, because I assumed that the MassTransit implementation was correct. The result looked something like this (note that I used Mike Hadlow’s first look article as the basis for my code):

[Gist MassTransit and Ninject Example 1.cs]

   public class PlayMassTransitModule : MassTransitModuleBase

   {

       public override void Load()

       {

           base.Load();

 

           RegisterEndpointFactory(x =>

           {

               x.RegisterTransport<LoopbackEndpoint>();

               x.RegisterTransport<MulticastUdpEndpoint>();

               x.RegisterTransport<MsmqEndpoint>();

           });

 

           RegisterServiceBus(@"msmq://localhost/mt_mike_publisher", x =>

           {

               x.SetConcurrentConsumerLimit(1);

 

               ConfigureSubscriptionClient(@"msmq://localhost/mt_subscriptions", x);

           });

       }

   }

Notice that I had to set everything up in the Load() override. This is the way it has to be right now. I’m working on a patch so that you can use the Ninject container integration exactly like you do with StructureMap. Hopefully I’ll have it done and accepted by the time this post is published. In the meantime, if you want to see the full solution, check out this branch in my github DemoCode space: https://github.com/ekepes/DemoCode/tree/NinjectDemo

Posted in Distributed Systems, MassTransit | Tagged , , , ,

Getting on the Bus

The kinda, sorta message broker we’ve built at work over the last few years works just fine for what we are doing today. I’m actually rather proud of some of the things we’ve done with it. But the primitive pub/sub implementation I bolted on it isn’t going to do the trick going forward, as we want to have distinct services for different functional concerns. We also want to be able to use CQRS where is makes sense, but at the very least operate in an event driven manner. The current code base won’t allow that to work without a lot of change.

The world has changed since we started on the project. There are at least two solid ESB projects out there for .Net (a third depending upon what you think of the state of Ayende’s Rhino Service Bus, but I don’t think it would be responsible to depend upon a single maintainer project for something so business critical). NServiceBus is the gold standard, and rightly so – Udi Dahan is the go-to guy for all things distributed in the .Net space (and beyond). MassTransit is also a very viable project.

The problem with NServiceBus for me, at this time, is that I can’t risk having the load on the system exceed the free community version. We have entirely too many customers, and our products are sold as an on-premise solutions. We could build in the cost, no doubt, but at the moment that’s not attractive. Especially since MassTransit is proving to be just what we need. So, I’m going forward with heavily evaluating MassTransit and figuring out how to make it work for us.

One of the biggest problems with MassTransit is an absolute dearth of documentation. Some of the samples are even out of date. This seems like a good place for someone to help out, and I’ve wanted to help out on an OSS project for a long time, but couldn’t find my niche. It seems like trying to help with the documentation problem is a good use of my time, and hopefully will help me better understand how MassTransit works. So, we interrupt our previously scheduled exploration of Ruby and Rails to bring you this series on MassTransit.

Posted in Distributed Systems, MassTransit | Tagged , ,

Burning up my 15 minutes…

I was asked to be on the Community Megaphone Podcast. Andrew Duthie (@devhammer)and I had debated Software Craftsmanship back in November or October via twitter and of course you can’t debate very well in 140 character shots. So we decided to have a panel discussion for the Community Megaphone Podcast at the NoVa Code Camp 2010.2 in December. It went reasonably well (you can find it here) but we couldn’t get into too much depth. After the panel, Andrew and I talked in the hallway for a while and that lead to him asking me to be on the show as a guest.

We recorded the show right as the Software Craftsmanship debate was hitting the social networking fan. It was a good discussion. And now you can hear it. I open up really rough with lots of bad speech habits, but after I settle in I’m not so bad. Smile

Posted in News | Tagged ,

Book Review: The Agile Samurai

The Agile Samurai by Jonathan Rasmusson has some differences from your typical book on agile project management. For starters, the style is very much like a Head First book, full of asides and fun graphics that help draw you in to the book. It also doesn’t stop at just laying out the rules and religion of a particular agile project management technique – it has valuable insight into how you get a project off the ground and a brief overview of some of the agile engineering techniques that will make your project successful.

Jonathan is a very engaging author. He clearly understands what he is talking about from a been-there-done-that perspective and is not afraid to warn you of things to watch out for. I was a little turned off by the whole samurai thing at first, but that’s mostly because I think the whole Zen/Eastern Mysticism thing is a bit overdone in software in general, and in agile specifically. Once I got over that bias, I thoroughly enjoyed the book.

I read the book mostly because I am always looking for good resources to pass along to people getting started working in an agile environment and this seemed like it would be a good one. I didn’t expect to learn much at this point – I’ve read more than my fair share of books and articles and been to training. I was pleasantly surprised – I picked up some really good information, particularly about the Agile Inception Deck.

If you are about to participate in an agile project, I highly recommend this book. If you have a team that is about to participate in an agile project, you should seriously consider passing out copies of this book. If you are a grizzled veteran, you probably won’t learn a lot from this book (information about the agile inception deck, an idea that came out of the ThoughtWorks consultancy can be found on the Web, including the author’s blog), but there are enough nuggets in there that you still may find it valuable, especially the detailed treatment of launching a project, a topic that is neglected in most other books about agile project management.

One slightly unrelated note – I read this book on my Kindle and I have to say that the formatting was exceptional. The Pragmatic Programmers by far take the most care in making there electronic books usable. I have books from another publisher that shall remain nameless that are completely unreadable.

Posted in Review | 3 Comments

Migrations

Rails has an extremely interesting idea for keeping a database up to date, no matter where it is (development, staging, production, etc.). Its called Migrations.

I’ve dabbled in this idea before – there is an open source project out there called dbdeploy.net, which is based on the java project dbdeploy. What it does is run all of your database update scripts in sequence, and theoretically allow you the capability to roll back to a previous version. I used it a part of our build process to keep our unit test database (there’s an anti-pattern we feel for) up to date. It worked fairly well, but wasn’t perfect.

What happens with Migrations is you write Ruby code that tells how you want to transform your database, and it will get handled no matter what kind of supported database you have. Its completely SQL syntax agnostic. It also is easier to create the rollback aspect, because it is just another method you have to write. And numbering is made easier because Rails takes care of numbering them for you.

The first thing I wanted to do when I saw this concept was port it to .Net. Yeah, except its been around for a long time, so of course someone beat me to it. Actually, a couple of people did.

So, I figured I’d do the next best thing and maybe write a post about how to use one of these ports. But Justin Etheredge beat me to it (long ago, in internet time). So, if you don’t know anything about Migrations or you do but you didn’t know you could use them from .Net, head on over to Justin’s post now.

Posted in Eric on Rails | Tagged , , , , , | 2 Comments

Eric on Rails

As I mentioned previously, I am actually going to really learn a new language or two this year. I played around with Ruby probably 6 years ago, but just a bit of dabbling while I was on the bench (I was in consulting at the time). I retained almost nothing.

Other than a brief diversion into PeopleSoft on Unix platforms with an Oracle database for two lost years of my life back in the mid-90’s, I’ve been almost exclusively working with Microsoft development tools. I don’t see that changing for me in a professional sense in the foreseeable future, but I know I need to become more diverse as I spend more time pretending to be an architect. There are other schools of thought out there I can learn from.

I have in general spent most of my reading and studying time with non-Microsoft things – I have spent a lot of time with agile project management techniques (mostly Scrum) and agile “engineering” techniques. I have embraced a lot of non-Microsoft technologies in the .Net space (NHibernate probably being the most notable one). So clearly I can no longer be called a Microsoft fanboy (I once used to get that a lot Smile). So this isn’t about Microsoft or any particular technology vendor. Its about making myself a better software development professional.

As I stated in this blog before, the innovation these days seems to come most heavily from the Rails world. I hate the idea that I’m following the cool kids – I never have cared a lot about doing the popular thing, but in this case, I think they might be on to something. Don’t get me wrong – there are lots of things that are suddenly innovative about Microsoft. The phone is a significant advancement of the state of the art, even if I doubt it will catch on. WebMatrix seems to help ease web development without the soul crushing abstractions of Access or LightSwitch. And F# is a good gateway/compromise solution to functional programming on the .Net platform (someday I hope to spend a fair bit of time with that animal).

But the next leg of the future is paved with things prominent in the Ruby world. They could have come from anywhere (and in the past seem to have most often come from Java, but I posted about that already). But right now the cutting edge of ideas like dynamic languages, lightweight web development, behavior driven development, automated acceptance testing, etc. seems to firmly reside in Ruby world. And I like the promises that those ideas bring to help enable us to build better software with higher quality faster.

My interest is not, as I said above, to switch my day job from C# and the .Net world to Ruby and Rails. There are still really cool things going on in .Net. I still believe in “thick/fat/smart” clients. No toolset does a better job for building such things than .Net. WPF and Silverlight still have a future.

Instead, I think that by spending my free time playing with Ruby and Rails will help me discover ways to be a better C# developer. Its time for me to leave my comfort zone in hopes of learning valuable new lessons (this is my initial guide, but I know there will be other resources – I’ll post about this book and those resources as I can). I plan to blog about my discoveries. Many of them will probably be things you already knew. Some of it may be things I already know, but not as deeply. It should be a fun ride.

Posted in Eric on Rails | Tagged , , | 1 Comment