Mostly apologies and excuses, but some Ruby at the bottom
So. I have a new job which I enjoy tremendously but it keeps me busy during daylight. I come home to spend a bit of time with my family, till later at night. Then, if I can manage it, I get do a bit of Ruby. Not a lot mind you, but it's fun.
Ackbar (don't go there, nothing to see, move along)
I've mostly decided on the direction Pimki is going in (I know, I know I promised to publish the survey results ages ago; I'm getting to it, honest!). In order to have the best solution for Pimki, I am writing a Rails ActiveRecord adapter for KirbyBase - the pure-ruby, plain-text DBMS. This has been taking most of my OSS time of late. Would have taken more but for the most excellent support from Jamey Cribbs, KirbyBase's developer.
Instiki is currently in weird zombie state. I think Alexey is in a similar state, and has very little time to update it. When I'm more or less done with Ackbar (i.e. it does what I need it to to support Pimki), I will take the then most current working version of Instiki and build Pimki2 on it + KirbyBase. This will probably be the last time I will do that. If there is any future work on Instiki - new features, bug fixes etc - I will evaluate them one by one and port them to Pimki only as I see fit. The current pace of Instiki development (looong periods of inactivity followed by MASSIVE, half done changes.... with minimal version increases), is just not something I can deal with.
So we get to the 1158th project listed on Rubyforge: Ackbar. What this means for Pimki users (myself included) is
A pure-ruby database: no madeleine crap, no external dependencies, no cross platform issues. This is where SQLite fails. By the nature of Pimki it has to Just Work. Mucking about with repackaging SQLite is an unnecessary complication both for me and for my users. (Not that I don't thing my users could handle a simple DLL, but if there are any problems - I can't do anything about them).
Plain text: In a pinch, it's really easy to get at your information. Again, no madeleine binary formats that cause me headaches between versions. The DB schema can be managed easily with AR migrations.
The hard bit is that KB is not SQL based. This means that I do not simply provide a channel for it, but have to override key methods in ActiveRecord::Base and replace the SQL construction with direct DB calls. It's also a nice exercise for me as I'm learning a lot on Rails through its underbelly - reading the source, not just the API docos.
So far I have the basic schema operations working, and most of the CRUDs (delete still won't, but I'll spank it into submission). I am currently fleshing out the tests to make sure that further development is stable and that features already implemented do cover all aspects. After that it's foraying into the AR associations (all the nice has_xxx methods). At this stage I don't think I'll use the built in Link_many and Lookup functionality of KB. I'll let AR handle that as a regular relational database.
The other downside is that there are minor API changes from "vanilla" ActiveRecord. After all, some of the SQL features just don't make sense, while a more rubyish interface is a natural extension. So while you may not be able to just drop it in place of another database in an existing Rails app, it won't be a lot of work to convert.
That's it for now. I hope I get time update this blog (and - god forbid - read other blogs) in the coming months. Even if I don't please be assured that I'm hard at work on Ruby. I have never been happier since giving up commercial programming, so that when I DO get to program, it's done the way I like it. I just hope the future quality of my projects will show this.
Previous Topic
