Archive for the ‘Koha’ Category
Koha Test Cases
Sunday, December 28th, 2008 by Allen ReinmeyerSince 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.
Koha event in Kansas on December 10
Wednesday, December 3rd, 2008 by Galen CharltonFrom 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.
KohaCon 2009 & Koha Dev Camp 2009
Tuesday, November 25th, 2008 by Nicole C. EngardThis from the Koha Mailing List:
There is a question on the table if this meeting announced as an American Conference for Koha should be more like a Koha Con 2009 with the format similar to 2006.
With that we would like to schedule a meeting to discuss on IRC the KohaCon possibility.
There is a wiki at: http://wiki.koha.org/doku.php?id=kohacon2009 - to better help organize some of this…
- Who wants/would be interested in attending this IRC (and eventually a full conference?)
- What days of the week are best for this IRC? (sooner the better)
- Times are best for you - GMT for this IRC? - http://wwp.greenwichmeantime.com/
- In this discussion we would talk if a developer meeting is of interest?
- Should it be pre or post the Conferece that is being planned for April 16/17 in the US?
- How much time should be considered 1 or 2 days?
- What should those days look like?
- Where is the best place to house them (how many is of concern along with other needed items if they are to meet)
In addition I would love to hear any input this group might have for the April 16/17 “conference” as well. Presentations - workshop etc… how it should be structured for a meeting of users and developers.
David Schuster
dschust1@tx.rr.com
Plano Texas
going live Jan 5th, 2009 as a LibLime customer! - this is open to all koha users and those interested. More information on the schedule to come after I figure out interest.
Working to Start Using DBIx::Class in Koha
Friday, November 21st, 2008 by Andrew MooreI’ve been doing some work recently to see if Koha could benefit from using an ORM tool like DBIx:Class. This would help abstract away the database interactions for developers. I’ve produced an example implementation of how we could do this and sent it to the Koha-devel list a few times in hopes of gauging how likely it is that Koha could move in this direction soon.
Since I didn’t receive much criticism and actually got some good advice and some offers of assistance, I’m hoping that I can keep working on this project until it gets accepted into Koha. To that end, I’ve started a wiki page where I can describe how I expect to eventually get to use DBIx::Class in Koha and how I envision us getting there. If you’re interested in helping me figure out a good way to go about this, or if you’re just interested in reading a bit about one possible future feature in Koha, take a look at that page and feel free to edit it
I’m hoping that this project makes it easier to contribute to Koha. That means that I may not have the best implementation in mind right now. I want to hear from you on how we can make it better. Thanks!
Git config change: UTF-8
Wednesday, November 19th, 2008 by Galen CharltonI’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\""
A quick look at some possible changes in 3.2
Friday, October 3rd, 2008 by Andrew MooreThere is a growing collection of “RFC”s for 3.2 features on the koha wiki. These are potential features that may be added in 3.2 or later. They’re put there to try to elicit community discussion to help steer them to make the best possible product. The 3.2 release manager, Galen, has indicated an interest in having these RFCs looked over by the end of next week, so I thought I’d take you on a quick tour of some of the more interesting ones. Here’s a quick look at some of the types of things being considered:
Administration improvements: The system of maintaining and using system preferences may get expanded by using roles and making the permissions collection more granular. On a somewhat related topic, there may be some work put into making independent branches work a little bit better.
Improvements to the user interface: In order to make Koha look and feel better to users, it’s possible we’ll extend the amount of AJAX elements that we use.
There are a handful of potential improvements for circulation. Among these is adding the concept of hourly circulation policies for some items. There are also a few that touch on holds, recalls, and fines.
Another interesting one would introduce summary holdings for grouping related items.
These are just a few of the RFCs that will get considered for features for 3.2 and beyond. You can help make Koha better by weighing in on how these may work together best.
Koha Community Meeting for 3.2
Tuesday, September 16th, 2008 by Joshua FerraroA number of Koha developers and users met recently on the #koha IRC channel to discuss various project issues. Several project positions were voted on and are now filled:
- 3.2 Release Manager - Galen Charlton, LibLime
- Translation Manager - Chris Cormack, Catalyst
- Documentation Manager - Nicole Engard, LibLime
- 3.0 Release Maintainer - Henri-Damien Laurent, BibLibre
The position of QA manager for 3.2 remains open. The two candidates are Frédéric Demians (Tamil) and your’s truly. No decision was made, and the discussion will be continued on the koha-devel mailing list.
Several announcements were made:
- Galen will set up gitosis on git.koha.org to allow Henri-Damien to push
patches to the 3.0.x branch. - Henri-Damien announced that minor revisions of 3.0.x will be
packaged and released every two months. - Galen announced a date of 10 October 2008 for the developers to complete
review of the RFCs for 3.2.
Various issues were raised that will be further discussed on the mailing lists:
- Coding standards for 3.2.
- Moving the Koha manual from Google Sites once www.koha.org is running Plone.
- Policies for ensuring that more patches are reviewed and tested.
The full log of the meeting is at
http://koha.org/cgi-bin/logs.pl?recall=recall&saved_query=2008-09-12%20meeting
or equivalently,
http://koha.org/cgi-bin/logs.pl?look=plain&startdate=2008091212:00:37&enddate=2008091213:30:01&search=Search
What’s a Smokebot?
Monday, August 18th, 2008 by Andrew MooreI recently put into place a few tools that should make automated testing of Koha a bit easier. The first is an installation of smolder that will graphically display the results of the test suite. The other is an addition to the test suite to make it easier to send reports to smolder. I have set up a cronjob to run the test suite twice a day and send the results into smolder. Some people call that a “smokebot,” since it’s an automated way to perform smoke tests.
I’m hopeful that this will help is in a few ways. One is that it may make it easier for us to catch those instances where a new patch will break some existing functionality. If there’s an automated regression test to verify some functionality and it stops passing at some point, we can use the smolder to tell when it stopped working. That may help us track down the cause of the failure.
The other way that this might help is is to increase the number of platforms that koha works on. If we start getting test results from other platforms or architectures, we can become more confident that koha works in other environments.
If you have questions about how to use the test suite in Koha or how to use smolder, please don’t hesitate to ask.
Koha 3.00.00 Released
Sunday, August 10th, 2008 by Joshua FerraroI’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.