Archives for posts with tag: novice programmers

Shifting gears from scripting to Java

2014/08/04 //

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.

Tags , , , , , ,
Categories MediaWiki, opw

A beginner’s definition of “Web API”

2014/05/28 //

This summer I’m taking part in the Outreach Program for Women, working on making the MediaWiki API more usable. As a part of this, I’ll be blogging every week or two with things I’ve done, things I’ve learned, or general thoughts as I get into the free/open source software world.

This is the second in a series on the MediaWiki API. Click here for previous post.

What is an API? “API” is short for Application Programming Interface, which is not much more informative. Broadly, APIs make it easy for programs to interact with each other–which is to say, they make it easy for programmers to incorporate a different program’s functionality into the program they’re writing.

This article on APIs by Brian Proffitt clearly describes the most important ways APIs work:

APIs… “[expose]” some of a program’s internal functions to the outside world in a limited fashion. That makes it possible for applications to share data and take actions on one another’s behalf without requiring developers to share all of their software’s code. Code-sharing on that scale wouldn’t just ruffle the feathers of programmers who’d rather keep it secret; it would also be grossly inefficient.

That’s true even for open-source programs. Who has the time to comb through all the code for somebody else’s application—which, trust me, can be awfully messy—just to use one function? (It’s also possible to run into tricky licensing issues if you’re not careful.)

APIs simplify all that by limiting outside program access to a specific set of features—often enough, requests for data of one sort or another. Feel free to think of them as doors, windows or levers if you like. Whatever the metaphor, APIs clearly define exactly how a program will interact with the rest of the software world—saving time, resources and potentially nasty legal entanglements along the way.

That’s the general concept behind APIs. Web APIs are similar, but made for the internet: they’re a way to fetch data from the database behind a website.

When you use a web browser to go to a website, your web browser makes an HTTP request to the server the page is stored on. The server, in turn, sends you data in the form of a web page: information in text/video/graphical form, arranged so that humans can easily understand it. You are now free to read the article/look at kitten pictures/write and post your blog post/watch that awesome fanvid.

When you write a program that uses a web API to fetch data from a website, your program makes a carefully-constructed HTTP request to the server the site is stored on. The server, in turn, sends you data in a format your program expects (if you asked for data) or incorporates your changes to the website (if you sent data). Your program now has a tasty chunk of data to use and you can use it to make diagrams/search for specific items/look at a user’s history/edit that wiki page/automatically bookmark those “to-watch” fanvids.

That’s it. A web API is just another way of exchanging information with a website. This web API description on Wikipedia is still full of acronyms… but it might make more sense now.

In the next post I’ll talk about how you can figure out how to make requests from an unfamiliar API.

Tags , ,
Categories opw