My Undergraduate Project So Far, Part 1: Spring and Summer 2013

Over the last year, I have been working on an undergraduate research project for Dr. Philip Johnson, head of the Collaborative Software Development Laboratory (CSDL). This is the first part of an end-of-year recap of my current progress. Next semester I hope to maintain a more regular update schedule.

January – May 2013: Research Proposal

In the Spring 2013 semester, I completed a research proposal for usability testing of new features that I planned to implement in the Makahiki software and presented my work at the 2013 Spring Proposal Conference. The goal of the research was to develop and test additional functionality for Makahiki that made it easier for system administrators and developers to install and configure. In addition to a successful research proposal, I was approved for funding from the University of Hawaii’s Undergraduate Research Opportunities Program (UROP).

The initial research proposal produced for my Honors 495 research writing course created a 28-page report, a 15-minute presentation, and a 48-inch-by-36-inch poster. PDF versions of these files can be viewed below.

Spring proposal conference 2013 poster.

My poster for the 2013 Spring Proposal conference. Click to view a full-size image (3.56 MB).

June 2013: SGSEAM Conference Paper

My first task for the undergraduate project was to assist with the data analysis for a conference paper on the “Serious Game Stakeholder Experience Assessment Method” (SGSEAM) under development by Dr. Johnson’s Collaborative Software Development Laboratory. This paper was published in October 2013 as “SGSEAM: Assessing serious game frameworks from a stakeholder experience perspective” [citation].

One source of usability testing data for this paper was the surveys that my classmates and I had filled out in ICS 691 when we tested out the Makahiki administrative interface. Having been lucky enough to avoid some of the more extreme problems when I installed and set up Makahiki as a student, it was interesting to be able to take a higher-level look at the data in order to identify trends in what we had seen as usability problems.

July 2013: Script Development

An analysis of the problems that my classmates and I had reported when we installed local instances of Makahiki in Spring 2013 indicated that many of us had wanted the Makahiki installation process to be faster or more automated. Dr. Johnson suggested that this could be fixed by creating an automated script-based installation for Makahiki.

This shifted the focus away from the Makahiki serious game setup feature which was part of the initial proposal, but allowed me to work on a more feasible virtualization-based solution to problems with the initial setup of Makahiki.

Two solutions were eventually attempted: automated Python scripts for Red Hat Enterprise Linux / CentOS 6.4 systems and Ubuntu 12.04.* systems, and a Vagrant installation with a provisioning script. The initial plan was to support all of these methods.

The Ubuntu Python script implementation used a single master script to run other sub-scripts based on the command-line arguments that it was issued. The scripts installed Makahiki dependencies, initialized and updated the database, and cleaned up files downloaded during the installation. This turned out to be somewhat difficult to port over to CentOS due to the differences in the CentOS 6.4 base installation of Python (2.6.6) and the minimum version needed by Makahiki (2.7.3).

The solution that I eventually worked out was to create an additional script for CentOS that completed an altinstall of Python 2.7.3. With an altinstall, Makahiki would run as long as a Python 2.7.3 environment had been initialized in the shell that makahiki was running in. However, to initialize this environment, the user had to remember to run the command "scl enable python27 bash" manually in each new shell. In addition, sudo commands ignored the altinstall and ran as if they were in the original shell with Python 2.6.6.

During script development, I found that Ubuntu 12.04.* and CentOS 6.4 systems’ default repositories used the wrong version of libmemcached, so compiling and installing the correct version had to be built into the scripts as well.

Due to the version-specific commands and dependency issues, Dr. Johnson and the other CSDL members advised me to focus on the Vagrant installation, as the OS-specific scripts were becoming unwieldy and would likely be difficult to maintain in the future. The scripts were removed from the project, but I was able to add the CentOS installation process to the Makahiki local Unix installation documentation.

The Python scripts are no longer being maintained but can be viewed on GitHub.

The Vagrant solution involved a single Ubuntu 12.04 LTS virtual machine downloaded from Vagrant’s servers. This machine was provisioned using a shell script that installed the necessary packages. Unlike the Ubuntu and CentOS Python scripts, which had been intended for possible use on non-virtualized installations, the Vagrant script could also overwrite configuration files with Makahiki-specific ones: it would always be running on a virtual machine, and always be overwriting the exact same default files.

Installing Makahiki on a Vagrant virtual machine on Windows was simpler than the process of installing Makahiki directly onto a Windows machine, so my next task was to document the configuration of an appropriate development environment for a Windows host working with Makahiki on Vagrant.

August 2013: Vagrant and Eclipse

In August, I documented the process for using a Vagrant installation of Makahiki with an installation of Eclipse on the host machine. The resulting environment used the PyDev and Remote Systems Explorer plugins to enable Python and SSH connection support, and installed XML/HTML/Javascript editors to assist with the process of web development for Makahiki.

The PyDev remote debugging server.

The remote debugger works well enough, but I wonder if it is really worth bringing down your firewall.

The PyDev remote debugger was blocked by Windows Firewall even when a rule was explicitly created to allow its designated port to pass through, and only worked when the firewall was fully deactivated. The remote debugger instructions were added to the documentation, but with a warning that using the debugger would likely create a security risk.

As the Fall semester began, I shifted my focus away from direct Vagrant development and worked on getting my study proposal approved by the university’s Institutional Review Board.

This summary of the progress of my undergraduate project continues in Part 2.

Advertisements