The Inquisitive Coder – Davy Brion's Blog

Trying to walk that thin line between intelligence and ignorance

Taking A Week Off

Posted by Davy Brion on February 4th, 2010

Well, i’m off for a week… i’ll be doing the tourist thing (you know, hanging out, having fun, laughing our asses off, taking pictures and generally annoying the hell out of the locals) in New York City and i won’t be back until February 14th. I will be avoiding all kinds of electronic communication and the internet in general, so if you’re wondering why i’m not responding to email, now you know why :)

I’m not leaving until Saturday morning, so if you have some ‘must-see’ or ‘must-do’ tips about New York, bring em on! :)

Posted in About The Blog | 3 Comments »

Browser Usage

Posted by Davy Brion on February 2nd, 2010

I read an article today about how Chrome has increased a lot in market share in the past year, mostly at the expense of Firefox.  I wanted to see how Chrome usage on this blog has progressed in the past year so i got some stats from Google Analytics and created this little graph:

image

(note: these numbers are obviously only from visits to this blog and are thus not representative of the entire internet (yet) etc…)

I started at the month before the first Chrome users were reported to give you an idea of Firefox’s score at that time.  Naturally, the people that come to this blog are into technology so it’s no wonder that Firefox is the dominant browser instead of IE.  Before Chrome entered the picture, nearly 70% of all visits to this blog in August 2008 were from Firefox users.  In its first month, Chrome immediately got about 8%, which i thought was pretty impressive.  Firefox’s numbers dropped below 50% for the first time less than a year later.  That’s a pretty big impact in a relatively short time.   And as you can see, Chrome usage has been growing a lot in the past 6 months ago, at the expense of both Firefox and IE.  I wouldn’t be surprised if Chrome catches up to Firefox in another 6 months.

I’m not fanatic about any browser (as long as i don’t have to use IE, right?)… i use Firefox for OS X at home, but i use Chrome at work.  I’m not really into the whole plugin/extension thing (except for Adblock obviously) so i’m not really ‘tied’ to a specific browser.  Now, some people are pretty fanatic about their browser so what i’m wondering is: what would it take for you to switch to another browser (no matter which one you use now)?  Are you hooked on extensions that you can’t go without in another browser?  What was the reason you picked your current browser and why are you sticking with it? Or is it all pretty much the same for you?  Do you frequently use multiple browsers?

In some weird way, i find that kinda stuff interesting so please do share :)

Posted in About The Blog | 14 Comments »

Good Team Dynamics Are Essential For High Technical Quality

Posted by Davy Brion on January 31st, 2010

Just read an interesting post from David Tchepak about the lessons he learned from his long-term agile project.  The post itself is interesting but there was one point in particular on the momentum of his team that caught my attention:

This probably sounds a bit touchy-feely, but I think dismissing it on those grounds is ignoring a fairly fundamental part of human nature. If every day, every task is a thankless struggle, the intertia will pull down your team’s morale, motivation, concentration, and reduce their creativity and ability to innovate. On the flip side, once the team gets up a bit of steam and starts churning through stories, seeing visible progress as they move across the task board and into the Done column, the team’s enthusiasm and creativity soars. They start kicking around new ideas on how to remove some duplication from the code and reduce some overhead for future stories.

David is right, but i’d go even further than that.  I’d assert that good team dynamics are essential for achieving high technical quality that is sustainable in the long term.  I think we can all agree that people work better together if they actually like working with each other.  And i’m pretty sure that many of us have experienced first hand how a negative relationship within a team can have a pretty negative impact on the technical quality of a project. 

Have you ever been on a project where you were looking at a piece of code thinking “wow, this really ought to be cleaned up… but i’m not touching it since John is gonna get all pissed over somebody touching his code”.  Or worse, “wow, he really made a mess of this but i’m not touching it… let him live with the pain”.   I certainly wouldn’t be surprised if many of us have at one point (or more) in our career had this exact thought about a certain piece of code written by a teammate at the time.  That is a perfect example of how negative team dynamics can have a pretty serious impact on the technical quality and thus, i’d argue, the long-term viability of the project.   See, the thing is that it won’t end what that certain piece of code.  Sure, code rot has been introduced.  But even worse, team rot is being introduced by this behavior as well, even if you are just trying to preserve the peace by trying to avoid a possible confrontation.

This kind of team rot will not end there.  If you don’t actively try to get rid of it ASAP, it’ll eventually spread throughout the team, as more and more people gradually get into the same mentality.  Eventually, even the strongest, most positive personalities can fall victim to it.  When new people join the team, they’ll quickly pick up on it as well and there are very few people who are willing to stand up to such a situation when joining an existing team.  As i’m sure you can imagine, nobody really likes working in such a team.  A lot of people in that situation will get into a “i’m just gonna look out for myself and to hell with anyone else” mentality.   They will try to do their job in a way that they will not be blamed for anything.  Communication will drop to a ‘nothing-more-than-necessary’-level.  A lot of issues will be ignored until they are actually found by end-users.  A lot of time and effort is going to be wasted in general.  And you’ll probably end up with a pretty high turnover rate of team members.  Believe it or not, these kind of teams truly do exist.

On the other hand, if everybody on the team gets along everything seems to go much more smoothly.  People won’t be afraid to make changes in other people’s code if everyone understands that it’s for the best of the project and if they know that it’s not gonna lead to a bitchfest from a difficult team member.  Discussions will be about actual facts and merits, not about not-wanting-to-give-in-to-someone-you-no-longer-like.  People will alert their team members when they notice something that could cause problems later on.  People will be much more likely to maintain their technical discipline when there is positive peer pressure to maintain high standards.   People will help each other when they can.  Essentially, those people will form a true team instead of being a collection of coworkers who are unfortunately working on the same project together.

As much as many of us strive to improve our technical abilities and skills on a continuous basis, we also need to ask ourselves the following questions regularly:

  • Am i a good team member?
  • Would i like to work with someone like me?
  • What can i do to make people enjoy working with me more than they might do now?

That doesn’t mean you have to become Mr Popular.  It doesn’t mean you have to crack the best jokes.  You can be almost entirely yourself, as long as you realize that:

  • communication is extremely important
  • treating others with respect is crucial
  • nobody likes working with whiney developers
  • you can’t expect others to work on their flaws if you’re not willing to work on yours… it’s a two-way street

Posted in Opinions | 3 Comments »

NDepend 3 Preview

Posted by Davy Brion on January 28th, 2010

I was just playing around with an NDepend 3 beta version to experiment with the new Visual Studio integration that the NDepend team has developed. 

Once you install the Visual Studio addin through the VisualNDepend.exe tool, you’ll notice the following menu has been added in Visual Studio:

01

If you select the first item, you can easily create a new NDepend project for your current solution:

02

You’ll also notice an NDepend icon in the bottom-right corner of Visual Studio.  Clicking on it shows you an immediate overview of NDepend’s CQL query results for your solution:

 03

Clicking on the Show SQL Explorer immediately brings you to this view, which many NDepend users will recognize:

04

You can also right-click on a type (or a method) and you’ll see the following NDepend context-menu:

05

Which in turn allows you to open many of the familiar NDepend views:

06

This particular view is something that i find extremely useful.  Notice how you get an immediate overview of relevant metrics when you click on one of the items in the graph.  Or you can look at the metrics view:

 07

I’ve never understood how to interpret this view, but NDepend users who do will be glad to know they can now access it extremely easily :)

One thing that i can see myself make extensive usage of are the following features:

08

I’ve only played around with it for about 15 minutes now, but i’m impressed.  I never really liked NDepend 2 because i always got completely lost in the VisualNDepend UI.  Now that i have all of this integrated in Visual Studio, it just seems much easier to get to the information i really want.  And if you have to review a lot of code (like me), then this new NDepend version is sure to save you a lot of time.   It’s pretty much everything you’ve always wanted or already loved from NDepend, but much more easily accessible.

I did notice some small visual glitches (which might be related to running this in a VMWare virtual machine on OS X) and at one time even a Visual Studio crash, but i’m sure those issues will be fixed before the final release.

Oh, and i’m also very happy to note that this particular issue has also been resolved :)

Posted in IDE, NDepend | No Comments »

Securing Your Agatha Service Layer

Posted by Davy Brion on January 27th, 2010

The question of how to implement security for an Agatha Service Layer is one that comes up frequently.  First of all, you need to remember that if you’re using Agatha with WCF you can use any of the WCF features that you’d normally use to secure your WCF service.  There’s already plenty of information available online or in books on implementing security for WCF services so i’m not going to spend time on covering those options.  What i am going to cover is the approach that we typically use for our Agatha service layers.

I don’t like to tie myself to WCF-specific features, so i always plug in custom authentication into either a custom Request Processor, or a base Request Handler class that all other Request Handlers must inherit from.   But first, how do we get the authentication-related data from the client to the service?

In each project i use Agatha in, i always have a MyProjectRequest and MyProjectResponse base class:

    public class MyProjectRequest : Request

    {

        public string UserName { get; set; }

        public byte[] PasswordHash { get; set; }

    }

 

    public class MyProjectResponse : Response {}

 

Each request in the project inherits from this base request, and each response inherits from the base response.  The base response class is often empty, though this does make it very easy if you ever need to send something back with every response.

Now obviously, if every single request that is sent to your service layer needs values for the UserName and PasswordHash properties you want this to be done in only one place.  I do this by using a custom request dispatcher:

    public class MyProjectAsyncRequestDispatcher : AsyncRequestDispatcher

    {

        private readonly IUserContext userContext;

 

        public MyProjectAsyncRequestDispatcher(IAsyncRequestProcessor requestProcessor, IUserContext userContext) : base(requestProcessor)

        {

            this.userContext = userContext;

        }

 

        protected override void BeforeSendingRequests(IEnumerable<Request> requestsToProcess)

        {

            base.BeforeSendingRequests(requestsToProcess);

 

            foreach (var myProjectRequest in requestsToProcess.OfType<MyProjectRequest>())

            {

                myProjectRequest.UserName = userContext.UserName;

                myProjectRequest.PasswordHash = userContext.PasswordHash;

            }

        }

    }

 

The IUserContext dependency is just a component that is registered in my IOC container and will be injected automatically whenever you get an instance of IAsyncRequestDispatcher.   Now, in this example you can see that i add the authentication data to every request in a batch, even though the batch will be sent in one roundtrip.  If you want, you can add the authentication data only to the first request and then only use the first request to do the authentication within your service layer.  I prefer to add the authentication data to each request and then authenticate every single request (even subsequent requests in a batch) within the service layer.  I’ll get back to this point later on.

Now, the only thing we need to do to make sure that your requests will always have the authentication data contained within them is to instruct Agatha to always use instances of your MyProjectAsyncRequestDispatcher class whenever an IAsyncRequestDispatcher is needed.  This is easily done during Agatha’s client-side configuration:

            new ClientConfiguration(typeof(MyProjectRequest).Assembly, new Agatha.Castle.Container(myContainerWrapper))

                {

                    AsyncRequestDispatcherImplementation = typeof(MyProjectAsyncRequestDispatcher)

                }

                .Initialize();

 

Keep in mind that you still have to register your IUserContext with the container on your own though. 

With that in place, we are sure that each request that comes from our clients always contains the proper authentication data.  Now we need to make sure that we actually authenticate these requests within the service layer.  You basically have 2 options: either implement your own Request Processor which adds authentication checks, or create a base Request Handler that your other Request Handlers inherit from.

We’ll first cover the option of using a custom Request Processor.   You could create one like this:

    public class MyProjectRequestProcessor : RequestProcessor

    {

        private readonly IAuthenticator authenticator;

 

        public MyProjectRequestProcessor(IAuthenticator authenticator, ServiceLayerConfiguration serviceLayerConfiguration, ICacheManager cacheManager)

            : base(serviceLayerConfiguration, cacheManager)

        {

            this.authenticator = authenticator;

        }

 

        protected override void BeforeHandle(Request request)

        {

            var myProjectRequest = request as MyProjectRequest;

 

            if (myProjectRequest != null)

            {

                if (!authenticator.AreValidCredentials(myProjectRequest.UserName, myProjectRequest.PasswordHash))

                {

                    throw new MySecurityException();

                }

            }

        }

    }

 

The BeforeHandle virtual method is called right before the request is passed to its Request Handler to be handled.  Note that this Request Processor would authenticate every request.  If you want a Request Processor that only authenticates the first request, you could do so like this:

    public class MyProjectRequestProcessor : RequestProcessor

    {

        private readonly IAuthenticator authenticator;

 

        public MyProjectRequestProcessor(IAuthenticator authenticator, ServiceLayerConfiguration serviceLayerConfiguration, ICacheManager cacheManager)

            : base(serviceLayerConfiguration, cacheManager)

        {

            this.authenticator = authenticator;

        }

 

        protected override void BeforeProcessing(IEnumerable<Request> requests)

        {

            var myProjectRequest = (MyProjectRequest)requests.ElementAt(0);

 

            if (!authenticator.AreValidCredentials(myProjectRequest.UserName, myProjectRequest.PasswordHash))

            {

                throw new MySecurityException();

            }

        }

    }

 

The BeforeProcessing virtual method is called before any of the requests are handled, so you could authenticate only the first request in a batch and then proceed with regular processing if the first one is authenticated.  Now, the big problem that i have with this approach is that you aren’t really in control of what is sent to your service layer.  Yes, you can guarantee that each request coming from your clients contains the proper authentication data.  What you simply can’t guarantee however is what other people or custom clients can send to your service layer.  If they send you a batch of 2 requests, the first containing valid credentials of a normal user for a benign request, it will pass the authentication just fine.  If the second request in that batch contains invalid credentials (to trick your authorization into believing it’s from a user with higher privileges for instance) for a request that could cause some damage (deleting important information or triggering certain tasks or whatever), then you can’t really do anything to prevent that.  Unless of course, you reject this approach and authenticate every single request.

As for the MySecurityException type, that’s up to you as well.  When you configure your Agatha service layer, you can set the SecurityExceptionType property to the type of exception that should be considered as a security exception.  When the Request Processor catches an exception of that type, it will set the ExceptionType property of the response to ExceptionType.Security so you can check for that specific situation in your client.

To configure Agatha to use your custom Request Processor, your configuration code would look like this:

            new ServiceLayerConfiguration(Assembly.GetExecutingAssembly(), typeof(MyProjectRequest).Assembly,

                new Agatha.Castle.Container(containerWrapper))

                {

                    RequestProcessorImplementation = typeof(MyProjectRequestProcessor),

                    SecurityExceptionType = typeof(MySecurityException)

                }

                .Initialize();

 

Another alternative is to create a base Request Handler for your project and to have each Request Handler inherit from it.  Something like this, for instance:

    public abstract class MyProjectRequestHandler<TRequest, TResponse> : RequestHandler<TRequest, TResponse>

        where TRequest : MyProjectRequest

    {

        public IAuthenticator Authenticator { get; set; }

 

        public override void BeforeHandle(TRequest request)

        {

            base.BeforeHandle(request);

 

            if (!Authenticator.AreValidCredentials(request.UserName, request.PasswordHash))

            {

                throw new MySecurityException();

            }

 

            Authorize(request);

        }

 

        protected virtual void Authorize(TRequest request) {}

    }

 

In case you’re wondering why i’m using Setter-injection here instead of Constructor-injection, read this.

I typically prefer the custom Request Handler approach for authentication.  In most applications that we write, authentication is not enough and we need custom authorization checks for many requests.  So i’m going to need a base Request Handler which introduces the virtual Authorize method anyway.  So i might as well do my authentication check right before it.

With the custom Request Handler approach, you probably still want to configure Agatha to use your custom security exception type:

            new ServiceLayerConfiguration(Assembly.GetExecutingAssembly(), typeof(MyProjectRequest).Assembly,

                new Agatha.Castle.Container(containerWrapper))

                {

                    SecurityExceptionType = typeof(MySecurityException)

                }

                .Initialize();

 

And then you just need to let your own Request Handlers inherit from your MyProjectRequestHandler.  Authentication will be performed for each request by default, and you can easily add specific authorization logic for every request. 

And those are pretty much the options you have to secure your Agatha Service Layer.   Oh, and be sure to only expose your Service Layer through SSL :)

Posted in agatha | 4 Comments »

Agatha Vs NServiceBus?

Posted by Davy Brion on January 26th, 2010

Ever since i open sourced Agatha, i’ve gotten questions from people who are wondering whether they should use Agatha or NServiceBus.  I’ve also gotten questions about things that people wanted to do with Agatha but that aren’t really supported.  And i’ve also noticed that people were coming to my site with search keywords like “agatha vs nservicebus”.  The thing is, they are hardly comparable.

Agatha is a Request/Response Service Layer framework.  It basically supports synchronous and asynchronous Request/Response style communication and tries to make it as easy as possible to write a service layer for that type of communication.  Apart from being easy to use, it also encourages a clean implementation of your service layer and a way to minimize the repetitiveness of cross-cutting concerns.  It also enables you to get better performance than with typical Remote Procedure Call or Remote Method Invocation style service layers because it will try to minimize roundtrips by batching requests and responses together.  In the next release, it will also offer a caching layer so certain requests (depending on how you set it up) don’t need to be processed and cached responses can simply be returned.  There’s also support for one-way requests (or fire-and-forget requests) but it has the same downsides as one-way requests with typical WCF services have. That’s pretty much all it does.  That’s probably all it’ll ever do.  In short, it’s just an upgrade over your typical WCF services.

NServiceBus on the other hand also does Request/Response, but that’s just one of the things it can do.  Again, Agatha is essentially an RPC or RMI framework whereas NServiceBus is built on top of one-way messaging technology.  This allows for much more possibilities when it comes to communicating between different applications or different parts or processes within the same application boundary.  A great overview of those possibilities can be found here.  Because it is based on messaging, there are a lot of benefits that you can get from NServiceBus that you’ll probably never get from Agatha.  For one, the ‘Store & Forward’ messaging model from NServiceBus might seem similar to Agatha’s one-way requests on first sight, but there are some very important differences.  If you send a fire-and-forget request with Agatha, and the service is currently down, then that request is essentially lost.  With NServiceBus, the message is stored in a message queue and it will be processed when the target of the fire-and-forget message comes up again.  From a reliability point of view, that’s obviously a tremendous improvement over what Agatha can offer you.  Another area where NServiceBus truly shines (IMO) is in its Publish/Subscribe implementation.  Some people have asked me if i’ll ever provide something like that in Agatha and the answer has always been ‘no’.   For one, it doesn’t fit into what Agatha tries to do and i don’t see the point in implementing it if a better implementation is available already in another project.   There’s plenty more interesting things in NServiceBus to deal with more advanced scenarios, which you’ll have to find out about on your own ;)

So which one is more suitable for you or your applications? As with every technology choice, it depends.  Agatha is great for most typical business applications.  If you need to communicate between one or more different clients (with different i don’t mean multiple instances but different types of clients like a web app, a silverlight client and/or a WPF client) and one service (you can obviously use it with more than one service as well if you want to) on an application server which encapsulates your business layer then it is a very attractive solution, as long as you don’t need the superior reliability that NServiceBus can offer you.  With superior reliability i particularly mean the ability to still process received messages once the service layer comes back up after having been unavailable.  In my experience, most business applications don’t really need that, since most of those applications are entirely unusable if the service they depend on is down.  In short, if all the possible downsides of using a WCF service layer are not an issue for your project, then Agatha will be a great fit.

If however, you need to maximize reliability, performance and general robustness of a critical enterprise application, then NServiceBus will definitely be a much better choice.  If you’re dealing with many distributed parts, NServiceBus will also make things much easier for you than Agatha (or any other WCF service layer for that matter) will.   And obviously, if you want to integrate multiple applications while reducing coupling between applications as much as possible, NServiceBus will also be a much better fit than Agatha.  With NServiceBus, you’d only need to share an assembly containing the types of the messages.  With Agatha, you either need to share an assembly with shared request/response types or use proxies for them and you would also have to know about the other applications since you’d need to access their services directly.  This can get quite ugly pretty fast.

And in some cases, you can just use both of them at the same time.  At work we have two projects that use Agatha for all of their internal communication within their own application boundary, yet they use NServiceBus to notify each other of certain events.  Neither of the applications knows about the existence of the other… the only thing they share is one assembly with some shared message types.  We’ve also started working on a new platform where each application in the platform will use Agatha for all of the communication within their own application boundary (since they’re all typical silverlight clients backed by a WCF service style applications) but they will use NServiceBus for every kind of communication that goes outside of the application boundary.

As with many things, it’s just a matter of choosing the right tool for the right job.  Hopefully, this post will help some of you make that decision should you need to make it in the future :)

Posted in agatha, nservicebus | 8 Comments »

Highly Recommended Book: Debug It!

Posted by Davy Brion on January 26th, 2010

I’m not the best debugger out there, but i usually manage to get to the bottom of things and sometimes i even enjoy chasing down a weird bug.  And while i actively try to avoid bugs as much as possible, i’m also always looking to learn more techniques or practices to efficiently find and fix bugs when they do occur.  So when i first heard about Paul Butcher’s Debug It, i immediately preordered it.  And now that i’ve read it, i’m very glad i did.

The book is divided in 3 parts.  The chapters of the first part explain in depth what kind of debugging strategy you’ll need.  Discussed topics include:

  • figuring out what you’re really looking for
  • tips and tricks to come up with a reliable reproduction of the bug and the value of having that reproduction
  • diagnosing the actual problem
  • coming up with a true fix
  • reflecting on why the bug ever got into the software
  • making sure that the bug can’t come back and that we learn from the mistake

For some of you, most of this stuff will just be common sense.  For a lot of developers though, this part alone should be considered required reading.  It’s a complete process of how to deal with bugs efficiently in less than 80 pages!  Think about that for a second: 80 pages that will improve your efficiency at your job and will reduce the amount of time you spend doing something you probably don’t like doing.  How could you resist?

The second part is pretty short (only 2 chapters) but pretty interesting as well.  It mostly deals with organizational patterns and practices that a development shop should take into account.  It covers things such as:

  • the importance of bug tracking
  • what makes a good bug report
  • effective communication with users and support staff
  • giving priority to bugs as soon as they’re discovered
  • the importance of pragmatic zero-tolerance for bugs
  • ways to get out of a Quality Hole

Not all developers will like the second part, but it definitely contains some valuable information for technical managers, or for developers who need to convince their technical managers ;)

The third part of the book deals with a lot of various strategies for a variety of specific situations.  While not everyone will get something out of every topic discussed in this part, odds are that quite a few of them will indeed be interesting for you.  You’ll find specific advice for quite a few special cases (performance, concurrency, backwards compatibility, third-party bugs, etc…).  You’ll also find the obligatory chapter on creating an ideal debugging environment with automated tests, a build system and continuous integration.  If you’re reading this blog, you’re hopefully already convinced of the values of such things so you might want to skip this chapter.  The final 2 chapters are again very interesting… They’ll show you how you can write software that will debug itself.  While not everyone will actually go out and do this, some ideas of that chapter should definitely be kept in mind by most of us.  The final chapter deals with some common (mostly organizational) anti-patterns for dealing with bugs.

All in all, there is just a lot of tremendously valuable information in this book.  And it’s only about 190 pages so it definitely won’t take you a long time to read it.  I’ve frequently been amazed at the inability of developers to efficiently debug issues when they occur.  And i’m not just talking about bad developers.  I’ve seen plenty of good or even great developers having trouble with debugging efficiently.  This book would definitely get them on the right track, with just a little bit effort.

Posted in Books | 3 Comments »

I Still Have Low Expectations For Visual Studio 2010

Posted by Davy Brion on January 25th, 2010

Last month i told you i had very low expectations for Visual Studio 2010 from a performance point of view.  Luckily, i was not alone as many people complained about it.  Microsoft has been working hard on the performance of VS2010 ever since.  Today i read a new post from Brian Harry about the results of their performance improvements.

Some quotes that make me cringe:

The performance is acceptable now and I would consider the product generally shippable…

Acceptable? One of the originally stated goals for Visual Studio 2010 was better performance over 2008.  At this point, it should be more than acceptable IMO!

I’ve been running the SLCTP3 for about 3.5 hours today and its been amazing. Previously I would have crashed at least 2 times and had insane perf issues.

I can only hope that it runs without crashing and insane performance issues for those of us who are using it 8 hours (or more) a day…

I’d say the performance is about equal or maybe slightly better in some scenarios than VS2008.

I find this very disappointing… again, it was supposed to be faster than VS2008

VS2008 still feels snappier when compared side-by-side on the same VM, but the performance doesn’t bother me in this build of VS2010.

I’m glad it doesn’t bother Brian, but i sure as hell would prefer that the new version is at least faster and snappier than the previous version

Build time is 10-15% longer for the same solution compared to 2008

Excuse me? Build time in 2008 is already ridiculously slow for large solutions… the fact that it has gotten slower on the same hardware is simply unacceptable

Compilation of WPF project is >500% slower on VS 2010 SLCTP 3

Wow… just wow

Intellisense pop-ups are slow to pop up

It’s not like we need those to be fast, right?

For those of you who think i’m making a big deal out of this, you might be right.  But i’m often working with large solutions and i frequently have multiple instances of VS running at the same time.  The performance of VS2008 is at times embarrassingly bad and to think that VS2010 is not going to improve this, and likely even make the situation worse is something that i can’t really be happy about. 

Can’t we just get a Visual Studio 2008 Service Pack with support for .NET 4.0 instead?

Posted in IDE | 25 Comments »

As A Movement, ALT.NET Has Been Dead For A While

Posted by Davy Brion on January 24th, 2010

Quite a few posts have been written lately on the state of the ALT.NET community, or movement or whatever else you want to consider or call it.  I’ve always thought of ALT.NET in 3 ways.

  1. it is a mindset
  2. it is a community
  3. there is a movement

The ALT.NET mindset was originally described perfectly by Dave Laribee:

  1. You’re the type of developer who uses what works while keeping an eye out for a better way.
  2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
  3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
  4. You know tools are great, but they only take you so far. It’s the principles and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principles (e.g. Resharper.)

This mindset still lives on, and will always stay alive. There will always be .NET developers that are continuously looking for better ways to create software.  We might not think there are enough of them, but they are still growing gradually.  Typical ALT.NET topics, practices and principles have become much more popular and more and more people are definitely still looking to learn about them.  I can’t think of a single reason why this would ever cease to happen.

As a community, ALT.NET hasn’t done a good job (IMO) of being accessible to new-comers.  I’ve complained about this in August 2008.  Nothing changed after that post, and nothing will change after this post either.  A lot of the people in the ALT.NET community are still too negative in expressing their views, or have even stopped trying altogether.  Some of them just attacked everyone who disagreed with them.  Things like that will obviously never, ever lead to adoption of your thoughts and ideas.  And after that, they’d complain that nobody was listening anyway and that they were tired of trying to discuss these things with people who didn’t believe in it yet. It also doesn’t help that quite a few people got involved purely for the sake of bettering themselves.  After all, the ALT.NET name was hot and being associated with it and getting involved with it was an easy way to improve your reputation, status and for some even their finances.

As a movement, we’ve failed as well.  Essentially, the ALT.NET movement is about education.  Teaching people the things we believe in.  Showing them that there are better ways to develop software than that what is more accepted in the Microsoft world.  In the early stages of the movement, there was a tremendous amount of interesting blog posts being written with exactly that purpose in mind.  Teaching people.  Showing them the benefits.  Explaining things to them.   After a while though, some of those bloggers didn’t quite put the same effort into it anymore.  A lot of them resorted to one-liners about why approach A is better than approach B and they weren’t really taking the time anymore to try to educate people.  The rise of Twitter certainly didn’t help either since you simply can’t teach this stuff to people through 140-character tweets.  You can’t really show them the benefit of whatever it is that you think is a good thing to do.  And since a lot of those bloggers are spending more of their time on Twitter than on working on their blogs nowadays, a lot of valuable knowledge and experience isn’t being spread as much anymore as it used to.  Now obviously, we can’t tell people how to spend their time so if those people prefer to spend time on Twitter instead of writing good posts that could help more people, that is their personal choice and nobody can blame them for that.   At the same time, they can’t really complain about the current state of ALT.NET as a movement and a community either.

But hey, the mindset still lives and will continue on living.  The best thing you can do is to share your knowledge and experience with as many people that want to hear it.  And trust me, there are quite a few people who want to hear it. 

Posted in ALT.NET, Opinions | 1 Comment »

Inversion Of Control Containers And Factories Aren’t Mutually Exclusive

Posted by Davy Brion on January 23rd, 2010

Julian Birch recently posted a reaction to my reaction to Uncle Bob’s IOC lunacy post.  Julian mistakenly thinks that i have a problem with using factories.  I definitely don’t have a problem with using factories.  I just have a problem with using them in the manner that Uncle Bob suggested in his post.  Jeffrey Palermo also recently posted an example of where he thinks using a factory is better than injecting dependencies.  I wanted to react to both those posts with a real-world example of where i prefer to use a factory and how i use an IOC container to do so.

As you probably know by now, i’m a big proponent of using IOC containers.  I’ve never stated that they should be used in every single application, but using one certainly pays off in most applications, especially as complexity increases gradually.  When you use an IOC container, you’ll have much less need for factories.   There are however two situations where i certainly prefer to use a factory.  And that is when:

  1. a certain dependency might not always be used by a class and that dependency is expensive to create
  2. i might need multiple instances of a dependency during the lifetime of a class

A good example of both those situations is when using Agatha’s AsyncRequestDispatcher class from a Silverlight user control.  Creating an AsyncRequestDispatcher is expensive because it in turn requires an instance of the AsyncRequestProcessorProxy class.  The AsyncRequestProcessorProxy class inherits from WCF’s ClientBase class, and those types are relatively expensive to create.   And due to the asynchronous nature of those service calls, you can never deterministically dispose of a AsyncRequestDispatcher instance with absolute certainty that it won’t be disposed before the response of the service call is returned from the service.  Because of that, the AsyncRequestDispatcher class was designed to dispose of itself automatically once the response is returned.  This effectively means that you’ll need a new instance of AsyncRequestDispatcher whenever you need to make an asynchronous call to an Agatha service. 

For most user controls, it obviously doesn’t make sense to inject one instance of the AsyncRequestDispatcher into the user control because you often need to make multiple service calls depending on user interactions or other events.   A good way to deal with this is obviously to ask a factory to create the AsyncRequestDispatcher whenever you need one.   Which is why Agatha offers the AsyncRequestDispatcherFactory class, which looks like this:

    public interface IAsyncRequestDispatcherFactory

    {

        IAsyncRequestDispatcher CreateAsyncRequestDispatcher();

    }

 

    public class AsyncRequestDispatcherFactory : IAsyncRequestDispatcherFactory

    {

        public IAsyncRequestDispatcher CreateAsyncRequestDispatcher()

        {

            return IoC.Container.Resolve<IAsyncRequestDispatcher>();

        }

    }

 

Now, some of you are probably thinking: what is the difference between this and Uncle Bob’s example?  Well, unlike Uncle Bob’s example this factory is not responsible for registering the required components to create an AsyncRequestDispatcher with the container.  It merely resolves an instance and returns it.  And yes, it uses the container to do so.   I could actually just new up an AsyncRequestDispatcher myself but then the factory would also have to know about its dependencies and make sure it’d be able to create them.  If those dependencies have dependencies of their own, i’m back to dealing with dependencies manually which is exactly what i’m trying to avoid throughout my codebase.

I can’t come up with a single reason why this would be wrong, but some of you probably will so feel free to point out those reasons :)

The benefit of this factory is that it enables me to delay the instantiation of an expensive dependency, and it also enables me to get more than one instance if i need to during the lifetime of a single object.  At the same time, it doesn’t have any of the downsides of Uncle Bob’s approach.  Also, this approach is something that you won’t need to resort to throughout your codebase, it’s more for edge-cases.

Now, how do we use this factory?  Instead of new’ing the factory manually like Jeffrey does in his example, the factory is registered with the IOC container and i simply inject the factory into the class that needs to use it.  This still enables me to change implementations of both the factory as well as the instances the factory needs to create.  And it also makes it easy to stub or mock the factory during tests.  I get all of the benefits from using Dependency Injection and an IOC container, and i have yet to notice any downsides to this approach.  But again, i only use this approach in the 2 situations i mentioned in the beginning of this post.  In most cases, you really don’t need factories anymore.  And when you do, just leverage your IOC container to make the factory as simple and dumb as possible.

Posted in Dependency Injection, Inversion Of Control | 10 Comments »