Fortunately, Google has now released a compatible version of the plugin. Tonight I upgraded my installation of Firefox to 3.5, updated Google Gears, and tested ‡biblios, and I’m happy to report that it’s now working.

There were a couple quirks:

1. When I upgraded Firefox, it didn’t detect that a new version of the add-on is available. I had to remove the old version of the add-on, then go to http://gears.google.com/ to install Gears.
2. When I went there, it didn’t offer me the chance to install Gears. I eventually figured out that I could go directly to the terms of use form to force the download and installation.

Basically the mechanism uses the same git rebase –interactive that you can use to squash commits, but instead opens one for editing mid-rebase.  Then you can revert it, and use git add -p filename for an interactive selection of chunks to leave in or out.  Add some git commit for your new pieces, and then git rebase –continue to finish.

Complete steps here.  The payoff is that git add -p is a great complement to interactive rebase.

If this were just my personal contention, I would couch this in terms of an RFC to deprecate the usage.  But we don’t get a choice here: DBI is telling us “don’t do it”.

Please refer to the DBI perldoc:

When all the data has been fetched from a SELECT statement, the driver should automatically call finish for you. So you should not normally need to call it explicitly except when you know that you’ve not fetched all the data from a statement handle. The most common example is when you only want to fetch one row, but in that case the selectrow_* methods are usually better anyway. Adding calls to finish after each fetch loop is a common mistake, don’t do it, it can mask genuine problems like uncaught fetch errors.

That last sentence is the most concrete and important (hence my bolding).  Moral of the story: don’t do it.  Or if you think you have to, at least comment why, like:

$sth->finish();  # FIXME: leaving data unfetched, should rework query

From Henri’s announcement:

We are very happy to announce Koha 3.0.2 Stable has been released on
http://download.koha.org/
Its name is koha-3.00.02.tar.gz You can download file and signatures

You can check the integrity of the package; either by verifying the provided
GPG signature (.sig) or by comparing the MD5 checksum:
c3fee4abbb29c88f97a5f7db5fe9eebf koha-3.00.02.tar.gz

I have also tagged this in Git as “version 3.00.02 final”
v3.00.02-final

…

This release is bugfix only release, and does not include new
features which would require some database changes.
It does add some databases changes though but only to FIX bugs.

The next release scheduled in July will include features which are now
in master but not ported yet to stable because of database change
required. That is to say mainly many content enhancement were not
integrated Librarything, Syndetics, Baker&Taylor, Babeltheque, and
BranchTransferLimits.
But we are willing to make them into the next release which will come
out as soon as possible in July.

Update: BibLibre’s announcement (in French).

• 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.

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.

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

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.

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.

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.