sfeldman.NET

.NET, code, personal thoughts

  • This Developer’s Life Podcast

    The other day I was listening to This Developer’s Life podcast, episode 1 – Getting Fired. Please don’t confused, I am not getting fired (yet), but I find it very interesting how Rob formulated his experience. I also completely in agreement with Oren Eini. Being honest (not rude) is a key to successful work relationship. Dealing with people is not always logical, therefore the importance of way things are communicated sometimes exceed the message itself.

  • The Agile Samurai – Book

    It is a great honour to work with the person who wrote the book Iimage just recently finished reading. The Agile Samurai is a mix of project management and software development. It’s a reality check helper if you are trying to run agile process in your company/team/project. The intention of this post is not to review the book, this is what I will do later at Amazon. Jonathan has managed to make me think of certain things in a different manner, maybe a little bit more realistic. There are a few new tools I can put under my belt (Inception Deck) to move forward with. The most important message from the book IMHO was not taking Agile literally as written - fluctuate, experiment, and question.

  • Consuming WCF Service from BizTalk

    Sometimes trivial things in .NET are not so trivial in the BizTalk world. Especially for standard .NET developers with the mindset for routine .NET development. Recently, I was asked to give a hand with a simple task that was surprisingly taking too long (and good that was asked for, why to waste time if you can leverage someone to give a hand – always something I resort to). On the web, there are plenty of resources, yet nothing emphasizes the little things that are obvious to somewhat experienced BizTalk-ers and is brand new to mature .NET developers. Lets dive into example.

  • AOP

    I am looking at the code for Silverlight application and there’s something that just bugs me… INotifyPropertyChanged. This is not the first time, and yet again I see this interface implemented again, and again, and again. This violates several good principles (Single Responsibility and Duplicated Code). It also pollutes the code with cross cutting concerns (change notification). My choice of solution for this is simple – buy, do not build. Yes, it is possible to write a base class that would scan for a custom attribute and will do the wiring. But why? Why not to look into something like PostSharp and take advantage of the hard work the author(s) put into it to make it work.