Initial layout of system

Defines the main pieces an how they would interact in order to produce a
result.

Now that the API looks decent can start implementing lower level
behaviors.
Brute force solution to detecting overage

Just enough code to detect that you spent too much for a particular
category

I know that I want to abstract this operation out so that I can have
different types of analysis. Before doing that though I want to add one
more so that I have a better idea of what my abstraction needs to be.

My plan right now then is to add detection for what months you spend the
most. This will give me new config data, new algorithm and new return
data. With those I should have a good baseline for determining the
analyzer abstraction

At this point I leave the integration test not passing since I want to
finish the alalyzers first, then will move to getting the config from
files which will get the integration test passing
Adds second method of analysis

At this point I have a pretty good idea what an 'analyzer' needs to be.
I'm not sure if I need an abstraction over the alerts it provides or if
I should just go with a single SpendingAlert class.

The main thing I don't like is I know I will have this magic string in
both that really identifies what the alert is for(clothing/category,
monthly income) and then the analyzer will have to know too much about
the formatting of an alert message. Another option would be some sort of
enum but that still seems like it will be too coupled.

Going to defer that decisions for the time being and just leave it as-is
while working on extracting analyzer behavior
Extract analyze behaviors into distinct classes

Behavior of the analyzers is extracted.

I'm getting to the point where I have enough stuff now that I need to
get out of this single file mode and start organizing things
Adding some structure

Now that I have a better idea of what the pieces are going to be I can
apply some structure to it.

One thing that really jumped out was the inconsistency with the term
'Spending'
Sometimes it was referring to the act of spending money and other times
it applied to your budget.  I wanted to clear that up so I renamed all
the stuff that relates to you spending money is under Activity.
Right now I just have a report with some financial transactions (because
transaction by itself is such a loaded word with computers)

I want to clean up my BudgetTool api a little bit and then add support
for loading from files so i can get my integration test passing again.

Then I need to decide what I want to do with alerts
Created a small DSL for configuration

I like the DSL approach because it helps discoverability and keeps
configuration all in a single unit
Able to load config & transactions from file

I can load things from files now which gets my integration test green
again.

The loaders are not very robust yet in terns of dealing with errors. And
are really doing too much at this point.
Separated parsing logic for transaction

This helps clean up the loader a bit and makes the error handling easier
to follow
Working on separate csv parser
Extracting CSV reader into its own concept to keep the parsing of CSV separate from the building of the FinancialTransaction
Exclude annotations from code coverage
Abstract out file access
Fixing up some issues with disposable & serializable types
Budget tool can run any analyzer now
Extracting behaviors from activity report
Refactor analyzers

I wanted to be able to get the analyzers to a more declarative
state where they say /what/ they are doing but not necessarily
/how/

I did this by moving the actual computation work out into
separate methods and then composing them with LINQ
Cleaning up
Formatting
Documentation