Among various things in C# 3.0, one of the syntactical sweets that I find quiet useful is the ‘var’ keyword. Combined with R# intelligence, you create a very readable code that is not cluttered with excessive type reminders. Just enough to keep it strongly typed and readable.

Personally, I favor:

Tentity - Database mirrored Table representation in code to mimic the concept of entity, bringing DB awareness, cache and persistence concerns in it, with design driven mostly for the state and some functionality dictated by DB operations to be performed on the data. A complete anti-POCO.

There was an interesting observation made once, that to be happy with what you do, you have to have 2 out of 3 things which are Fun, Respect, and Money. If you have all three, then you are doing great. In case there is only one out of three, it is really up to your spirit, until you move on. Two is a reasonable number if you passionate about what you doing.

Svn 1Click Setup - did a very nice job from specifying environment locations and variable to configuring the server and service. Simplifies a lot the whole experience.

Something I have learned from JP Boodhoo lately (and NOT the only thing):

Filename: {SomeComponent}Specs

TestFixture: When{specification}

SetUp: establish the context

Test: Should {expected behaviour}

SUT: exercised component

TestFixture: When {next specification}

Something like SpecUnit.NET would produce

SomeComponentSpecs

• When specification
  • Should expected behaviour
• When next specification
  • Should
  • Should

Intent-revealing documentation/report

It is nice once in a while to get back to the course or training session you took and make sure that you haven’t wasted your time for nothing. This is not about ego, this is about making sure that what ever you know today will be absolutely no enough tomorrow and constantly remind yourself this basic law of software development.

I am lucky to TA at JP’s Nothing But .NET boot camp. Unlike MSDN events, NBDN is a whole different story. If you heard of it and were hesitating, or doubting if it is for you at all - my answer would be short - if you are hungry for knowledge and always looking how to improve yourself - get it.

I was reading about NHibernate mapping of the properties that have no setter, and how it’s done through the backing field (reflection I assume). The setting looks like this:

Pair programming is a proven technique for sharing knowledge among team members and teams. Benefits of that are felt after relatively a short period of time, boosting not just the productivity, but self-confidence of the developers (which is playing an important role even though is not admitted), and most of all, improving the maintainability of the code when it comes later. And it comes. It always comes.

But I would like to review additional alternatives to the knowledge sharing with team members (both direct team members, and those that are a part of another teams that might not come into direct contact with what your team is doing). What are the ways to share the knowledge?

I was holding off using R# when it’s not even in an EAP mode. But today I have had it. Uninstalled R# 3.1 for Visual Studio .NET 2008 and went to R# 4 nightly build.

Long time ago I had to deal with a case where the famous ViewState generated by WebForms was quiet heavy. This post is not going to wine about how bad ViewState is for the environment. This post is to show that even working with something big and nasty such as web forms, you still have to give a thought what are you trying to do and what is out there that can help you to accomplish the mission.