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).

As a team we have found ourselves in a very delicate situation where we had to make a group design decision and it was quiet an interesting experience. What happens if your opinion does not align with the decision? How do you express your opinion without suppressing others opinions, promoting your concepts without falling into the nasty habit of ignoring anything that is different?

You discus. Can’t prove that what your idea is all about is the way to go, that means it’s either not better or you haven’t really tried to explain it to others so they would see the benefit and be convinced. Conclusion - take your time, step back, see what’s going to happen, accept what the team has decided, and if you really thing that’s not the way to march, start thinking of a better way to debate your case and have some solid proof of concept.

I am extremely excited to be a part of a team that has deliberately decided to follow the Agile path and TDD way of producing results. Along with that I am learning myself tones.

As a team, the decision was made to use strict mocks to understand better what mocking is all about and how dependencies should be tested for interactions, but not the their state (i.e. don’t test dependencies themselves within the tests that are exercising System Under Test). IMO while this is a valid and good way of grasping the concepts and wrap around the whole idea of mocking, this is not necessarily the best way to express tests. Once basic understanding is there, strict mocks should not be forced upon all the tests. Reasons? Personal reason for myself - it doesn’t feel right. Once it doesn’t feel right, question it, doubt it, dig for alternatives and a better answer.

While reading Joshua Kerievsky book “Refactoring to Patterns” could not go silent about abuse of Singleton pattern he described. The question that was asked in the book “When is a Singleton unnecessary?” - “Most of the time”. Honestly, I can recall at least a few times when I was sick with Singletonitis: different Utilities, Session related classes, Context related classes, Resources related classes, you name it.

From my own experience this is so true. While Singleton allows only one instance of a class (pro), it also makes testing virtually impossible, coupling components dependent upon Singleton to a concrete implementation (con).

A good identifier for an entity is considered to be a number. A unique identifier for an entity, such as identifier that can be synchronized across multiple databases, is considered to be GUID. The only issue with a GUID is that it’s generated on the DB side, and therefor has  a certain performance hit (an extra roundtrip to the DB to generate the GUID and let NHibernate know about it on insert of a new record). The alternative is to use a generator strategy guid.comb - a guid generated on the client side and as a result of that eliminate an extra roundtrip to the DB. The other benefit is that the value generated by this strategy is sequential, and therefore the GUID values are somewhat more traceable in terms of their order of creation.

This post shows a good example of how to refactor your code to preserve Law of Demeter. Very clean and simple example. R# is there for the refactoring part, to make things less manual and friction free. As a reminder, Law of Demeter:

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.

Enumerations are for enumeration. Obvious. Often, though, it’s used also for some metadata knowledge. For example, an enumeration for gender might look like:

This is my goodbye post to Sunwapta, the company I spent 3 years with. Definitely, this was one of the most exciting experiences that have happened to me during my career as a software developer. People there have helped me to grow and mature, and for that I owe them my gratitude. I have learned tones. Thank you for keeping up with me and listening to all of the things I was bringing in. I hope when you run into code I had contribution to, it will bring up more of the positive thoughts and not the opposite. It is a bit sad to leave things not entirely finished, but I am more than confident that they will be done in the best way. After all, together we have done a long way and learned awesome things that not only made us better developers, but also taught that pounding in code is not everything that matters, but thinking, analyzing, constantly improving, and most of all, never settling on mediocre, always striving to better.

This post is not sponsored by the manufacturer. Neither do I get dividends from the sales. This is pure lips service to a great product line I’ve used for years.

We all have cell phones. Well, if you don’t (I wonder were you managed to hide all these years), no worries, soon you will. A joke was once told that rather than giving people social identification number, they better be given a cell phone number - that way it’s unique and you always keep in touch. As they say, in every joke there’s a little portion of joke.

This is definitely interesting turn of things. Rather than come with it’s own exact copy of an existing product, MS will provide an OSS product as a part of a bundle. I wonder if there are more interesting and welcomed surprises coming from this direction.

We have used jQuery for a couple of recent project to save ourselves headaches on the client side, and the library is quiet impressive. Definitely good news.