Recently Ilya Ryzhenkov posted a thread on the ReSharper blog. The article was about how R# 4.0 gives you a suggestion to use implicitly typed locals.

I've been running R# 4.0 nightly builds for a few weeks now and I've noticed these little buggers popping up all over the place.

Here's what it looks like:

Usually, I nearly agree with most of everything the R# team posts and even though sometimes I may disagree with something, I'll find the edge case where it does apply, so we're at a 99% agreement rate with them! Hell, you can't lie about it, R# seriously improves your productivity and it only keeps getting better.

Unfortunately, this is the one time I'm going to fully disagree with this post and actually the suggestion in R# - which is why I have disabled it. You can disable it  by going to the R# options:

Why I Disagree

The post stated that "It induces better naming for local variables". I don't know about that. I can still call an apple an orange and call a orange a banana I want. Nothing forces me to do anything. The only thing I know at that point is that it's still an anonymous type. A name is that, just a name. Nothing forces developer x to write a good variable name. I still see Junior developers using wrong variable names. The only thing that's going to help here is a good code review process.

The post then goes into to say that it "It induces a better API". Again, I don't agree. How can this induce a better API? I feel that letting the compiler choose which types it is returning has its validity in certain cases, but not inside of your entire system. It brings back the horror days of VB's "Variant" (and yes, I'm aware that var is not Variant and I know the differences - but have you seen an old system where EVERYTHING was a variant? Oh my jeebus, save me now). Just because I'm letting the compiler do the work doesn't mean that I should have "good variable names" to help me distinguish what I'm working with.

This the one that sent me over the top... "It removes code noise". *insert sound of game show buzzer* Yeah... um... I'd have to say that's complete non-sense (in my opinion). Over use of the var keyword is going to add code noise and is definitely a smell to me. If I open up a class and see everything as "var" type, I'm going to cringe. The readability of this code has diminished to a point where its now costing me more money to maintain and read the code than it is if I were to use a strongly typed variables when I could. Even the MSDN states:

Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types. [Source]

The last one is almost not worth putting into the post... "it doesn't require a using directive". Wait a minute... I bought ReSharper so I could be more productive... hitting ALT + ENTER to add the directive isn't a bad thing. Who cares if another directive is up there, that's what its used for, to tell the compiler what blocks of code look into during compilation.

Conclusion

This is not a bash on the ReSharper guys, not at all, but an explanation of why I disagree completely with this post. Heck, I agree with most everything on that blog (most of the time) and I'll never speak up about it. I'm a huge ReSharper fan and I will continue to use it and proclaim its greatness, but while reading this post I noticed a smell immediately. While using var has its uses, I think it can be abused.

The saying goes... "When all you have is a hammer, everything looks like a nail."  Lets not use var as our hammer. Its a special tool for special cases. We don't use ice axes for steak knives do we (even though that would be very manly and barbaric - and hell, kind of fun), so we shouldn't use var for unintended uses.

Having worked on quite a few teams where I've been the lead responsible for helping implement TDD or been an Agile Coach - I've seen a group of habits develop when teams first start utilizing TDD. These are ...

1. No test isolation

All functionality that is being tested is in one test. Tests are heavily over specified.

How to fix: Spend some time pairing with the developers that are having the issue. Help explain why we want to break tests apart into smaller units, aka: "UNIT" tests. Let them know that we do not want to test the entire class in one unit test. Just because it can be done doesn't mean it should be done. Ya know, I COULD drive into oncoming traffic, but its just not a good idea. :)

2. Failure to recognize the TDD Mantra 

Most  new TDD'rs will go from Red to Green to - I'm done! Nope. I'm sorry guys, we have one more in that list - Refactor. Let's say it together.  Red/Green/ReFactor, Red/Green/ReFactor :)

How To Fix: Help the developers realize that we want to refactor for a reason. We have a passing test, we know what to expect from our results. Now lets clean up our code, maybe introduce some interfaces, change some variable names, introduce some fields, extract some methods, etc. Doing this allows us to clean up the code as well as have the confidence that our changes did not muck up the expected result. Run the unit tests after you refactor. If it breaks, oops, lets go figure out WHY it broke. We caught the error early, its a lot cheaper now. :)

3. The previous lends itself to Insufficient Test Coverage/TDD is my new Debugger

The developers usually will do enough to get the test passing and then move onto the next task. They think of TDD as a new debugger.

How To Fix: Sit down with the developers that have this issue and explain: Just because we can now unit test a method/object and step through it with a debugger doesn't mean that this is the new debugger.  That's not the point. Just because the test passes doesn't mean we're done. Just because your method passes if you pass a valid object into it doesn't mean that its fully tested. What happens if I pass a null object into it? What happens if I pass a new'd up object with nothing instantiated? Have those instances been tested? Have we tested that our objects are interacting as we expect them to? Do we know if the Logger got called? How do we know if we didn't test it?  That its the classic question: How do we know it works, if we don't have a test to prove it?

4. No concept of separation of concerns or IoC/dependency injection.

This is not a big deal and I expect it of most new TDD converts. Usually while learning TDD the first few tests do not need DI/IoC, but this is something that will help in the future and will need to be understood to really grasp. This really comes into play when we start separating our concerns and breaking dependencies between objects. The refactoring that takes place here can really get deep into DI/IoC sometimes.

How To Fix: Give them a great intro into interfaces and how they're used. Show them great articles on DI/IoC written by Martin Fowler, Jeremy D. Miller, Ayende, and have them join certain mailing lists such as altdotnet to join in/read the discussions. On that list alone, DI/IoC discussions occur on a daily basis.

5. TDD Complaints

I've seen complaints such as:

1. It takes too long to write the tests
2. I write more test code than real code.
3. The tests are harder to write than the real code.
4. How is this going to help me get my project done? I can just hit F5 and test it and I can tell if it works or not with my own eyes.
5. Who cares if it passes a unit test, I'm the only person who works on this project.

How To Fix: This is one of those habits I've seen in every place I've coached. These are classic examples of someone who hasn't "seen the light" of TDD yet. In my experience, the easiest way to help them see the light is to pair with with them while writing unit tests. They will instantly see why the unit tests help them and the team. Every single time I do this I help the TDD newcomer realize that by writing this test they've exposed X bugs that they didn't think about before. It usually goes like this: "Ok, that test passes, what would happen if an empty string was passed into this? Would the DB accept an empty string?" Them: "Oh... good point, I didn't think of that." Instantly lights start turning on. Another thing that works great to help developers see the light is to ensure that you're utilizing Continuous Integration such as CCNET, or TeamCity. Have them create a unit test for a section of code. Check it in. Watch it build and watch unit tests pass. . Then have them change the code (the code which is under test) and ensure it returns a different result. Maybe it returned a user's name, such as "bob", now have it return the users name with some characters appended to the end of it, such as "bob123". Have them check it in, watch the build fail because the unit test failed. Explaining to them that this helps catch errors before the product is live is crucial. Once they have the "Ohhh!! I get it now moment", they won't want to stop writing tests.

Note: I posted this quite awhile back at FooTheory but it didn't transfer over to this blog via cross posting for some reason. Internet-wackiness I call it.

This is an oldie but a goodie. It was brought up that not one developer at my current client knew about this object in the framework.

So, how do you find where the app is running at?

Easy: Use the AppDomain object. This works for both Web and Non-Web projects.

Code:

1 AppDomain.CurrentDomain.BaseDirectory

The AppDomain object will return the application's domain information, which includes the info about where it is executing. We get the current domain of the executing thread and then get its BaseDirectory to see where it's executing.

This:

Returns this:

Enjoy.

Update: There seems to be an issue with recurring events that are NOT set up by you. This is a huge inconvenience. Hopefully the Google Calendar team fixes this soon as this renders this sync tool un-usable as most of my recurring events are set up by others (Project Managers).

Google dropped the Outlook Calendar Sync yesterday. You can see the alert in your Google Calendar.

The great news is that it offers a two way sync between Outlook and Google Calendar. As a consultant, this is great. I can now have a synced calendar between my different clients an my personal life. I can sync my clients outlook (dfelker@example.com) with my personal calendar and then sync my work Outlook with my personal. Therefore I have a master calendar that is updated at all times. Regardless if I'm at the client, logged into their domain, or logged in at the office, or at home, I get the reminders and notifications I need. No more checking 3-5 calendars to make sure I do/don't have a meeting that day. :)

As you may or my not know, you can have Google Send you text messages for calendar events every morning as an Agenda. So when  you wake up, it will be waiting for you in your cell as a text message.

What it looks like installed:

I downloaded it and it places an icon in your tray that looks like this:

When the calendars are sync'ng up, this icon is displayed:

Yup, that's right. Team Foundation Sever told me TOO BAD, SO SAD, GO AWAY, TRY AGAIN ANOTHER DAY. What a great way to start a Monday. Oh, any by the way, we have an emergency release that might have to get pushed out. We're waiting on upper management to make the final decision... fun-fun it is.

Photo By: Auntie P

This weekend I rebuilt my machine. I have a Dell Inspiron 6400 Laptop and it came loaded with Vista Business (and TONS of junk-ware I don't need/nor care about). The one thing I love is that to restore back to factory settings only took about 10 minutes. Yes, 10 minutes - that's craziness. Most rebuilds take hours (unless you're using Ghost or something like that). There is a little partition on the drive that has the factory restore files on it. Just boot into the boot menu during start up (F8) and then choose restore to factory default and you'll have a factory machine within 10 minutes, total awesome-ness.

After I spend the next 6-8 hours installing VS2005, VS2008 (yes, I need both, some clients will only have VS2005 and the solution files in VS2005 and VS2008 are different, by a line), Office 2007, and my list of tools that are close to Hanselmans tools list I finally was ready to get back to work on Monday. I came in today and tried to connect to TFS (2005). Nope. Not going to happen. Here's the error:

 

TF31002: Unable to connect to this Team Foundation Server (...) Please contact your TFS Administrator.

 

Me: *Expletive*

Great, I am the TFS administrator. I have FULL access rights to TFS, I AM THE ADMINISTRATOR!! I have no idea why this would happen. I was able to connect last Friday, on Saturday before the re-install and team members are working against TFS as I speak. Then I rebooted, tried a few other things. Checked Windows firewall and a few other places. Nope. Still didn't work.

Me: *Expletive*

The Fix

I had a hunch this was caused by some type of interception of a call to TFS. I then decided to uninstall Macfee Anti-Virus because, well, because I can't stand anti-virus software that bloats my system. After the always-required-reboot, I started up VS2005 and tried to connect to TFS.

It worked.

I wanted to know if anyone else had this problem so I did a little poking around and I found this thread on the MSDN forums. It looks like this is the EXACT problem that I had.

Oh what a joy AV software is. Actually, I can't stand it - not one bit.