Archives for the month of: August, 2014

For the last part of my internship, I’m adding a search function to the Java Wiki Bot Framework. Unfortunately, the Java ecosystem has had other ideas. JWBF uses Maven, a common build automator and dependency manager, and I’ve had a difficult time getting it working on my own system. (I wrote about the things I tried here.)

Partly because of the frustration of getting such a simple program up and running and partly because it’s been a decade since I used anything besides a scripting language, I’ve had a hard time getting myself to work on the project itself. Tonight I jumped into the Java method problems at Coding Bat. It’s all online so there’s no need to struggle with classpaths or system-specific differences. I’ve been enjoying it, kind of like I enjoy working math where I know the steps, or enjoy balancing redox equations.

Note to self: doing little bits of code practice is kind of like washing up the glassware you know you’ll need so you can just get started on the next reaction whenever the one running decides it’s done. Gather ye momentum where ye may.

I’ve been looking at web API client libraries in a lot of languages for my OPW internship project: Python, Perl, Ruby, and most recently, Java. Fortunately for me, the Java Wiki Bot Framework (JWBF) is the clear leader in the available libraries, so it was the only one on my list to evaluate.

That evaluation was challenging! I hadn’t written or read any Java since my first CS class–about a decade ago now. Since then, I’ve been working with interpreted languages, not compiled ones (see: Python, Perl, Ruby). The idea of dependencies becoming relevant at compile-time was strange to me (what, you can’t just check whether it’s installed properly with import jwbf?!). I’d never used Maven, and the project-based structure with a zillion subfolders was not intuitive. Auto-generated documentation (JavaDocs) were available, but it wasn’t clear what was expected from one (not to mention what a good one was.

I’ve learned a lot since I started wrestling with this. I now know about:

  • Limitations of JavaDocs. Basically: good for granular description of packages and methods, but your project should really have a separate larger-scale document that talks about design goals and the overall approach behind your implementation.
  • The internal structure of JWBF. mediawiki/actions is where most of the methods you’ll want your bot to use are kept.
  • What the deal with Maven is. Turns out it’s not an IDE, but rather a build automator and a dependency manager. It connects to Maven Central, an online repository that a lot of dependencies can be downloaded from.
  • How to start a project in Maven, how it handles dependencies, and (broadly) how I might use JWBF vs. hack on JWBF.

I also found a handful of debugging links (using the Eclipse IDE), which I haven’t tried myself yet. They’re on the table for next week’s work.

I have about two weeks left in my internship, and in that time I’ll make a handful of improvements for the project. I’ve already starting rewriting the README to be friendlier to and more informative for new Java developers, and soon I’ll start drafting a higher-level supplement to the JavaDocs, including information on which packages a MediaWiki API client developer should start with. Code-wise, I’ll be implementing a search function to address this feature request and writing the tests and documentation to support it.