Resharper 2.5 EAP Update

Well I've been using the Resharper 2.5 EAP for awhile now and I'm quite impressed with how quickly they have brought the quality of the Visual Basic integration up to snuff. Of course they are only doing the read-only functionality but even that subset of functionality is quite a bit. The EAP has quickly become a tool we can't imagine developing without. One small example is how we've set Alt+U to run all unit tests in the solution. The guy I pair with won't admit it but I think he prefers using the Resharper Unit Test stuff over NUnit. Sure the big green circle isn't as big but the integration and ease of use is so nice. We still use TestDriven.Net for running individual tests but we love Resharper for running all the tests.

In terms of a 3rd party tool nothing I've tried comes close to Resharper in terms of how it will affect your productivity. If you didn't try this before because it was only C# you are in luck. So print out that Key Mapping document and get started today. You won't regret it.

A Daily Build Process...

We spent a large part of Sunday in at work. Our original intention was to implement a daily build process. The easiest method I could see of implementing this was to use CruiseControl.Net. Before we could do that though we needed to add a few remaining projects to the CC.Net process so that everything was CI'ed.

This is the part where our plans for the day start going south...

As we're adding the new projects we realize that our original directory layout was wrong. And then we realize that our actual build scripts require way to much effort to get working for a new project. At this point we can either leave things as they are and just hack together the remaining builds or we can fix things.

Of course if we don't fix things now we'll just have more to fix later...

So we ended up fixing all our scripts and moving things around. Now this is all based on our current level of knowledge about CC.Net so we may have made a few errors in how we set things up, but I think I'm actually quite happy with how it all came together.

Now about that daily build process...

Domain Specific Language

Martin Fowler does an a very good job at explaining Domain Specific Languages in a JAOO conference talk. One thing to note is that the actual slides he uses in his presentation are shown lower on the page in real time. I didn't realize this at first which made it a bit hard to follow at first. Definitely a must see.

A whole new world.. and Launchy!

Well first off I'll start with an update on things. We implemented CruiseControl.Net last Sunday and have been using pair programming for the last few weeks. It’s been a really great learning experience. I had always thought that pair programming wasn’t something that would ever interest me but it turns out I was wrong. I find that I’m much more productive with someone to work problems through and the noise levels in the room don’t affect me at all. We’re also doing a bit of TDD. Well our own version of it, which we update as I get time to read Test Driven Development: By Example. I’m also looking forward to reading the 2nd edition of Extreme Programming Explained. I’ve definitely become an agile convert but now I want to research the various flavors to see what best jives with me. All in all I’m very happy with how life is progressing professionally.

And in other news Jean-Paul released another little tidbit of information that has helped me immensely. It's a product called Launchy and let me tell you this thing is awesome. By default it scans your Start -> Programs and Control Panel for all applications. When you bring it up you type in the name of the program (or just the first letter) and it will show you the most likely match. After a second or two a drop down will appear that shows you the top 10 matches which you can pick from. Once you use an application with it, it will make it more likely to return that application (especially for the same keystrokes) in the future. It’s replaced Slickrun as my application launcher of choice.

2007 Microsoft Launch

Well I and a few others from my company went to the 2007 Microsoft Launch event and I figured what better reason to get caught up on my blogging.

For those of you who didn't know today was the official launch event for " Windows Vista™, the 2007 Microsoft® Office system and Microsoft® Exchange Server 2007". There was a keynote and then a day of sessions. I of course took the developer track so I can only comment on it but there was also a Business, IT Pro and Architecture track.

The keynote itself was very much oriented towards the Business and IT crowd. I'm interested in the business side of things though so it was still interesting to see. The only real complaint I have was with the guy I have dubbed "Mr. Uhm". Where I use to work we had a rule that the usage of the word Uhm was not allowed during any discussion. The reasoning being that if you used it in front of your fellow co-workers you were probably also going to use it in front of customers. And anyone who has seen a presenter who keeps saying the word Uhm or Uhh can tell you that it makes for a very unprofessional display. We had different counts but my personal count was on average one Uhm every 6 seconds.

After that we started on our developer track. I don’t remember the names of the two people who gave the various presentations but they were both very good. The first session was an overview of Windows Vista and Office 2007. There was some good information provided for those who haven’t been following the products. I’ve actually used the Office 2007 Beta 2 a bit so I’m already very impressed with the new interface. And seeing some of the capabilities of Windows Vista really gets me excited about being able to play with it.

The next session was on Windows Presentation Foundation. I know a bit about the technology having heard about Xaml but seeing it in action was very cool. There is going to be a lot of interesting interfaces coming out of Xaml. Some will be monsters but there will also be gems. The session itself was well presented though the audio levels were a bit loud as the presenter has a voice that projects very well.

Next on the menu was a session on development using the Microsoft Office 2007 System . There were a few technical problems in this session but even with those it was still worth going to. It was funny because I had to drag one of my coworkers there and he actually ended up liking it. The fact that a docx is really a zip file blew us both away. Also the usage of XML to store the values from custom fields in a document will make for a lot of interesting possibilities. All in all I think that developing for Office 2007 is going to be an enjoyable experience.

Our next session was the one I had been looking forward to the most. Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF – not WWF since we all know what happened to the wrestlers who tried to take on the panda bears); after having worked with MSMQ and worked on a workflow design I can say that both of these technologies really excite me. And that was before seeing the presentation. Now having seen how easy these technologies make things I’m really looking forward to getting a chance to use them. The ease with which WCF allows you to change your communication layer is amazing. And WF has the potential to change things. The ease with which any application can now implement workflow is going to open up so many possibilities. It doesn’t hurt that the actual implementation and tools look very nice.

And last but not least was Microsoft Office SharePoint Server 2007 with a dab of InfoPath (web-based). We actually use SharePoint where I work and the things that we saw in this session gave me a lot of ideas. The ease with which you can bring data in from your own applications is very cool. The fact that SharePoint 2007 is also a WF host is amazing. You can now setup a workflow so that when a new item gets added to a library a workflow is initiated. And they even provide a tool that makes it so non-developers can create workflows. We didn’t get to see too much of it so I’m not sure how advanced it is but it does look interesting.

So all in all I was quite happy with the event and I learnt a lot of interesting things. I’m definitely looking forward to getting my hands on the various technologies. In fact I’ve got .Net 3.0 and the various tools downloading right now. If you live in one of the cities where this event is coming in the near future I recommend you take the time to see it. Even if you’re not working with Office or workflows or communication today you never know what tomorrow will bring.

Internet Explorer 7.0 gives up the ghost

Well Internet Explorer 7.0 will no longer run on my machine. Not sure what happened but I was running it.. and it suddenly disappeared. After that any time I tried to execute it it would show up for a second and then disappear. Uninstalled and reinstalled and still the same behavior so now I'm back to good ole IE 6.

Tabbed browsing how I miss thee.. and yes I know about Firefox..

ReSharper for VB.Net (Early Access)

Well it looks like those of us who are in VB.Net land are now being let in on one of the most amazing tools available for C#

Resharper 2.5 has been released under the Early Access Program. It currently only has read-only functionality (Go to, Navigation, etc) but that alone makes for much more efficent programming.

I also recommend you download the Resharper 2.0 Default Keymap, print it out and keep it next to you.

Between this and SlickEdit Command Spy gadget mouseless programming has never been easier.

The Big Move...

Well I've been in a moving state for over a week now. We weren't planning on starting our move until last Sunday but then "The Crickets" started to make their presence known and it was time to get out of dodge.

Jeremy Miller makes posted his Programming Manifest and I have to say I agree completely. Very well done.

I've actually been having some really good discussions with a contractor of ours lately. It's interesting because he is old school so he provides some good counter points to the "interface based" design that is so popular these days. It's good having different views so you can decide what makes the most sense to you.

Testing.. Why not involve a client?

Fellow Edmontonian Igloo Coder brings up a few very good points about testing. The most valuable every experienced developer knows by now and every new developer should know..

"Developers don't make good testers. Because of this, don't rely on them to do your only testing"

One thing he doesn't mention is that part of the problem is ego. Most developers have some sort of ego (generalization I know.. I've seen truely great coders with no ego.. and others with an insane amount of ego..) which makes it hard for them to believe that the piece of code they just wrote isn't the best coding every done. This is one place where I really think experience helps though.. after you've been doing this a few years assuming you ever go back and look at your old code it's inevitable you'll have the "wtf was I thinking?!?" moment. So eventually a good developer will get to the point where they are comfortable making the statement..

"This code is great but it probably has some room for improvement."

It's at this point that a good developer will arm themselves with various tools.. unit testing (and hopefully some coverage testing) being the most prominent. Which isn't to say that unit testing, coverage testing is going to catch every bug. These tools are good at finding code quality and logic problems with code but they miss out on many other types of errors. Igloo Coder mentions using Q&A to help find your issues and this is going to help you catch substantionally more errors. One thing I would add to this is that it's a good idea to have someone in your Q&A team who is either a domain expert on the problem the application was created to solve or even better is one of your clients. You'd be amazed how many clients you have that WANT to help.. that if you talk to about testing code (and explain that there are going to be some quality issues) will gladly take your latest iteration (after your technical Q&A people have gone over it) and work through it. This kind of person can bring you valuable insight into what your application does great and what it does poor.

Of course you will need to remember that like all people this person has a personal agenda. They want to help you resolve issues with the application but they also want it to work how they think things should work. So you need to balance the feedback from them with what you know about the application. And when something they are recommending goes completely against your understanding of what should be you may want to consider talking to other clients. Verify what the general expectation is. Sometimes your original understanding will be bang on.. and other times you'll wonder how the requirements you have are so far off them mark.

So assuming it's an option for you consider adding client involvement to your testing arsenal. Your application will be the better for it.

NCover & NCoverExplorer Update

Thanks to a bit of help from Kiwidude I was able to use NCoverExplorer to get NCover working. It's a very cool tool that allows you to easily run NCover. It has a very nice interface that makes it easy as pie to run NCover against NUnit. Oh and it will even generate MSBuild and NAnt scripts for you. How cool is that?

So now that NCover has been added to my toolbox I'm wondering how best to integrate it into the build process. Does anyone know if you can set it up so that if you don't have say 90% code coverage the build fails? Oh well something to investigate.

Next on the list is a bit of special time with NDepend which is a code metrics tool. Should be fun.

It's all about what you've got in your toolbox...

Here is a quick list of what I've actually been playing with over the last few weeks and a bit of a comment on each.. I'll expand on each of these in an individual post when I've got a bit more brain power.

NUnit - This is an obvious one that most people should already know about. It brings the concept of "Unit Testing" to those of us who aren't working at Google, Microsoft or ThoughtWorks. This free “unit testing framework” is the basis of almost everything else I've learnt because without "Unit Testing" or that eventual goal of TDD the other tools don't make as much sense. NUnit was very easy to pickup thanks to the documentation that's available. It's also been nicely integrated into the other tools.

TestDriven.Net – This is an add-on for Visual Studio that allows you to run your NUnit (or various other unit testing frameworks) tests easily from within Visual Studio. The NUnit GUI is very cool but at the end of the day once you get past the cool green/yellow/red you’ll just want to know if you passed or failed as quickly as possible.

FxCop - I don't know about you but it feels like it has been a few years since I last tried FxCop. Back then I tried it.. looked at the giant list of issues (most of which appeared to be a bit silly) and promptly uninstalled it. Well if you're like me and you've grown up a bit it may be time to re-evaluate this little tool. I don't know if it's me or FxCop but the issues it finds seem to be a bit more important now and it wasn't actually that painful to get my project FxCop compliant. O

--- Intermission ---

So your world has started to brighten a bit.. you've got some unit tests written and your project was FxCop compliant last time you checked.. but if you’re like me you've got 50 things to do and trying to remember to run your unit tests all the time has fallen to the wayside. Which of course means that your unit tests are out of date and your code is not even close to FxCop compliant anymore. So does that mean you should give up on this whole unit testing concept? Go back to the way things were? Well No.. it just means you like me need a bit more process and thankfully the tools exist today to bring you that process.

And if you’re not like me and things have been humming along great.. Well maybe these tools will help them hum along just a little bit nicer.

--- End Intermission ---

CruiseControl.Net – If you a tree falls in the forest does anyone know? Well if that tree was being monitored by CruiseControl.Tree they would. CruiseControl.Net allows for “Continuous Integration” or as I like to call it.. knowing to nearly the second that your shit is broken. The concept is simple… every time code is checked into your source code repository (you are using one right? This is your lively hood we’re talking about isn’t it?) CruiseControl.Net will find out and then the magic begins. Using CC.Net with a little help from NAnt (explained below) your code is compiled, and optionally NUnit and FxCop are both ran. If any problem occurs you are notified either via email or via the little CC.Net system tray utility. Either way you can yell at the numbskull that just broke the code (or quickly fix it before someone else realizes that you’re the numbskull that broke it)

NAnt – Personally I started using NAnt for two reasons. The first being that it was the only way I could get CC.Net to build my application but more importantly I needed to be able to do a complete build, unit test, fxcop cycle with a single button click. NAnt is a tool that lets you build scripts to carry out various tasks. The fun thing is that while NAnt comes with many tasks there is also a community effort around building new tasks. So if you’re stuck using VSS as your source control (better than nothing.. worse than anything else) and you notice that NAnt doesn’t contain a task to retrieve your source code then NAntContrib will come to the rescue. Then it’s just a matter of putting together a build file (easy as pie using all the help available online) and you’ve got yourself a build process.

NCover – I haven’t actually gotten this to work.. mainly because the help sucks and there isn’t a lot in the blog sphere on how to set it up. Once I figure it out I’ll do a HOWTO. Oh and it appears that there are two seperate NCover projects. I'm using the NCover.org one.

ReSharper – If you are a C# developer and you are not using this tool.. download it ASAP.. print out the default key map and get ready to stop using your mouse for so much.

I think at the end of the day all these tools are really about one thing. Process.. or as I like to call it "Forcing me to actually have a process". Each tool adds a bit to your individual or team process and once you have them all in place and see them actually help your development efforts you can't imagine how you got by without them.

Learning... or the day I remembered I like being a Software Developer...

Long story short not to long ago I was considering not being a software developer anymore.. good news for me and my sanity I switched to a new company and got a new lease on the good or is that geek? life :) Add a little Edmonton .Net User Group and some Jean-Paul into the mix and suddenly I realize how much I've missed and how little time I've spent learning over the last 3 years.

With that in mind I've spent the last few weeks trying to cram those missed 3 years into a few weeks. Of course that's impossible but I do have the basics down in quite a few things and am learning more everday. With that in mind I'll be doing a few posts on various technologies from the point of view of a complete newbie and my thoughts on it.

And if you yourself find that maybe you don't quite feel that same loving feeling for software development that you use to.. ask yourself one simple question.. When is the last time you saw or learnt something that made you get pumped up? If it's been awhile I'd recommend looking into a local .Net group, attend some information sessions by a seasoned pro or two or heck maybe just pick up a new book. You may find that it's not software development that's gotten stale.. but lack of learning.

Shane

Jean-Paul Podcast

Well Jean-Paul has delivered another excellent performance, this time via a podcast on Developer Night in Canada. In it he starts with a discussion on design patterns with a tangent or two into the world of TDD and other topics of interest to developers of all shapes and sizes.

My only question is where is this guy's MVP? Oh wait it's probably waiting on the reference application we are all eagerly awaiting :)

Developer: Will work for room!

Jeffrey Palermo has a series post that talks about his view on How to Produce Software Quickly and while I agree with almost everything he says I did do a big double take when I saw his comments regarding slow communication.

Now I'll start with the caveat that I don't know what Jeffrey means when he talks about a team. Is he talking two people? five people? twenty people? Because these numbers all have different meaning when you talk about putting that many people in a single room. I've worked two people to a room.. I've worked six people to a room.. I've even worked twelve plus to a room and each was a unique experience.

Personally I am of two minds to this... the first part agreeing that team communication can be an important thing.. but this comes with a few caveats..

1. The room itself has to be setup properly. There needs to be a few things put in place to manage noise and distractions as much as possible. There should be a door to the room that closes.. the room should be built in such a way to control noise (carpeting, dropped ceiling, etc).. and there should be a limit on having meetings in the room. If your entire team is going to be involved in a meeting and you want to have it in the room then great but if two out of six people are required then move it to another room.
   
   
2. The more people you have in a room the more you are going to negatively affect productivity because the "problem" with people is that we all have our own quirks. People have various tolerances for noise and have various habits that generate noise. For instance I tap my foot a lot.. and according to various people I hit my keyboard keys ‘loudly’. I’m good at ignoring constant environmental sounds but any discussion occurring will immediately make me lose my train of thought and often times pull me in. Each person is unique in what they do and what level of distraction they can take and so even in a small group environment you are going to have people who are never able to enter the “zone” where they can code for two hours straight to solve a really complex problem without realizing that two hours has even passed.
   
   
3. The more junior members a team contains the more valuable communication is going to be. In a team where most of the members are either junior or intermediate and they are being managed by one or more senior developers having that open environment where people can quickly bounce ideas and concepts off each other is going to be worth the loss in individual performance. The inverse of that is that the more senior members the team has the less benefit you get from an open environment. In this kind of situation you are going to want to affect individual performance as little as possible.
   

So now that we've gotten the group communication thing out of the way let's get down to my other point of view.

Noise and distraction suck.

The "zone" is real! Many of us have coded for hours straight on a complex problem and we look in shock at the time and realize how much time has really passed. Or as I like to call it the "Holy crap it's already time to go?" moment.

At a more senior level in my experiences it seems to me that communication usually comes down to a few forms.

1. The "What the heck is this component suppose to do anyway?" question.
2. Something you need from another developer to do your job.
3. The best way to code a complex issue.

The first form of communication is obviously a very bad thing and should not be happening. It’s a sign that the proper procedures and/or project management are not in place. You should never have to ask someone else what this should be doing. You should be looking in Sharepoint (or whatever you use) and finding the business rules and requirements for that component. You should have a list of what your team wants to accomplish this week and you should be working off a priority based task list. Even if you're the one writing that priority based task list at least it exists so others can look at it and tell when/what is going to be available for testing (yes.. yes I love TDD too but you are backing that up with a little bit of Q&A aren't you?). If you find yourself constantly having to get up to ask questions about the code you are writing then that should be a big flashing red light.

The second form of communication is actually another sign of problems. Your co-developers should know what is required of them this week, and they should be emailing you a list of what they have done with instructions as to it's use. If you get to a point where you have to stop work and ask them for something you are already wasting valuable cycles. Sure you can task switch while they finish up whatever it is you need but it's much preferable to never have to task switch at all.

The third form of communication is actually very important to any level of developer. Any smart person knows that nobody knows everything. There is usually more then one way to solve an issue and by taking a few minutes to discuss a complex issue with another developer you may get the mental kick you need. But at the same time this form of communication should be rare, happening only when a developer is working on something that is difficult or unique in some way. If a developer requires feedback on every single thing they code then something is wrong. Either the component is too complex and needs to be broken out a bit better.. maybe splitting it up a bit OR there is a problem in problem solving skills that needs to be addressed. This form of communication is the reason a developers room has a white board and a few addition chairs in it.. so that on those occasions where someone does need to come over and discuss how a component should work a small group can get together to it discuss without interrupting the other members of the team.

So in the end I’ll update my developer per office concept to be..

• A room per senior developer who is working independently.
• A room shared per senior/intermediate developer and the developer she/he is mentoring.
• A room shared per two to three team members who are working together on a project.

At least that's how I see it...