superbat - bachelor's thesis. multi language programming teaching tool, based on javabat and...

8/8/2019 SuperBat - Bachelor's Thesis. Multi Language Programming Teaching Tool, based on JavaBat and Facebook Thrift

http://slidepdf.com/reader/full/superbat-bachelors-thesis-multi-language-programming-teaching-tool 1/72

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 oreven 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 adifficult 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 arenot 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 allthe 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 codesamples, 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—basedon 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 themethod 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

Figure 1 Screenshot: JavaBat—Category Listing

➊ Category title and a set of selected problems (di-

rect access)



The following screenshots provide a survey for a typical workflow on JavaBat:

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

Figure 3 Screenshot: JavaBat—Problem Selected

A solution can now be provided.

➊ Problem description

➋ Expected results

➌ Input field to enter solution

Figure 2 Screenshot: JavaBat—Problem Listing

➊ Selected category

➋ List of associated problems



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.

5

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


➊ Sample solution on display

Figure 4 Screenshot: JavaBat—Problem Solved

➊ Test results are on display

Figure 6 Screenshot: JavaBat—Help



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

window. The usage of the codePad is a bit

tricky as it evaluates each line when the return

key gets hit. So for more complicated state-

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

Figure 7 Screenshot: BlueJ—Several Components

➊ Project window

➋ Source Code / Documentation window

➌ Terminal➍ Debugger

➎ ʻcodePadʼ



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 foundon 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.

8

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)



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 onStuart 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

9

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)



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

10

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.



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

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

Figure 8 Model: Thrift—Mode of Operation



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 Railsframework. 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 AJAXUsing 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 thefunctionality 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:

13

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.



“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 machinecan 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++.

14

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



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 andthe 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-

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

amount of files and directories on the server’s

file system. Given many users, this will have

16

Figure 10 Model: Required Functionalities for Stu-

dents

Figure 9 Model: Required Functionalities for Teachers



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

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 publiclyavailable instead, as is JavaBat.

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-

17

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.

Figure 11 Model: First Attempts to Dispel the Dark-

ness



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 functionalitiesversion, 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-

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]

18

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

Figure 12 Model: Entity Relationship Model



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

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 sufficientfor the majority of cases. Further information can be found in the SQLite documentation. [47]

19

Figure 13 Model: Logic Data Model



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 andproduct 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-

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

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.



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 programminglanguage 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

of the categories list, a search field is provided

as a short cut for more experienced users (Fig-

ure 14–➊). The categories and the problems

list make use of the ‘row striping’ pattern [56,

p.187ff] to visually separate the rows. The se-

lected row will be highlighted with a third

color.

The change in the main navigation modelfrom ‘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

21

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

Figure 15 GUI Design: Version 1—Studentsʼ View

Code sample on display.

➊ List of categories

➋ List of problems, belonging to the selected cate-

gory

➌ Description of the selected problem

➍ Text area to enter a solution

➎ Floating layer displaying a sample solution (hidden

by default)

➏ Save, run, compile button

➐ Selectors for description language and program-

ming language



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

languages have to be reselected repeatedly

whenever a new problem is selected, as theselectors 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

the discussed elements and concepts ap-

plied to the students’ view of the applica-

tion while Figure 16 displays the teachers’

view. At least in the students’ view the ba-

sics have not changed much during the de-

velopment process. Of course some details

had to be reconsidered continuously. The

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

Figure 17 Screenshot: Problem Creation Interface

Early unformatted Rails implementation..

➊ Category selector

➋ Text input: problem name

➌ Text input: return type (to be replaced by a selec-

tor)

➍ Text input: method arguments

➎ Text input: test cases

➏ Description table

➐ Sample code table

Figure 16 GUI Design: Version 1—Problem Editor,

Teachersʼ View



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 providestext 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-

guage selector and then adding or

deleting the contents all in the same

text input field is confusing. Further-

more it is not right away visible

which languages have been added yet

and which ones are still missing.

Therefore tables for languages and

programming languages were added.

Figure 17 shows a screenshot of a

very early Rails implementation of

the problem editor. Buttons to add

descriptions and code samples have

23

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.

Figure 18 GUI Design: Version 2—Problem Editor, Teachersʼ

View

➊ Tool tip displayed when the user hovers over edit/delete but-

tons

➋ Edit and delete buttons have been added to each list entry,

an add button has been placed add the bottom of the lists

➌ Unpublished problems are displayed in a different color

➍ The category selector

➎ The return type selector

➏ Arguments and test cases can be entered in a more humanway

➐ Context sensitive help is provided

➑ Save and publish button, checkbox to decide if a code sam-

ple will be displayed to students

➒ Descriptions attached to the problem

➓ Sample solutions attached to the problem



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 categoryselector (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-

ble values are clearly defined and not

necessarily common to the audience

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

Figure 19 GUI Design: Version 2—Problem Editor, Teachersʼ

View

➊ Description editor in floating layer



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 modelrequires an additional ‘add argument’

button to generate more of those

selector/input combinations if neces-

sary. Finally it was decided to use the

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 aredisplayed 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 buttonsreact in the same manner. Clicking one of the delete buttons will open a JavaScript confirm

dialog before finally deleting the according item.

25

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

ments



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.

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-bitserver (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

Figure 21 Screenshot: the Applicationʼs Current State

The complete series is available on the CD.



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-

plemented in Rails at an early stage

27

Figure 23 Model: Problem Creation Workflow

Figure 24 Screenshot: Problem Creation WorkflowThe complete series is available on the CD.

➊ 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 problemeditor 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



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

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

is only partially reflected.

28

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



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 26 Model: Garrett IA Model—Part 2



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

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–➌)



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 languages13 , 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.

31

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



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.

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 thiswould 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

in several directories: _lib_javaTPL ,

_lib_cppTPL , etc.

32

Figure 28 Model: Class Diagram—Generators

Figure 29 Model: Class Diagram—Runners



_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 templateto 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 asmany redundancies as possible.

_lib_tools contains the above men-

tioned generator and runner class hi-

erarchies.

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 storesthe 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

Figure 30 Model: File and Directory Structure



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 fileJavaClientTPL.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 JavaClientextends 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 ,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-

34

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

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.



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**>();...

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

Listing 1 JavaClientTPL.java—Excerpt

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 ittrim($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;

}...

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"},

Listing 2 JavaClientGenerator.php—Excerpt

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":{


"input":{"1":"false","2":"true"}

}

"4":{


"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");


System.out.println("Test3 failed");

}

try {

assertFalse( client.goToSchool( true, false)); System.out.println("Test3 passed");


System.out.println("Test3 failed");

} transport.close();}...

8.3 Generating the Thrift FileThe 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 sharednamespace java sharedinclude "../../_lib_thrift/shared.thrift"

service Executor extends shared.SharedService {...<**returnType**> <**methodName**> ( <**arguments**>)

}

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

spectacular as the template.

...namespace cpp sharednamespace java sharedinclude "../../_lib_thrift/shared.thrift"service Executor extends shared.SharedService {...

bool goToSchool ( 1:bool weekday, 2:bool vacation)}

Listing 3 JavaClient.java—Excerpt

Listing 4 problemName.thrift—Comments Omitted

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.

8.5 Copying Additional Files

To finish the problem generation, the file _lib_misc/build.xml

has to be copied to the directory problemName/samplesolution/

java/run/. Additionally the file _lib_misc/JavaClient is re-

quired. It does not need to be copied, however. All the proce-

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

Figure 32 Screenshot: Prob-

lem—goToSchool

Files and directories that have

been generated when the

goToSchool.thrift file was proc-

essed by the Thrift compiler (for

the contents of the gen- directo-

ries, see Figure 31)



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 theserver. 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 autogenerating 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 acookie 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 systemare 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

44

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



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 theapplication 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)

ANT - Another Neat Tool. Java based build tool, pro-

vided open source and for free by the ASF

Apache - very popular web server

Apache Software Foundation - nonprofit community of

open source projects/developers

ASF - Apache Software Foundation

B)

BlueJ - Learning environment for Object Oriented Prin-

ciples in Java

C)

CLI-PHP - see PHP CLI

CS - Computer Science

D)

DB - Database

DBMS - Database Management System

E)

eCampus - Learning Management System

ExpanDrive - Mac OS sshfs client with a GUI

F)

Facebook - Company based in Palo Alto, California,

issuing a community website

Finder - Mac OS File Browser

Fitnesse - testing framework

G)

Garrett IA Model - Interaction Model for Web Applica-

tions invented by Jesse James Garrett

Greenfoot - Learning environment for games and ani-

mation

GUI - Graphical User Interface

H)

I)

i16 - 16 bit integer value (Thrift)

i18n - short for internationalization



IDE - Integrated Development Environment

J)

JavaBat - The inspiration for SuperBat

JSON - JavaScript Object Notation, lightweight data-

interchange format

JUnit - Java testing framework

JVM - Java Virtual Machine

K)

L)

M)

Make - classic tool for automated software builds

Mongrel - web server for Ruby web applications

Moodle - Learning Management System

N)

Netbeans - a free IDE, provided by Sun Microsystems,

Inc.

O)

OOP - Object Oriented Programming

P)

PDA - Personal Digital Assistant. Handheld mini com-

puter

PHP CLI - PHP Command Line Interface: A way of

using PHP scripts on the system command line rather

than on a web server

prototype - JavaScript framework

i



Q)

R)

Rails - short form of Ruby on Rails

RMI - (Java) Remote Method Invocation

ROR - Ruby On Rails

RPC - Remote Procedure Calls

Ruby on Rails - framework for agile web development

S)

script.aculo.us - JavaScript effects framework

Seneca FSOSS - Free Software and Open Source Sym-

posium at Seneca College, Toronto, Canada

Smartphone - mobile phone with extended capabilities

SOAP - Simple Object Access Protocol

SQLite - Lightweight Database Management System

sshfs - Secure shell file system. Tool to mount remote

hard-drives

T)

Terminal - Command Line Interface

TestNG - testing framework

Thrift - Software framework for scalable cross-language

services development

UI - User Interface

U)

V)

WEBrick - Ruby library program to build HTTP serv-

ers, default ROR server

W)

XML - eXtensible Markup Protocol

X)

YAML - YAML Ain’t Markup Language. Human read-

able data serialization standard

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,


[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,


[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


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


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 Studentsp. 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. 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 PasswordsDevice 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

ubuntu-8.04.1-server-amd64.iso --lampIncluded are: apache2.0, php-apachemodule, mysql,

java6, python, ruby

Detailed instructions [15]

RubyOnRails

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

mended way’)

Sqlite3 for Ruby


JSON for Ruby

sudo gem install json


PHP5-CLI

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


Thrift

See detailed instructions on the following page

ANT

sudo apt-get install ant

SVN

sudo apt-get install subversion

Git

sudo apt-get install git-core

Postfix

Required by restful_authentication

sudo apt-get install postfix

Detailed Instructions to secure the mail server [57]

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 56drwxr-xr-x 2 root root 4096 2009-02-25 22:04 cppdrwxr-xr-x 2 root root 4096 2009-02-25 22:04 erldrwxr-xr-x 2 root root 4096 2009-02-26 10:24 gen-cppdrwxr-xr-x 4 root root 4096 2009-02-26 10:24 gen-javadrwxr-xr-x 4 root root 4096 2009-02-26 10:24 gen-pydrwxr-xr-x 2 root root 4096 2009-02-26 10:24 gen-rbdrwxr-xr-x 3 root root 4096 2009-02-25 22:04 javadrwxr-xr-x 2 root root 4096 2009-02-25 22:04 perldrwxr-xr-x 2 root root 4096 2009-02-25 22:04 php

drwxr-xr-x 2 root root 4096 2009-02-25 22:04 pydrwxr-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://[email protected]/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

xviii

Figure 11 Model: First Attempts to Dispel the Darkness



xix

Figure 12 Model: Entity Relationship Model



xx

F

i g u r e 1 3 M o d e l : L o g i c D a t a M o d e l



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

superbat - bachelor's thesis. multi language programming teaching tool, based on javabat and...

Documents