Tim Barcz : Tools

Jet Brains Development Academy Welcomes Another

Tim Barcz — Wed, 12 Aug 2009 02:55:00 GMT

A few years ago I was introduced to ReSharper (JetBrains) from a co-worker (Thanks Grant!). Having always been one who desires to move more quickly through code and take advantage of any shortcut I can, ReSharper felt like "coming home".

Last week I was invited to be part of their development academy as a an academy expert. For those of you not aware of this hidden gem that JetBrains has created:

Members of the Academy are recognized experts in various areas of software development. They contribute to Java and .NET communities by advocating best development practices through formal and informal publications and meetings, and serve as a versatile source of expertise.

I'll be entirely honest and say that I don't consider myself an "expert" in anything, let alone ReSharper. Yes, ReSharper is an integral piece of my development environment and an extension of my finger tips, but I'm always coming across new key commands or features that were always sitting there, begging me to use them, making me realize, I can stretch this tool a bit more (or is it the other way around?).

The reason I'm so fond of ReSharper is that development tools litter the .NET space. This is plainly visible by picking up a magazine and thumbing through it, taking notice to all of the component manufacturers and tools available. The quality and usefulness of some of these tools can often be called into question. ReSharper, however, is a pleasure to work with. Even in it's memory hogging days (around version 4.0) I didn't mind it so much, the productivity gain was entirely worth it (version 4.5 works beautifully). There are tools that I like having and tools that I must have. Had the company I work for not purchased ReSharper, I would have paid for it out of my own pocket. I can't say that for a great number of tools out there.

Your IoC Container Choice is Not a Feature of Your Application

Tim Barcz — Mon, 30 Mar 2009 02:51:00 GMT

I don't want to be a wet blanket, but someone's got to put a stop to the IoC love fest going on out there. An Inversion of Control (IoC) container , for those of you were aren't yet familiar, allows you to retrieve instances of objects at runtime. A relatively common solution to a common problem. In the .NET world there is no lack of choices of IoC containers:

(I won't go fully into IoC, but If you'd like more resource you can read Martin Fowler's article on the subject or post specific questions in the comments or contact me through. Read on, there is value here in this post for you.)

Let me state clearly now, IoC containers are a means to an end and NOT a feature of your application. The goal is to have loosely coupled applications, IoC containers help get you there, but you can absolutely have a loosely coupled application without an IoC container (see the Gang of Four creational patterns).

Occasionally I'll hear some comment about IoC and how great a certain container is or how an application would be so much better if another, sexier, container was used. Here are some recent tweets that illustrate:

Man i love #StructureMap, always finding new things i can do, and have fun doing them
really need to look at structuremap, but we''ve invested a lot into castle with our own facilities/resolvers/etc
Ninject is da bomb!
Switched from Windsor MicroKernel to Ninject in 10KLOC project in < 1 hour by creating a little proxy. Now to complete the conversion.
It is a talk on Castle Windsor so i guess Ninject will not do.
Can't imagine why somebody would use Ninject beside the fact that it's PURE AND UTTER AWESOME. Yeah! Ninject FTW.

Some of the statements above are probably innocuous, but some rub me slightly the wrong way. Specifically the two comments above about switching from one container to another. There are probably times when the choice of one container over another makes sense, but I would bet that these scenarios are the exception and not the rule.

Choosing one container over another won't make your application a success, the architecture, or lack there of, will have far more of a say on your application than will your container choice. As yoda might say, "The container you choose does not a good app make".

NHProfiler - An Early Look

Tim Barcz — Tue, 09 Dec 2008 07:09:17 GMT

Over the past week I've had the distinct opportunity to have a first-hand look into NHProf, Ayende's upcoming profiler for NHibernate. It's been an honor to be part of the team that is putting NHProfiler through its paces. While NHProfiler is still in private beta it is very impressive and I want to let you peek inside.

This evening I decided to sit down and spend some time poking around an application and watch NHProfiler to see if anything seemed out of sorts. Here's what I found:

Easy To Understand

You can get by without purchasing NHProf, from what I see there's nothing you can't "figure out" yourself. NHProf is a lot like ReSharper or CodeRush, you can get by without it, but why would you want to? Here's what I mean, you can pop open SQL Server Profiler and see what is being executed:

That's messy but take a look at how NHProf collates the data:

Relevant

You can sift through the SQL Server Profiler trace if you'd like to but NHProfiler does a great job in giving you the same information, just presented better.

From this view I can see that five queries were run and I can see that three of the same queries are being issued which might point to an area where there is some tweaking to do.

Performance Gains

We all want our applications to run faster. We want speed and performance but often times its takes quite a bit of time to find performance problems and their subsequent fixes. NHProfiler allowed me to very quickly find some queries that didn't need to be executing and tweak some code to eliminate those calls. Since I can see the code that NHibernate generates I can also make modifications to query I'm submitting to NHibernate for further performance gains.

In a very short amount of time (the writing of this blog post has taken several times longer) I was able to reduce reduce data access time by a factor of nearly 10. How do I know that, I have the hard data to prove it.

Before:

After:

Conclusion

If you use NHibernate, NHProfiler is a must. By using NHProf to observe my applications I'm able to save my time and not have to burrow through SQL Server Profiler or wonder what is going on at the data level. I am quickly able to observe what is going on and when and make any necessary modification and then observe the outcome. While you can use Visual Studio without ReSharper or CodeRush many of you out there have found you just don't want to. After using these productivity tools you find that you're able to work with less friction. NHProfiler is the same way, you can work without it, but I highly recommend against it.

Keep your eye on Ayende's blog for information coming soon.