Henri-Damien Laurent, Release Maintainer for Koha 3.0, has announced the release of Koha 3.0.2, the second maintenance release of Koha in the 3.0.x series. The release tar file can be downloaded from http://download.koha.org/koha-3.00.02.tar.gz.

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

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.

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.

If you were wondering about the opinion of the newly installed President Obama on the topic of libraries, you needn’t speculate. Instead, you can refer to the record of his 2005 speech to the ALA Annual in Chicago.  How that praise will or will not translate to effective policy is a question for a more political blog…

Even though we are halfway through the first month of the new year, I thought it would still be a good time to bring up my programming-related New Year’s resolutions.  With the way the landscape in programming changes every few years it seems only appropriate to encourage personal growth.  I have found previously when I do this it also strengthens the languages that I already know.  Learning Rails re-inforced the idea not only of testing, which is stongly built-in to the framework, but also concepts like MVC (Model-View-Controller) architecture and DRY (Don’t Repeat Yourself) concepts.  Here’s what I have set as personal goals for 2009:

• Learn a new language.  I’ve previously worked in mostly Java and Perl, with a bit of Ruby on Rails thrown in.  So I could claim Ruby on Rails and still learn a lot (for that matter, Perl as well…) but I want to challenge myself and try to learn Python.  Initially, there seems to be a good deal of overlap between Python, Ruby and Perl, so I think that should help me.  I will start with Dive into Python as that has a complete textbook online.
• Learn 2 new frameworks.  I have not completely decided on what to do here.  Looking at our biblios project makes  me want to learn Google Gears.  If I learn Python, Django, a web framework similar to Rails, would blend nicely.  Catalyst might be a great fit that could directly impact Koha.
• Contribute to one other open-source project or consistently attend a code group.  These will probably go together.  Here in Atlanta, where I live, there are groups for all the languages and most of the frameworks that I’ve mentioned above.  They tend to meet once a month and often have side meetings to work through learning aspects or book clubs related to the topic at hand.  It’s a great way to meet people and learn what others are doing in the same field of interest. Meetup.com is where I found the Rails group I (very) infrequently attend and actually heard about the Perl Mongers group in the area that I’m hoping to attend this year. Often, you can find people in need of help for various projects, or who are looking to help if you have a project of your own that needs help.  Meetup is international and it’s very easy to start your own group if one isn’t already meeting. Maybe I’ll even start a Koha group??

So feel free to share your goals or resolutions in the coming year in the comments below, or even the methods you use to improve yourself.

I’m pointing out a change that Frédéric Demians made recently to the Git usage page on the Koha development wiki.

In order to avoid mangling non-ASCII characters in commit messages for patches submitted via git-send-email, Frédéric suggests forcing the Content-Type header in patches prepared by git-format-patch to specify UTF-8. This can be configured like this:

git config --global format.headers "Content-Type: text/plain; charset=\"utf-8\""

‡biblios currently has some (as of yet) little used code which sends signals at certain key events to any javascript listeners who may be interested: opening a record for editing, saving a record, performing a search. This is good for notifying listeners of the event with some data relating to the event.

With this mechanism, however, it isn’t possible for the listeners to act as filters for the data. I’d like to be able to configure ‡biblios to run marcxml data through a series of arbitrary filters (possibly even allowing for the filters to perform AJAX operations to allow for server side processing).

What I imagine is something alongs these lines:

In the ‡biblios configuration file, a section defining filters for certain events:

<filters event="save">
  <filter name="update003">
     <code>update003(marcxml)</code>
  </filter>

  <filter name="update999">
     <code>update999(marcxml)</code>
  </filter>
</filters>

‡biblios would then, at each predefined event type (e.g. save) send out the save signal but also run through any filters defined in the configuration file, evaluating the javascript code contained therein. Each type of filter would know to expect the marcxml as a parameter and would be required to return the (possibly modified) marcxml to the caller.

I imagine some javascript code like this to make this happen:

  // marcxml is an xml document
 var filteredxml = marcxml;
 for( var i = 0; i < filters.length; i++) {
   filteredxml = eval( filters[i].code ); // filters[i].code accepts the already defined marcxml variable
}
return filteredxml;

In this way, administrators or developers could modify the behavior of ‡biblios with respect to marcxml handling simply by writing a javascript file containing functions to be referenced from the biblios configuration file. The javascript file containing these filter functions would be loaded into ‡biblios via the already existing plugin loading mechanism.

I’m happy to announce that Koha 3.00.00 has been released.

It’s available for download from the usual location:

http://download.koha.org/koha-3.00.00.tar.gz

Check out the release notes.