Regdel

I'm using Ruby 1.8 to develop Regdel with and Ruby 1.9 to demonstrate Ruby with.

Its been an interesting experience and I usually feel that supporting varied runtime environments results in higher quality code.

The most recent hurdle involved Ruby class variables. I'm not sure why, but Ruby 1.9 did not like how I was using class global variables. You know, the ones like:

@@something = "else"

Instead, I've switched to using attr_accessors, like this:

this.something = "else"

Thankfully, both Ruby 1.8 and 1.9 are cool with attr_accessors.

After experimenting with the alternative database model I posted about recently, I've thought more about involving git and the ledger-cli file format.

I like this idea, and took a step in this direction today simply by adding grit as a requirement. It is only being used to display some information about the repository, but its a start!

I'm experimenting with a new data model, inspired by ledger-cli and datamapper single table inheritance.

Take a look:

# Xact = transaction
class Xact
  include DataMapper::Resource

  property :id,Serial
  property :posted_on,Integer
  property :memorandum,String
  has n, :assets
  has n, :liabilities
  has n, :equities
  has n, :expenses
  has n, :revenues
  has n, :banks

end


# Postings are the individual account changes
class Posting
  include DataMapper::Resource

  property :id,Serial
  property :type,Discriminator
  property :xact_id,Integer
  property :commodity,String
  property :quantity,BigDecimal, :scale => 2, :precision => 5

  belongs_to :xact
end

# Single table inheritance for every account
class Asset < Posting; end
class Liability < Posting; end
class Equity < Posting; end
class Revenue < Posting; end
class Expense < Posting; end
class Bank < Asset; end

The idea here is that each account is an object. The code above has the account types and then a bank account. This is obviously pre-alpha code, but the idea is there.

Its a big departure away from the way I've traditionally modeled accounting databases, so why bother?

I like this model because its super simple, and because it leverages some quality work that's already been done with datamapper, and it supports the sort of quick, instant reporting that is core to ledger-cli, especially the balance feature.

I'm interested in aligning Regdel with ledger to add to the traction its established. Open source accounting and bookkeeping software could use a little unity in my humble opinion. For awhile I felt that the single plain text file was a serious limitation, but those limitations might be alleviated with the combination of a SQLite and git, but that's a topic for another day.

Feedback about this new data model is much appreciated!

Quick Review
I'm very pleased with how the alpha version of Regdel has developed. I didn't have a concrete plan as I was pretty much dabbling in, experimenting with, and learning about the Ruby and Rack-based Sinatra web development framework.

In the process, I've come to realize how much I like developing with Ruby, and some Ruby libraries are incredibly helpful. Concurrently, I've been focusing on managing my time better and trying to get more done in less time by automating repetitive tasks, planning my work, and setting goals.

For instance, I've started to use Rake for organizing tasks, more specifically running tests, generating documentation, and automating the deployment of redgel to the demo.

Now I need to start doing some planning, but I'm a little hesitant. I get frustrated with plans because they often don't happen as I expected. If I don't update my written plans, events diverge and the plan becomes totally out-of-date. Frustrations aside, I recognize the value of planning, so I'll start with a broad stroke.

Planning the Regdel Plans
I'm not going to jump directly into the plans just yet! I want to put a little planning into how I will approach the process. I'd like to have a simple plan reference so that it will be easy to keep updated, but where should it be?

Options:

• In the repository, alongside the README.md and CHANGELOG.
• A page in this blog.
• Github.com wiki

I like the idea of keeping it in a plain text file in the repository, but then again I'm concerned it won't get enough visibility. I'm experimenting with the automation of publishing documents like these that occasionally and irregularly update. If that works well, maybe keeping Regdel plans in the repository is the right choice.

While working on Regdel, I've again come across ledger-cli, a C++ software command line application which uses a text file for bookkeeping information. Ledger-cli is primarily a reporting system, i.e. it is not used for data entry, data manipulation, or similar. This was done on purpose, and in many cases that's a good thing.

I've dabbled with ledger in the past, but this time I took a serious look at it, and I'm actually starting to use it to some degree. Not for my main bookkeeping database, but when I want to quickly make a note of a transaction. I simply jot down the transaction into a text based ledger file. I'd considered doing this before but was concerned about managing the file(s), and instead added a feature to PBooks for entering simple notes. Nowadays, however, thanks to git I'm feeling a lot more comfortable with basic file management.

The significance of all this to me is that ledger-cli and its use of static file formats make it easy for a single person to quickly enter a couple of transactions without fear of being able to summarize the contents. The ledger-cli parser and memory model of the data can output the entire dataset as XML, which really liberates the entire kit-and-caboodle. That is really awesome when you think about it, and its importance should not be underestimated.

While ledger-cli can easily handle the processing of hundreds of thousands (millions?) of entries, I loathe to think of the work involved in the data entry. The ledger file format attempts to support faster entry of data with the use of xacts, but I can't comment on those as I've actually never tried using them. With PBooks, I developed a method of importing data from CSV files, but before I get into that, let me explain a tiny issue I have with the name and terminology of ledger-cli.

I find it ironic that ledger calls itself ledger, because in bookkeeping terms, I'd consider the file its centered on a journal. In my experience, a journal is the point of initial data entry, and journal entries contain multiple accounts. Conversely, ledgers are account focused, with references back to the original journal entry.

Not a big deal, but relevant. With PBooks, I wrestled with workflow for awhile because traditionally, data is entered into the journal as transactions take place, but in our technological world, I found it easier to leverage the CSV formatted data exports of my online bank accounts - ledger data.

The solution I came up with was to import CSV account data into the ledger as "unmatched", and then give the user the ability to match each transaction to one or more corresponding account(s). It works well for me in practice, and it was possible to created shortcuts using the transaction memos. I consider that workflow solution to be similar in some ways to how ledger-cli uses xact statements.

While the philosophy of ledger is truly solid, reliable, and even elegant (and its starting to really build momentum and traction in the open source world), I'm not sure how realistic it is for the majority of small businesses to use for their bookkeeping and accounting purposes. True, its possible to use something like GnuCash to manage a ledger file in XML, but I don't think that makes much of a difference for reasons I won't get into right now.

Instead, let me write about Regdel. I've been considering a lot of different ideas but haven't come up with a clear direction. I'm thinking about:

• graphical user interfaces
• data storage
• access controls
• work flow
• reporting
• data management
• automation
• revisions
• backups

More to come...

I've deployed an alpha demo of Regdel:

Redgel Demo

There are several things broken at the moment, but its nice to have something public!