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.

This morning one of the Koha Librarians created a page on the Koha Wiki for everyone to share their Custom Reports/SQL statements. This from Owen at Athens County:

Koha users have begun building a library of useful SQL statements for use in building Koha reports. It’s on the Koha Wiki. You can add your own or put in a request for a report you’d like to know how to do. If you’d like to contribute you can either register on the site or use OpenID to log in. If you’ve never edited a wiki before, be sure to check out the Formatting Syntax article before you jump in.

Technorati Tags: koha

I’m at the Developers’ Meeting at KohaCon 2009 and they just went around the table with Tips & Tricks - here are my notes (sorry it’s not cleanly written):

Chris - Git has a built in garbage collector $ git gc - if you run it after creating a branch and before checking it out, makes switch branches much faster (make a branch, run this and then checkout the branch).  Also cluster ssh http://sourceforge.net/projects/clusterssh/ is a handy tool

Jesse - has a simple shell script that builds the environment

Joe - has a script he makes on different servers that he uses to get his shell to where he wants it to be for testing, it sets his self created variables and standard values (http://blogs.liblime.com/developers/2009/04/19/simple-shell-trick/).  Also he posted a good tip on the LibLime blog: http://blogs.liblime.com/developers/2009/04/10/simple-git-trick-for-bash/

Thomas - it’s important to remember that the real world of records is much more complicated than the record you see most frequently, so when testing things trying the really hard MARC records (Josh has a test file of really tough MARC records) will give you a better test base.  In the real world, you will find typos in ISBNs printed in the book - ISBNs that can’t possible be right or match our matching rules.  And also remember that records will lie about their encoding all of the time - and they seem to prefer it that way. 

Galen - One of the things that he does since he can’t claim to have the visual design skills that Owen does - he has become a real stickler about the HTML that is on the OPAC & Staff client - making it appear as XHTML.  There are tools in Firefox that can make for a good development environment: Fire Bug, for validation the HTML validator plugin in excellent at doing it quickly without submitting your site to an online validator, Firefox accessibility plugin lets you run automated tests against your site to meet requirements for ADA, Also the web developer plugin, Yahoo! Dev tools are slow, but they provide valuable info.  Something that is useful, but not a dev tool, is the Zotero plugin (citation manager) www.zotero.org — geared toward people to do lots of research online.  

Corey - Hasn’t done much dev work, but as far as install goes, if you install on red hat linux make sure you have lots of caffeine and the RPM packages

Agnes - Adds to Corey’s comment by saying she repeats his comment for 64 bit Zebra

Brendan - Fetch & Pull do not to the same thing!  He likes the graphical SQL interface and uses Cocoa (http://sourceforge.net/projects/freshmeat_mysql-cocoa/)

Everyone - Use Screen: http://www.gnu.org/software/screen/

Danny - took notes too: http://dbouman.blogspot.com/2009/04/general-koha-tips-and-tricks.html

Technorati Tags: kohacon09

Here’s a file I use to get myself into the correct environment for a given Koha installation. I create one of these for each Koha I’m using or testing, then just source the file into my shell to put myself in the right directory, with the right ENV variables set.

#!/bin/bash
#
# source this file, e.g.:
# . ./standard_export.sh

export KOHA_CONF=/home/atz/koha/etc/etc/koha-conf.xml
export KOHA_LOG=/home/atz/koha/log/production-intranet-error_log
export OPAC_LOG=/home/atz/koha/log/production-opac-error_log
export PERL5LIB=/home/atz/koha/production/koha
echo KOHA_LOG  = $KOHA_LOG
echo OPAC_LOG  = $OPAC_LOG
echo KOHA_CONF = $KOHA_CONF
echo PERL5LIB  = $PERL5LIB
cd $PERL5LIB

Having done battle with the koha code base for a few months, there have been too many times when something conceptually simple has been surprisingly difficult to express in code.

With KohaCon coming up soon, I thought I’d throw out this hypothetical question to get your creative juices flowing.

If you could do it all over again, how would you go about creating a Free library automation system from scratch?

Read the rest of this entry »

Chris Cormack shared this useful trick for keeping track of what git repo you are currently using/editing. Stick it in your .bash_profile to have your prompt adapt to the repo you are in!

function parse_git_branch {
  ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
  echo "("${ref#refs/heads/}")"
}

RED    ="\[\033[0;31m\]"
YELLOW ="\[\033[0;33m\]"
GREEN  ="\[\033[0;32m\]"

PS1="$RED\$(date +%H:%M) \w$YELLOW \$(parse_git_branch)$GREEN\$ "

Anyone who has ever watched the MySQL query log while koha serves requests knows that koha makes A LOT of repetitive SQL queries for every request.  Most of these requests are for individual values in the systempreferences table.  There is also another large batch of queries for data from the language_descriptions table.  The queries are not that heavy by themselves, but there are way too many of them happening per request, and it’s for the same data every time.

In an attempt to minimize the number of repetitive queries, I tried to make koha use memcached.

Read the rest of this entry »

There is much talk in the United States right now, between conservatives and liberals about “values.”  The conservatives feel that we’re compromising the values that made this country wonderful, and that the liberals are doing it, etc, etc, ad nauseum.  I’ve watched that discussion with aloofness, because I’m of a third opinion altogether.

But my RSS feed threw this little tidbit about “values” at me yesterday, and I just couldn’t resist.  Consider the values that make an open-source software project great–it varies, of course, but Eric Raymond established in The Cathedral and the Bazaar that what made them awesome was that they served some useful purpose, and people found it, and liked it enough to chip in and help.  I’m okay with that definition, for now.

In Kier Thomas’s article, he moans a little about Firefox and Ubuntu losing track of those features that made them so incredible successes, and I think he may well be right.  If so, I think it behooves every FOSS project–including Koha–to pay attention.  What makes this project so great?  If you’re not currently developing, that’s okay, but have you told someone who is why you use Koha?  What value does it fill for you and your institution?  What’s the slickest part of it, that impresses you and your staff?

As developers, we’re frequently isolated from the day-to-day users of the software we develop, so we don’t know what sorts of real-world uses you’re putting it to.  It happens, from time to time, that we make obsolete some feature you like.  Trust me, we’re not doing it out of meanness!  Tell us about the things you love, as well as the things you think need work.  We need to know these things, or we run the risk, as Firefox and Ubuntu seem to be, of developing toward our own idea of what you need–which is not always correct.

Three years ago, Koha users and developers from around the world met up to discuss the future of the project. It is now time for us all to meet again, this time on U.S. soil. This conference is not just a great way for Koha community members to put faces with names (and online aliases), but a great way to get the community together to discuss what matters to us and learn from others around the world.

Please take a minute to read the press release and register for the conference ASAP so that we can get an accurate head count. This is a great learning experience - and registration is free - so it’s well worth attending!

Technorati Tags: koha, kohacon09

One tool I make heavy use of during development is ack. It is a grep replacement that is optimized for searching through source code, and it has been a great help to me for when I needed to dig through the  koha code.

Acks strength is in its really useful set of default behaviors.  Unlike grep, its default is to recurse through your directories while simultaneously ignoring backup files, core dumps, and source control directories like RCS, CVS, .svn, etc.   Technically, you could do this with grep, find, and lots of command-line options, but getting the right incantation might take some trial and error.

Ack condenses all that into 3 easily-typed letters and then gives you a bit more.  One nice touch is that it can use color to highlight matches that it finds, but if it notices that it’s output is being sent to a pipe, it’s smart enough to disable color.  You can also use it to only look through files of the types you care about.  For example, if you wanted to only search through your css and javascript files for the string ’sidebar’, you’d type:

ack –js –css ’sidebar’

There’s also a really handy vim plugin for ack that lets you search through your source tree from within vim.  The search results are presented to you inside a :copen window and you can move backwards and forwards through the list of results using the :cprev and :cnext commands.

I like it a lot, and I recommend giving it a try if you haven’t already.  It certainly makes searching through large codebases a lot easier.

_   /|
\'o.O'
=(___)=
   U    ack --thpppt!