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

(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

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

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

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

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:

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

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

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

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:

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:

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

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:

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:

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:

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:

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:

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:

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:

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:

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

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

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.

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?

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. 

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:

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.

Matt Hidinger pretty much nailed it in the comments:

Well it appears to have something to do with Efferent Coupling at the Type Level (http://www.ndepend.com/Metrics.aspx#TypeCe) — simply meaning the number of types that a class directly depends on.

So it appears that you’re aiming for less than 20 direct type dependencies and highlighting classes with more than 35 deps.

I imagine this is a view of a particular namespace, but I’m not sure on that.

I mentioned in the comments that i’d write more about it soon, so here it is.  That screenshot comes from a product (called Glance) that we initially developed for internal use, because a lot of the people at our company are well, addicted to data.  I guess we got tired of looking at numbers at some point so we decided to spruce things up a little.  Let’s walk through an example, shall we?

In my case, i’m interested in code metrics.  Well, some of them at least.  The following picture shows a high level view on the status (or health) of some code metrics for a particular project:

Their names aren’t being shown correctly yet, but the metrics that are shown are the following: Association Between Classes, Cyclomatic Complexity, Depth Of Inheritance, Effererent Coupling and Number Of Lines Of Code.  Notice their colors.  They can range from green (which is good) to red (which is bad).  Again, i’m looking at these metrics on a project level so the colors that are shown here represent the average status of each specific metric for the entire project. In this particular image, you can see that the Cyclomatic Complexity color is starting to turn a bit yellowish.  When you hover over the metric, you get to see the following:

As the description of this particular metric says, the goal is to get a value of 0.2 which would result in a status of +1.  0.4 would be neutral so that’s 0 and anything greater than 0.6 would be –1.  The color ranges from red to green based on the status (-1 = red, +1 = green). For this particular project, the average value of all types is 0.5649.  This is sort of confusing, because you’d think that it should be close to red but the average status is 0.3587 and that is what the color is based on.  Now, if the average value is close to red yet the average status is green, it means that there are probably some classes that have a very high score (for this metric, that’s obviously very bad) and they have a heavy influence on the average.  The average status however, is not impacted in this case.  At this point, we’re still not quite sure whether the color should be based on the average status, or the average value but that’s a minor detail which isn’t important for this post

Anyway, when i click on the metric i get the following screen:

This shows a circle for each top-level namespace in the project.  Each circle is colored based on the average status of the types within that namespace.  As you can see, some of them are green, and some are yellow.  What you don’t see in this screenshot is that those circles are all floating around the center circle (which represents the parent level of this view) in a 3D view.  I rotated the view to make it as clear as possible where the circles are located.  When you hover over one of the circles, you’ll again see the value and the status of the namespace that is represented by that circle.

Obviously, you can do this with each circle in the view:

This namespace isn’t even close to green, so we really ought to check out what’s going on.  When i click on it, i drill-down into the data again, and i get to see the namespaces and classes that are in the EMS.Silverlight.Common namespace.

The EMS.Silverlight.Common.Controls.Tooltip namespace seems to be in the worst shape, so i click on it again.

Oops.  We have two classes that are pretty red.  I guess we’ve identified a good candidate for refactoring

To wrap up the screenshot bonanza i’ve got going on here, here’s a picture of the Lines Of Code metric in a large web application.  It clearly shows that there are 4 parts that we really need to look at for large classes, while the rest of it doesn’t really warrant any attention at this time.

Now, as cool as those screenshots are (at least, i certainly think so) they aren’t really the coolest part of all this.  First of all, you might be wondering “who on earth goes to all this trouble to develop a tool to look at code metrics like this?”.  Well, as a company we are kinda “out there” but we’re definitely not that far “out there”.  It would be ridiculous to develop something like this purely to look at code metrics.

Instead, we can use this for pretty much any kind of data.  The tool doesn’t even know it’s showing code metrics.  It is just showing data from a data warehouse where we’ve defined dimensions and hierarchies, like Assembly -> Namespace -> Type in the above example, to define the context for some Key Performance Indicators (KPI’s).  The actual code metrics come from nightly NDepend builds that we run for each of our projects.  The data is imported in our warehouse and then we can look at it with this tool due to the KPI’s that we’ve defined.

So basically, pretty much everything is possible as long as you can get the data in your warehouse and define some KPI’s for that data.  I only showed you code metrics in this post, but we use it for a lot more than that.   Some examples include Holiday Acceptance (which manager is the fastest or slowest in approving holidays), Aging Invoices (which customers are always late with payments), Project Revenue (which projects do we make the most money on), Issues (who fixes bugs the fastest? who creates the most or the fewest bugs?), etc…

And you really can get all of that data from everywhere… in our case, we get a lot of data from our EMS system and obviously from Genesis as well.  We also get data from NDepend (as you’ve seen in this post), from TeamCity (anything build-related), Subversion, whatever you want basically.  Obviously, you’re not limited to looking at the data in the ‘circle view’.  You can get traditional graphs as well.  For instance:

This is global view of all requested changes for all of our projects (both commercial projects for customers as our internal applications).

The following picture shows the average lead time for issues that we had in 2009 based on the type of issue:

Finally, an overview of the time we spend on global task types:

Note that we do very little up-front design, and our continuous/evolutionary design is obviously a part of our regular Development tasks.  And i’m sure you can understand that this kind of data is very helpful when we need to make estimations for new projects.  We have a very good view on the amount of overhead that we typically have for project management, for instance.

One of the biggest benefits (IMO anyway) is that with the way the data is visualized (especially with the circle view), everyone can easily look at the data and see where more attention is required.  I don’t know a lot about finances but i know that red circles are bad.  My boss doesn’t know anything about good code, but even he now has a pretty good view on the quality of our code and he actually likes coming up to some of our guys to say “wow, class X in your project really could use some attention huh?”.

And today i heard that one of our customers who’s already using this is apparently learning quite a lot about their business because of this tool.  They also put a lot of data in their warehouse and they are learning in advance where they need to improve their business processes before those things really become a problem because of what Glance is showing them.  The process is actually pretty simple. If it’s green, you don’t really need to spend time on it.  If it’s turning yellow or red, you probably want to investigate things and try to improve the situation before it really starts causing problems.  In the future, we’re also going to add automated notifications to it.  So once things start going bad, you’ll be notified of them automagically.

In short, you can find out what’s really going on in your organization and focus your efforts on where it truly makes sense to do so.  And that, my friends, is what it’s all about.

There are two major problems that i have with his post.  The first is this one:

I like this because now all the Guice is in one well understood place. I don’t have Guice all over my application. Rather, I’ve got factories that contain the Guice. Guicey factories that keep the Guice from being smeared all through my application.

What’s more, if I wanted to replace Guice with some other DI framework, I know exactly what classes would need to change, and how to change them. So I’ve kept Guice uncoupled from my application.

For those of you who don’t know, Guice is an IOC container from Google.  Uncle Bob doesn’t want references of an IOC container spread out throughout his application, but he doesn’t seem to mind coupling his factories with his IOC container for some reason.  He seems to think that he can actually switch to a different container more easily because of this, because he would only have to modify his factories.

Here’s the deal.  If you have more than a handful of references to your IOC container in your code (apart from the registration obviously), then you really don’t know what using an IOC container is all about.  Yes, i know Uncle Bob is supposed to be a legend.  Yes, i realize that i’m saying that a legend in the OO world doesn’t seem to grasp some of the most important concepts of using an IOC container.  Can you really disagree with that after reading his post?

His whole idea of making it easier to switch to another container with his approach is ludicrous.  He would have to modify every single factory that he uses, and in his trivial non-real world examples that wouldn’t be a lot to do but out here in the real world, we’d end up with a boatload of those factories and they would all have to be modified.  Conversely, if you’re using an IOC container in the way it is meant to be used, you’d only have to change your registration code and the one or two places where you resolve something manually through the container.  And that’s it.  Yes, you typically only need one or two places where you use the container directly.  Well, unless you’re Uncle Bob of course.

My other problem with his post is with the sample that he uses.  It really is a very simplistic example and the approach he outlines simply does not scale when you’re dealing with large, real-world codebases.  His approach might work for the size of the examples in his books, or for the code of Fitnesse, but if i were to apply his recommended approach for some of the systems that we’re working on, it would lead to a terrible mess very quickly.  Not exactly what i’d have in mind when thinking of Clean Code.

The one thing i do like about this post? Well, there are quite a few people who follow Uncle Bob blindly and can’t say a single bad thing about his thoughts/ideas/approaches.  I know quite a few of them make extensive use of IOC containers and some of them are even involved in the development of these containers.  Hopefully, Uncle Bob’s post will finally convince these people that blindly following anyone is simply never a good idea and that you have to keep a critical mindset for everything that you read, no matter who wrote it.

There are probably a few answers to that question, but one reason that can’t really be disputed is that a lot of the tooling that Microsoft offers to developers simply encourage this kind of stuff.  Let’s go over a little example.

I wanted to see what some of Microsoft’s recommended tools would create for me if i wanted to create a Silverlight application which uses a database.  Obviously, a Silverlight application can’t use a database directly so the application will need to communicate with a service.  The service obviously does have access to the database.  RIA Services is a solution that Microsoft seems to be pushing a lot for this specific scenario so i figured i’d give this a shot.

I created a RIA Services Class Library project in my solution and tried to add a ‘Domain Service Class’ (as the RIA Services templates call it) to the project.  If you already have a DataContext or an ObjectContext defined within the same assembly, you can immediately select the database tables that you want to expose.   So i canceled the dialog and quickly added an ADO.NET Entity Data Model to the solution for which i selected my Chinook database.  I tried to create a ‘Domain Service Class’ again and got the following window:

Well, now that sure is easy isn’t it? I can immediately select all my ‘Entities’ and i can even check whether i want to be able to edit them through the service, and apparently i can also generate associated classes for metadata (which would be useful for validation according to the tooltip).  I checked the Album table, and left the ‘Enable editing’ option unchecked.  This created a service with the following code:

I don’t know about you, but i love those TODO statements.  After all, you really do might want to consider constraining the resultset that could be returned by the GetAlbum method.   Who knows, perhaps you have certain use cases where you don’t want all of the ‘entities’ in the Album table to be returned by your ‘domain service’.  Hopefully, this service will be used by developers who are smart enough to realize that they should modify this method, instead of using client-side LINQ statements to filter the returned Album ‘entities’ as i’m sure we’ve all seen in too many Microsoft demo’s already.

It gets better if you recreate the service and check the ‘Enable editing’ option.  Now you’re ‘domain service’ will also contain the following methods:

Man, this sure is easy, isn’t it? I now have a service that offers me full CRUD access to the Album table in my database.  If i wanted to, i could now start implementing a screen in my Silverlight application which allows my users to list the albums, edit them, delete them, create new ones, etc… and i wouldn’t even have to change anything in my ‘service layer’.   The problem is that too many developers actually will do exactly that.   After all, why should they doubt any code that was generated by a tool which comes from Microsoft?  If the tool can generate this, then certainly some people actually want you to use it like this, no?  If not, why would it even generate code like this?

I’m sure this kind of stuff gets a lot of ooh’s and aah’s during the product demo’s at Microsoft events, but other than that, what good does this really bring?  Is this really the way you want people to develop their services?  Do you really want developers to pretty much expose the database as-is to remote clients?  And those TODO statements simply won’t cut it, you know that all too well.  I simply don’t think there’s any good reason to generate code like this because a lot of people will simply take it as is and use it like that directly from their client code.  Oh sure, most of them will hook up the authentication but i’m willing to bet that very few people will actually put real business logic in there.  Why would they?  The message that a lot of people will get from the resulting code is that a service is merely a way to provide CRUD for your database tables.  What’s business logic to these people?  Right, the stuff they’ll implement in their presentation layer because this service doesn’t really encourage people to consider implementing it there.

The only benefit that i can see from using RIA services is that you don’t really have to deal with your service contracts, and your operation contracts or any of that stuff.   No, we won’t be doing any of that.  We simply use a [EnableClientAccess] attribute and we’re done!  I don’t really consider that a benefit, though i can certainly understand why people would not want to deal with the pain of classic WCF services.  RIA Services is simply a solution to the wrong problem.

I haven’t looked at ADO.NET Data Services (which will be renamed to WCF Data Services in .NET 4.0) yet, but i suppose it’ll be more of the same: something that makes it incredibly easy to create services directly on top of your database data.

Seriously though: who on earth actually wants that?

I have no doubt that there are some people out there that are using RIA Services in a responsible manner and are sticking by responsible architectural guidelines.  I also have no doubt that those people are ignoring most of the tooling that is offered by Microsoft around it.  So really, why not get rid of this kind of tooling, and spend the effort that normally goes into those tools (or anything else which encourages bad practices for that matter) on providing actual guidance to the developers of your platform?  The last thing we need are more developers who think that this is ‘ok’, or projects that have been delivered based on this kind of ‘architecture’, or customers that are turned off by .NET projects because “they all have maintenance problems”. 

As you can see, the DoSomething method does something important, so you as a developer should consider its behavior important as well.   In some cases, you might want to add something extra to this behavior in a derived class.  Some developers would do that like this:

When they compile this, they’ll get the following warning:

warning CS0108: ‘HidingMethods.MyDerivedClass.DoSomething()’ hides inherited member ‘HidingMethods.MyClass.DoSomething()’. Use the new keyword if hiding was intended.

When this occurs, either one of 4 things can happen:

1. The developer doesn’t bother to read compiler warnings (an offense worthy of a bitchslap) and is not aware of a possible problem
2. The developer sees the warning and just adds the ‘new’ keyword to the method.
3. The developer reads the documentation to figure what this really means, and hopefully realizes his mistake.  If he does, he combines this option with option 4.  If he doesn’t, he goes the option 2 route.
4. The developer realizes his mistake and either makes the base method virtual and adds the override keyword to the method in the derived class, or when that’s not possible, either renames the method or thinks of a different approach.

If you’re unlucky, you either end up with no modification or the method will now look like this:

Great, no more compiler warning! All is well in the world now, right?

Err… not really.

The DoSomething method of MyDerivedClass actually hides the original DoSomething method. 

The following code will always produce the expected behavior:

That is, when the DoSomething method of an instance of MyClass is called, it will obviously execute the original DoSomething method.  And if the DoSomething method of an instance of MyDerivedClass class is called through a reference of MyDerivedClass then it will call the ‘new’ DoSomething method.

The following code however, would not produce the expected behavior:

In this example, the DoSomething method is always called through a reference of MyClass.  When the DoIt method receives an instance of MyClass, the original DoSomething method will obviously be executed.  What some (many?) people unfortunately aren’t aware of is that when an instance of MyDerivedClass is passed into the DoIt method, the ‘new’ DoSomething method will not be executed but only the original one will be executed.  The reason is because methods that hide inherited members can only be called through references of the type, or derived types of that, that hides the inherited method.  Doesn’t really sound like a fun situation to debug, right?

So anyways, back to my original question: is there any valid reason why you would want to do this? Or better yet, can you share a situation where you had to resort to hiding an inherited member and if so, are you happy with the solution or did you consider it a hack?  And are you aware that it is essentially a bug waiting to happen?

So far, i have never actually seen a valid reason for doing this.  The only reason i’ve seen so far for occurrences of hidden members was because the developers that used it simply didn’t know any better.  In some cases, either me or someone else wasted debugging time on this when a piece of code that used a reference of a base class suddenly didn’t do what was expected when it was passed an instance of a derived class which hid the original method.  

I have read of only one valid reason to do this, and that is if a (either virtual or non-virtual) method with the same signature is introduced outside of your control in a base class that you can’t modify (like say, a class in the .NET framework or some other 3rd party assembly that you depend on) and you want to get rid of the compiler error that you got when recompiling against the newer version of the assembly.  In that case, it does make sense though i’d still say it’s going to be a future source of confusion sooner or later, and quite likely lead to a future bug as well.  In that situation, i’d much rather rename the member in my class.  Even if it means that consumers of my code will be forced to deal with the breaking change.  After all, a simple rename will always be less work than having to debug an issue because of a hidden member.

That’s what happened when i ran the RunMeFirst.bat file that comes with the NServiceBus download. 

What if i actually need msmq_ADIntegrated?

Every year we work with interns from the school that i and many of my coworkers come from. We’ve been extremely lucky with the interns we’ve gotten from that school so far, and many of our best developers actually come from that school. We basically expect to get really good people from them and when they do good during their internship, they usually get offered a job and most of them accept it. Last year, we had 5 interns from that school. Two of them are now working for us. There was another guy who i would’ve loved to have on our staff. This kid was 21 (maybe 22, not sure) years old, and i quickly noticed that he was exceptionally talented. I don’t know about you guys, but i rarely get to talk with anyone who really makes a great impression on me (on a technical level) who i’m not already working with or who i’ve haven’t worked with in the past. I was very impressed with this kid even before i saw his code. He knew a lot of stuff that most of us only learn after a while, and he seemed to be a very all-round talent.

I was very curious to see how he would complete his internship and i was already hoping that he would be working for us once he graduated. He took on a leadership role of his team (which admittedly, consisted only of interns) but he really managed them pretty well. He took care of most of the technical challenges, and he made sure the others were productive in their tasks. If he wasn’t sure of certain technical issues, he didn’t mind asking for advice or help. The skills and the approaches he demonstrated at his age were truly exceptional in my opinion. No matter how good you think you are right now, think back about how you were when you were 21, 22 years old. I thought i was pretty good back then, but i didn’t even know a fraction of what i know right now. And i don’t just mean on a technical level, but more about how businesses work, how you need to deal with people and situations, stuff like that. Most people simply don’t have a clue about how to deal with that at that age.

This kid knew, though. Not everything obviously, but at least a lot more than most people would at that age. He’s smart, he’s talented and he knows how to apply his skills. The one thing he doesn’t know yet, is how to deal with previous mistakes. And that is something you only learn once you’ve been working in a professional environment for a year or two, and if you’re lucky enough that people will challenge you and confront you with your mistakes. He may not have liked it, but i once caught him breaking the build and i told him he needed to fix it. He said it was a problem with subversion and that something must’ve gone wrong with the commit in question. I showed him that it was impossible that it could’ve been due to a problem with subversion and that he simply made a mistake in his commit. And while he probably still won’t admit it, he knew that i was right and that he was wrong. Now, there’s nothing wrong with a situation like that per se, but it was clear that he wasn’t used to a situation like that.

Think about it. You’re gifted. You’ve got a lot of talent. You’re pretty much better than anyone you’ve ever had to deal with at school. But the thing is, true improvement comes from learning from your mistakes, and you need to be in a situation where people aren’t afraid or too intimidated by your skills to be able to tell you when you’re wrong. If you don’t get confronted with your own mistakes, you are going to miss out on a lot of opportunities to improve yourself.

This guy made it very clear from the beginning that he wanted to pursue another degree after he graduated. And he’s currently doing that. The thing is, with the skills that he has, and the ability to convince other people of his skills, combined with the extra degree that i have no doubt he’ll earn this year, it’s very likely that he is going to end up with some large company in a very comfortable position. The thing that worries me though, is that a lot of people in those kind of companies aren’t very honest with their employees. Especially the ones they consider to be ‘high-potentials’. I doubt that he’s going to be around the kind of people who are going to be honest with him when he makes mistakes (and he surely will make them, as everyone does). And no matter how good you are, no matter how well you learn from your own mistakes, a very large part of self-improvement comes from being confronted with your mistakes by others.

So finally, we get to the ‘advice’ part of the post. To him specifically, and anyone else who recognizes himself (or herself) in a story like this i would advise the following:

• Do not automatically assume that a fancy position at a large company is the best situation for you. For most of these companies, you’re only valuable as long as you’re willing to play along with their game. It’s their game, their rules. You either play along, or you fold after a while, and believe me when i tell you that it is going to end up bothering the hell out of you.
• Learn to appreciate criticism. If you handle it right, you’re only going to end up better from it and you will truly learn from it.
• Status or position doesn’t mean anything if you suddenly realize you’re surrounded by idiots.
• If you don’t really need the extra money you can make while working for people who truly couldn’t care less about you personally, you certainly don’t need to subject yourself to all of the crap that will come with it.

You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

First of all, i don’t really get what this person was trying to achieve by notifying me of this. What am i going to do about it? Ask them to add a notice? Should i even care about it? I don’t, actually. If anything, i’m glad they’re using it and i just hope that it works for them and that they don’t run into any issues with it. If i didn’t want people using it, i shouldn’t have posted it. And as for adding a notice… that would be nice, but it’s not going to make any difference for me whether they do or don’t.

I think it’s different when you release code as an open source project. Then i obviously do want people to respect the license, but for blog code i don’t really care what people do with it. I did mention a license in the original post, but that’s pretty much only because some people don’t want to use it if there is no license mentioned. Which is correct, theoretically. But the vast majority of code that i list on this blog never has a mention of a specific license. It’s just too much of a bother IMO, and there isn’t anything that i can realistically do about it if people use it without respecting the license anyway.

So for future reference: feel free to do whatever you want with any code that i post on this blog, unless of course that code comes from an open source project. Would it be legal? No. Am i going to do something about it? No.

I actually had to think about how i could do this, but it turned out to be very simple.  The trick is basically to retrieve the MethodInfo of the method you’re interested in, and then check the declaring type of that method.  If the method has been overridden, the declaring type will equal the type of the class you’re checking.  If it hasn’t been overridden, the declaring type will be that of one of the base classes:

Not sure if there’s a better way to do this (if so, please share) but for now, this is good enough for me.

Is it really that much more expensive though? I ran a little experiment and i’d like to share the results with you.

Suppose you have the following 2 classes:

As you can see, there is no difference between the IncreaseLong and VirtualIncreaseLong methods, except that the latter is virtual and the former is a regular instance method.  According to many people, calling VirtualIncreaseLong instead of IncreaseLong will be more expensive.  I also have a derived class which overrides the VirtualIncreaseLong method with a slightly different implementation.

If we call these methods a bunch of times (like 1000000000 times), we should notice quite a difference according to many people.

I wrote the following test code which calls these methods a bunch of times, times it, and outputs the results.

The output of running this code might surprise you.  On my machine, i got the following results when the code was compiled in debug mode:

The difference between calling the regular instance method and the virtual method is quite small.  I’d even say it’s negligible.

When compiling in release mode, i got the following output:

I ran the test a bunch of times, and there was no consistent observable performance penalty when calling the virtual methods.  In fact, the virtual methods often performed faster than the regular instance methods and in most cases were equally fast.  I’m not claiming that virtual methods are faster than regular instance methods, but if there really was an extra real-world performance cost associated with virtual methods, it surely should be observable with this test code, no?

Obviously, this test isn’t scientific in any way.  But still, i think it does show that the so called performance cost associated with virtual methods is highly overrated.  There definitely will be cases where virtual methods are more expensive than regular instance methods, but i’m willing to bet that those cases are rare and that the vast majority of .NET developers will never be negatively impacted by it. 

Side note: have you ever noticed that most people who recommend to avoid virtual methods due to their performance cost never put the same emphasis on avoiding the cost of say, frequent remote operations?  Which is odd, since i wouldn’t be surprised if that would be the most common reason for performance problems with .NET applications.  Then again, that’s what you get when the biggest company pushing a platform advocates meaningless performance improvements while at the same time pushing bad architectural decisions/guidelines on the world because the resulting code is supposedly easier to write, use and maintain.

You can download the example code here so you can run the test yourself. 

Been there, done that, but never had the courage to post it.

That got me thinking.  What exactly is courageous about being honest about a mistake you made?  I mean, everybody makes mistakes and nobody is an exception to that.  Why do so many people try to hide this fact?

I used to work at a large financial institution where a lot of the people weren’t very honest about mistakes they made.  When things went wrong, a lot of them came up with excuses or denied outright that they had made a mistake and blamed it one someone else or on some other event.  That’s one of the worst things you can do if you ask me.  For one, it reduces your credibility and people will be less likely to trust whatever it is you say once they realize that you’re not entirely honest about such things.

One of the biggest mistakes that i made there led to learning one of my most cherished lessons.  I once accidentally truncated 4 large tables in a production database.  It was very early in the morning and parts of my brain must’ve still been sleeping.  I knew that the database operations guys were going to spend a lot of time on trying to fix things, and that it would be a very unpleasant situation for me.  When i called them, i just told them outright that i had made a really stupid mistake and that i needed their help.  It was pretty obvious that they weren’t used to someone actually telling them that and to my surprise, they were very cool about it.  They restored the 4 tables rather quickly and the whole situation was resolved without too many problems.  I told my superior about what had happened and that it was my own stupid fault that the application was down for a few hours.  He too took that rather well.  From that point on, i’ve made it a habit to just be entirely honest about every mistake or screw up that i’d make. 

For one, why on earth should i worry about what people will think of me because i made a stupid mistake?  Like i said, everyone makes mistakes and as long as you don’t make too many of them too frequently, there is nothing wrong with it.  And anyone who will think differently of you because of it is really just a hypocrite.  In fact, most people will respect you more if you are just honest and open about it.

As for writing posts about them… there are a few reasons why i do that.  First of all, by writing about them you are more likely to remember the mistake and you’ll hopefully won’t make it again.  Secondly, it’s typically an interesting opportunity for others to learn from as well.  Last but not least, by posting honestly about them i can hopefully show people that there really isn’t anything wrong with being honest about it and who knows, maybe even encourage them to do the same in the future when it happens to them.

But is it courageous? I don’t think so… If a certain action doesn’t justify any fear, then there’s no reason to consider doing so courageous either.

Oh, and if you want to read up on more of my mistakes, check out the following posts:

• My 2 most cherished mistakes
• How a simple foreach statement can waste an afternoon
• Do not dispose in the prerender event
• The importance of releasing your components through Windsor

Come to think of it, there should be plenty more of those… guess i gotta start posting about them more often