Fernando Zamora

A while back I had a conversation with a friend. This friend told me the calculations of putting 20% down versus not putting the 20% down towards a new house revealed that the monthly payment would not go down by much. I thought about it and did my own calculations. Let's take as an example a calculation with the following characteristics. Price: $100,000 Down Payment: 0% Term: 30 Years Interest Rate: 6% Payment: $599.55 If instead you put the 20% down, you end up with a payment of 479.64. That doesn't seem like much. So let's say that instead you went with a 15 year fixed mortgage. Your payment would now be $632. That's assuming that your interest rate went down to 5% because you took a 15 year mortage instead. Ok, so you still end up paying a bigger payment with a 15 year mortgage. That's true, but that's only $32 more dollars for 15 years instead of $599 for 15 years (only counting first 15 years of both mortgages). The former is equal to $5,760. The ...

Over the last several years or so, I have observed something that I refer to as "The Token Anti-pattern ". I have seen this pattern rear its ugly head as a way of passing parameters from one class to the next. The parameters are neatly wrapped up as properties of a class. In the worst case that I've seen the Token had about 20 properties that were not cohesive, making the token class itself non-cohesive. It was a scenario where the process was basically a work flow. The workflow stepped it's way through many steps. Many of the steps branched out to different paths, calling out other objects. The token was passed to these other objects. The different paths required different pieces of information as preconditions. These pieces of data were attached to the "Token" along the way. The token for one path would have property1, property2 filled but property3 null. Whereas for a different path property1 would be null and property2 and property3 would be fil...

This post has migrated to  https://beginningprogrammer.com/programming/ioc-container-vs-service-locator/

I recently prototyped a simple application to see how the simplest form of posting and receiving messages using MSMQ worked. The prototype was a simple WinForms application with two buttons - one for post and one for receive - and a rich textbox to log the activity. All of the logic for the process was in the event handlers for the two buttons. There was no MVP, no separation of layers, no unit testing. The whole form file was no longer than maybe 80 lines of code. I showed the demo to one of my colleagues and he shook his head in disappointment . Being that we have recently paying attention to the craftsmanship movement on DDD, BDD and the like he asked "Where is the MVP? Where are the unit tests?". I proceeded to explain to him that it was all a simple test that I wanted to perform and I didn't want to clutter my code with unnecessary complexity. Besides, the code was very straight forward and did nothing useful other than demonstrate how to post and receive tri...

We've been using CSLA - Component-based Scalable Logical Architecture in a product for approximately one year and while it solves quite a few problems it violates some major good practices. No Clear Separation of Layers While at the time that we chose CSLA we knew very little about domain driven design, it is no excuse for the framework to possess the data access layer within the business object. This makes it extremely difficult to separate the concerns. As a result, it is difficult to mock the data-access layer creating many problems when attempting to perform unit tests. This also puts the additional responsibility of data access on the business object class, violating the Single Responsibility Principle( SRP ). Data access layer should be totally separated from the business object period. Having the data access within the within the BO class is not the only additional responsibility placed on the class but is the most significant one I can think of. No Context Validation...

This is my first official blog on the world wide web. I had to do it. Everyone else is doing it so why not me. Hey, it's free anyway right? I intend to blog about anything and everything. You can count on finding much information here; most of it useful. I will be writing about coding (programming), money and life experiences. Go ahead and subscribe to this feed if you dare. I promise you, you will not be dissapointed.