Much of my team’s recent development has focused on creating Web APIs to make it easier to share data around the University. For this purpose we are using the Web API framework Dropwizard and a number of other tools including Git, Groovy, Gradle, Codenarc, and Swagger. In this post I will be describing how we have used these tools to implement a reusable Web API development environment.

Information Services uses the Java stack for many applications that benefit from the ease of deployment of “Write once, run anywhere”. We chose Dropwizard largely for compatibility with our existing processes and codebases as there are few other lightweight Web API frameworks in the Java space. We are using the Groovy programming language which compiles to JVM and is compatible with other Java libraries. Groovy is increasingly used in enterprise software development for its compactness and additional features in comparison with Java. While much of our Groovy code is little more than Java with syntactic sugar, Groovy’s functional programming features and emphasis on domain specific languages offer powerful tools for abstraction when they are needed.

One of our uses for Groovy is with Gradle, the dependency management and build automation tool we use. With a suitable Gradle script, it is possible to download dependencies, run automated tests, and compile an application simply by executing the command gradle build. We have been using the Shadow plugin to compile our applications to single JAR files which contain all of the dependencies needed for deployment. Our build pipeline (implemented with Jenkins) continuously builds and deploys these archives with a command line like:

$ java -jar web-api-skeleton-1443208918992-bd8adef-all.jar server configuration.yaml

Another Gradle plugin we use is Codenarc, a static code analysis tool for Groovy. Run at the same time as our unit tests, our Codenarc rules alert developers to violations of our style guidelines. Although it is just a convenience, it has saved our team some time spent discussing style issues during code review.

An important aspect of developing Web APIs is documenting HTTP resources, methods, and messages. Although there are no formal standards, Swagger is increasingly used to specify and define Web APIs in a machine- and human-readable format. We use Swagger to communicate the structure and function of our services by integrating with our Web API gateway and by generating a point-and-click interface for exploration.

Dropwizard describes itself as “a Java framework for developing ops-friendly, high-performance, RESTful web services” that “pulls together stable, mature libraries from the Java ecosystem into a simple, light-weight package that lets you focus on getting things done.” It was initially released in 2011 and at the time of this writing is at version 0.8.2. Dropwizard favors certain conventions but leaves most design decisions up to the application developer. Its bundle of libraries for HTTP, JSON, logging, testing, monitoring, and databases is the source of both its power and its complexity: Although a great deal of functionality is available out of the box, some effort is required to understand the way the libraries interact.

The structure we have been using for our Dropwizard projects generally consists of classes defining the application and its configuration, custom data types, resources mapping URLs to method calls, database access objects, authentication, and automated tests. We have developed a Web API Skeleton that can be cloned easily with Git to reuse code and distribute updates between multiple applications. We have developed a number of Web APIs to test various features of Dropwizard, integrate with other University systems, and train new employees. These include our Dropwizard Test, Student Application Decision, REST Performance Ranking, Catalog API, and Locations repositories which are all freely licensed and available on GitHub.

For more information and a detailed demonstration of Dropwizard and our other development tools, watch the following 30-minute screencast:

Link to video of demonstration of tools used to develop Web APIs, including git, Java, Groovy, Gradle, Codenarc, Swagger, and Dropwizard.
Demonstration of tools used to develop Web APIs, including git, Java, Groovy, Gradle, Codenarc, Swagger, and Dropwizard.
PDF.js with incorrect zoom
PDF.js with incorrect zoom

As part of my job as Student Programmer at MIST I have the opportunity to contribute to Free and Open Source Software projects. In addition to giving back to the community, this provides a valuable opportunity to gain software development experience by working with different codebases, styles, and workflows. In this first post on the MIST Blog I will describe my experience contributing a bug fix to the Mozilla project PDF.js.

PDF.js is a project to implement a PDF reader in HTML and JavaScript. Its goal is to decrease users’ reliance on proprietary PDF readers to display documents on the Web. Formerly available as an add-on, PDF.js has been integrated with Mozilla Firefox since version 19.

Although PDF.js is capable of properly displaying many complex documents, many features remain unimplemented and many bugs persist. One of the bugs I encountered on my OSX development machine was that the PDF.js user interface zoomed along with the content when using the command key. This had been reported in the Mozilla bug-tracking system for several months before I decided to find a solution.

After downloading the source code, running it in a local environment, and browsing files for evidence of the cause, I discovered that there was a flaw in the logic that handled keyboard events. In particular, the code did not properly distinguish between the control key and the command key peculiar to Macs. I made the necessary changes and submitted a pull request to the PDF.js team for review. After ensuring the changes passed automated tests and squashing the commits as instructed by one of the contributors, my solution was accepted and the bug report was closed. According to Bugzilla, the fix should appear in Firefox 40.

commit 34d3b96b52fe95531b0a4ff14659edabcc6ba9ee
Author: Taylor Brown <browtayl@onid.oregonstate.edu>
Date:   Thu Apr 9 16:51:16 2015 -0700

    prevent viewer from zooming on cmd+mousewheel

diff --git a/web/viewer.js b/web/viewer.js
index f9788d8..87ea071 100644
--- a/web/viewer.js
+++ b/web/viewer.js
@@ -1981,7 +1981,8 @@ function handleMouseWheel(evt) {
   if (PresentationMode.active) {
     evt.preventDefault();
     PDFViewerApplication.mouseScroll(ticks * MOUSE_WHEEL_DELTA_FACTOR);
-  } else if (evt.ctrlKey) { // Only zoom the pages, not the entire viewer
+  } else if (evt.ctrlKey || evt.metaKey) {
+    // Only zoom the pages, not the entire viewer
     evt.preventDefault();
     PDFViewerApplication[direction](Math.abs(ticks));
   }

I have uploaded a screencast to OSU MediaSpace demonstrating the problem and the solution. It was satisfying to make a small but meaningful contribution to a widely-used Free Software project in the course of my work, and I look forward to doing so again.