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!

One of the joys–or perils, depending on how it’s going–of any big development project is housed in the usefulness of the tools you use to manage it.  In Koha’s case, git is where we keep our code, and there are a number of repositories, both inside and outside LibLime, where we keep up with things.

I’m still trying to decide if git is a blessing, or a curse.  When everything is going right, and I’m using it to update our customer sites, I think very highly of it. A fistful of commands in bash, and the customer is up-to-date–what’s not to like about that?

But I’m making some small forays into development.  Little stuff, mostly things that affect me installing and keeping Koha and its’ infrastructure happy.  Shouldn’t be too hard, right?

Here’s a tip: the coding is the easy part.

I had to look up (again) how to extract what I’d done as a patch.  Okay…I made up my little edit, and did git-commit and git-format-patch to make a nice little file to git-send-email it…

…and discovered that my MacBook’s postfix isn’t running.  Lovely.  So I spent an hour putzing with that, trying to get it working–it runs, but it won’t talk to anyone–and finally had a V-8 moment, and uploaded the patch to our development server, and git-send-email’ed it from there.

I’m sure the “real” developers who contribute here are all laughing like hyenas at my thrashing around trying to get a 5-line patch out.  I’m sure Joe or Galen could have handled this in their sleep.

But doggone it, I’m proud of that little patch!  Not for its’ contents, which are trivial at best, but because I managed to coax it out into the light of day, without help!

Seriously, git is a great tool for managing code in a distributed-work way.  It just seems like Dark Arts at first…