There’s a good article at Ars Technica talking about even more ways to trick out your Vim text editor. It includes links to:

• platform-specific desktop GUI versions (win32/linux: GVim; Mac OS: MacVim)
• MiniBufExplorer add-on
• Automatic text completion via Omnicompletion
• Vim wiki
• script repository
• other add-ons for IDE-like behavior or a more simple text-editor behavior for new users

Worth checking out if you spend your day moving through code.

Note: any attempts to turn this into a vi vs. emacs discussion will be suppressed mercilessly.

Recently, I’ve been asked to add tagging to the guided reports section. I used this as an opportunity to implement a mixin that’s similar in spirit to acts_as_taggable for Ruby’s ActiveRecord ORM.

I called this class, “C4::Taggable”, and it will inject tagging-related methods to any class that uses it. Normally, it’s bad form to use Exporter in OO code, but that mainly applies to when you’re defining a class. However, when you’re defining a mixin, I believe the use of Exporter is justified, because it’s one of the easiest ways to inject methods into a namespace.

To illustrate this technique, here is an outline of how C4::Taggable is implemented. (For brevity’s sake, the method bodies were omitted.)

C4::Taggable

  package C4::Taggable;
  use strict;
  use warnings;
  use base 'Exporter';
  use C4::Context;
  our @EXPORT_OK   = qw( add_tag remove_tag tags search_by_tags                );
  our %EXPORT_TAGS =   ( mixin => [qw(add_tag remove_tag tags search_by_tags)] );

  sub add_tag        { }
  sub remove_tag     { }
  sub tags           { }
  sub search_by_tags { }

  1;

Notice how C4::Taggable exports tagging-related methods.

Next, C4::Report is outlined. Note that by using C4::Taggable, C4::Report became taggable by virtue of having tagging-related methods for C4::Taggable being mixed into it.

C4::Report

  package C4::Report;
  use strict;
  use warnings;
  use C4::Context;
  use C4::Taggable ':mixin';

  sub new            { }
  sub id             { }
  sub borrowernumber { }
  sub date_created   { }
  sub last_modified  { }
  sub savedsql       { }
  sub last_run       { }
  sub report_name    { }
  sub type           { }
  sub notes          { }
  sub update         { }

  sub table          { }

  1;

Isn’t that simple? Now any time you want to add tagging to a class, you just use C4::Taggable.

What’s the catch?

The catch is that C4::Taggable will have expectations about the host class and the database schema. The host class has to provide a few methods so that C4::Taggable can introspect enough to generate the right SQL. There will also be a table you have to create that has a predefined structure and naming pattern. I won’t go into any more detail here, but suffice it to say that for C4::Taggable to work, certain conventions have to be followed.

To me, it’s a small price to pay, because it makes it ridiculously easy to add tagging to other classes should that ever be necessary or desired.

David Schuster has announced a meeting of KUDOS (Koha Users and Developers of Open Source) at the annual meeting of the American Library Association in Chicago.

Date: Sunday, 7/12/2009
Time: 1:30 pm - 3:00 pm>
Location: Hyatt Regency Chicago (not the Hyatt that’s close to the
convention center)
Room: Grand Suite 3

Hi all,

I’m Daniel Sweeney, and I’m Senior Business Analyst at LibLime. Galen and the Coders have written a lot of the posts on this blog, while I’ve been staying in the background. If you’re a LibLime customer who’s interested in custom development, though, you’ve probably heard from me. I thought I’d write up a quick post about how the analysis process works at LibLime.

As a business analyst, I’m responsible for writing up specifications for new functionality in Koha that libraries are interested in sponsoring. The general idea is that the specification should be something that both the staff at the library and the programmers at LibLime can understand and agree on. That way LibLime knows that what we’re building matches what the library wants, and the library knows what’s going to arrive when LibLime delivers.

I should mention, the title “Business Analyst” makes it sound like I rate bonds or something. A better title might be “Library Analyst,” but the BA title is pretty standard in the IT industry, so we kept it at LibLime.

I usually start the process off with a conference call with staff from the library who do the work that Koha supports. My usual tactic is to make believe that I’ve never worked in a library, gone to library school, or ever talked to anyone in the library community at all. (None of those things are true, but playing dumb can really work for  you.)

I tend to talk a lot, but the call is really an opportunity for me to listen. I want to find out what the library is doing, and what the context is for the changes we want to make in Koha. I usually try to find out about things that sound like they’re incidental to the change that the library wants, but can show me how people are doing their jobs. That’s valuable when writing up a functional specification that will affect how people at the library do their jobs.

Once that call is done, I write up a preliminary specification. I usually try to do this right away so that things are fresh in my mind. The preliminary specification is always subject to revision–what I really want is to get a good set of ideas down on paper so that I can talk to both the development staff here about the ideas and to the library again. Sometimes I completely rewrite that spec multiple times, either because something is not clear, or because we develop some of the ideas better as we talk about them.

Finally I reach a point where the spec makes sense to the library and matches what they wanted in the first place. It’s harder than it sounds to turn a simple idea that sounds like common sense into a detailed document that describes how it will fit into Koha.

Once the library understands what the spec says, and accepts that it’s right, then the programming side takes over, and reviews the spec to get a detailed idea how long it will take to actually do. This estimate drives the quoting process. The specification is part of the quote that goes to the library that sponsors development, and we need to get the details right so that we know how much work it will be.

In a lot of ways the Business Analyst is the bridge between the library and the programmers. I hope that gives people at Koha libraries who’ve never sponsored any development an idea of how the process works. I do subscribe to the comments to the blog, so feel free to ask questions there about the process.

Henri-Damien Laurent, Release Maintainer for Koha 3.0.x, has published a new Git tree with a candidate for Koha 3.0.2. From his original announcement:

I am glad to announce that work for stable version 3.0.2 is well advanced.
You can test it on koha-maintenance project
see http://git.koha.org/cgi-bin/gitweb.cgi?p=koha-maintenance.git;a=summary
for the code.

How can I test it ?
if you have a dev version :
git remote add maintenance git://git.koha.org/pub/scm/koha-maintenance.git
git fetch maintenance
git branch –track testing_3.0.2 remotes/maintenance/master
git checkout testing_3.0.2

Any bugs should be reported to Henri-Damien directly — since the changes have not been pushed yet to the 3.0.x branch in the main public repository, any issues are technically not bugs against that maintenance branch. Henri-Damien and I discussed whether or not to create a new product or component in the bugs database for his maintenance tree, and for now have agreed not to do that. Once initial testing of his koha-maintenance tree has been completed, Henri-Damien will be merging it into the main repository’s 3.0.x branch and any remaining 3.0.2 issues can be filed in Bugzilla. Of course, if this doesn’t work out, say if if Henri-Damien gets absolutely deluged with emails about the 3.0.2 candidate, we can revisit this decision.

Many thanks to Henri-Damien for working so hard on 3.0.x.

I just sent a call for the next general IRC meeting of the Koha project, which will take place on 3 June 2009 at 10:00 UTC+0. Here’s a link to one time zone converter. We’re currently seeking a major coffee company to sponsor caffeine for North America and New Zealand. The initial agenda for the meeting is on the Koha wiki; to propose new items, please update the wiki page or post to the Koha mailing list. At the moment there are three standing agenda items:

1. Update on 3.2
2. Update on 3.0.x
3. Follow-up on actions from the 6 May 2009 IRC meeting.

I look forward to seeing everybody there.

The first general IRC meeting of the Koha project in a long time took place today. For those who couldn’t make it, a log of the discussion is available. The agenda for the meeting is on the wiki.

Some highlights from the meeting:

1. Koha 3.2 will be frozen for new features at the end of August. After two months for testing and translation, general release will be at the end of October. I will release a pre-alpha version of Koha 3.2, which will include the acquisitions work by BibLibre, during the month of June, and I plan on another intermediate pre-alpha release between June and August.
2. Henri-Damien Laurent plans two releases in the 3.0.x maintenance branch, 3.0.2 in June and 3.0.3 shortly thereafter to reconcile differences between the 3.2 tip and the 3.0.x branch.
3. There was a long discussion of the Koha bugs database. At KohaCon, users and potential users of discussed ways to keep track of potential developments to Koha and arrange sponsorships to fund the enhancements. We’ll be using the Koha bugs database to do this, and this will mean some changes to it (adding a field to record sponsorship status) as well as promoting the use of it.
4. I will start a weekly blog for news about the progress of 3.2.
5. We’ll start sending a monthly FAQ to the Koha mailing list and improve the welcome message to new subscribers. I will draftask Nicole Engard to help out with composing it, but if you have ideas for what this message should include, I’ve started a page on the wiki.
6. Nearly two and a half hours into the meeting, we talked a bit about KohaCon 2009, which was very successful. Thanks to David Schuster and the Plano Independent School District for hosting it, and thanks to the members of the KohaCon planning committee for doing a superlative job.

I would like to thank everybody who participated. Special thanks to MJ Ray for taking care of many wiki updates during the meeting. I’ll be calling another IRC meeting to occur in early June.