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.
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 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.
Submitted by Djun Kim on 26 February 2006 - 12:57am
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.
Submitted by Djun Kim on 25 February 2006 - 10:11pm
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.
Submitted by Djun Kim on 12 February 2006 - 3:21pm
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?"