pecuniary difficulties

Master of my Own Destiny

2005-07-27T20:54:00.000-07:00

I've decided that I don't like blogger for the same reason I don't like canned finance software - I want to have full access to my data. In the interest of holding on to my data, I've moved my blog to WordPress running off my server.

You can find it at http://www.ljug.com/pecuniary

Rationale Revisited

2005-07-27T08:24:00.000-07:00

I was thinking more about my reasons to embark on this project, and thought I would get them down on... err... paper? Well, somewhere.

I was reading a page that was discouraging the use of proprietary binary formats. That sounds a lot like what I am saying, but it's not quite the same. That same page lists some alternative open-source packages for personal finance. The problem is, I am still locked in to a single program. Sure, I can move my data around easily, but heck I can do that with ~~Quicken~~ my current package, too. I want to have my data accessible from a variety of programs and scripts without having to export and import data.

As an analogy, consider HTML. I use BBEdit a lot for editing raw HTML. But I also use TextEdit. And, until the UI drives my batty, Nvu. And sometimes I'll whip out a Perl script to process my documents. I've even used Visual Studio to edit HTML, and I will often use more than one editor at the same time. My choice of data storage (HTML) does not dictate my choice of editor. That's the power I want with my financial data. Now, I could just stick it in a text based format, but a database offers me options for searching and relating data that are hard to duplicate with text formats (though not impossible). Where HTML is SGML with added rules, this will be a SQLite database with added rules. The fact it is binary just means you will have to use different editors to read and modify it. It would still be perfectly possible using existing tools to create and modify your financial data, just like you can with HTML. And just as easy to screw it up.

Directions

2005-07-26T15:39:00.000-07:00

I should probably lay out some directions for this endeavor. Nothing is set in stone, but I need to start somewhere. First, I plan to do all my work on the Mac. That's not to say this format won't be relevant for Windows, Linux, etc, it's just that I really don't care about those platforms. I will be using technologies and resources available on Mac OS X as my guide. If you have a problem with that, go away. Of course, I doubt there will be anything Mac-centric about this format, though the first things to use it will probably be written by me and therefore will only run on OS X. In fact, I will probably focus on OS X 10.4, Tiger.

Given that focus, I expect to use a handy SQL-based database. Since 10.4 comes with SQLite pre-installed, I will be concentrating on it. I assume any SQL-compliant database will work (e.g. MySQL), but my focus will be SQLite. I would also like to have the broadest choice of development environments available. I expect to be able to use Cocoa with Objective-C, Carbon with C++, AppleScript, REALbasic and as many others as possible. The idea is to increase access to the data so simply tools can be built around it. SQLite is accessible from all those environments, so it seems like a perfect fit.

It Begins

2005-07-26T15:15:00.000-07:00

Well, here goes nothing. I have finally found a reason for entering the blogosphere (yes, I am sure that is a newbie thing to say). After years of using a commercial personal finance manager (you know like Quicken - a lot like Quicken), I have decided I want to move on. I'm tired of handing over my personal financial data to someone else's software.

Of course, I'm not sure I have the time to right my own. It might be entertaining, but I have too many other commitments in my life. Buying another package doesn't really help. I would just be handing my fate over to some other entity. No, I want control, but I don't want to write yet another account tracking app.

My idea, then, is to define a file format instead. Specifically, I would like to define the structure for storing financial information, like bank accounts, transactions with info about payee, amount, date, check number, etc. Then I (or others) can whip up small (or large) applications that access the data. I can start out with apps to enter transactions. Maybe one to import data. Add one to report totals. Another to reconcile bank statements. But I would only have to add the pieces I wanted. If the format succeeds, I can start using apps written by other people.

Of course, community feedback would be great. For now, I will use this blog to post my progress and thoughts. At some point, if there is enough interest, I may add forums and a Wiki. We'll see how it goes.