“Man is a tool-using animal”–unless it’s me.

February 6th, 2009 by david.bavousett

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…

Obama on Libraries

January 26th, 2009 by atz

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…

KohaCon 2009

January 25th, 2009 by Galen Charlton

Please mark your calendars for KohaCon 2009. From David Schuster’s announcement today:

KohaCon 2009 will be held in Plano, TX April 16 and 17.

This is a FREE conference. There is no registration fee, but we are
requesting that all attendees pre-register. Details (travel, hotels, agenda draft, etc) can
be found at:

Koha WIKI: http://wiki.koha.org/doku.php?id=kohacon2009

There is a “Tentative Schedule” - it will change as more people sign up
probably for programs. Travel information along with Hotel accomodation
information. Lunch and dinners will be on your own. Feel free to contact
any of the three people listed on the Wiki at the top or email me directly.

After the conference, there will be a three-day Koha developers meeting in Plano on April 18 through 20. All who develop for Koha, want to develop for Koha, or are interested in Koha development are welcome to attend.

LibLime at ALA Midwinter

January 20th, 2009 by Nicole C. Engard

As I mentioned before, LibLime will be at ALA Midwinter in book #722 and will be speaking at the following events. Come join us - or just stop by to say hi :)

FRIDAY, January 23rd

2:00 - 5:00 PM
OUTSIDE THE BOOTH… Panel Discussion
Starting Over: Re-Inventing the Integrated Library System (ILS) and the Library Automation Industry– RMG’s Nineteenth Annual Presidents’ Seminar: The View from the Top
on the panel… Joshua Ferraro, CEO LibLime

RMG’s Nineteenth Annual Presidents’ Seminar will include the traditional panel of library automation executives from industry companies plus featured speakers from libraries undertaking technology developments and initiatives.

Hosted by Rob McGee, RMG
Denver Convention Center, Korbel Ballroom 3B

6:00 PM - Stop buying your records back! Introducing ‡biblios.net
Presenter: Joshua Ferraro, CEO LibLime

‡biblios.net is a FREE browser-based cataloging service with a data store containing over thirty-million records. Records are licensed under the Open Data Commons, making the service the world’s largest repository of freely-licensed library records!

SATURDAY, January 24th

10:00 AM - Gee, I wish Koha did this… LibLime and the Development Process
Presenter: Becky Bell (WALDO)

WALDO has contracted with LibLime for over 35 software enhancements and now has a lot of experience in working with LibLime as the projects move from an idea to a specification and finally into software. You’ll hear a brief update of the status of these projects. Plus, we’ll follow one of the projects from the scoping study stage through the specification approval stage and end as the project moves into development and software testing.

10:30- 12:00 NOON
OUTSIDE THE BOOTH…
Serials Management in Koha’s open-source library software.
Presenter: Nicole C. Engard, Open Source Evangelist LibLime

The presentation will help you understand what open source is all about and show you how the Koha open-source automation system cannot only handle your serials in the library catalog, but provide better services to your patrons.

ALA Midwinter program sponsored by the ALA ALCTS Continuing Resources Section College and Research Libraries Interest Group. (E-Journals All Around: in the Catalog, the Knowledgebase, and the Web)

Sheraton Hotel, Gold

1:00 PM - Koha ZOOM OPAC Demo
Presenter: Joshua Ferraro, CEO LibLime

1:30 - 3:30 PM
OUTSIDE THE BOOTH…
KUDOS (KOHA Users and Developers of Open Source) Meeting

NOTE: This is for users of Koha only. Libraries who are interested in Koha, but have not yet signed a contract with a support provider or implemented Koha on their own, should attend the Koha Interest Group Meeting– see below.

Crowne Plaza Hotel
Room: Altitude

3:30 - 5:30 PM
OUTSIDE THE BOOTH…
Koha Interest Group Meeting
Crowne Plaza Hotel
Room: Altitude

SUNDAY, January 25th

10:00 AM - Stop buying your records back! Introducing ‡biblios.net
Presenter: Joshua Ferraro, CEO LibLime

‡biblios.net is a FREE browser-based cataloging service with a data store containing over thirty-million records. Records are licensed under the Open Data Commons, making the service the world’s largest repository of freely-licensed library records

1:00 PM - Koha ZOOM OPAC Demo
Presenter: Joshua Ferraro, CEO LibLime

3:00 PM - Open-Source Technical Services Tools
Presenter: Nicole C. Engard, Open Source Evangelist LibLime

MONDAY, January 26th

9:30 AM - Koha ZOOM Staff Client Demo
Presenter: Nicole C. Engard, Open Source Evangelist LibLime

10:40 - 11:10 AM
OUTSIDE THE BOOTH…
ALA Tech Showcase: ‡biblios: a new social cataloging (r)evolution from LibLime
Presenter: Joshua Ferraro, CEO LibLime
Pueblo Theater (1)

12:30 or 1:00 PM - Stop buying your records back! Introducing ‡biblios.net
Presenter: Joshua Ferraro, CEO LibLime

‡biblios.net is a FREE browser-based cataloging service with a data store containing over thirty-million records. Records are licensed under the Open Data Commons, making the service the world’s largest repository of freely-licensed library records!

Technorati Tags: , ,

Programming resolutions

January 18th, 2009 by Allen Reinmeyer

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.

Exploring Koha with REPLs

January 4th, 2009 by john.beppu

A REPL is an interactive shell for programming languages that:

  • Reads expressions,
  • Evaluates them,
  • Prints the result and
  • Loops back to do it all over again

REPLs are simple tools that I’ve found tremendously useful for learning new languages and exploring unfamiliar code. Read the rest of this entry »

Koha Test Cases

December 28th, 2008 by Allen Reinmeyer

Since Andrew Moore has already done some great work on building up Koha’s test suite for C4 classes, I thought I’d talk about some of the ways that we as developers can add to his work.  I know in my recent development work, I have been trying to add tests where I can.

There’s a good overview on running the test suite, or specific test cases, on the Koha wiki.  What I’d like to talk about are a couple of reasons why we should be writing test cases whenever possible.

Adding more tests to our test suite can be beneficial in a number of ways.  As a new developer to Koha, writing test cases has really helped me understand what’s going on behind the scenes.  For me, writing the test case before I start working is the best way to figure out what the code is doing now, and also what it should be doing in the case of bug fixes, or what I want it to do in the case of adding new features.  That process, generally called Test Driven Developement, or TDD for short, can be awkward for many developers that have never done it before.  My main point though is not to get everyone drinking the TDD Kool-Aid, so the benefits of TDD can wait.  Though as someone that had to re-learn how to develop using TDD, I can attest to the changes one has to overcome. Test cases can be easily written both before and after code changes, so let’s get back to the topic at hand.

Another benefit of test cases is that it allows for a more rapid refactoring of the code base.  Even in my short time with LibLime and working on Koha, many of us on the Koha IRC or mailing lists have discussed ways to improve the code base, like converting to DBIx, mod_perl, or just adding warnings to classes. The more robust and complete our test cases become, the higher the confidence all of us can have in changing the code by running the test suite (or class) after we make changes.  Part of the problem in making these large-scale changes though, is the concern for what functionality we would break or alter.  Having test cases that validate behavior both before and after changes are made can be a huge benefit to successful deployment.

Of course, one of the problems in writing test cases is the fact that as a developer, often times you write as much (or more) in the test cases than you do in the actual code change itself!  While that is often true, most of the time this can be attributed to initial setup cost as once tests are written, they can be used over and over again.  An example is the work I am doing on enhancing the fines portion of Koha.  As I write test cases, I am also able to use the same test cases I wrote for the C4::Members class in another branch, making C4::Members work with DBIx::Class.  As these test cases get merged into the Koha public repository, others can also use these tests to validate still more changes to C4::Members.  So I spent some time initially doing more code than I planned, but in the long term, the benefits quickly repay the initial cost spent in code and time.

While it is often helpful to still test code changes through the browser, having test cases also allow us as developers to isolate problems faster. If you can verify that methods are inserting/updating records correctly via test cases, you save valuable time on support by then focusing on Javascript or HTML errors.  Code also tends to become more maintainable as ‘do-all’ methods get broken up into smaller methods that are easier to test.  In my past experience, while there can doubt as to the quality of the tests available, or concerns that existing test cases are not reliably structured, there can be no doubt that everyone agreed that the existence of tests provided a more stable end product. With the community’s help, hopefully we can all witness that first-hand here as well.

‡biblios.net collaborative sharing and editing of records

December 8th, 2008 by Chris Catalfo

LibLime is developing a new open platform for sharing bibliographic records as part of its forthcoming ‡biblios.net project (now in beta at http://beta.biblios.net). As part of this platform, LibLime is making available bibliographic records via several protocols: z39.50 and SRU for starters, eventually via a REST protocol and OAI-PMH.

LibLime is also allowing write access to the records via the protocol ‡biblios uses to interact with Koha. This api (documented more fully at the biblios.org site) looks like the following:

authenticate: POST username=x password=y. Receives: cookie for session use
bib_profile: GET. Receives: xml document describing marc21 fields in use by backend Koha server.
bib/xxx: GET: Retrieves a marcxml document at xxx bib number.
bib/xxx: POST: Saves posted marcxml document to server.
new_bib: POST: Saves marcxml document (new to database) to server.

In the coming weeks we will announce publicly available urls for these access services, so sharpen your pencils and get ready to collaboratively share and edit some records!

Koha event in Kansas on December 10

December 3rd, 2008 by Galen Charlton

From the news blog of the Northeast Kansas Library System:

The Northeast Kansas Library System is hosting a “Kansas Koha Interest Group Day” conference for libraries interested in the Koha open source integrated library system next Wednesday, December 10th at the NEKLS system office in Lawrence, Kansas. The conference is open to anyone interested in open source ILS systems, and Koha in particular.

More information here.

Git tip: [prefix] in commit messages

December 2nd, 2008 by Galen Charlton

When you use git format-patch and git send-email to format and mail a patch, the subject line of the email becomes

[PATCH] first line of commit message

Since patches go through a mailing list, mailman adds a prefix of its own:

[Koha-patches] [PATCH] first line of commit message

When the patch is applied, git am invokes git mailinfo to clean up the subject line, including whitespace, “Re:”, and any leading sets of text in square brackets. However, it can be a little too greedy.

If your original commit message starts with

[bug 1234] add automatic whale-saving,

the patch will reach me with the subject line

[Koha-patches] [PATCH] [bug 1234] add automatic whale-saving.

However, git am (as of 1.5.5, at any rate) will chomp it down to

add automatic whale-saving.

Oops! No bug number to immortalize your rescue of cetaceans via an ILS!

To avoid that, try bug 1234: ..., (bug 1234) ..., or if you really like square brackets, move it to the end: ... [bug 1234].