I’ve recently been trying to improve my rather disorganized personal finances.
While I previously “managed” by leaving the bulk of the money in my account
and hoping that I’d calculated my expenses versus salary roughly correctly,
this is suboptimal for answering various questions like “Do I have enough
money to go on holiday?” or “Have I forgotten to pay the electricity bill
for the last year so that I now have to pay it back?”
Clearly there is a better way. Checking off expected payments, knowing what’s
due in the next week/month/etc., and siphoning off the excess into a linked
savings account for example. But this requires being alert and accurate…
Failing that, I could always use a computer ;-)
Spreadsheets
Surprisingly perhaps, the humble spreadsheet is an instrument of frustration
for this kind of task. I’m currently using Google Docs, which is underpowered,
but not really much more hateful than Excel or OpenOffice.org.
It’s particularly bad at being a working document. Moving an item (to
reschedule the date, for example) involves:
- inserting rows
- cutting and pasting
- deleting the original rows
- changing the date
- “filling” down the subtotal column (because spreadsheets don’t have the concept of a calculated column).
Worse yet, because spreadsheets don’t know about dates, adding regular
payments (bills, weekly spends etc.) is an exercise in manually creating them,
and then visually auditing the sheet to make sure you put them in the right
places.
Other apps
Of course dedicated apps for personal finances do exist. I looked at the
Linux ones, Gnucash, Kash, etc. Mostly they crashed. Sometimes they ran
but utterly confused me. And then crashed.
There are also web based ones. My initial survey of these suggests that
they are prettier and easier to use, but perhaps clunkier, or tied into
specific bank systems.
Beans means…?
So, being a programmer, the obvious answer is to attempt to roll my own.
As a learning exercise ;-) Though I’ll attempt various sketches of this in
Haskell, I’ll start off by trying to implement it in Modern Perl:
specifically the
Moose
OO framework, using various niceties such as
the pretty declarative syntax of
MooseX::Declare.
Every project needs a good name! But this is just a learning exercise, so for
now I’ll call it “Beans”.
I’m hoping this will end up an ongoing series of posts, please feel free to
follow along at the
Beans git repo if you like,
or to suggest improvements, for example:
- a better project name
- shinier ways to do this in Moose and Modern Perl
- how this would be more elegant in Haskell/Lisp/etc…
As always, these posts will be fairly rough drafts, I’m hoping to tidy this up
into a more finished article soon, so any comments are really welcome to help
me polish it up!
Declarative code
In this installment, I’ll just define a data type for a line item in Beans.
You can see the current code as of this evening,
but let’s look at it in detail here.
We’ll start off by using Moose, and declaring our class:
use MooseX::Declare;
class Beans::Item {
...
}
Now we’ll want to declare some fields for our class. For example, every
payment made or expected will have a value:
has value => (
isa => Num,
is => 'rw',
required => 1,
);
What’s that? Perl has types?! Yes indeed, Moose gives us types, and
automatically validates against them. So when we try to create our object,
we’d find that:
my $obj = Beans::Item->new( ); # fails, value is required!
my $obj = Beans::Item->new( value => "foo" ); # fails, "foo" is a string
my $obj = Beans::Item->new( value => 10.00 ); # OK! 10.00 is a number
I’ve cheekily missed out a few details though… Num isn’t a Perl
builtin keyword, so we’ll need to import it. In fact, while we’re at it, let’s
pull in Str too, so that we can add a couple of string fields at the
same time:
use MooseX::Types::Moose qw/ Num Str /;
has name => ( isa => Str,
is => 'rw',
required => 1,
);
has comment => ( isa => Str,
is => 'rw',
);
Now we also want to be able to add the date of the expected payment:
use MooseX::Types::DateTime qw/ DateTime /;
has due_date => ( isa => DateTime,
is => 'rw',
required => 1,
);
This means we could do
my $obj = Beans::Item->new(
value => 10.00,
due_date => DateTime->new(
year => 2010,
month => 6,
day => 30,
),
);
# but I'd prefer to be able to do
due_date => '2010-06-30',
And we can indeed make this prettier using coercions!
use DateTime::Format::Natural;
my $dt = DateTime::Format::Natural->new( prefer_future => 1 );
coerce 'DateTime'
=> from 'Str'
=> via { $dt->parse_datetime($_[0]) };
# We'll need to tweak the due_date declaration too...
# (coercions don't run unless you ask for them)
has due_date => ( isa => DateTime,
is => 'rw',
required => 1,
coerce => 1,
);
While every line item will have an expected due_date, we’ll also want
to keep track of what date the item was actually paid, if it has
been paid. As this is uncertain, we use the Haskell-inspired Maybe
type. (As far as I can see, this isn’t actually as powerful as Haskell’s
Maybe monad, it’s more like a nullable type).
use MooseX::Types::Moose qw/ Num Str Maybe /;
has paid_date => ( isa => Maybe[DateTime],
is => 'rw',
);
Once we’ve got this type, we can calculate a boolean field based on it.
The paid field will be true if paid_date contains anything,
and false otherwise. Let’s try defining it like this:
use MooseX::Types::Moose qw/ Num Str Maybe Bool/;
has paid => ( isa => Bool,
is => 'rw',
lazy => 1,
default => sub {
my $self = shift;
defined $self->paid_date
},
);
The default code block gets called the first time we ask for
the field. There are a couple of problems with this of course – once it’s
set, if we change the paid_date, this field won’t change. We’ll come back to
this later, but here are some ideas:
- change it into a method
- use immutable objects, so that setting this lazily on first request is
always the right thing to do
- use triggers to update paid when paid_date is set
(and vice versa! setting the boolean flag could set the payment date to
today’s date, for example).
Now, though we specified that the name should be a string, nothing is
preventing us from passing the empty string ""… but Moose allows
us to define a better type constraint here too!
use MooseX::Types -declare => [qw/ NonEmptyStr / ];
subtype NonEmptyStr
=> as Str
=> where { length $_ };
# so now we can modify this definition to:
has name => ( isa => NonEmptyStr,
is => 'rw',
required => 1,
);
>
Finally, let’s add a list of tags. Just for now, we’ll define these as an
array of non-empty strings:
use MooseX::Types::Moose qw/ Num Str Bool Maybe ArrayRef /;
has tags => ( isa => ArrayRef[NonEmptyStr],
is => 'rw',
default => sub { [] },
);
Notice how we’re using default again to set the default value to
an empty array.
That’s it for now! Next time around we’ll maybe look at parsing and displaying
line items, and start to do useful things with them.