sfeldman.NET

Today was a great day. One of the things we do with the team is experiment how we write our test. Experimenting seems the most effective way of figuring out what should be our testing approach. At this point we are mostly doing specification driven tests (unit tests).

I was reading through the book when combined several subjects together, such as "help tests" and "error handling", and realized that the core "Depend upon abstraction.  Do not depend upon concretions." principle is underused by myself.

I finally got a chance to get to the next book on my reading list. Highly recommended book. "Uncle Bob" not only has produced a quality book, but also has captured a significant amount of wisdom that helps to make coding more rational.

It's not a secret that I prefer certain tools/frameworks/applications over other ones. So is true with unit testing framework. My currently preferred one is MbUnit. My team was using NUnit so far, and honestly I respected the choice and didn't mind that much. Until this week.

I have posted a question at VisualSVN user group in regards to reverting delete operation on an item in a project. The workaround is very much manual, and feels wrong. At this point I was either able to revert the change for the deleted file only and manually add it to the project, or revert both deleted file and modified project file, and manually remove the references to the files that are reported as 'missing'.

Lately I had an accident with my HP Pavilion laptop and wanted to share the HP service story with you. Hopefully it will save people time and money.

This is late news, but I really recommend listening to the podcast with Robert C. Martin on .NET Rocks! Decided to listen to this one as a result of the book have read a while ago, Agile Principles, Patterns, and Practices in C#. The guy who has spent over 30 years trying to figure out how to do software, has some ideas to inspire how you do things. Audience? Developers, managers, users. Anyone. This is a great content to listen to.

Naming conventions is always brought up when a team is trying to standardize the way code is expressed. Tab size of 2 vs. size of 4, Camel case vs. Pascal case, blog opening on a new line vs. same line with expression, member fields prefixed vs. underscored vs. nothing, control names with Hungarian notation or without it. The list goes on and on. The truth is that this is really doesn't matter. I have learned to accept what team decides to go with and once you embrace the style it's all good. What really matters is the code being produces, not the size of the font it's printed in (well, probably not the best example, but you get the idea).