Posted on
February 3, 2008 10:33
by
JP
Categories:
Actions:
E-mail |
Permalink |
Comments (0) |
Trackback
I received the bill for my newly consolidated student loan yesterday. They never sent me the first bill, so I am already overdue now. Outstanding balance: $26K and some change. In retrospect, this could be my biggest financial blunder to date, but I won't go into that. How I am going to deal with this debt is what I want to talk about today. You need to understand that I have a wife, three kids, two mortgages, and two car notes....so knuckling down (or sucking it up) and just living lean and paying the bill is not an option. I am already living lean.
Strategy #1: Go back to school. I can take six hours a semester at the local community college (which is actually a pretty darn good school) and that will get me on deferred status with my loan provider. Plus, it might be the only chance I ever get to program C again. This would cost about $600 a year vs. $1250. A co-worker of mine is currently using this strategy. The problem is she is down to taking things like underwater welding because she has taken almost ever class they offer. She probably has the beginnings of 15 degrees accrued up. The price of being a Rice graduate, I guess.
Strategy #2: Sell used books on Amazon. I have another co-worker who says certain kin folk of his made about $30K one year doing that. Not sure what it takes to pull this off, but I see a lot of garage sales in the crystal ball. Heck, I could probably pay off my loan just by selling my computer book collection. Seriously, I am not crazy. I wouldn't do that, but still, it is tempting. I think I have a copy of Pro Biztalk 2006 that I have absolutely no emotional attachment to, so that might end up as grist for the mill.
Strategy #3: Doing #1 and #2 at the same time. Go back to school, get the loan put on hold, and earn money to pay it off. All at the same time. This seems like a big commitment, so I only listed it here because I wanted 3 things in the list so it looked legitimate. I really don't think I have the stamina to do this because I am training to become an elite marathon runner....we'll get into that later. Also, I committed to taking the CAPM at work...sheesh, let's talk about that later, too.
I was pilfering material from Analysis Patterns today looking for a pattern that I could teach myself (or in this case re-familiarize myself with) very quickly. Honestly, I just don't want to jack around with patterns today, but I only made my promise of a "pattern-a-day" yesterday, so it would look bad if I didn't produce.
I came up with Quantity. It's very simple and we have all probably done it a million times. Basically, a quantity is a data type that contains a numeric value along with its unit of measure:
Ok, that's the easy part.
After I read about Quantity it made me start thinking about units of measure. I have worked on many applications centered around energy (natural gas, offshore drilling, trading, etc.) The one thing these applications have in common is units of measure (UOM). And I am not talking about 1 or 2. I mean hundreds of quantities. On top of that, all of these quantities usually need to be converted between many different UOM's.
One for One UOM's
I want to see how many barrels of some variant of gasoline the refinery has produced last month. Now, I want to see the results in gallons. In fact, I want all of my reports to be able to handle any applicable unit of measure. This stuff gets hard from a database perspective.
In the application I just mentioned, every value in the database had a corresponding UOM. If a table had 50 quantities, then there were also 50 matching UOM fields. The UI also reflected this. For every textbox that took a numeric value, there was a corresponding dropdown to pick the UOM. I think there may have been advantages to this method, but the nightmares I still experience from working on this project persist today.
Querying the database was just plain hard. Imagine a query where you have to convert all values to a common UOM by doing multiple joins to several tables containing UOM's and conversion factors. You'll have to imagine it, because I sure as heck don't want to get into it. It sucked. However, to be fair, I am not sure we had much choice. The system needed this flexibility. I just wonder if we couldn't have come up with a better implementation. There was just too much you would have to know in order to extend the system. It was not a very maintainable solution. I know, because I had to maintain it for over a year.
UOM Template
In the current system I am working on, we came up with the concept of a UOM Template. The template table contains things like WeightLarge, WeightSmall, LengthLarge, LengthSmall, VolumeLarge, VolumeSmall, DistanceLarge, DistanceSmall and so on.
To put this in perspective, WeightLarge might contain TONS, whereas WeightSmall might contain LBS. This works quite well, because our system has a natural boundary in which we can apply a template. It's project-based. That is, there is a record in the database that represents Project 123 and we can easily say that Project 123 is using UOM Template 456.
The UOM template for a project is initially populated from one of two master templates. The user can then tweak individual settings. In the UI, values are displayed in a numeric textbox and the unit is shown in a label next to it. The rules for what fields get what UOM's are in the domain.
The template itself is simple but big. The reason is that there are many units that are only used in one place in the UI or need a different UOM from the default weight, length, and volume units. So, the template contains things like CakeThickness, MudDensity and all of the other one-off values the application is keeping track of. But you know what, I like it. It is very easy to maintain. What I have not explored is how difficult it would be to do unit conversions in a system like this. We don't have to. My gut is the aforementioned One For One method works better for this, but I would probably exhaust all other possibilities before trying that model again.
Enterprise applications have vendors, operators, employees, contacts, clients, and organizations. This means a whole lot of phone numbers, addresses, and email addresses; essentially contact information. Over the years I have seen applications model these things a million different ways. Some good, some not so good. Party [Fowler AP] makes things much easier, at least from a domain perspective.
Just think of parties as entities that have addresses, emails, and phone numbers. The important thing to note is that this can include people as well as organizations.
In OO terms, Party might be an abstract type containing references to addresses, emails, and phone numbers. Derived type would include domain entities like Company, Vendor, Employee, Client, and so on.
