I wanted to put a simple test in place to document the behaviour of a value converter WPF application I am working on is using. First I did it the standard TDD way (sort of spiking multicultural support of MbUnit framework). The result worked great.

I am a total newbie in WPF development. One of the things I wanted to have is to format the values coming out of my domain object into UI, and being able to parse those values back into business objects.

I am coming from a web environment, where no state exists in between requests. I started with an approach usually apply in the web applications, quickly realizing it will not work that way. The fact that DataContext (like a ViewData) is there and doesn’t have to be reconstructed is great. The down side - it’s not strongly typed. At the same time maybe the only way to use it is one, when assigning the data(object) and that’s it. Also bugging the fact that the properties are used for binding as string texts, but that I have to understand better.

Issues are:

• Constant requirement to defrag the VSS database* Loosing checked in code* Merging is absolute on block, and not partial merging* VSS client for VS.NET sucks, when getting latest version and focus away, the VSS dialog box hangs, along with VS.NET itself* Deleting checked out files leaves them on server* Checking in files that were touched, but final result was not different from original (1)* Patching?

What did you find that I didn’t list here? Help me to convince my good fellow coworkers to move away from the beast. Thank you.

Logging is the process in which trees are cut down for forest management and timber. Logging is controversial due to its potential environmental and aesthetic impacts.

I am going to talk about other one, the one that is vital, helpful, and has positive impacts. Software logging.

Hosted projects are easier in terms of debugging and tracing issues - you have got all the control in case you are the host. Though in some cases even the fact that you hosting the application does not help. Then troubleshooting becomes painful if not impossible.

I’d like to drop a few word for the book was lucky to read lately - Fearless Change: Patterns for Introducing New Ideas.  Authors of the book have succeeded to capture ways to apply changes in amazingly accurate way. Written as a pattern book with orientation for software development (and not only) this book makes a perfect read for those who are willing to make changes and affect others.

Firefighters are not analyzing the situation, they are taking several plans to consider leaving the simplest and the least harmful to be executed. Can be this applied anywhere? No. When you have stressful times in software development you need to enrich your knowledge and learn about the problem. Doesn't mean to put on hold the development. Neither it means to implement the firemen approach and forget about it. It means take out the fire and learn how to avoid fires in the future by implementing the proper solution when you can.

So today I was challenged. Challenged to talk about my achievements at the company I work for. Why is it a challenge? Simply because I don’t like to brag about my personal achievements when know how much I still have to achieve. But in this case this is different, as I would like to have a chance to look back and review what are the achievements I managed to generate in the company (Note: compensations are not linked to this :).

Some call it science, I call it art. Watch the video.

I had to refactor a portion of code and decided to go with strategy pattern. Interesting thing is that the final result might look more complex, but when discussed with a fellow developer, got green light in terms of “more maintainable” and “self documenting” code result. So here I am sharing it with others for review and opinions.

The problem

A person is associated with a plan it is member of. Association is expressed in a plan code assigned to the person. Based on the code a person is assigned, different fields from his plan details record are pulled into calculation. Possible plan codes are PlanA, PlanB, PlanZ. Each plan is driving out the price for member, spouse, and total costs. Fields involved in calculations are:

The company I work for has a significant amount of web applications of a specific line of business. This line of applications started 8 years ago (I am with the company just for the last 3 only). Since I started to be interested in Domain Driven Design, felt strongly that this line of applications should be re-addressed with a DDD approach. But the resistance was enormous, motivating that “these are the pure data centric applications and there’s no place for domain, the data is the domain and as a result of that it is a DATA driven design application”.