Djun Kim's blog

I'm pleased to announce the first public beta release of Statistics::RserveClient, a Perl module providing an interface for interacting with the powerful open-source R platform for statistical computation.

Using RserveClient, a Perl applications can make a connection to a (possibly remote) Rserve server, send R commands as strings, and receive the results of the evaluation as Perl data structures.

Since Rserve communicates via a binary protocol, computations can return plots and other binary data.

Using RserveClient is straightforward:

WeBWorK's extensive library of problems (numbering almost 29,000 entries, at current count) is one of the great attractions of the system. I'm planning a post discussing some statistics about the growth of the library and the distribution of authorship, types of problems, and so on, but that will have to wait for another day. What I wanted to highlight today is current work on the library, and plans for future directions.

What's with the Name?

One of the most noticeable changes for casual users is the name change. At the recent Code Camp in Rochester, there was an extensive discussion of this topic. We wanted to choose a new name that reflected the fact that WeBWorK is now international. This fact is also manifesting in the recent work in internationalizing and creating translations for the WeBWorK user interface. But the existing moniker ("National Problem Library") was starting to feel a bit constrained and unnatural. In the end, we voted on WeBWorK Open Problem Library, or just OPL for short.

This choice was intended to emphasize WeBWorK, the software (or project, or brand, if you

I spent most of last week participating in an intensive code sprint/code camp for WeBWorK. I've been using the software for over three years, and hacking on it for about two, but this was my first real meeting with many of the community members.

I'll go into more detail in a later post, but for now I'll just say I was incredibly impressed by the technical expertise, passion and energy, thoughfulness, and openness of the community. It was humbling and inspiring to be welcomed to such an atmosphere of warmth, trust, and positivity, and super cool to be working with a group whose experience ranged from 2nd year undergrad to emeritus professor.

I gave a talk today at the February meeting of the Vancouver Island Java User Group (VIJug) on integrating Search into web applications using Solr (and Drupal).

I attended the first official meeting of the new Knowledge Management Community of Practice board meeting today - last meeting was very brief and informal, and dealt with introductions, appointment of members, arrangements to be addressed in terms of signing authority for the bank accounts, etc. Members of the KMC can expect to be hearing from me in my new capacity of Secretary.

Knowledge is one of those things we take for granted. It's far easier to recognize its absence than to define what it is, or to capture or record it. All of this means (to quote Joni Mitchell), that we don't known what we got till it's gone.

Keeping timesheets up to date is one of the least favorite activities for most developers I know. Most of them regard it as a pointless activity, done only under duress, satisfied by doing the minimum at the last possible moment. "The stuff I have to fill in just duplicates information in the issue tracker, e-mail, source code control system. No one reads this stuff, anyway." At the same time, many of these developers are very meticulous when it comes to change logs, bug reports, and blogging about issues that matter to them.

Joel Spolsky has become something of a legend among the current generation of software developers. His common-sense, tell-it-like-it-is, experience-rich, narrative teachings have helped tens of thousands of followers to better software and better software organizations, since well before the great dot-bust.

The point of this article is to enjoin software developers everywhere:

Write immortal code

This seemingly simple goal unpacks to explain every guideline and rule ever invented to legislate better software. At the same time, it is very easy to apply: just ask yourself, "What can I do to help this chunk of code I'm writing to outlive me?"

As Canadians lurch towards a January Federal election, the various political parties seem to be grasping at straws to distinguish themselves from each other.

Strangely, not one has given a clear message about one of the most critical issues facing Canada in the next ten years - building and maintaining a sustainable, competitive, technological economy.