Bachelor Thesis

Mini Exercises for Java,

based on JavaBat

von Thomas Staubitz

Berlin, 02.03.2009

FHTW Berlin
Fachbereich 4
Wirtschaftswissenschaften II
Internationaler Studiengang Medieninformatik

Erstgutachterin Prof. Dr. Debora Weber-Wulff

Zweitgutachter Prof. Dr. Marc Latoschik
Abstract
Mini Exercises for Java, based on JavaBat
The purpose of this thesis is to create a web-based, interactive environment for beginning
programmers and Computer Science (CS) students. This application allows teachers to gen-
erate small programming problems, to add problem descriptions in various (human) lan-
guages, to add code samples in various programming languages, and to define any amount
of test cases necessary to determine whether a solution is correct or not. The application al-
lows students to work on solutions for these problems online. By executing their code on the
server against the test cases previously provided by the teacher, they get immediate feedback
on the correctness of both their code syntax and code logic. The idea to this application is
based on Nick Parlante's ‘JavaBat’. The problems to be solved are intended to be of a simple
nature: Logical problems, strings, arrays, loops, recursive problems, etc. Any kind of problem
that can be solved within one method—not depending on other methods or other classes ex-
cept the standard data structures—can be incorporated in the application.

Mini Java Übungen, basierend auf JavaBat

Es soll eine web-basierte, interaktive Lernumgebung für Programmieranfänger bereitgestellt
werden. Diese Applikation wird es Lehrern ermöglichen Aufgaben zu generieren die von
Studierenden zum Üben grundlegender Problemstellungen des Programmierens genutzt
werden können. Diesen Aufgaben können Beschreibungen der Problemstellung in mehreren
Sprachen und Codebeispiele in mehreren Programmiersprachen zugeordnet werden. Wei-
terhin kann zu jeder Aufgabe eine beliebige Anzahl von Testfällen, bestehend aus den Einga-
beparametern und dem von diesen abhängigen, zu erwartenden Rückgabewert angelegt
werden. Studierende können diese Probleme bearbeiten und erhalten eine sofortige Reso-
nanz, nicht nur über die syntaktische Richtigkeit ihres Codes, sondern auch über dessen lo-
gische Korrektheit. Die Idee zu der Applikation basiert auf Nick Parlantes ‘JavaBat’. Die von
den Studierenden zu bearbeitenden Übungen sollen sehr einfacher Natur sein. Eine Übung
umfasst nicht mehr als eine einzelne Methode und wird nur die gebräuchlichen Datenstruk-
turen benutzen. Der Titel dieser Arbeit ist allerdings insofern irreführend, als dass die Appli-
kation nicht nur Problemlösungen in Java zulässt, sondern auch in einer grossen Anzahl an-
derer Programmiersprachen. Zur Zeit werden, neben Java, auch Python, Ruby und C++ un-
terstützt. Die Unterstützung weiterer Programmiersprachen wie unter anderen Objective-C,
SmallTalk, PHP, Haskell oder Perl kann mit relativ geringem Aufwand ermöglicht werden.
Table of Contents
1 Introduction ............................................................................................1

2 Objective ................................................................................................2

3 Status Quo – Existing Applications ........................................................3

3.1 JavaBat ..............................................................................................................3

3.2 BlueJ ..................................................................................................................6

3.3 Greenfoot ...........................................................................................................7

4 Why SuperBat? ......................................................................................8

5 Technology Selected ..............................................................................9

5.1 Thrift ...................................................................................................................9

5.2 Ruby On Rails ..................................................................................................11

5.3 Mongrel ............................................................................................................12

5.4 SQLite ..............................................................................................................13

5.5 AJAX ................................................................................................................13

5.6 Shell Scripts and PHP ......................................................................................13

5.7 JSON ...............................................................................................................13

5.8 JUnit .................................................................................................................14

5.9 Ubuntu ..............................................................................................................14

5.10 ANT and Make ...............................................................................................14

5.11 SVN ................................................................................................................15

6 Analysis ................................................................................................16
6.1 Required Functionalities ..................................................................................16

6.2 Database Analysis and Design ........................................................................17

7 Design ..................................................................................................20
7.1 User Interface ..................................................................................................20

7.2 User Interaction ................................................................................................27

7.3 Localization and Internationalization ................................................................30

8 Implementation Details .........................................................................32

8.1 Application Structure ........................................................................................32

8.2 Generating the Java Client ..............................................................................34

8.3 Generating the Thrift File .................................................................................38

8.4 Running the Thrift Compiler .............................................................................39

8.5 Copying Additional Files ...................................................................................39

8.6 Generating the Server ......................................................................................40

8.7 Running the User Generated Code .................................................................40

8.8 Security Aspects ..............................................................................................40

8.9 Odds and Ends (or Close Encounters of the Third Kind) .................................41

9 Tests .....................................................................................................43

10 Summary ............................................................................................44

Glossary .....................................................................................................i

Bibliography ..............................................................................................iii

Illustrations ..............................................................................................vii

Code Listings ..........................................................................................viii

Appendix ..................................................................................................ix
List of Used Interface Design Patterns ....................................................................ix

Users and Passwords .............................................................................................ix

Installing Additional Software ...................................................................................x

Installing Thrift .........................................................................................................xi

Installing SuperBat .................................................................................................xiv

CD Contents ...........................................................................................................xv

Selected Figures in Full Size ................................................................................xviii

Complete Source Code Listings ............................................................................xxi

Eigenständigkeitserklärung ......................................................................................1
1 Introduction
Computer science students are essentially facing two major tasks in their first semesters.
Matthew Butler and Michael Morgan, Faculty of Information Technology at Monash Univer-
sity, Melbourne, Australia state:

“It is one of the challenges of teaching programming that the balance must be found
between providing support for the low level issues, such as the syntax needed to im-
plement programming functions that allow students to see concrete examples of pro-
grams work in action, while still covering highly complex conceptual areas such as ob-
ject orientation, that allow efficient program design techniques.” [10, p.101]

No matter whether low level or high level—immediate feedback for learners is an extraordi-
narily important topic in every learning environment. No one wants to wait for hours or
even days to get to know the results of her work. Especially in the case of programming ex-
ercises where missing semicolons, commas or other hardly visible—sometimes even invisi-
ble—characters can be accountable for success or failure, immediate feedback is essential.

To obtain a working program, there is more than correct syntax. Syntactically correct code
can still provide completely wrong results. That is where test cases come into play. With their
help it is possible to verify if the expected results are according with the actual results.

Unfortunately test cases are not automatically available, they have to be written. This is a
difficult problem for programming novices. They are struggling with the odds and ends of
the programming language, so learning to use unit test frameworks at the same time is often
beyond their scope. Testing without using unit test frameworks is often tedious. Too often
the result is not testing at all.

The application to be developed not only provides teachers with the possibility to specify
relevant test cases for their programming problems, it even forces them to do so. Students on
the other hand are forced to run their code against those test cases. Thus they immediately
get feedback, still not on the quality of their code, but at least on its accuracy. Since they are
not yet familiar with the syntax of code they should not be additionally concerned with test-
ing. The application will support them to learn step by step and maybe they even get an idea
of the benefits of unit tests at an early stage in their careers.

1
2 Objective
Said Hadjerrouit points out one of the principles for the design of learning environments:

“Knowledge in a given domain must be actively constructed by learners, not passively

transmitted by teachers.” [23, p.2]

The objective of this thesis is to develop an application helping students to actively construct
and practice their low level routines. It will provide an interface for teachers by which they
can generate programming problems and supply them with descriptions for various human
languages, code samples in various programming languages, and test cases to verify the ac-
curacy of solutions provided by students. In the beginning this application will support Java,
Python, Ruby, and C++. Later on it will be possible to extend this list with more program-
ming languages. Section 5.1 will discuss this issue in depth. The application will manage all
the necessary file system and database operations. It also will operate security checks on the
provided student code. Section 8.2 will discuss this aspect in detail.

On the students’ side, the application will provide an interface to enter, save, compile, run,
and test methods. The application will embed these methods in a class. It will not be possible
to supply classes or other Object Oriented Programming (OOP) structures. From now on
these methods will be called solutions. Again, the student only has to enter her solution
while the application takes care of all the necessary file system and database operations.
Teachers also will be able to provide solutions. These will be called sample solutions or code
samples, depending on the context: a sample solution being a fully functional entity on the
server’s file system while a code sample is a string of source code stored in the database,
which optionally can be displayed to the student if she needs help. To generate a sample so-
lution, a code sample is mandatory.

A minimal user management will be provided. Available user roles will be either teacher or
student. Teachers will register as students first. They can then be upgraded to teachers from
the administrator.

Subsequent sections will use the terms front end and back end in a way that front end de-
scribes the components of the application that is directly visible to the users, no matter which
role these users have. Whenever necessary it will be differentiated between the teachers’
view and the students’ view. The term back end will be used to describe the part of the ap-
plication that handles the activities happening on the server’s file system.

From now on the application will be called SuperBat. Sections 3.1 and 4 will explain why.

2
3 Status Quo – Existing Applications
3.1 JavaBat
JavaBat, developed by Nick Parlante of Stanford University, Palo Alto, California, USA, is the
direct inspiration for SuperBat. It is a problem
based online live coding application. Each
problem consists of a problem statement or
description, which should be as precise and
unambiguous as possible, an input field where
students can enter their solution, and some
test cases against which the code is run. [36]

JavaBat gives an immediate feedback—based

Figure 1 Screenshot: JavaBat—Category Listing
➊ Category title and a set of selected problems (di-
rect access)
on the test cases. Thus the student instantly
knows if her code has been correct. It offers a
means to practice the coding basics such as
loops, if/else logic, strings, lists, etc., and is
intended to solidify the understanding of
these concepts. The problems, having low
overhead and an exam like volume, are very
simple. [36]

Nick Parlante differentiates between coding in the ‘large’ and ‘small’:

“By ‘large’ I mean the sweeping, strategic issues of algorithms, data structures, ... what
we think of basically as a degree in Computer Science. You also need skill in the ‘small’
-- 10 or 20 line methods built of loops, logic, strings, lists etc. to solve each piece of the
larger problem. Working with students in my office hours, I see what an advantage it is
for students who are practiced and quick with their method code. Skill with the
method code allows you to concentrate on the larger parts of the problem, or put an-
other other way, someone who struggles with the loops, logic, etc. does not have time
for the larger issues.” [36]

JavaBat’s intention is to train the skills of programming in the ‘small’. Later on in this section,
‘BlueJ’ will be discussed, which is aimed more at skills of programming in the ‘large’. JavaBat
tries to provide an environment where students can focus on these small things without hav-
ing to think about the ‘large’ at all. It is all about practicing the basic structures. The target
audiences are high school and first and second semester students at universities.

3
The following screenshots provide a survey for a typical workflow on JavaBat:
Figure 2 Screenshot: JavaBat—Problem Listing
➊ Selected category
➋ List of associated problems
Figure 3 Screenshot: JavaBat—Problem Selected
A solution can now be provided.
➊ Problem description
➋ Expected results
➌ Input field to enter solution
The problems are ordered by categories, Fig-
ure 1 shows the category listing as displayed
on JavaBat’s start page. Accompanying each
category title a selection of significant prob-
lems is displayed, providing quick access to
these selected problems. Selecting a category
navigates to the problem listing. Figure 2
shows category ‘Warmup’ being selected and
displaying the list of associated problems. In
Figure 3, problem ‘nearHundred’ has been
selected out of this list and the interface now
shows the description (Figure 3–➊), the ex-
pected test results (Figure 3–➋), and the input
field where the students can enter their code
(Figure 3–➌).
If the submitted code is correct the student
gets an immediate response from the applica-
tion. Figure 4 shows the test results for suc-
cessfully evaluated code. If the student has
difficulties solving the problem she can peek
at a code sample (Figure 5). Code samples are
only available for selected problems. Alterna-
tively, hints how to approach the problem can
be provided.
JavaBat also provides an environment of help
pages and programming knowledge based on
Nick Parlante’s computer science lectures at
Stanford.
Javabat provides a simple user administration.
Students can create an account and save the
problems they solved on the server if they are
logged in.
4
According to Nick Parlante:

“The name of the server is JavaBat, based on the Greek word ‘bat’ meaning ‘this do-
main was available’“1 [36]

JavaBat only supports English and Java, currently it does not provide an interface for other
teachers to add problems. This will be featured in JavaBat’s upcoming next version.

Figure 4 Screenshot: JavaBat—Problem Solved

➊ Test results are on display Figure 5 Screenshot: JavaBat—Problem Selected
➊ Sample solution on display

Figure 6 Screenshot: JavaBat—Help

1 According to the Greek-English online dictionary kypros.org, this is not quite right. Bat or βατ in modern Greek
translates as Watt (as in James Watt). (http://www.kypros.org/cgi-bin/lexicon, Retrieved: 12/18/2008)

5
3.2 BlueJ
Another application to teach programming is ‘BlueJ’ by Michael Kölling. It was developed as
a part of a University research project about teaching object orientation to beginners. It is
currently maintained by a joint research group at Deakin University, Melbourne Australia,
and the University of Kent in the UK.

BlueJ is operating on a higher level than Java-

Bat. Its purpose is to teach OOP techniques
such as inheritance, composition, etc. The goal
of JavaBat and SuperBat is to teach “low level”
techniques such as loops, conditions, etc.

BlueJ is a hybrid between a programming

learning tool and a (mini-)IDE. Its GUI con-
sists of a project window, a source code editor
(switchable to a documentation viewer), a
terminal window, a thing called the ‘codePad’,
and a debugger. The user can enter simple
statements in the codePad and evaluate them
directly. The results are shown in the terminal
Figure 7 Screenshot: BlueJ—Several Components
➊ Project window window. The usage of the codePad is a bit
➋ Source Code / Documentation window tricky as it evaluates each line when the return
➌ Terminal
key gets hit. So for more complicated state-
➍ Debugger
➎ ʻcodePadʼ ments the user has either to omit code format-
ting such as line breaks or indentation or she
has to write the code in an editor and copy and paste to the codePad. Creating a new class
provides the user with some example source code that can be viewed and edited in the
source code editor. Documentation—even JavaDocs—is generated automatically. The project
window (Figure 7–➊) is the place to create new classes, tests, interfaces, etc. BlueJ displays
the classes in an UML style representation. It also knows about (and displays) inheritance
and composition relationships between classes. Objects can be created visually and even sin-
gle methods of these objects can be executed separately.

Michael Kölling describes it like this:

“One of the fundamental characteristics of BlueJ is that you cannot only execute a
complete application, but you can also directly interact with single objects of any class
and execute their public methods. An execution in BlueJ is usually done by creating an
object and then invoking one of the object’s methods. This is very helpful during de-

6
 velopment of an application – you can test classes individually as soon as they have
been written. There is no need to write the complete application first.” [30, p.9]

These are just some basic features of BlueJ. It is a very interesting project, especially its auto-
mated testing feature is definitely worth having a look at. To do this is far beyond the scope
of this thesis. More information on this topic can be found at Kölling, The BlueJ Tutorial [29]
and Kölling, Unit Testing in BlueJ [30] .

A BlueJ plugin for ‘Netbeans’ is available which is meant to help students to switch from
BlueJ to a full-blown IDE at some point.

3.3 Greenfoot
Greenfoot is a learning environment developed, especially for animation and games pro-
gramming. It is another project by Michael Kölling, Deakin University, and the University of
Kent. To discuss it here is beyond the scope of this thesis. Further information can be found
on the Greenfoot homepage. [25]

7
 4 Why SuperBat?
Currently JavaBat is free for anyone to use, but lacks the option for teachers to provide prob-
lems of their own and it does not offer multi-language support. The initial idea was to coop-
erate with Nick Parlante on JavaBat; to obtain the sources and to add the missing features.
This was presuming that JavaBat would be available under the terms of any flavor of open
source license. It turned out that this presumption was wrong. Mr. Parlante is planning to
commercialize JavaBat and therefore did not want to pass on the sources. He is working on a
new version himself, which will offer an elementary problem editor for teachers. It was
planned to cooperate in testing2 the application’s new features. As first, the new problem edi-
tor still would not offer multi-language support and second, working on the test cases alone
soon appeared to be a bit lean for forty pages of a bachelor thesis, it was decided to start
working on SuperBat instead. A simple reverse-engineering of JavaBat plus adding a prob-
lem editor would have been rather senseless as Javabat’s next version will provide this fea-
ture. Multi-language support was considered trivial. Therefore it was decided to spice things
up by adding not only multi-language but also multi-programming-language support. The
application’s name—SuperBat—has been chosen as a tribute to JavaBat, expressing Super-
Bat’s extended capabilities.

2 In the end, instead of supplying Nick Parlante with test problems for JavaBat, some of the JavaBat problems
were used to test SuperBat. The problems and code samples visible in some of the screenshots, etc., often are
derived from the following Javabat problems (http://www.javabat.com/prob/p187868, Retrieved: 02/20/2009),
(http://www.javabat.com/prob/p181646, Retrieved: 02/20/2009), (http://www.javabat.com/prob/p159531, Re-
trieved: 02/20/2009), (http://www.javabat.com/prob/p101230, Retrieved: 02/21/2009)

8
5 Technology Selected
It was decided to use a mix of technologies to use the advantages of each to optimize the
quality of the result as well as the length of the development time. Ruby on Rails was chosen
for implementing user interfaces (UI) and database operations. Server side file system opera-
tions are handled with simple shell scripts or—whenever things get more complex—with
Command Line Interface (CLI)3 PHP. The students’ solutions are tested with JUnit test cases.
The selected Database Management System (DBMS) is ‘SQLite’.

Initially the biggest problem appeared to be the multi-programming-language support. It

was close to evident that the solution to this problem might be spotted somewhere in the
field of remote procedure calls (RPC). There is a great variety of established protocols avail-
able: SOAP, CORBA, RMI, SUN RPC, to name just some of them. The main purpose of these
protocols is to distribute applications over the web or at least to multiple machines. Most of
these protocols have a rather controversial reputation of having a huge overhead and being
hard to learn and to implement. To discuss all these protocols would be far beyond the scope
of this thesis. Further information can be found at the following sources: WikiBooks –
CORBA programming [60], Introduction to CORBA [48], Java Tutorial RMI [49], Overview of
SOAP [12].

In 2008 three new candidates appeared on the scene. Google’s Protocol Buffers [21], Cisco’s
Etch [5], and Facebook’s Thrift [4]. The decision for Thrift was essentially based on a post on
Stuart Sierra’s blog [45] and the discussion of RPC packages on Steve Vinoski’s blog [58].

5.1 Thrift
Thrift was developed at Facebook, open sourced in 2007 and added to the apache incubator
in 2008. [4] The assets of Thrift were that it supports more programming languages than any
other candidate—as this was the original reason to work with some sort of RPC proto-
col—and its extremely lightweight nature. The drawback is the lack of documentation. The
Wiki on the Thrift homepage is very poorly maintained. There are hardly any tutorials to
find. Reading the sources helped a lot in this case as they contain a decent little demo project,
which can easily be adapted. Protocol Buffers and Thrift are said to be very similar; Mark

3 PHP used on the System command line. In contrast to the Apache module PHP. An introduction to CLI-PHP can
be found here: (http://www.ibm.com/developerworks/opensource/library/os-php-command/index.html, Retrieved:
02/14/2009)

9
Slee4 , Facebook’s technical lead on the Thrift project had worked on Protocol Buffers during
his internship at Google before5.

On its homepage Thrift is described as follows:

“Thrift is a software framework for scalable cross-language services development. It

combines a software stack with a code generation engine to build services that work
efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell,
C#, Cocoa, Smalltalk, and OCaml.” [4]

Thrift uses an interface description language (IDL) file to generate the bindings for a wide
range of programming languages. The concepts and constructs supported by Thrift are
namespaces, base types, constants, enumerations, structs, containers, typedefs, services,
asynchronous function invocations, and exceptions. The syntax is similar to C++. Thrift does
not support cyclic structs (structs containing themselves), inheritance and polymorphism,
and heterogeneous containers. A function cannot return NULL directly. To achieve an
equivalent result it (the NULL Object) either has to be wrapped in a struct or a marker value
has to be returned instead. Thrift supports the primitive types that are common in program-
ming languages such as bool, byte, i16, i32, i64, double, and string. Furthermore it supports
structs, which are equivalent to C/C++ structs. The struct concept is similar to the class con-
cept in OOP languages. Structs however, do not support inheritance. The elements and struc-
ture of a struct are described in the ThriftIDL file. Thrift supports three container types. List,
set and map. Each of these containers expects the type of its future content elements. The
elements may be of any valid Thrift type whereas the keys of a map should be of a primitive
type for compatibility issues. The list translates to a std::vector in C++, an ArrayList in Java,
and native arrays in the supported scripting languages. The set translates to a std::set in C++,
a HashSet in Java, or a set in Python. The map translates to a std::map in C++, a Java Hash-
Map, an associative array in PHP, or a dictionary in Python/Ruby. Thrift exceptions integrate
seamlessly with each language’s native exception handling. Services are Thrift’s equivalent
to Java interfaces and C++ pure virtual abstract classes. Void is a valid return type and func-
tions can be declared ‘async’ if they do not have to wait for a response. [46]

Having installed the Thrift compiler, it is a straightforward process to use Thrift in an appli-
cation. The minimal requirement is a single ThriftIDL—or .thrift—file. This has to be written
manually6. Recurring tasks can be outsourced to separate services in separate .thrift files. To

4 On blip.tv a video is available showing Mark Slee and David Reiss presenting Thrift at the Seneca FSOSS sym-
posium in 2007 (http://blip.tv/file/446822, Retrieved: 12/20/2008)

5 Amongst others, some of the comments on Stuart Sierraʼs blog are claiming this
(http://stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers#comment-32039, Retrieved: 02/14/2009)

6 As opposed to the automated generation of the bindings.

10
access the facilities of an external service, services can extend each other. This concept is simi-
lar to inheritance in object oriented languages. Once these files have been written they just
have to be processed by the Thrift compiler,
which will generate the necessary code for
each specified programming language. These
generated files are bundled into directories,
which are named according to the program-
ming languages: ‘gen-java’, ‘gen-py’, ‘gen-
cpp’, etc. While the number, the nature, and
the content of these files is dependent on the
programming language for which they are
generated, their purpose and mode of opera-
tion is always the same. They wrap around the
variables, constants, methods, etc. specified in
the .thrift files, thus translating the specific
data types of each programming language
into a common idiom. At this point the foun-
dation is set to write the server and the client
files.

Apart from the ThriftIDL file a server and a

Figure 8 Model: Thrift—Mode of Operation
client are needed to complete the Thrift appli-
cation. These can be arbitrarily combined, e.g.
a C++ client might send requests to a Python server, etc. To establish a connection between
client and server Thrift provides a framework of socket, transport, protocol and server
classes for each of the supported languages. In section 8.2 to 8.7 this process and how it was
implemented in SuperBat will be discussed in more detail. Figure 8 shows an abstract model
of Thrift’s mode of operation.

5.2 Ruby On Rails

Ruby on Rails (ROR or Rails) was chosen for implementing SuperBat’s user interface (UI)
and database operations because it is supposed to provide very quick results in these areas.
The tenor of quotes describing Ruby is similar to the following, found on the webpage of
AES Technologies (India) Pvt. Ltd.:

“Appreciable reduction in the code lengths and volume that enhances the speed of the
project completion is seen with Ruby. Lessening the debugging pressure of the pro-
grammer, work moves at a smoother rate and more relaxed. Independent threading
facility, irrespective of the operating system and the highly portable nature enhances
the user-friendly nature of Ruby. [...] Ruby creates an environment that makes the pro-

11
 grammers to work more clearly, faster and be more meticulous and highly imagina-
tive.” [1]

Ruby itself is an interesting language, but this alone will not speed anything up. It actually
slows down the development process if the developer has to learn a new language first. The
main reason why working with Ruby was supposed to speed up development was the Rails
framework. This turned out to be true only at the very beginning. Later on, the lack of expe-
rience with the language and the framework slowed down the proceedings by almost the
same amount. This lack of experience cannot be blamed on Ruby or Rails.

While the core of the Ruby language, as well as the Rails framework is documented ex-
tremely well, some of the plugins are documented rather poorly. This unfortunately, is a
problem known in all programming languages. Some aspects of Rails’ best known paradigm
‘convention over configuration’ sometimes tend to be a mixed blessing for novices when
they go astray from the trail blazed by Rails. With hindsight, from a speed of development
point of view, considering the developer’s previous knowledge, it might have been a better
idea to use one of the PHP alternatives to Rails such as cakePHP [11] or symfony [51]

During the development process the question of scalability in the context of Rails applica-
tions was raised a couple of times. Gary Pollice of Worcester Polytechnic Institute (WPI),
Worcester, Massachusetts, USA, a sceptic himself:

“I've seen too many tools that promise great productivity gains. They look good on
‘toy’ projects, but fail horribly when you apply them to real problems.” [42]

describes the excellent experience one of his colleagues at WPI made with Rails:

“Assistments is a typical client/server Web application […] By last year, Assistments

consisted of over 50,000 lines of code (LOC) of mainly Java code. […] The last informa-
tion I received indicated that there were less than 5,000 LOC for the team to write and
maintain. This is better than a 10X productivity increase, and there have been fewer
defects reported against the system than average.” [42]

5.3 Mongrel
To deploy Rails applications various options are available. The most convenient one is to use
‘WEBrick’ as this is the default server that is delivered with Rails. According to various
benchmark tests [31, 34] Mongrel seems to be the faster and more scalable Ruby deployment
server. As little additional effort was required it was decided to switch to Mongrel right from
the beginning. Later on in the production version Apache2 could be used as a load balancer,
serving several Mongrel instances. [27]

12
5.4 SQLite
It was convenient to keep SQLite as the Database Management System in SuperBat’s devel-
opment version as it is Rails’ default DBMS. 7 On a productive system it probably should be
replaced by MySQL or another full scale database.

5.5 AJAX
Using AJAX, small portions of the page content can be updated while the larger part of the
page does not have to be reloaded. This of course improves the application’s responsiveness
as less data has to be sent from the server to the client. While at some points similar effects
might have been achieved using e.g. frame-sets, AJAX offers another advantage: using little
animations, the user’s attention can be directed to those parts of the webpage that have been
changed. If this technique is deployed very carefully it improves the application’s usability,
however it rapidly exhausts the user’s attention when it is overused. Both techniques, AJAX
and frame-sets, have similar drawbacks. Pages cannot be bookmarked precisely and the
functionality of the bowsers ‘Back’ button is reduced. Some clients, such as mobile phones,
also tend to have problems with AJAX sometimes. To support those, a separate, less complex,
more linear GUI will be necessary but this is not considered to be a major problem. Due to
Rails’ MVC architecture a separate view could be accomplished rather easily if the demand
for a mobile implementation will arise. It comes very handy that Rails has a convenient built-
in AJAX support. The ‘prototype’ framework and ‘script.aculo.us’ effects are delivered with
Rails as well as Rails methods such as link_to or form_for can easily be replaced by remo-
te_form_for or link_to_remote in case links or forms are not supposed to reload the com-
plete page.

5.6 Shell Scripts and PHP

Server side file system operations are handled with shell and CLI-PHP scripts. This turned
out to be a double-edged sword as well. Ruby itself provides an easy to use interface to shell
scripts so the PHP detour is redundant. Furthermore this construct complicates debugging
the complete system, while debugging and testing individual components induces similar
efforts either way.

5.7 JSON
Test cases and method arguments are stored in the database in JSON format. JSON is a
lightweight data interchange format. [13] Implementations are available for a very wide
range of programming languages. Its human-readability is sufficient, as Subbu Allamaraju,
Principal Engineer at Yahoo! Inc. notices:

7 One of SQLiteʼs drawbacks during development is that reliable SQLite User Interfaces, at least for Mac OS, are
hard to find. MesaSQLite, SQLite Database Browser, and the Firefox SQLite extension tended to stay out of date
when contents were inserted or deleted. The Terminal never failed.

13
 “one could easily argue that JSON is as human-readable as XML - provided both are
pretty-printed” [2]

While creating JSON is as easy as creating XML, evaluating JSON is far less annoying than
fiddling about with XML in most programming languages. [2] In SuperBat’s current state,
teachers have to provide the method arguments and test cases directly in JSON notation.
This of course is not a usable solution. Several options to find a better solution to this prob-
lem will be discussed in section 7.1.

5.8 JUnit
As during the projects initial phase testing was a core task, several unit testing frameworks
were examined. Finally it was decided to use JUnit 3 to handle the testing of students’ solu-
tions. SuperBat uses only a fraction of its features anyway, so JUnit 3 is more than sufficient
to accomplish these simple tasks.

5.9 Ubuntu
It was decided to use an Ubuntu 64-bit server. Ubuntu is easy to install and very well docu-
mented. This server was installed on a VMWare Virtual Machine running on a Mac OS X
host system. The constellation promised faster development times than using an internet
based server. Furthermore, it provided the required privileges and could have been easily
restored if things had gone wrong. The drawback was that it would have required additional
effort to make it accessible by the internet. This never became necessary, however. Working
on a virtual machine turned out to be extraordinarily convenient. The state of the machine
can be paused and reloaded very quickly at any time. Lengthy system shutdown or boot
procedures could be omitted most of the time. Additionally by using ExpanDrive, an sshfs
client for Mac OS X, the functionality of a Linux server could be combined with the ease of
use of the Finder. To select the 64-bit version turned out to be a rather rash decision. The
amount of hardware able to run the virtual machine was thereby drastically reduced. There-
fore it has been decided to reconsider this decision and to set up a new development server
running a 32-bit Ubuntu server system.8

5.10 ANT and Make

The automated compilation of source code in various programming languages is a basic task
for this application. Students’ solutions, sample solutions, and problems have to be compiled
frequently. ANT is a Java based build tool provided by the Apache Software Foundation.
Currently it can be considered as the standard tool to build Java applications. It is used in
this project to build the necessary Java programs. Although it is possible to build C++ code
using ANT, it was decided to rely on the classic ‘Make’ to build the solutions written in C++.

8 The attached CD contains a detailed description on the problems that occurred.

14
5.11 SVN
SVN has been chosen as the version control tool as it is well known to the author. More re-
cent developments such as Git have been considered but discarded as the project contains
enough experiments in other sectors. As only one developer was involved in the project and
all the development took place on a single machine, the advantages of Git would no longer
have much effect. Git had to be installed on the server later on as many Rails plugins are us-
ing it to distribute their downloads.

15
6 Analysis
This section will highlight the application’s essential functionalities and the database analy-
sis and design phases. Figuring out the essential front end functionalities, especially for the
students’ view, has been achieved by reverse-engineering JavaBat. The teachers’ view and
the way problems and solutions are stored on the file system, however, had to be developed
from scratch. Probably the most delicate task at the very beginning, was figuring out when
and in what hierarchy problems and solutions will be stored on the file system. Figure 11
shows an early attempt to structure this problem.

6.1 Required Functionalities

The core functionalities for teachers are adding, editing, and deleting problems as well as
adding, editing, and deleting the attached descriptions and code samples. Generated prob-
lems will not automatically be published. As long as they are not published they will only be
available in the teachers’ view. Unpublished
problems are invisible for students. Only after
problems have been thoroughly tested should
they be published and made available for stu-
dents. Published problems should not be ed-
ited in a way that the method signature will be
changed. This is because there might be many
saved solutions out there that depend on the
long term integrity of the method signatures.
Therefore the options to edit published prob-
Figure 9 Model: Required Functionalities for Teachers
lems are restricted. Published problems still
may be added to another category. Descriptions and code samples will always be editable of
course, as to err is human, and nobody should be forced to live with stupid typos for the rest
of her life. Registering and login, and especially the administration of classes and assign-
ments are not necessarily core functionalities of the application. For some time it was consid-
ered to implement the application as a plugin for an existent Learning Management System
(LMS) such as Moodle and to rely on the LMS’
capabilities to handle the administrative ne-
cessities. Later on it was decided to add at
least a minimal user management.

Adding a problem does not only add some

values to the database, as it generates a large
Figure 10 Model: Required Functionalities for Stu- amount of files and directories on the server’s
dents file system. Given many users, this will have

16

Figure 11 Model: First Attempts to Dispel the Dark-
ness
and therefore will need to be watched closely in a future ‘public’ beta version. The problem
gets worse if the system is not constrained to students of a certain university, but is publicly
available instead, as is JavaBat.
to be handled somehow. Logged in students
will be able to save their solutions. This can be
achieved in two ways: either the solution’s
complete file structure will be kept on the
server’s file system or only the piece of code
written by the student will be saved in the da-
tabase. The file structure will then have to be
generated anew each time the student runs
her code. Regenerating the file structure will
slow down the system, especially in stress
situations. On the other hand, this will save a
large amount of disk space when many stu-
dents are using the system frequently. An av-
erage Java solution claims approximately 100 -
150 KB. Solutions for scripting languages
claim a little less disk space. In an average
Moodle course9 at FHTW this would sum up
to approximately 300 MB of disk space for the
complete course. This seems not much at first,
but it will accumulate after several courses

When many students are compiling and running their code at the same time it will stress the
server. At this point it might turn out to be a good idea that all the file system operations
have been strictly separated from the front end application. It should be rather easy now to
distribute this part of the application to separate servers. Another possibility to speed up the
file generation process, would be to replace the PHP scripts with some kind of C code. Then
again the time consumed with file generation is nothing compared to the time spent compil-
ing the sources or generating the Thrift code, files, etc. Switching to a faster language would
not help at all in this case.

The Rails front end can be distributed as discussed in section 5.3 if necessary.

6.2 Database Analysis and Design

The objectives for the database design were to avoid redundancies and to retain flexibility.
Some decisions have been reconsidered several times during development. One of the recur-

9 Given 20 students, each solving 100 problems. Admittedly the size of the course is probably bigger than aver-
age and these students are extremely diligent.

17
ring questions was whether to implement SuperBat as a standalone application or as an i.e.
Moodle plugin. This is reflected in the various stages of the database design. Figure 12 shows
the Entity Relationship Model (ERM) for the full scaled database version. This version in-
cludes assignment lists and a simple
user management. It was decided to
start with a leaner and less elaborate
model, however. The complete as-
signment list complex has been re-
moved. At the beginning of the de-
velopment process, the user man-
agement was also removed.

Figure 13 shows the Logic Data

Model for the reduced functionalities
version, which is very similar to the
model currently used in SuperBat.
Assignment lists are omitted and the
user management is supposed to be
handled by the hosting LMS. The ta-
ble ‘Student’ at the bottom of the fig-
ure can be seen as a reference to the
hosting LMS’ ‘User’ table. Existing
flaws in the previously shown ERM
have been fixed. A category for in-
Figure 12 Model: Entity Relationship Model
stance is not an attribute of a problem
but an entity itself. A minor flaw in
the logic data model is the lack of a description column in the category table.

Finally a basic authentication and user management module was put back into the applica-
tion. The Rails plugins ‘restful_authentication’ [20] and ‘role_requirement’ [24] were in-
cluded to provide the application with more flexibility. These plugins added the tables
‘roles’, ‘roles_users’, and ‘users’ to the database.

In most cases there is no need to access the database directly when working with Rails and
SQLite. Operations that are meant to be persistent are better applied using migrations10, oth-
erwise they will be lost if the database is migrated the next time. [28]

10 So called migrations are Ruby scripts to do database operations such as creating tables, etc. The process of
executing these scripts is called to migrate the database.

18
A basic knowledge of how to access a SQLite database directly is essential, however. As pre-
viously mentioned all the tested GUI clients were unreliable. Therefore the Terminal was

Figure 13 Model: Logic Data Model

used to peek into the database. The following provides the most basic commands to control
if the database is in the expected condition.

First, switch to the Rails project’s database directory and open the development database:

cd /path/to/railsroot/db/

sqlite3 development.sqlite3

SQLite will now open an interactive dialogue.

sqlite>

The following commands retrieve the existing tables (please note the period in front), show
information about a certain table (note the semicolon), and exit the program (period again):

sqlite>.tables

sqlite>PRAGMA table_info(table_name);

sqlite>.exit

These commands plus the standard SQL statements such as ‘SELECT’, etc., will be sufficient
for the majority of cases. Further information can be found in the SQLite documentation. [47]

19
7 Design
To define a clear boundary between user interface and user interaction has been difficult in
some cases. Section 7.1 will discuss the more detailed aspects as to what happens if a certain
button gets clicked, while section 7.2 will highlight the larger scale aspects such as work-
flows, etc.

7.1 User Interface

Interface design is often considered a subordinate task in application development. Jef
Raskin states about the consequences:

“Project methodologies often fail to take full advantage of what is known about inter-
face design. This omission can be the result of bringing in interface designers long after
much of the opportunity for improving the quality of interaction between user and
product has been lost. Designs are most flexible at their inception. If interface designers
are consulted only after the software has been designed and the software tools chosen
or when the software is nearly complete, the correct advice—namely, to start over—is
unacceptable.” [43]

At any time during the application’s development process it was attempted to synchronize
the application’s requirements with the users’ needs. Right at the beginning of the develop-
Figure 14 GUI Design: Version 1—Studentsʼ View
The solution has successfully passed all tests.
The test results are on display
➊ ʻSearchʼ for direct access to problems
➋ Category short description. Appears when the user
hovers over the list entry with the mouse pointer.
➌ Test result table (screenshot from JavaBat)
➍ The top navigation bar for additional functionalities,
such as about, help, login, register, etc.
ment process several basic layouts had been
considered. Not least, depending on these
layouts, the tool to implement the applica-
tions’ front end has been chosen. In case the
front end would have become more complex,
it was considered to use Flex instead of Rails
to handle the front end tasks. It has been ob-
served during an earlier project that creating
complex interfaces can be done very effi-
ciently with Flex. Finally the decision to use
Rails was made due to its ability of almost
automated generation of standard database
operations and the application’s rather simple
user interface.
The design patterns that are used to describe
SuperBat’s UI elements in the following sec-

20
tion, are referring to Jenifer Tidwell’s book ‘Designing Interfaces - Patterns for Effective In-
teraction Design’ [56]11.

JavaBat’s user interface is very simple and straightforward. With a growing number of cate-
gories and problems this approach will eventually reach its boundaries. It was attempted to
keep this simplicity and straightforwardness, while expanding the scalability of the applica-
tion’s UI in the context of growing amounts of
content. The idea of bundling problems into
categories was kept, as well as the elements
that are displaying sample solutions and test
results. These two elements were separated
from the page’s main window into floating,
draggable layers, to make way for the addi-
tional necessary language and programming
language selectors. JavaBat’s ‘one-window
paging’ model [56, p.28ff], was replaced by an
extended ‘two-panel selector’ pattern [56,p 29,
31], which is familiar from various documen-
tation and reference pages as for example the
Java API Specification [50]. Instead of using a
frame-set, AJAX was applied to update the
contents of the panels. Additionally, at the top
Figure 15 GUI Design: Version 1—Studentsʼ View of the categories list, a search field is provided
Code sample on display.
as a short cut for more experienced users (Fig-
➊ List of categories
➋ List of problems, belonging to the selected cate- ure 14–➊). The categories and the problems
gory list make use of the ‘row striping’ pattern [56,
➌ Description of the selected problem
p.187ff] to visually separate the rows. The se-
➍ Text area to enter a solution
lected row will be highlighted with a third
➎ Floating layer displaying a sample solution (hidden
by default) color.
➏ Save, run, compile button
➐ Selectors for description language and program- The change in the main navigation model
ming language from ‘One-Window paging’ to a ‘Tiled Pane’
implies that there will be less room for some
elements. For instance there is not enough room left to initially display each category’s de-
scription. These descriptions will now be displayed in a floating layer when the user hovers
over the category’s list entry with the mouse pointer (Figure 14–➋).

Figure 15–➐ shows the two language selectors. Whenever a new language is selected the
contents of the according HTML element will be updated. The selectors are placed on large

11 A short description of the used patterns is given in the Appendix

21
arrows, indicating which parts of the page will be affected. Additionally an AJAX ‘Shake’
effect is applied to the affected element to focus the users attention on this area. Currently the

Figure 16 GUI Design: Version 1—Problem Editor,

Teachersʼ View

languages have to be reselected repeatedly

whenever a new problem is selected, as the
selectors always switch back to the system’s
default settings. This is very inconvenient,
and a future version will provide a facility
to preselect user defined default languages.

Figures 14 and 15 show an early version of Figure 17 Screenshot: Problem Creation Interface
Early unformatted Rails implementation..
the discussed elements and concepts ap-
➊ Category selector
plied to the students’ view of the applica- ➋ Text input: problem name
tion while Figure 16 displays the teachers’ ➌ Text input: return type (to be replaced by a selec-
tor)
view. At least in the students’ view the ba-
➍ Text input: method arguments
sics have not changed much during the de-
➎ Text input: test cases
velopment process. Of course some details ➏ Description table
had to be reconsidered continuously. The ➐ Sample code table

darkened area marks the part of the page

that is invisible without scrolling on a 800 x
600 pixels screen. Figure 15–➏ shows that unfortunately the ‘Save, Compile and Run’ button

22
initially would be out of range of such a small screen12 . Diminishing the input text area
would possibly cause an awkward
user experience. Therefore it was de-
cided to apply a dynamically growing
text area as well as positioning the
button to the right of the text area.
These arrangements are supposed to
provide an optimal usability for both
small and large screens.

The teachers’ view of the problem

had to be changed more drastically
during the development process. The
first design (Figure 16) only provides
text input fields for description, sam-
ple code and test cases. It turned out
to be necessary to change this struc-
ture. An additional input for the prob-
lem header was required. Also the UI
model for the multi-language support
turned out to be incomplete. Adding
or deleting languages by just switch-
ing to each with the according lan-
Figure 18 GUI Design: Version 2—Problem Editor, Teachersʼ
View
guage selector and then adding or
➊ Tool tip displayed when the user hovers over edit/delete but- deleting the contents all in the same
tons text input field is confusing. Further-
➋ Edit and delete buttons have been added to each list entry,
more it is not right away visible
an add button has been placed add the bottom of the lists
➌ Unpublished problems are displayed in a different color which languages have been added yet
➍ The category selector and which ones are still missing.
➎ The return type selector
Therefore tables for languages and
➏ Arguments and test cases can be entered in a more human
programming languages were added.
way
➐ Context sensitive help is provided Figure 17 shows a screenshot of a
➑ Save and publish button, checkbox to decide if a code sam- very early Rails implementation of
ple will be displayed to students
the problem editor. Buttons to add
➒ Descriptions attached to the problem
➓ Sample solutions attached to the problem descriptions and code samples have

12 It might be reasonably argued that the vast majority of the target audience is not using screens of that size
anyway. Optimizing the page for more common sizes such as 1024 x 768 or 1280 x 800 would extinguish the
problem. Other clients such as Smartphones or PDAʼs require a completely different User Interface anyway, due
to their very small screens and possibly different means of User Interaction.

23
been placed above the descriptions and code samples tables. Buttons to edit and delete de-
scriptions or to edit, delete, and run sample solutions have been placed adjacent to each list
entry. The insights gained during the development process were applied to the GUI Design.
Figure 18 shows some of the most important modifications. Edit and delete buttons were
added to the categories and problems
list items. Due to the restricted
amount of space in those lists, these
buttons have been implemented as
little icons (Figure 18–➋). An add but-
ton, also implemented as an icon, was
placed at the bottom of the categories
and problems lists. When the user is
hovering over these icons, tool tips
are displayed (Figure 18–➊). In the
teachers’ view unpublished problems
are displayed in a different color in
the problem list (Figure 18–➌). In the
students’ view they will not be dis-
played at all. A category selector has
been added to the problem editor. The
category selected in the category list
will be preselected in the category
selector (Figure 18–➍). The text input
field to specify the problem’s return
type has been replaced by a selector.
This was decided because the possi-
Figure 19 GUI Design: Version 2—Problem Editor, Teachersʼ ble values are clearly defined and not
View
necessarily common to the audience
➊ Description editor in floating layer
as Thrift types are requested (Figure
18–➎).

The inconvenient JSON notation in entering the method arguments and the test cases, has
been replaced by the following:

• Arguments: Argument 1 type, argument 1 name line break

Argument 2 type, argument 2 name line break
etc.

• Test Cases: Assertion type, [return value,] argument 1, argument 2, … , argument n line
break (Figure 18–➏)

24
Possible values for ‘assertion type’ are true, false, and equals whereas equals requires a re-
turn value.

Providing the user with a more elaborate way to enter the method arguments was also con-
sidered: a selector to choose the argument type plus a text input field to provide the argu-
ment name was discussed as an alternative to the simple text area (Figure 20). This model
requires an additional ‘add argument’
button to generate more of those
selector/input combinations if neces-

Figure 20 GUI Design: Version 2—Alternate UI Element, Argu-

sary. Finally it was decided to use the
ments simpler version as it seems more us-
able once users have learned the syn-
tax of the Thrift data types. The return type selector offers hints for the syntax. Additionally
context sensitive help buttons are provided to inform the user about the expected input (Fig-
ure 18–➐). The acceptance of this decision will have to be tested. If necessary a two way solu-
tion for different grades of user proficiency or preferences will have to be implemented. The
same consideration with a higher complexity applies to the way of entering the test case
data. Either way it now will be the application’s duty to convert this data into valid JSON
objects.

Save and publish buttons, as well as a checkbox to specify whether code samples will be dis-
played in the students’ view, are placed between the text area to enter test cases and the de-
scriptions table (Figure 18–➑). Descriptions and sample solutions attached to a problem are
displayed in tables at the bottom of the problem editor. The button to add another descrip-
tion or sample code is positioned at the table header’s right hand side. Edit and delete but-
tons were added to each list item. Clicking on the sample solution’s language logo will exe-
cute the code. As this behavior is not really obvious, a tool tip will be added here as well. It
will have to be tested if this functionality is too obfuscated. In case it turns out to be unusable
an additional ‘run’ button will have to be added. If the user clicks on the description’s or
sample solution’s edit or add button, the description or sample solution editor will open in a
floating layer as displayed in Figure 19. The category’s and problem’s edit and add buttons
react in the same manner. Clicking one of the delete buttons will open a JavaScript confirm
dialog before finally deleting the according item.

25
Figure 21 shows some screenshots of the front end’s current state. They show that—at least
in terms of functionality—most of the changes discussed on the previous pages have been
implemented on the whole. However, the layout details still need to be adjusted.

Figure 21 Screenshot: the Applicationʼs Current State

The complete series is available on the CD.

While conducting some final tests, a couple of bugs were detected. First, the workflow to cre-
ate a new problem needs to be fixed. Currently it is a hybrid between the old and the new
version. Section 7.2 will highlight some of these changes.

Some actions produce errors on the newly created SuperBat installation on the Ubuntu 32-bit
server (see section 5.9). Clicking on the sample solution editors submit button produces an
‘Error Code: 500 Internal Server Error’. The solution is generated, however and can be exe-
cuted. When executing the solution the test results are not displayed. It has been tried to lo-
cate the cause of these errors but up to now these efforts were in vain. As these errors do not
occur on the original installation, it is suspected that they are raised by a missing file or di-
rectory, missing read or write privileges, or differently adjusted settings in the new installa-
tion.

26
 7.2 User Interaction
Figure 23 shows a model of the
problem creation workflow. At the
time when this model was created,
the workflow was supposed to im-
plement the ‘wizard’ pattern [56,
p.42ff] , leading the user step-by-
step through the interface. Moving
forward in the problem creation
process is always well-defined.
Moving back is not so at some
points. A user moving back from
the sample code editor might not
expect to get back to the descrip-
tion editor but rather go back di-
rectly to the problem editor. The
Garrett IA Diagram in Figure 27
shows the same aspect from a
slightly different perspective. Fig-
ure 24 shows the same proce-
dure—plus the two additional
steps to get there—as it was im-
Figure 23 Model: Problem Creation Workflow plemented in Rails at an early stage

➊ A click on a category name opens the problem listing

➋ A click on the problems edit button opens the problem
editor. At the bottom of this page the descriptions and
code samples are listed. If a new problem has been
generated, the user gets redirected to the description
editor and from there to the sample code editor. This is
just an offer. The user can move back to the problem
editor whenever she wants without having to enter con-
tent.
➌ The Problem editor provides buttons to access the
description respectively the sample code editor
➍ Description editor
➎ Sample solution editor
➏ When the code sample is saved the ʻrunʼ button ap-
pears.
➐ Clicking on it runs the code against the predefined
test cases. The browser displays the results
Figure 24 Screenshot: Problem Creation Workflow
The complete series is available on the CD.

27
in the development process.

The following diagrams show the basic options for user interaction with the application’s
front end. They were created at an early stage of the development process, therefore at some
points they do not exactly represent the current state of the application’s interaction model.
Wherever necessary this will be indicated. In Figure 25 for instance, the user management

Figure 25 Model: Garrett IA Model [17]—Part 1

(1a): If the user is logged in, the logout function is available.
(1b): If the user is logged in, return her profile page. If the user is not logged in, return login page
(1c): If the user has the role ʻTeacherʼ, return her teacher profile page. If the user has the role ʻStudentʼ, return her
student profile page
(1d): Display the problems that are matching the search criteria
(1e): Display the problems that are attached to the selected category
(1f ): If the user is logged in, save her solution to the database. If not, return to login page

still is assigned to a hosting LMS only. The decision to implement a basic standalone version
is only partially reflected.

28
Figure 26 Model: Garrett IA Model—Part 2

Currently the application will not provide profile pages, neither for students, nor for teach-
ers. This is something to address in one of the application’s next versions. Profile pages are
meant to manage global user data such as name and password. They will also hold lists with
solved (students) and generated (teachers) problems. Preferences such as which user inter-
face version is preferred will be managed here as well.

Figure 26 implies that each teacher can edit only those problems that have been created by
herself, as they are accessed through the teacher’s profile page. This is an option that was
considered at the beginning of the development process. As it would have required a much
more elaborate user management, a different implementation was chosen. Each teacher can
access all the problems, no matter who created them. A more elaborate user management
will definitely be an option for a future version. Providing possibilities for each teacher to
handle decisions differently—such as if a code sample will be shown or not—will have to be
considered at the latest once assignment lists, etc., have been added. Currently as the appli-
cation will only be used for voluntary additional exercises, this option is not fundamental
and has therefore been omitted.

Figure 27 (1a) still shows the original idea to organize the problem creation in a wizard-like
pattern. [56, p.42ff] Because of the insights gained during the development process this was
replaced by a combination of several other patterns. Obviously, none of the used patterns can
be regarded on their own. In most cases, these patterns are a combination of not only one or
two, but a number of patterns, as Jenifer Tidwell defines very fine grained patterns. In this

29
Figure 27 Model: Garrett IA Model—Part 3
(1a) - Creating a new Problem is a comparatively straight forward process. Therefore it was decided to use the
ʻwizardʼ pattern. [32, p42]
(1b) - Due to the possibility to provide various languages and programming languages, editing an existing prob-
lem is not that straight forward at all. Going back stepwise is neither. Various solutions to step back have been
tested. All of these have been quite discouraging, where their usability aspect was concerned. It was therefore
decided to provide a view that contains a form for the problem core values as well as lists for those values that
might have multiple entries. (See also Figures 17–➏, 17–➐, 18–➒, 18–➓, and 24–➌)

case the patterns ‘animated transition‘ [56, p.84ff] , a form of ‘closable panels’ [56, p.111ff] ,
and a form of ‘moveable panels’ [56, p. 114ff] were combined to establish a more satisfying
user experience. The aforementioned patterns describe the essential behavior of the interface
element. This is a good example for the above mentioned statement that many—of the fine
grained—patterns are cooperating. To mention just a few of them: the ‘escape hatch’ [56,
p.86], to be seen in Figure 19–➊ (the close button at the top right of the description editor
layer) or the ‘button group’ [56, p.137ff] (see Figure 18–➌).

7.3 Localization and Internationalization

According to Wikipedia, internationalization is the process of preparing the software so that
it can be adapted to various languages while localization is the process of adapting the soft-
ware to a certain language. [61]

The topic does not fit seamlessly into the section’s principal theme: ‘Design’. There have been
reasonable arguments to place it at some other section such as ‘Implementation Details‘ or
maybe ‘Technology Selected‘. In this case—not selected, as currently SuperBat is neither lo-
calized nor internationalized. Finally it was decided to place it here as internationalization

30
implies a couple of aspects concerning user interface, user interaction, and user experience.
For instance the readability of certain fonts in different languages, possible required addi-
tional space in some languages 13, or the basic comprehension of user interface elements. The
use of icons instead of text on buttons is one way of internationalization. Unfortunately this
often arouses international incomprehension. This was discovered a long time ago. Jef
Raskin states in his book ‘The Humane Interface’:

“Icons contribute to visual attractiveness of an interface and, under the appropriate

circumstances, can contribute to clarity; however, the failings of icons have become
clearer with time. For example, both the Mac and Windows 95 operating systems now
provide aids to explain icons [...]” [43, p.168]

These aids obviously then need to be internationalized and localized again.

There are a couple of localization plugins available for Rails. The plugin ‘gibberish’ [59] has
been considered as it seemed to be comfortable to use. There is not much to localize in Su-
perBat anyway. All elements that are related to the generated code, such as problem names,
code samples, and test cases are best internationalized if they remain English.

Category names and descriptions are user generated and will require a slightly more elabo-
rated data model than they currently have to be internationalized. Their localization will re-
quire bigger efforts from teachers, as, if they establish a new category, they will have to do so
in several languages.

Problem descriptions are user generated and can be provided in a wide variety of languages.
Adjusting the writing direction can be done easily with CSS: direction:ltr; direction:rtl;
This is supposed to work in all modern browsers. [14]

The remaining are some buttons as well as the global navigation. In an internationalized ver-
sion, new aspects of sorting and searching will emerge. Students might want to search only
for problems available in a certain language. Teachers might want to search for problems that
are not available in a certain language to provide a translation. Obviously the same applies to
programming languages.

Later it was discovered that Rails 2.2 will ship with a built in internationalization (i18n) API.
[18] Therefore it was decided to postpone this topic until later.

13 I.e. German, and even more French require much more space than English does for text based buttons or list
items.

31
8 Implementation Details
8.1 Application Structure
The applications front end is basically a typi-
cal Rails application. Only few parts of the
auto-generated structure have been changed.
Most of the changes concerning the user inter-
face and user interaction have already been
discussed.

The application’s back end essentially has to

handle a great deal of file system operations. It
creates files and directories, runs the compil-
ers and interpreters, and handles catching
their output, passing it to the front end to be
displayed. At first most of this was done with
simple shell scripts. Since redundancies
started to appear in the code, it was decided to
switch to CLI-PHP to avoid the redundant
code by applying object oriented principles.
Figure 28 Model: Class Diagram—Generators
Figures 28 and 29 show how the ‘Generator’
and the ‘Runner’ class hierarchies are organ-
ized. When the user clicks on the problem edi-
tor’s submit button, a big deal of the action is
passed from the Rails front end to the shell.

Figure 30 shows the application’s two

branches with a focus on the back end. The
front end is located in the HTTP servers root
directory. On the development system this
would be /var/www/superbatFE

The back end is located outside of the HTTP

servers root directory in /var/superbat. This
directory contains the templates (TPL) to gen-
erate the source code in the supported pro-
gramming languages. These files are bundled
Figure 29 Model: Class Diagram—Runners
in several directories: _lib_javaTPL,
_lib_cppTPL, etc.

32
 _lib_misc contains some additional
required files such as build.xml to be
used by ANT, Makefile to be used by
Make, and a copy of JUnit.

_lib_thriftTPL, contains the template

to generate the problem specific .thrift
file, while _lib_thrift contains a so-
called shared service used to log the
communication between the Thrift
server and the Thrift client. Common
static tasks, which would be repeated
in various .thrift files are segregated
from the Thrift template to avoid as
many redundancies as possible.

_lib_tools contains the above men-

tioned generator and runner class hi-
erarchies.

Figure 30 Model: File and Directory Structure Finally the directory ‘problems’ con-
tains the file hierarchy for each prob-
lem. When the user in the front end clicks on the problem editor’s submit button, Rails stores
the submitted values in the database. Additionally—here in the back end—a directory hier-
archy for the new problem is generated. At the top of this hierarchy a directory is generated
whose name is derived from the problem’s name. This is why problem names have to be
unique and should not contain spaces, slashes, etc. In this directory the directories cpp, java,
py, and rb are generated, which will be holding the solutions later on. In each of these direc-
tories a samplesolution directory is generated. In each of those samplesolution directories a
src and a run directory are generated. Now the problem’s environment is set and the files
can be generated. The following sections will cover these operations in detail. The teachers’
sample solutions will be stored in the samplesolution directory later on. As previously men-
tioned, this is the point where things would get complicated if more than one code sample
per problem and programming language was allowed. The names of the directories that will
store the students’ solutions will be generated from the accessing IP address, a time stamp,
and the session id. If the student is logged in, her login name will be used as well. These di-
rectories are temporary and will be deleted when the session has ended. Whether the solu-
tions of logged in students will be stored here in the file system or if only the data necessary

33
 to regenerate them will be stored in the database, will
have to be discussed in more detail before the application
goes into production.

Figure 31 shows the file hierarchy of a generated problem

including a sample solution in Java and Python.

In the following, some light will be shed on the necessary

steps to generate a functional problem. The order in
which they are discussed is approximately chronological.

8.2 Generating the Java Client

At this point it is necessary to dwell on the usage of Thrift
in the application. For each problem a Java client is gener-
ated by replacing the placeholders in the file
JavaClientTPL.java with the—preprocessed—problem
data given by the teacher. For each solution a server—de-
pendent on the chosen programming language—is gener-
ated by replacing the placeholders in the file
{pl}ServerTPL.{pl}14 with the—preprocessed—solution
data given by a teacher or a student. The Java client is
holding the JUnit test cases against which the solutions
will be tested. Therefore the generated class JavaClient
extends class TestCase from the JUnit 3 framework. The
client (problem) and the server (solution) are communi-
cating using the methods provided by the Thrift frame-
work. Due to the bindings that will be generated by proc-
essing the file problemName.thrift through the Thrift
compiler, it does not matter in which programming lan-
guage the solution is written. These bindings are shown
in Figure 31. The directories gen-cpp, gen-java, gen-py,

Figure 31 Screenshot: File Struc-

ture—Problem
Files and directories that have to be
generated for a single problem. The
directories starting with gen- are gen-
erated by Thrift. Sample solutions in
Java and Python are provided for this
problem. Studentsʼ solutions have not
been provided yet.
and gen-rb as well as the contained
files and subdirectories are generated
by Thrift.
Listing 1 shows an excerpt of the Java
client template’s content. Unfortu-
nately some lines of the code in the
file are still redundant in all the cop-

14 Where {pl} is to be replaced by the symbol for the appropriate programming language

34
ies to be generated. These are the imports and the lines establishing the communication be-
tween client and server, to name a few. Another shady piece of code is the prophylactic im-
port of maps, sets and lists. To clean this up would require to parse the contents of the sup-
plied user generated data, checking if any of these containers have been used. It was decided
to do this the easy way. An annotation to suppress the resulting compiler warning was
added instead. Fortunately Java is not persnickety in this respect and abundant imports are
cheap. The following paragraph will describe the process of replacing the template’s place-
holders by user data in detail.

The client generator reads the template file’s content as a string. Then it performs a simple
string replacement on this string. The substrings delimited by <** **> are replaced by the
strings that have been preprocessed from the user generated data. The resulting string is
written to the new file JavaClient.java.

...
import com.facebook.thrift.TException;
...

import java.util.HashMap;
import java.util.HashSet;
import java.util.ArrayList;

import junit.framework.TestCase;
import junit.framework.AssertionFailedError;

@SuppressWarnings("unused")
public class JavaClient extends TestCase{

public void <**testMethodName**>() throws TException {

TTransport transport = new TSocket("localhost", 9090);
TProtocol protocol = new TBinaryProtocol(transport);
Executor.Client client = new Executor.Client(protocol);

transport.open();
<**testCaseBody**>
transport.close();
}
public static void main(String [] args) {
try {
JavaClient jc = new JavaClient();
jc.<**testMethodName**>();
...

Listing 1 JavaClientTPL.java—Excerpt

The following listing shows the client generator’s generateTestCaseBody() method, which is

35
replacing the template’s placeholder <**testCaseBody**> with JUnit assertions that are gen-
erated dynamically from the user generated input.

...
private function generateTestCaseBody ()
{
$testCaseBody = "";
for ($i = 0; $i <= count($this->testCases); ++$i) {
if (isset($this->testCases[$i])) {
$testCaseBody .= "try {\n";
switch ($this->testCases[$i]["assert"]["type"]) {
case "t" : $testCaseBody .= "\t\t\t\tassertTrue( ";break;
case "f" : $testCaseBody .= "\t\t\t\tassertFalse( "; break;
case "e" : $testCaseBody .= "\t\t\t\tassertEquals( "; break;
}
$testCaseBody.= "client.".$this->methodName."( ";
for ($j = 0; $j <= count($this->testCases[$i]); ++$j) {
if (isset($this->testCases[$i]["input"][$j])) {
$testCaseBody.= $this->testCases[$i]["input"][$j].", ";
}
}
//clean it
trim($testCaseBody);
$testCaseBody = substr( $testCaseBody,0,-2);
$testCaseBody.= ")";
if ( isset($this->testCases[$i]["assert"]["value"])) {
$testCaseBody.= ", ".$this->testCases[$i]["assert"]["value"];
}
$testCaseBody.= ");\n";
$testCaseBody.= "\t\t\t\tSystem.out.println(\"Test$i passed\");\n";
$testCaseBody.= "\t\t} catch (AssertionFailedError e) {\n";
$testCaseBody.= "\t\t\t\tSystem.out.println(\"Test$i failed\");\n";
$testCaseBody.= "\t\t}\n\t\t";
}
}
return $testCaseBody;
}
...

Listing 2 JavaClientGenerator.php—Excerpt

The methods replacing the other placeholders work analog to the preceding.

Assumed the following user input (here still in JSON notation):

Problem name: goToSchool

Return type: bool

Arguments: {
"1":{"type":"bool","identifier":"weekday"},

36
 "2":{"type":"bool","identifier":"vacation"}
}

Testcases: {
"1":{
"assert":{"type":"t"},
"input":{"1":"true","2":"false"}
},
"2":{
"assert":{"type":"f"},
"input":{"1":"false","2":"false"}
},
"3":{
"assert":{"type":"f"},
"input":{"1":"false","2":"true"}
}
"4":{
"assert":{"type":"f"},
"input":{"1":"true","2":"true"}
}
}

The resulting generated code will be:

...
public void goToSchool() throws TException {

TTransport transport = new TSocket("localhost", 9090);
TProtocol protocol = new TBinaryProtocol(transport);
Executor.Client client = new Executor.Client(protocol);

transport.open();

try {
assertTrue( client.goToSchool( true, false));
System.out.println("Test1 passed");
} catch (AssertionFailedError e) {
System.out.println("Test1 failed");
}
try {
assertFalse( client.goToSchool( false, false));
System.out.println("Test2 passed");
} catch (AssertionFailedError e) {
System.out.println("Test2 failed");
}

37
 try {
assertFalse( client.goToSchool( false, true));
System.out.println("Test3 passed");
} catch (AssertionFailedError e) {
System.out.println("Test3 failed");
}
try {
assertFalse( client.goToSchool( true, false));
System.out.println("Test3 passed");
} catch (AssertionFailedError e) {
System.out.println("Test3 failed");
}
transport.close();
}
...

Listing 3 JavaClient.java—Excerpt

8.3 Generating the Thrift File

The file problemName.thrift can be considered the heart of the application. It is generated
analog to the procedures discussed in the previous section. The following listings will show
the template and the resulting—generated—file. These listings are complete, only some
comments have been omitted.

...
namespace cpp shared
namespace java shared
include "../../_lib_thrift/shared.thrift"
service Executor extends shared.SharedService {
...
<**returnType**> <**methodName**> ( <**arguments**>)
}

Listing 4 problemName.thrift—Comments Omitted

The placeholders in the template above are replaced by the following code, which is as un-
spectacular as the template.

...
namespace cpp shared
namespace java shared
include "../../_lib_thrift/shared.thrift"
service Executor extends shared.SharedService {
...
bool goToSchool ( 1:bool weekday, 2:bool vacation)
}

Listing 5 goToSchool.thrift—Comments Omitted

38
8.4 Running the Thrift Compiler
The command thrift --gen cpp --gen java --gen py --gen ruby -r -o /path/to/
problemName /path/to/problemName/problemName.thrift will generate all the files and direc-
tories that are needed to translate between the Java client discussed in the previous section
and the solutions which will be provided in any of the sup-
ported programming languages during the following steps.
Due to the way the directory structure is organized, the Thrift
bindings—as well as the Java client—only have to be gener-
ated once per problem instead of once per solution. Figure 32
shows the files and directories that have been generated at this
point of the problem generation process.

•The basic directory hierarchy has been generated

•The JavaClient has been generated

•The ThriftIDL file has been generated and has been proc-
essed by the Thrift compiler—thus having generated the Thrift
bindings.

To edit a problem in a way that changes its fingerprint, the

complete problem will have to be deleted and regenerated
from scratch. This is only possible as long as the problem has
not been published.
Figure 32 Screenshot: Prob-
lem—goToSchool 8.5 Copying Additional Files
Files and directories that have
To finish the problem generation, the file _lib_misc/build.xml
been generated when the
goToSchool.thrift file was proc- has to be copied to the directory problemName/samplesolution/
essed by the Thrift compiler (for java/run/. Additionally the file _lib_misc/JavaClient is re-
the contents of the gen- directo-
quired. It does not need to be copied, however. All the proce-
ries, see Figure 31)
dures so far have been the result of the user’s click on the
problem editor’s submit button. The following steps will generate a sample solution. To
achieve this the teacher will have to add a code sample to the problem. Students’ solutions
will be generated analog to this procedure. Dependent on the solution’s programming lan-
guage there are some additional files that have to be copied. C++ requires _lib_misc/
MakeFile to be copied to samplesolution/cpp/run/; Java requires _lib_misc/JavaServer—a
shell script to start the execution of the Java program. Like the file _lib_misc/JavaClient,
_lib_misc/JavaServer does not have to be copied. It is sufficient if it exists in the specified
directory.

39
8.6 Generating the Server
The procedure is the same as generating the JavaClient and the ThriftIDL file from the tem-
plates. Server templates are available for each currently supported programming language.
PHP scripts preprocessing the user generated content, replacing the template placeholders
and writing the results to a new file also are available for each currently supported pro-
gramming language. To add support for another programming language that is supported
by Thrift the following steps will have to be taken:

• A template needs to be created

• A PHP class {pl}ServerGenerator extending class AbstractServerGenerator needs to be

created

• The new ServerGenerator needs to be added to the ServerGeneratorFactory

• The programming language needs to be added to the ProgLang database table

• A PHP class {pl}ServerRunner extending class AbstractServerRunner needs to be created

• The new ServerRunner needs to be added to the ServerRunnerFactory

8.7 Running the User Generated Code

When all the files have been successfully generated, the front end will provide the User with
a ‘run’ button. By clicking on this button the user will execute the generated code on the
server. If the selected programming language is not an interpreted language, the code will
have to be compiled first. From the currently supported programming languages only Java
and C++ need to be compiled. The Java code is compiled using ANT, C++ code is compiled
using Make. If the code contains syntax errors these will be detected by the compilers and
they will be displayed to the user. Otherwise the client and the server will be started. The
solution code contained in the server is tested against the client’s JUnit test assertions.
Whether or not the results provided by the solutions do match the predefined test assertions
will then be displayed to the user. As the server would run ‘forever’ it has to be stopped
right after the code has been executed. To do so, its process id has to be stored when it is be-
ing started. With this knowledge, stopping the server is trivial. As each solution provides its
own server, conflicting situations are not expected if multiple students execute their code si-
multaneously.

8.8 Security Aspects

As just mentioned, user generated code will be executed on the server. This obviously evokes
a wide range of nightmare scenarios for each system or network administrator. Every en-
deavor will have to be made to secure the application before it can be made productive. As a

40
first step, the user generated code will have to be parsed for keywords that imply an abusive
usage of the application. Candidates are ‘thread’, ‘fork’, ‘exec’ or similar commands that
might be used to start separate threads or processes. Each attempt to manipulate the file sys-
tem has to be prevented for all supported programming languages. As it is very easy to in-
teract with the system shell, at least from within Ruby or PHP applications, the usage of
commands such as ‘rm’, ‘chown’, ‘chmod’, ‘cp’, ‘file’ , ‘find’, etc. to mention just the tip of the
iceberg, has to be prevented as well. In Ruby an indicator for an attempt to interact with the
shell is the usage of back ticks ‘´’. In PHP the commands ‘exec’, ‘passthru’, ‘system’,
‘shell_exec’, ‘popen’, to mention just a few, are potential troublemakers. Any unauthorized
attempts to access the database also have to be prevented. Particular precautions have to be
taken if new programming languages are added as the keyword list possibly needs to be ex-
tended. Further possibilities to attack the server will have to be investigated very thoroughly
and an intensive testing with malicious users is strongly advised before bringing the applica-
tion to production. Even if all precautions have been taken, it is suggested that the applica-
tion be run on a separate server and regular backups are made on a daily basis.

Ruby offers a feature that might be advantageous to secure the application. Safe levels can be
set and Objects can be marked as tainted. In fact, every object that involved external data
somewhere in its creation history, or that is derived from such an object is marked as tainted.
If the safe level is set to 1, exceptions will be raised as tainted objects try to perform certain
operations, such as to pass form data to the eval method. [52] It has to be investigated how
far this might be useful for this applications purposes and if other languages provide similar
security mechanisms.

8.9 Odds and Ends (or Close Encounters of the Third Kind)
This chapter loosely couples some observations that were made while working on the appli-
cation respectively exploring the used tools and techniques.

Most of Ruby’s features are very straight forward and intuitive to learn. Often it consumed
more time than anything else to recognize that things are really as simple as they seem. Con-
structions such as the following example from The Pragmatic Programmer’s Guide are
amazing:

5.times {  print "*" }

3.upto(6) {|i|  print i }

('a'..'e').each {|char| print char }

produces:

41
 *****3456abcde

[53]

In the very beginning of a project Rails takes care of many tedious standard tasks, which
normally a developer would have to take care of herself. The concept of scaffolding or auto
generating the basic structure of an application definitely speeds up the development proc-
ess. On the other hand Rails also provides some really hard to track traps for newbies. One
of these is that Mongrel needs to be restarted to recognize changes to almost anything out-
side of Rails’ app/controllers, app/helpers, app/views, app/models directories. Another er-
ror, which was very time consuming to track down is the so-called cookie overflow. The
cookie size is about 4 KB. flash[:notice] and flash[:error] are a means to send messages
from one action to another. It seems as if these messages are stored temporarily in a cookie.
When they are used to send long debug messages from one action to the next they raise a
cookie overflow error.

Python syntax uses indentation to delimit methods, loops, etc. This makes it much harder to
build a waterproof generator than for the other programming languages.

Fixtures are a means to provide test data for tests in Rails. Fixtures are files that are stored in
the YAML [16] format. The colon, indicating the end of a Python method signature caused
problems in these fixtures. Most likely, there is a possibility to escape colons in YAML files
but it has not been encountered yet.

The tab-key applied on a text input field of an HTML document makes the cursor jump to
the next form element instead of indenting the code in the text field. For most web forms this
is the expected behavior of course. In this case it is rather annoying as—while writing co-
de—the tab-key is expected to indent the line as it would do in a text editor. It has to be fur-
ther investigated if there is a chance to change this behavior in the desired manner. JavaS-
cript methods such as preventDefault() might be good candidates to start with. If a possibil-
ity to change this behavior has been found, it still has to be tested if the desired usability
boost becomes a reality.

42
9 Tests
Because bugs kept sneaking into the application during the development process, it was de-
cided to safeguard the application with unit tests. Rails supports testing very well; basic test
stubs are generated automatically. The tests are separated into functional, unit, and integra-
tion tests. The unit tests test the models: if the data is entered correctly into the database and
if the data is compliant to the specified constraints, etc. Functional tests test the controllers: if
redirects happen where they are expected and if pages are rendered as expected, etc. Rails
provides a variety of methods such as: assert_response, assert_template, assert_differ-
ence, assert_redirected_to. These assist the developer in writing useful tests.

‘autotest’ [22] is a very handy tool for testing Rails applications. In principle it is constantly
running—previously specified—tests against the application. This enables developers to
monitor the effects of their work roughly in real time.

Testing in the applications PHP component is handled with PHPUnit [6], a unit testing
framework for PHP derived from JUnit.

Writing tests before writing the actual code definitely leads to better results. It has been expe-
rienced that writing useful tests later on is rather difficult especially if the developer and the
tester are the same person. Writing the tests first requires a certain amount of self-discipline,
however, especially if the schedule is tight. In the end it not only reduces debugging time
later on, but also yields more thoroughly reflected code.

43
10 Summary
The applications current state is best described as an incomplete, almost alpha version. On
the teachers’ side the basic functionality is available. Categories, problems, sample solutions
can be generated, edited, and deleted. Sample solutions can be compiled if necessary and can
be executed. The compiler’s and JUnit’s response can be displayed to the user. Some trivial
functions such as the possibility to add a description for a category can be added with little
effort.

The basics of the user management are set. The controllers still need to be secured, which can
also be done with little effort. Two user roles are available: ‘Teacher’ and ‘Student’. Each of
these roles can be granted with separate privileges. Additional roles can be added with little
effort.

The UI needs to be finished. The foundations to do this are laid. The UI designs have been
reworked according to the findings during development. The changes in the UI that already
have been applied still need to be reflected in the functional test cases.

The bulk of the remaining work is securing the application. Possible vulnerabilities have to
be investigated thoroughly and plenty of testing has to be done. Not only the application’s
security has to be tested, but load testing of the server needs to be done as well. Generating
and compiling the sources requires numerous resources, so it might not take too many users
to slow down the system. Should this happen, various possibilities to distribute the system
are available. Which of those or which combination of those would be the best to apply will
have to be investigated in more depth.

When the application is secured, the integration into Moodle and if possible other LM Sys-
tems can be investigated.

In a future version the support for additional programming languages can be added. As far
as these languages are supported by Thrift this can also be done with very little effort.

The application is on the right track to be finished successfully. It enables teachers to supply
their students with exercises and it meets the requirements of novice programmers to learn
basic programming tasks in a straightforward, little time-consuming way. There are still
many tasks that have to be carried out, but for most of them a solution or at least a possible
approach has been found or indicated. The biggest issue left is the security problem; but on
the other hand, if the application is running on an isolated server there is only little to be
damaged. A testable alpha version can be finished in about half a human-month15 . To bring

15 Referring to The Mythical Man-Month (Brooks, 1975)

44
the application to production will take another estimated 2 - 3 human-months, intensive al-
pha testing included.

The choice of some of the used tools is rated ambivalent. To select the 64-bit version of the
Ubuntu server definitely was not a brilliant idea as it leads to many hardware incompatibili-
ties. This is more a cosmetic issue concerning this thesis and its accompanying DVD than the
application itself. If necessary this decision can easily be fixed. The decision to use a wide
variety of programming languages requires a wide range of skills from possible future de-
velopers. This could of course become a cost factor. On the other hand the domain of the ap-
plication is multi-programming-language support, therefore these skills are required any-
way. As mentioned before, the anticipated gain in development speed by using Rails was
only partially fulfilled. Working with Ruby and Rails was very pleasant mostly. Learning
something new in the short term always requires additional time.

45
Glossary
A) I)

ANT - Another Neat Tool. Java based build tool, pro- i16 - 16 bit integer value (Thrift)
vided open source and for free by the ASF
i18n - short for internationalization
Apache - very popular web server
i32 - 32 bit integer value (Thrift)
Apache Software Foundation - nonprofit community of
i64 - 64 bit integer value (Thrift)
open source projects/developers

IDE - Integrated Development Environment

ASF - Apache Software Foundation

J)
B)
JavaBat - The inspiration for SuperBat
BlueJ - Learning environment for Object Oriented Prin-
ciples in Java JSON - JavaScript Object Notation, lightweight data-
interchange format
C)

CLI-PHP - see PHP CLI JUnit - Java testing framework

CS - Computer Science JVM - Java Virtual Machine

D) K)

DB - Database L)

DBMS - Database Management System

M)

E) Make - classic tool for automated software builds

eCampus - Learning Management System Mongrel - web server for Ruby web applications

ExpanDrive - Mac OS sshfs client with a GUI

Moodle - Learning Management System

F)
N)
Facebook - Company based in Palo Alto, California, Netbeans - a free IDE, provided by Sun Microsystems,
issuing a community website
Inc.

Finder - Mac OS File Browser

O)

Fitnesse - testing framework OOP - Object Oriented Programming

G) P)

Garrett IA Model - Interaction Model for Web Applica- PDA - Personal Digital Assistant. Handheld mini com-
tions invented by Jesse James Garrett puter

Greenfoot - Learning environment for games and ani- PHP CLI - PHP Command Line Interface: A way of
mation using PHP scripts on the system command line rather
than on a web server
GUI - Graphical User Interface
prototype - JavaScript framework
H)

i
Q) T)

Terminal - Command Line Interface

R)

Rails - short form of Ruby on Rails TestNG - testing framework

RMI - (Java) Remote Method Invocation Thrift - Software framework for scalable cross-language
services development
ROR - Ruby On Rails
UI - User Interface
RPC - Remote Procedure Calls
U)
Ruby on Rails - framework for agile web development
V)
S)
WEBrick - Ruby library program to build HTTP serv-
script.aculo.us - JavaScript effects framework
ers, default ROR server

Seneca FSOSS - Free Software and Open Source Sym-

W)
posium at Seneca College, Toronto, Canada
XML - eXtensible Markup Protocol
Smartphone - mobile phone with extended capabilities
X)
SOAP - Simple Object Access Protocol YAML - YAML Ain’t Markup Language. Human read-

SQLite - Lightweight Database Management System able data serialization standard

sshfs - Secure shell file system. Tool to mount remote

hard-drives

ii
Bibliography
[1] AESTechnologies, Developing web applications using Ruby on Rails framework,
http://www.advanceecomsolutions.com/resources/developing_web_applications_using_Ruby_on_Rai
ls_framework.asp, Retrieved: 02/14/2009

[2] S. Allamaraju, JSON vs XML, http://www.subbu.org/blog/2006/08/json-vs-xml, Retrieved: 02/18/

2009

[3] ApacheIncubator, Apache Thrift Download, http://incubator.apache.org/thrift/download/, Retrieved:

02/20/2009

[4] ApacheSoftwareFoundation, Apache Thrift, http://incubator.apache.org/thrift/, Retrieved: 10/05/2008

[5] ApacheSoftwareFoundation, Etch Project Incubation Status,

http://incubator.apache.org/projects/etch.html, Retrieved: 12/20/2008

[6] S. Bergmann, Installing PHPUnit, http://www.phpunit.de/manual/3.3/en/installation.html, Re-

trieved: 02/22/2009

[7] Blip.tv, Facebook's Thrift: Scalable Cross-Language Development - Mark Slee, David Reiss,
http://blip.tv/file/446822, Retrieved: 12/20/2008

[8] Borf, Comment on Stuart Sierra's Blog,

http://stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers#comment-32039, Retrieved: 02/14/2009

[9] F. P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley, 1975.

[10] M. Butler and M. Morgan, Learning challenges faced by novice programming students studying high
level and low feedback concepts,
http://www.ascilite.org.au/conferences/singapore07/procs/butler.pdf, Retrieved: 02/24/2009

[11] CakePHP, CakePHP: the rapid development php framework, http://cakephp.org/, Retrieved: 02/19/
2009

[12] T. Clements, Overview of SOAP, http://java.sun.com/developer/technicalArticles/xml/webservices/,

Retrieved: 12/20/2008

[13] D. Crockford, Introducing JSON, http://www.json.org/, Retrieved: 10/23/2008

[14] css4you, direction: Schreibrichtung: CSS-Referenz auf CSS 4 You - The Finest in Stylesheets,
http://www.css4you.de/Texteigenschaften/direction.html, Retrieved: 02/23/2009

[15] DebianAdmin, Ubuntu LAMP Server Installation With Screenshots,

http://www.debianadmin.com/ubuntu-lamp-server-installation-with-screenshots.html, Retrieved: 02/
20/2009

[16] C. C. Evans, The Official YAML Web Site, http://www.yaml.org/, Retrieved: 02/22/2009

[17] F. Frank, json -- JSON implementation for Ruby, http://json.rubyforge.org/, Retrieved: 11/07/2008

[18] S. Fuchs, The Ruby on Rails I18n core api,

http://www.artweb-design.de/2008/7/18/finally-ruby-on-rails-gets-internationalized, Retrieved: 02/
16/2009

iii
[19] J. J. Garrett, A visual vocabulary for describing information architecture and interaction design,
http://www.jjg.net/ia/visvocab/, Retrieved: 02/14/2009

[20] github, technoweenie's restful_authentication at master - GitHub,

http://github.com/technoweenie/restful-authentication/tree/master, Retrieved: 02/20/2009

[21] GoogleCode, Protocol Buffers - Google's data interchange format,

http://code.google.com/p/protobuf/, Retrieved: 12/20/2008

[22] G. Grosenbach, autotest -rails, http://nubyonrails.com/articles/autotest-rails, Retrieved: 11/15/2008

[23] S. Hadjerrouit, Toward a Constructivist Approach to Web-based Instruction in Software Engineering,

http://www.nik.no/2003/Bidrag/Hadjerrouit.pdf, Retrieved: 02/24/2007

[24] T. C. Harper, rolerequirement - Google Code, http://code.google.com/p/rolerequirement/, Retrieved:

02/20/2009

[25] P. Henriksen and M. Kölling, Greenfoot - A quick intro, http://www.greenfoot.org/doc/intro1.html,

Retrieved: 10/08/2008

[26] T. Iqbal, Installing C++ Boost on Gentoo and Debian/Ubuntu,

http://beans.seartipy.com/2006/03/15/installing-c-boost-on-gentoo-and-debianubuntu/, Retrieved:
02/20/2009

[27] S. Kemp, Running Ruby applications with Mongrel and Apache2,

http://www.debian-administration.org/articles/495, Retrieved: 02/14/2009

[28] M. Kern, Guide to Ruby on Rails Migrations,

http://www.oracle.com/technology/pub/articles/kern-rails-migrations.html, Retrieved: 02/27/2009

[29] M. Kölling, The BlueJ Tutorial, http://www.bluej.org/tutorial/tutorial-201.pdf, Retrieved: 12/10/2008

[30] M. Kölling, Unit Testing in BlueJ, http://www.bluej.org/tutorial/testing-tutorial.pdf, Retrieved: 10/28/

2008

[31] A. Kovyrin, High-Performance Ruby On Rails Setups Test: mongrel vs lighttpd vs nginx,
http://blog.kovyrin.net/2006/08/22/high-performance-rails-nginx-lighttpd-mongrel/, Retrieved: 02/
14/2009

[32] Kypros-Net, Greek - English Dictionary, http://www.kypros.org/cgi-bin/lexicon, Retrieved: 12/18/

2008

[33] R. McCoy, Command-line PHP? Yes, you can!,

http://www.ibm.com/developerworks/opensource/library/os-php-command/index.html, Retrieved:
02/14/2009

[34] MissionData, Mongrel vs. WEBrick,

http://www.missiondata.com/blog/ruby/71/mongrel-vs-webrick/, Retrieved: 02/14/2009

[35] D. Pape, Installing sqlite3-ruby, http://dpape.com/blog/index.php?entry=entry070827-032711, Re-

trieved: 02/20/2009

[36] N. Parlante, JavaBat About, http://www.javabat.com/about.html, Retrieved: 10/02/2008

[37] N. Parlante, JavaBat Array-1 makeEnds, http://www.javabat.com/prob/p101230, Retrieved: 02/21/

2009

iv
[38] N. Parlante, JavaBat Logic-1 cigarParty, http://www.javabat.com/prob/p159531, Retrieved: 02/20/
2009

[39] N. Parlante, JavaBat Warmup-1 monkeyTrouble, http://www.javabat.com/prob/p181646, Retrieved:

02/20/2009

[40] N. Parlante, JavaBat Warmup-1 sleepIn, http://www.javabat.com/prob/p187868, Retrieved: 02/20/

2009

[41] N. Partridge, Building Thrift on Ubuntu,

http://blog.nickpartridge.com/2008/09/building-thrift-on-ubuntu-804.html, Retrieved: 10/18/2008

[42] G. Pollice, Rails: The luxury line to professional Web sites,

http://www.ibm.com/developerworks/rational/library/aug07/pollice/index.html, Retrieved: 02/14/
2009

[43] J. Raskin, The Humane Interface, Addison-Wesley, 2000.

[44] RubyOnRailsWiki, Rails On Ubuntu, http://wiki.rubyonrails.org/rails/pages/RailsOnUbuntu, Re-

trieved: 02/20/2009

[45] S. Sierra, Thrift vs. Protocol Buffers, http://stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers,

Retrieved: 10/05/2008

[46] M. Slee, A. Agarwal and M. Kwiatkowski, Thrift: Scalable Cross-Language Services Implementation,
http://incubator.apache.org/thrift/static/thrift-20070401.pdf, Retrieved: 02/22/2009

[47] SQLite, Query Language Understood by SQLite, http://www.sqlite.org/lang.html, Retrieved: 02/29/

2009

[48] SunDeveloperNetwork, Introduction to CORBA,

http://java.sun.com/developer/onlineTraining/corba/corba.html, Retrieved: 12/20/2008

[49] SunDeveloperNetwork, Trail: RMI (The Java™ Tutorials),

http://java.sun.com/docs/books/tutorial/rmi/index.html, Retrieved: 12/20/2008

[50] SunMicrosystems, Java Platform SE 6, http://java.sun.com/javase/6/docs/api/, Retrieved: 02/15/

2009

[51] symfony, symfony | Web PHP Framework, http://www.symfony-project.org/, Retrieved: 02/19/2009

[52] D. Thomas, C. Fowler and A. Hunt, Programming Ruby: The Pragmatic Programmer's - Guide Locking
Ruby in the Safe, http://www.rubycentral.com/pickaxe/taint.html, Retrieved: 02/14/2009

[53] D. Thomas and A. Hunt, Programming Ruby - The Pragmatic Programmer's Guide,
http://www.ruby-doc.org/docs/ProgrammingRuby/html/intro.html, Retrieved: 02/17/2009

[54] ThriftWiki, GettingUbuntuPackages, http://wiki.apache.org/thrift/GettingUbuntuPackages, Re-

trieved: 02/26/2009

[55] ThriftWiki, ThriftInstallation, http://wiki.apache.org/thrift/ThriftInstallation, Retrieved: 02/25/2009

[56] J. Tidwell, Designing Interfaces: Patterns for Effective Interaction Design, O'Reilly Media, Inc., 2005.

[57] UbuntuDocumentation, Postfix, https://help.ubuntu.com/community/Postfix, Retrieved: 02/20/2009

v
[58] S. Vinoski, Just What We Need: Another RPC Package,
http://steve.vinoski.net/blog/2008/05/22/just-what-we-need-another-rpc-package/, Retrieved: 10/
14/2009

[59] C. Wanstrath, Ya Talkin' Gibberish, http://errtheblog.com/posts/55-ya-talkin-gibberish, Retrieved: 02/

16/2009

[60] Wikibooks, CORBA Programming, http://en.wikibooks.org/wiki/CORBA_Programming, Retrieved:

12/01/2008

[61] Wikipedia, Internationalization and localization,

http://en.wikipedia.org/wiki/Internationalization_and_localization, Retrieved: 02/23/2009

vi
Illustrations
p. 3: Figure 1 Screenshot: JavaBat—Category Listing

p. 4: Figure 2 Screenshot: JavaBat—Problem Listing

Figure 3 Screenshot: JavaBat—Problem Selected

p. 5: Figure 4 Screenshot: JavaBat—Problem Solved

Figure 5 Screenshot: JavaBat—Problem Selected

Figure 6 Screenshot: JavaBat—Help

p. 6: Figure 7 Screenshot: BlueJ—Several Components

p. 11: Figure 8 Model: Thrift—Mode of Operation

p. 16: Figure 9 Model: Required Functionalities for Teachers

Figure 10 Model: Required Functionalities for Students

p. 17: Figure 11 Model: First Attempts to Dispel the Darkness

p. 18: Figure 12 Model: Entity Relationship Model

p. 19: Figure 13 Model: Logic Data Model

p. 20: Figure 14 GUI Design: Version 1—Students’ View

p. 21: Figure 15 GUI Design: Version 1—Students’ View

p. 22: Figure 16 GUI Design: Version 1—Problem Editor, Teachers’ View

Figure 17 Screenshot: Problem Creation Interface

p. 23: Figure 18 GUI Design: Version 2—Problem Editor, Teachers’ View

p. 24: Figure 19 GUI Design: Version 2—Problem Editor, Teachers’ View

p. 25: Figure 20 GUI Design: Version 2—Alternate UI Element, Arguments

p. 26: Figure 21 Screenshot: the Application’s Current State

Figure 22 GUI Design: Logo Designs

p. 27: Figure 23 Model: Problem Creation Workflow

Figure 24 Screenshot: Problem Creation Workflow

p. 28: Figure 25 Model: Garrett IA Model—Part 1

p. 29: Figure 26 Model: Garrett IA Model—Part 2

p. 30: Figure 27 Model: Garrett IA Model—Part 3

p. 32: Figure 28 Model: Class Diagram—Generators

vii
 Figure 29 Model: Class Diagram—Runners

p. 33: Figure 30 Model: File and Directory Structure

p. 34: Figure 31 Screenshot: File Structure—Problem

p. 39: Figure 32 Screenshot: Problem—goToSchool

Code Listings
p. 35: Listing 1 JavaClientTPL.java—Excerpt

p. 36: Listing 2 JavaClientGenerator.php—Excerpt

p. 38: Listing 3 JavaClient.java—Excerpt

Listing 4 problemTPL.thrift—Comments Omitted

p. 39: Listing 5 goToSchool.thrift—Comments Omitted

viii
Appendix
List of Used Interface Design Patterns
(According to Jenifer Tidwell [56])

One-Window Drilldown/One-Window Paging: each of the applications pages is shown in a single window. Scrol-
lable if necessary. Navigating completely reloads a page.

Two-Panel Selector/Tiled Panes: The application’s window is split into several panes. Clicking on an item in one
pane changes the contents of the other panes. A Three-panel selector adds another level of abstraction.

Wizard: The user is guided through a complex process step-by-step.

Row Striping: Alternating rows in a list or table are displayed in slightly different colors.

Animated Transition: State changes in the user interface are animated to attract the user’s attention

Closable Panels: Additional information or interaction elements are displayed in separate panels that can be
opened and closed.

Moveable Panels: The position of these panels is not fixed

Escape Hatch: Possibility to get out of a situation without changing anything. Aka cancel or close button.

Button Group: Semantically connected buttons are displayed close to each other.

Users and Passwords

Device User Password

Server: tombstone jerry grateful_dead

Application: teacher jerry garcia

mysql root pigpen

ix
Installing Additional Software
Always update apt-get first: sudo apt-get update

Ubuntu Server Thrift

ubuntu-8.04.1-server-amd64.iso --lamp See detailed instructions on the following page
Included are: apache2.0, php-apachemodule, mysql,
ANT
java6, python, ruby
Detailed instructions [15] sudo apt-get install ant

RubyOnRails
Detailed instructions [44] (look for ‘The recom- SVN

mended way’) sudo apt-get install subversion

Sqlite3 for Ruby

Detailed instructions [35] Git

sudo apt-get install git-core

JSON for Ruby

sudo gem install json Postfix

Required by restful_authentication
Detailed instructions [17]
sudo apt-get install postfix
PHP5-CLI
Detailed Instructions to secure the mail server [57]
sudo apt-get install php5-cli

PEAR

sudo apt-get install php-pear

sudo pear channel-update pear.php.net

sudo pear upgrade-all

PHPUnit
Add pear channel:

sudo pear channel-discover

pear.phpunit.de

Install:

sudo pear install phpunit/PHPUnit

Boost
Required by Thrift
Detailed instructions [26]

x
Installing Thrift
Thrift requires quite a bulk of additional packages.

sudo apt-get install build-essential autotools-dev autoconf automake

sudo apt-get install libboost-dev automake libtool flex bison

sudo apt-get install sun-java6-jdk

sudo apt-get install libevent-dev

sudo apt-get install pkg-config

The mono packages are necessary for C# support only.

#sudo apt-get install mono-runtime monodevelop monodoc

The thrift version in the Git repository works for Ubuntu 8.04 but not for Ubuntu 8.10

wget -O thrift.tgz
"http://gitweb.thrift-rpc.org/?p=thrift.git;a=snapshot;h=HEAD;sf=tgz"

tar -xzf thrift.tgz

To install Thrift on Ubuntu 8.10 use the Thrift version from the SVN repository. This does not work for Ubuntu
8.04

svn co http://svn.apache.org/repos/asf/incubator/thrift/trunk thrift

The preceding steps assumed that the current directory is the user’s home directory.
I.e. /home/jerry/ both variants will then install Thrift in /home/jerry/thrift
From here on the same steps are required for both versions:

cd thrift

./bootstrap.sh.

sudo ./configure --with-boost=/usr/lib (depending on the location of boost )

sudo make install

The basic installation of Thrift is done now. For Java support the following step is necessary:

If not installed yet, install ANT (see previous page) and go to Thrift’s lib/java directory

cd lib/java #assuming the current directory still is /home/jerry/thrift

sudo ant

xi
Some other programming languages might require additional steps. Instructions can be found in the according
thrift/lib/progLang directories’ README files.

Download page [3]

The previous instructions have been accumulated from the following sources [41, 54, 55]

To test if the Thrift installation is working copy the directory thrift/tutorial to an arbitrary location.

I.e. /var/thrifttest

cd /var

cp -R /home/jerry/thrift/tutorial thrifttest

Now compile tutorial.thrift using the Thrift compiler.

cd /var

cp -R /home/jerry/thrift/tutorial thrifttest

sudo thrift --gen cpp --gen java --gen py --gen rb -r -o thrifttest/

/thrifttest/tutorial.thrift

Change into the thrifttest directory and list the files.

cd thrifttest

ls -l

The output should be similar to this:

total 56
drwxr-xr-x 2 root root 4096 2009-02-25 22:04 cpp
drwxr-xr-x 2 root root 4096 2009-02-25 22:04 erl
drwxr-xr-x 2 root root 4096 2009-02-26 10:24 gen-cpp
drwxr-xr-x 4 root root 4096 2009-02-26 10:24 gen-java
drwxr-xr-x 4 root root 4096 2009-02-26 10:24 gen-py
drwxr-xr-x 2 root root 4096 2009-02-26 10:24 gen-rb
drwxr-xr-x 3 root root 4096 2009-02-25 22:04 java
drwxr-xr-x 2 root root 4096 2009-02-25 22:04 perl
drwxr-xr-x 2 root root 4096 2009-02-25 22:04 php
drwxr-xr-x 2 root root 4096 2009-02-25 22:04 py
drwxr-xr-x 2 root root 4096 2009-02-25 22:04 rb
-rw-r--r-- 1 root root 741 2009-02-25 22:04 README
-rwxr-xr-x 1 root root 293 2009-02-25 22:04 shared.thrift
-rwxr-xr-x 1 root root 4063 2009-02-25 22:04 tutorial.thrift

The gen-* directories have just been generated.

Everything has been set up now so it is time to see if it works. First one of the servers needs to be started. If it is
decided to do the test with a server and/or client in a compiled language it needs to be compiled first.

xii
For C++:

cd cpp

sudo make

or for Java:

cd java

sudo ant

The clients and servers in the scripting languages can be used right away. Server and client can be arbitrarily
combined, but the server needs to be started first. In the following example a C++ server and a Java client will be
started. The current working directory is /var/thrifttest and both server and client have been compiled yet.
As the server will run until it is stopped again, it will be necessary to either use the command screen or to use
several Terminal windows as assumed in the following example.

Server window Client window

cd cpp

./CppServer

Starting the server...

Thrift: Thu Feb 26 12:36:20 2009

TServerSocket::listen() IPV6_V6ONLY
Protocol not available

cd java

./JavaClient

ping()

1+1=2

Invalid operation: Cannot divide by 0

15-10=5

Check log: 5

ping()

add(1,1)

calculate(1,{4,1,0})

calculate(1,{2,15,10})

getStruct(1)

xiii
Installing SuperBat
Suggested best practice is to create a SVN repository and to import the sources from the CD.

svnadmin create /path/to/repository

svn import -m "Alea Iacta Est" /path/to/sources file:///path/to/repository/

Then do an initial checkout. Something similar to the following examples, depending on the connection that has
been chosen to
be used with SVN.

sudo svn checkout file:///path/to/repository/<component> /path/to/

workingdirectory

cd /path/to/working directory

sudo svn checkout svn+ssh://user@IP.ADD.RESS/path/to/repository/<component>

The suggested locations to check out these directories on Ubuntu are /var/superbat and /var/www/
superbatFE.

The directory /var/superbat/problems has to be created manually.

cd /var/superbat

mkdir problems

Depending on the environment it might be necessary to recursively change the owner of superbat and super-
batFE.

cd /var

sudo chown -R jerry superbat

cd /var/www

sudo chown -R jerry superbatFE

To start Mongrel:

cd /var/www/superbatFE

script/server

SuperBat is now accessible via: IP.ADD.RESS:3000/

xiv
CD Contents
• grafix
• raw
• charts_diagrams
• classes_sequence_interaction.graffle
• db_models.graffle
• directory_hierarchy.graffle
• flowchart_functionalities_state_garrett.graffle
• thrift_model.graffle
• logo
• bigbat_complete.psd
• bigbat_torso.tif
• bigbat.png
• bigbat.psd
• bigbat.svg
• minibat.png
• P1020301.ai
• P1020301.jpg
• P1020301.psd
• smallbat.psd
• UIDesign
• ApiStyle.psd
• ApiStyleBackend_new.psd
• ApiStyleBackend_new.tif
• ApiStyleBackend.psd
• ApiStyleBackend.tif
• ApiStyleResults.tif
• ApiStyleSampleCode.tif
• browserheader.tif
• checkbox.tif
• closeBtn.tif
• lists.rtfd
• loginBtn.tif
• resultstable.tif
• screenshots_frontend_new
• current_version_confirm_delete.tiff
• current_version_description_editor.tiff
• current_version_display_testresult.tiff
• current_version_java_problem_created_and_compiled.tiff
• current_version_loggedin_as_teacher.tiff
• current_version_login_layer.tiff
• current_version_problem_editor.tiff
• current_version_register_layer.tiff
• current_version_samplecode_editor.tiff
• current_version_solution_editor.tiff
• current_version._about.tiff
• intermediate_version_about.tiff
• intermediate_version_login_layer.tiff

xv
 • intermediate_version_solution_editor.tiff
• screenshots_frontend_old
• Picture{12-25}.tiff
• select.tif
• separator.tif
• textarea.tif
• textfield.tif
• toolbar.tif
• vscroll.tif
• vscrollLong.tif

• used_in_thesis
• Figure{1-32}.tif
• internetsources
• 1_Developing web applications using Ruby on Rails framework.pdf
• 2_JSON vs XML at subbu.org.pdf
• 3_Apache Thrift download.pdf
• 4_Apache Thrift_home.pdf
• 6_Chapter 3. Installing PHPUnit.pdf
• 8_Thrift vs. Protocol Buffers - Digital Digressions by Stuart Sierra.pdf
• 10_butler.pdf
• 13_JSON.pdf
• 14_direction_ Schreibrichtung_ CSS-Referenz auf CSS 4 You - The Finest in Stylesheets.pdf
• 15_Ubuntu LAMP Server Installation With Screenshots -- Debian Admin.pdf
• 16_The Official YAML Web Site.pdf
• 17_JSON implementation for Ruby.pdf
• 18_The Ruby on Rails I18n core api - artweb design.pdf
• 19_Jesse James Garrett_ Visual Vocabulary for Information Architecture.pdf
• 20_technoweenie's restful-authentication at master - GitHub.pdf
• 22_autotest -rails | Ruby on Rails for Newbies.pdf
• 23_Hadjerrouit.pdf
• 24_rolerequirement - Google Code.pdf
• 26_Installing C++ Boost on Gentoo and Debian_Ubuntu.pdf
• 27_Running Ruby applications with Mongrel and Apache2.pdf
• 28_Guide to Ruby on Rails Migrations.pdf
• 29_bluej_tutorial-201.pdf
• 30_bluej_testing-tutorial.pdf
• 31_a_Looking For Optimal Solution_ Benchmark Results Summary and Findings __ Homo-Adminus Blog
by Alexey Kovyrin.pdf
• 31_High-Performance Ruby On Rails Setups Test_ mongrel vs lighttpd vs nginx __ Homo-Adminus Blog
by Alexey Kovyrin.pdf
• 33_Command-line PHP.pdf
• 34_Mission Data Blog » Blog Archive » Mongrel vs. WEBrick.pdf
• 35_Giving Back - Installing sqlite3-ruby.pdf
• 36_JavaBat About.pdf
• 41_Nick's Blag_ Building Thrift on Ubuntu 8.04.pdf
• 42_Rails_ The luxury line to professional Web sites.pdf
• 44_RailsOnUbuntu in Ruby on Rails.pdf

xvi
 • 45_Thrift vs. Protocol Buffers - Digital Digressions by Stuart Sierra.pdf
• 46_thrift-20070401.pdf
• 52_Programming Ruby_ The Pragmatic Programmer's Guide.pdf
• 54_GettingUbuntuPackages - Thrift Wiki.pdf
• 55_ThriftInstallation - Thrift Wiki.pdf
• 57_Postfix - Community Ubuntu Documentation.pdf
• 58_Just What We Need_ Another RPC Package __ Steve Vinoski’s Blog.pdf
• 59_Ya Talkin' Gibberish — err.the_blog.pdf
• 60_CORBA Programming - Wikibooks, collection of open-content textbooks.pdf
• 61_Internationalization and localization - Wikipedia, the free encyclopedia.pdf
• additional
• adaptive path » ajax_ a new approach to web applications.pdf
• BSDRailsBenninger.pdf
• Mike Clark's Weblog.pdf
• ThriftInstallation - Thrift Wiki.pdf
• sourcecode
• superbat
• Contains the application’s back end component.
The suggested location on an Ubuntu system is /var/superbat. A complete listing is omitted
• superbatFE
• Contains the application’s front end component.
The suggested location on an Ubuntu system is /var/www/superbatFE.
A complete listing is omitted
• thesis
• thesis.pages
• thesis_print.pdf
• thesis_web.pdf
• sourcecode_listings.pdf

xvii
Selected Figures in Full Size

Figure 11 Model: First Attempts to Dispel the Darkness

xviii
Figure 12 Model: Entity Relationship Model

xix
xx
Figure 13 Model: Logic Data Model
Complete Source Code Listings
Back End 1

Front End - app 42

Front End - config 82

Front End - db 85

Front End - public 91

Front End - test 94

xxi
Eigenständigkeitserklärung
Hiermit versichere ich, dass ich die vorliegende Bachelor Thesis selbständig und nur unter
Verwendung der angegebenen Quellen und Hilfsmittel verfasst habe. Die Arbeit wurde bis-
her in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt.

Berlin, 02.03.2009