With still 9 days to go I’ve decided to do a bit of a wrap up for the year.
It was a pretty massive year in a lot of ways starting with
- This year we had the highest number of commits ever, as of today 2619 commits
- 82 different people had code committed into Koha
- 32 were new developers
- At least (probably about 4 times this many really) 167 libraries liberated themselves by moving to Koha
- 3.12 and 3.14 were released on time and with no major issues
- Kohacon in Reno was a great time.
- The NZ trademark issue was finally settled with the Community winning it’s challenge to Liblime/PTFS’s application.
- I wrote 50 patches, signed off 182 patches, did QA on 72 and when doing release maintenance pushed 248.
- Maui came to the 4th birthday party of Te Po Atarau.
- Kahurangi turned 7 and had a space party.
- I turned 40
- Laurel had ankle reconstruction surgery, that resulted in a bunch of complications that meant I did the school run for most of the year.
- I gave 11 presentations. (It would have been 12 but I bailed on one)
- I survived 3 Whisky O’Clocks
- I travelled 36,577 km
Unfortunately I had to pull out of doing my lightning talk at NDF, I simply didn’t have the time to be able finish what I was going to present. I felt it was better to pull out than do something that wasn’t up to scratch, not really fair on the conference attendees otherwise.
But I still think the idea has some merit, so here is a snippet of the unfinished, rough edged, cut down for youtube, thing I was going to present
Massive thanks to Andrew Caudwell who writes Gource, without which this would not be possible.
It’s running circulation data with 1 minute = 1 day, but it’s equally interesting running a bit slower. There is a lot more I wanted to do, like using the actual book covers, visualising more data, like acquisition, and cataloguing .. tracking an item throughout its life. All of which is easily doable, just with more time.
Anyway, I hope people get something out of it.
Basically I had lost track of all the presentations I had committed myself to giving, so wanted to note them down here so I don’t do that again.
I don’t think I have missed any, if I have please tell me
UPDATE: I did forget one, added now
So last week I had the pleasure of attending a hui organised by the Auckland Libraries. The full title is ‘New Rules of Engagement: Future Directions for Children’s and Youth Services at Auckland Libraries’, subtitled ‘A hui of awesome awesomeness’. It certainly was awesome, unfortunately I could only stay for 1 day of the 2 day hui, but I did get to hang out with some librarians and some of other speakers the day before it.
I was on a panel about digital spaces for children and youth, I talked mainly about the OS Academy we run here at Catalyst, and how successful that is in engaging youth. There were quite a few questions during that panel discussion and during lots of other ones, and it sparked some ideas, so I am going to write them down here before I forget them.
- A FLOSS Academy for Librarians – this came from a question where the asker said something to the effect ‘How do we know what we don’t know?’ I think an academy modelled after the academy we run for High School students would be a great way to expose people to a lot more that is out there.
- Everyone seems to agree that there is much more to librarianship than what you can learn in an academic course, but there was no real agreement on how to balance that with the fact that payscales are often tied to said courses. Some places you can’t even be called a librarian without them. Professionalism destroying artisanship again?
- Fun is fun, and the key to engagement, dress it up however you like but this seems to be what it boils down to.
- An idea I had for next year would be a ‘Spectular fails’ session. All the ideas you had that went horribly wrong. These are massively useful learning tools for others.
- In the same vein, how about a fails track at LIANZA sometime. Fail often and fail loudly
That’s about all I can remember, it was a great conference, one I would be keen to attend again. Much thanks to all the organisers and attendees
600 people reached the top of Mt. Everest in 2012. This blog got about 8,100 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 14 years to get that many views.
In 2012, there were 62 new posts, growing the total archive of this blog to 272 posts.
The busiest day of the year was December 12th with209 views. The most popular post that day was RDA Support in Koha.
Read the full report
Something I hear and have heard a lot in my life as a programmers is
We should rewrite this, I have no idea what it is doing
Now, your instinct to rewrite is almost always the correct thing to do, but almost always the implementation is wrong. Why is this? Well it’s because of the same reason we want to rewrite it, we don’t know what it is doing. So often we end up causing regressions, or accidentally leaving features out. How do we get around this? This is where I stand up and go to put on a broken record. The answer is unit tests, in fact ask me anything I’ll probably say unit tests.
- “How do I make Koha do this?” “Well first you write a unit test and then …”
- “I want to change this template” “Have you run the xt/tt_valid.t on that?”
- “Want some coffee?” “Is it unit tested?”
- “Where’s the remote?” “Oh, I wrote a unit test for that.”
But seriously, if we invest time in writing tests, forcing us to learn the behaviour of the current implementation, we can then make sure our refactor/rewrite still passes these tests. We can also make sure any new behaviours we add have tests written for them too, after having to implement tests to test existing code, writing tests before writing the code seems a lot nicer.
I’m sure this is new to no one, and I’m really writing it as a reminder to myself, but hopefully it may be some help to others too. Go forth and refactor/rewrite
It seems like common sense, but all too often in the tech sphere people forget a really simple rule.
It doesn’t matter how correct you are if the way you communicate only serves to alienate those you seek to persuade.
Koha has fortunately been quite lucky in this regard 99% of the people involve understand that the project is about far more than code and that people are what really matters.
But it can happen anywhere even occasionally with Koha. It’s even more unfortunate when it is a goal people agree is well worth it. So people agree with the message but the delivery of it only serves to make people less likely to listen.