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