Paper ID #30280

Industrializing Your Web Application Development Project

Dr. Gregory Kulczycki, Virginia Tech
Dr. Kulczycki has extensive experience in research and development both in academia and industry. He
received his doctorate from Clemson University in 2004 and began working as a professor at Virginia Tech
shortly thereafter. In 2011 he went to work for Battelle Memorial Institute as a cyber research scientist,
while continuing to be involved in teaching. He is currently back in the computer science department at
Virginia Tech as a professor of practice, where he teaches, designs courses, and develops online content for
Virginia Tech’s highly-regarded Master of Information Technology program. Dr. Kulczycki has various
publications on topics including formal specification and verification, web services, and software reuse.
His interests include object-oriented programming, software specification and reasoning, design patterns,
and online learning.
Dr. Steven Atkinson, Virginia Tech
Dr. Atkinson works in industry as a Senior Software Engineer for Netflix and in academia as an Instructor
at Virginia Tech for the Computer Science Department. He was one of the first employees at LinkedIn, and
his industrial experience spans 21 years, including work at startup companies in fields ranging from enter-
prise document management, to healthcare and high performance networking. Dr. Atkinson’s academic
experience includes a Ph.D. from University of Queensland, Australia and an Assistant Professorship at
West Virginia University. He has publications in the areas of formal specification and verification of soft-
ware systems, and software reuse. Dr. Atkinson’s interests currently include programming languages,
high performance data transmission and re-architecture of larger existing software systems and software
engineering curriculum development.

c American Society for Engineering Education, 2020

 Industrializing Your Web Application Development Project

Abstract

In any software development course, a good project is key. It challenges students, and it drives
decisions about other course materials. Keeping it fresh and up to date can be a challenge,
especially in fast-changing areas like web or mobile development.
This paper presents two distinct experiences and insights (one of us is a university professor, and
one is an industry professional) on “industrializing” a full-semester project in a web application
development course that we co-teach. By industrializing, we mean evaluating the project with a
focus on whether it is consistent with current industry practices, and then developing the project
as any good company would: using best practices from software engineering and industry, such
as iterative development, continuous integration, refactoring, and regression testing. Over the
course of only three years, we went through not one, but two major revisions of a semester-long
project, and we anticipate more revisions in the future. We began with a project that was
effective from a teaching standpoint but was in need of a significant update to its code design
and implementation.
We first discuss the environment in which the course is taught. It is part of a graduate, online
degree program that caters to working professionals from a variety of backgrounds. We then
introduce the project – a mini e-commerce web site that is presented to students over the course
of the semester in 10-12 separate assignments. We detail why and how the project
implementation was modified, despite the fact that the functional requirements remained
relatively stable. We then summarize the lessons learned from these revisions and talk about how
we plan to manage changes in the future. Finally, we offer suggestions on how others might go
about industrializing their own software development projects.

Introduction

Industry and academic professionals continue to call for more collaboration in Computer Science
and Information Technology education [1]. Project-Based Learning (PBL) [2] and Active
Learning [3] are key instructional approaches that benefit from a strong industry connection. In
this paper, we talk about our experience in injecting industry practice into the core of the project-
based course: the project itself.
One of the authors of this paper is a university professor; the other author is a professional web
developer. Together, we teach a graduate course on web-application development that is centered
around a semester-long project.
When the course was first introduced in the Fall of 2016, only the professor was teaching it. The
semester-long project – a mini e-commerce web site – was a good one. It used a model-view-
controller architecture, involved both front-end and back-end development, and required a
connection to an SQL database. The implementation of that project, however, already felt a bit
dated. The front end used Java more than JavaScript, and the back end used on an older
framework that concealed underlying design patterns. Since a major goal of the course was to
expose students to current technologies and practices used in real-world web development, the
professor invited the professional web developer to join the course as an instructor in the next
semester. The project underwent a major revision to bring it more in line with current industry
practice. Two years later, the project went through another major revision, again in the interest of
reflecting common practices in industry.
We learned a lot from doing two major project rewrites in less than three years, but perhaps the
most important “lesson” is that these revisions will continue. And if we want to keep up with the
changing software landscape in industry – especially in the fast-moving world of web-
development – the project must continually evolve to reflect those changes. This does not mean
that we are in for a career of stressful project rewrites, but it does mean if we want to keep the
course current, we will have to find a pace of making changes that we can maintain indefinitely,
reminiscent of one the principles of agile development: Agile processes promote sustainable
development. [Everyone] should be able to maintain a constant pace indefinitely. [4].
Related Work
Web-development projects – especially those involving the development of small e-commerce
web sites – are popular in software engineering education. They work well with project-based
learning [5] and agile methods [6]. They are well-suited for courses where industry collaboration
or a real-world feel is desired [7][8], especially in capstone projects [9]. We found that many
research papers or experience reports that talked about web development in software engineering
education were concerned with students getting a feel for the development experience. They
asked questions like: Was PBL employed? Were students using Agile? Were they working in
teams? Was the project real-world enough? Our concerns were more focused on the code design
and implementation. We wanted to ensure that the languages and technologies we used to teach
web-development were consistent with what is in use today, and that the code design and the
patterns were reflective of what a professional web developer would use. If one of our students
were to sit down with a prospective employer and demo their project, and speak intelligently
about its implementation, we wanted to have some confidence that the employer would be
impressed.
In 2013, a panel at the ACM SIGITE conference (Special Interest Group on Information
Technology Education) looked at the role of web development curriculum in IT programs [10].
One of the panelists (Zheng) discussed the problems involved in “keeping up with the real
world” in web development. Trying to keep up with the real-world is what motivated the author
(of this paper) who is a professor to reach out to the author who is a professional web developer
for help in teaching the course. Another panelist (Connolly) noted that web development was
undergoing a significant shift that started around 2010. “The typical server-side development as
the staple of most web development courses is becoming less representative of real-world
practice because of the increasingly need to integrate rich JavaScript front-ends with server
template systems.” [10](p. 60) He makes the point that many instructors were still trying to catch
up to the old way of doing web development. We agree that this shift in web development has
occurred. In fact, the shift to JavaScript front ends was the main driver for our second major
project rewrite, which uses a JavaScript front-end framework to access a REST API on the back
end.
In 2015, ACM Transactions on Computing Education published a special issue on web
development [11]. In the introduction to that issue, the editors lament the scarcity of web
development in both university curriculum and academic research, saying “you can see web
development everywhere except in the curricula of the various computing programs.” [11](p. 1)
One of the articles in that special issue looks at key concepts used in web development, like basic
programming principles, decomposition, and abstraction [12]. They suggest that a web
development course might be designed based more on these concepts than the latest methods and
techniques. While we are sympathetic to these concerns, we think you can use up-to-date
methods and techniques and still reinforce those concepts. Fundamentally, those are software
engineering principles, and they are used in the design and development of all good software.
Lui and Phelps also note the challenges of keeping up with the pace of change in web-
development courses [13]. They discuss the tools and technologies they use for their course,
along with the broad categories of subjects they cover: the presentation tier, the logic tier, and the
storage tier. Those broad categories are similar to ours, and for us they have not changed through
two major project rewrites. Their paper appeared in 2011, when they and most other instructors
were still teaching old-style web development (before JavaScript frameworks became widely
adopted). In the paper, they mentioned that they were using a textbook in their course. This fact
was interesting to us, because even when we were teaching “old-style” web development it was
extremely difficult to find a satisfactory textbook on the topic (the editors of [11] also noted this
difficulty). Once we made the switch to a JavaScript framework, it became even more difficult to
justify using a textbook. Part of the reason for this is the advancements in the quality of online
resources. For example, online readings and tutorials for Vue.js (the JavaScript framework we
use) are very good, and they are updated at a much faster pace than a text could be.
Background
Our web development course is offered in an online master’s program for information
technology that caters to working professionals. The students have a wide range of experience –
some have very little technical expertise, while others have significant real-world experience
working in the IT field. There are even a few students every semester that are self-taught web
developers. The only prerequisite for our course is a course called Object-Oriented
Programming with Java. Students are encouraged, but not required, to take Software
Engineering before signing up for Web Application Development. One of our challenges in the
course is teaching students with a wide variety of comfort levels in programming and
development.
The course is entirely online and asynchronous, so any lectures need to be prerecorded. We have
access to great educational resources such as LinkedIn Learning for videos and O’Reilly
Learning for books. There are weekly readings and assignments, which are posted at the
beginning of each week. Once a week (typically Wednesdays at 8pm) we have a live, online
Q&A session that students can attend, where we typically do a partial walkthrough of the current
assignment and answer questions. If students cannot attend the Q&A session, they are required to
watch the recording. If the students have questions that the live Q&A does not answer, they can
post their questions to Piazza (an online Q&A forum), which both instructors check at least once
a day. Students are encouraged to make their posts public and answer other student questions.
Posting code is discouraged.
Model Project and Course Project
When this course was first designed, the professor’s knowledge of web development was
limited, so he used an online tutorial – the NetBeans e-commerce tutorial [14] – as a basis for the
course project. The tutorial was well-written, and it was partitioned into a dozen or so sections
that could easily be broken up into weekly modules. The application developed in the NetBeans
e-commerce tutorial – Affable Bean, an online grocery store web site – served as a model or
reference project that both we and the students could refer to when discussing the concepts and
the principles taught in the course. Though the students were often required to read parts the
tutorial, they could choose to implement them or not. The graded course project was modeled on
Affable Bean. It involved an online bookstore of the student’s own design. Though similar to
Affable Bean, it had enough changes so that copying code from Affable Bean, which was freely
available online, and then modifying that code for their bookstore project would require at least
as much understanding as writing the code from scratch. Table 1 shows the pages in the model
project (Affable Bean) and a sample course project (My Bookstore) created by the professor,
along with a description of each page.
Table 1 Sample pages from the model and course projects. A standard acceptance test for the site involves choosing a
category, adding items to the shopping cart, changing item quantities, completing the customer form, and submitting to
obtain a confirmation.

Model Project Pages Course Project Pages Description

Welcome Page – All pages in the
application have the same header and
footer. The model project welcome page
showed four categories. Clicking on one
takes the user to the category page. The
course project required a category
dropdown in the header. Students had
some flexibility on what they put in the
body.

Category Page – The category page listed

four items in a specific category. It
allowed the user to add those items to the
shopping cart. It contained category
buttons so that the user could change
categories without going back to the
welcome page. The model project used a
table to display the products; the course
project required a resizable grid.
Cart Page – The cart page showed the
contents of the shopping cart and allowed
the user to update the quantity of each
item in the cart. The students had
flexibility in how they updated the
quantities.
 Checkout Page – The checkout page
contained a form for customer
information. The form fields were
validated using both client-side and
server-side validation.

Confirmation Page – The confirmation

page appeared when the user successfully
“purchased” the item in their shopping
cart. It only appeared if the database had
been correctly updated.

As we mention below, we had to abandon the NetBeans e-commerce tutorial after the first
rewrite. But even though we abandoned the tutorial, because it used technologies that we no
longer used, we kept a revised version of Affable Bean as a model project. In fact, having the
model project took on a renewed importance during that first rewrite. It allowed us to cleanly
separate the rewrite into two distinct portions. Rewriting the model project (Affable Bean) was
the responsibility of the professional developer. He would design and implement the code based
on his expertise, professional experience, and understanding of industry best practices. Rewriting
the course project (My Bookstore) was the responsibility of the instructor. He would look at the
model project code and try to understand it, asking questions of the developer. If he saw
something that he thought needed simplified for presentation or educational purposes, he would
discuss it with the developer. The professor would then decide how to code the course project
and how to present the assignments to the students. Sometimes the professor’s concerns would
result in the developer rewriting portions of the model project, and sometimes the developer’s
concerns would result in the professor bringing the course project code in line with the model
project. But equally possible was that the model project kept the more sophisticated code and the
course project used the simplified code. When this occurred, it had the benefit that we could refer
students to the model project if they wanted to see an alternative and more complete way of
dealing with a particular issue. In all, the decision to maintain both a model project and a course
project facilitated our rewrites.
Problems with the Original Project
A drawback of the NetBeans e-commerce tutorial was that it was already somewhat dated when
we first used it. The tutorial was written around 2010, and it had been only slightly updated since
its release (recall that the first course was taught at the end of 2016). For the most part, this was
not a serious problem, because the principles we wanted to teach were basic, and the tutorial did
cover them. At the same time, however, we knew that the technologies used in the project would
have to be brought up-to-date relatively soon. Another issue was that the tutorial was tied to an
IDE (NetBeans), framework (EJB – Enterprise JavaBeans), and application server (GlassFish)
that were not commonly used in industry. The older tools and technologies were a long-term
concern.
Shortly after that first semester got underway, it became clear that some students more familiar
with web development had similar concerns. They were asking questions like: Why aren’t we
using Bootstrap? Why are we using EJB instead of Spring? A comment from the course
evaluations at the end of the semester exemplifies this:

A lot was missed on both the front end and back end that should be taught. For example, what
is event bubbling within JavaScript? This is a very common interview question asked. We
barely covered JavaScript within the course. What about common design patterns used for
web applications such as Post-Redirect-Get? Web application security was covered in one
week. JDBC wasn’t covered at all which in my opinion is more important. What about the
DAO or DTO pattern? We used EJB for the course, but Spring is much more common by a
large margin.

It was for this reason that the professor reached out to the professional web developer for advice
on how to make the project code and technologies more relevant. Eventually the web developer
became so involved in the project that he agreed to be a co-instructor for the course. More about
how that happened can be found in [15].

The First Project Redesign

For the first project redesign our primary goal was to replace the EJB framework portions of the
project with custom Java code that used the DAO (Data Access Object) pattern with JDBC. This
would allow us to use any IDE we wanted. We chose IntelliJ, which is popular with professional
developers. It would also allow us to use any application server we wanted. We chose Tomcat,
which is the most common Java-based server. As the developer saw other potential areas of
change, we would discuss the feasibility of adding them to the new Affable Bean project, which
we subsequently called Simple Affable Bean. We did not want to change the functionality of the
original Affable Bean project, nor did we need to change the user interface, as students were
required to create their own designs. That meant the rewrite was essentially a refactoring.
One aspect of the rewrite we were concerned about was whether the revised code would be
significantly more complex than the original code. One of the nice things about the NetBeans
e-commerce tutorial was that it was accessible to students in the program: non-CS students with
a wide variety of technical and non-technical backgrounds. The concern was mitigated by the
two-project approach (model project and course project) discussed above, and by the fact that we
could give starter code in the assignments if needed. For example, at the end of this revision
there were multiple controller servlets, DAO classes, and model classes. Instead of making
students code all the servlets, DAOs, and model classes, we gave them some of these, and then
asked them to write the others, which were often similar. The most important thing we did to
ensure that the rewrites were as teachable as the original code is something most good software
developers do all the time: we developed the code iteratively and spent a lot of time
communicating before, during, and after each iteration.
Student Assignments before and after the First Rewrite
The next few sections give some details about the rewrite and how it affected the course project
and the structure of the course. The original semester-long project was comprised of nine
assignments. To keep the redesign as simple as possible, we tried to maintain similar topics. The
table below gives the project-related assignments before and after the first rewrite.

# Before Rewrite After Rewrite

1 Application Design – Come up with a custom design Application Design – Come up with a custom
for the site design for the site
2 Data Model Design – Draw an EER diagram of the Page Views – Create pages with HTML/CSS and
database Flexbox
3 Page Views – Create pages with HTML and CSS Connect to Database – Create/populate database
and test
4 Controller Servlet – Create a controller servlet DAO Pattern – Use the DAO pattern to
dynamically populate a test category page
5 Connecting to the Database – Implement category MVVM Pattern – Implement the category page by
page using JSTL SQL tags in HTML code combining #2 with #4 and use view-model objects
with servlets
mid-term exam
6 Entity Classes and Session Beans – Separate Session Management – Implement shopping cart
database code from HTML using EJB to model page and add-to-cart buttons on category page
tables
7 Session Management – Implement shopping cart Validation – Validate customer form using client-
page and add-to-cart buttons on category page side and server-side validation
8 Transactions – Implement checkout page with Transactions – Implement transactions with create
client-side and server-side validation methods
9 Security – Add security (SSL/TLS) to pages Final Deliverable – Security and Ajax buttons

The next table compares the pre-rewrite Module 6 (Entity Classes and Session Beans) to the
post-rewrite Module 4. These modules serve a similar purpose of creating Java classes that
model database tables and functions.

M6 Detail Before Rewrite (Assignments) M4 Detail After Rewrite (Assignments)

Entity Classes and Session Beans DAO Pattern
1. Recording: Entity classes and Session Beans 1. Recordings:
[instructor created video and slides] (1) Simple Affable Bean: Overview
2. Read: EJB in Action, 2nd ed., Chapter 1: What’s (2) EJBs and the DAO Pattern
what in EJB3 (3) DAO find methods
3. Web: NetBeans E-Commerce Tutorial: Entity [all above are instructor created videos and slides]
Classes and Session Beans 2. Read: Servlets and JSP: A Tutorial, Chapter 5 (EL)
4. Quiz: EJB, JPA, and CDI and Chapter 6 (JSTL)
5. Assignment 6: Adding Entity Classes and Session 3. Web: W3Schools.com SQL Tutorial
Beans 4. Quiz: JSP and EL
6. Q&A: Attend live or view recording 5. Assignment: DAO Pattern
6. Discussion: EJB, DAO, and Frameworks
7. Q&A: Attend live or view recording
The two most time-consuming assignments before the first revision were the Page Views
assignment and the Transactions assignment. For the Page-Views assignment, students had to
implement their unique web page designs with HTML and CSS. The Transactions assignment
covered both (1) client-side and server-side validation of the form fields on the checkout page,
and (2) using code with EJB annotations to update the database. The first five assignments in the
table above were given before the midterm exam, and the rest of the assignments were given
after the midterm exam. This fact is important because our first and most pressing goal for the
rewrite was to stop using EJB and switch to a DAO pattern using Java and JDBC. We therefore
expected that the DAO assignment would not be needed until after the midterm. However, the
developer was able to write some preliminary DAO classes quickly, and we ended up using those
in an assignment before the midterm.
The rewrite had an immediate and significant impact on both the assignments and the course
structure, though the full impact was not evident until several semesters after the rewrite, because
we continued to make minor changes each semester.
Practices and Principles Applied in the Rewrite
In the rewrite for the model code, the professional developer employed good software
engineering practices such as putting the code under version control, refactoring, regression
testing, and iterative development. In the subsections below, we have included rewrite-specific
software engineering principles that were applied. Each subsection corresponds roughly to a
major release of the code for the model project. The sections are labeled with a number for easy
reference, and the principle that motivated them. In each subsection, we discuss the changes
made and how they impacted the course.
[1-1] Place Your Model Project under Version Control
The first step taken by the developer was an obvious one – he took the complete code for Affable
Bean and checked it into a GitHub repository. The code was tweaked to ensure it worked with
application servers other than GlassFish that support EJB (JBoss and TomEE). We say the step is
obvious, yet we know that not all instructors take this approach with their projects. In full
disclosure, the professor author of this paper is one of them – he still has other courses in which
version control consists of copy-pasting a project into new folder each semester. While that
approach may work for say, a two-week project, it was clear that it would not be sufficient for a
project that spanned the entire semester.

The use of version control permitted experimentation with multiple web containers to strengthen
the foundation of the project. After experimentation, Tomcat was chosen as a container because
it is not opinionated towards the use of any particular framework, and because it is the Java
container that is most widely used in industry.

[1-2] Teach to Patterns, not Particulars

In replacing the EJB framework, we wanted to teach well-established design patterns, not the
particulars of another replacement framework such as Spring or Struts. Our decision was to
avoid frameworks in general. The developer wrote a new database layer for the model that
allowed us to avoid any framework-specific issues. This was the basis for the use of the DAO
(Data Access Object) pattern, the use of immutable model objects, thread-safe singleton services,
and the Post-Redirect-Get patterns throughout the project.
These changes affected the course considerably. In the original Assignment 6 (entity classes and
session beans), which was given after the midterm, students used NetBeans Wizards to
automatically generate entity classes and session beans. Now we were asking them to create
DAO classes and immutable model classes by hand in assignment 4, two weeks before the
midterm. To mitigate the mostly repetitive work of writing so many classes, we gave them starter
code with DAO and model classes for some of the tables in the database, then required them to
complete the remaining classes. Also, for assignment 4, students only had to write find methods
for the DAO classes, the create methods would not be needed until assignment 8 (transactions).
In addition to modifying the assignments and coming up with appropriate starter code, the
professor also had to modify course materials. The EJB portions of the NetBeans tutorials were
no longer relevant, so they could not be used, and the developer’s implementation of the DAO
pattern had slight differences to online resources that described the pattern. In the end, the
professor had to create lecture recordings with custom slides that introduced the DAO pattern
based on the revised Affable Bean project.

[1-3] Organize Code Professionally

The origin of the original Affable Bean application was a tutorial, building a toy system for basic
learning. As such, it made a few simplifying assumptions. First, the presentation layer was a
simple single servlet for all pages. Second, user actions (like add-to-cart) were unnaturally
implemented in a mixture of servlet and session code. Finally, there was not a clear separation
between business logic that could be reused across web applications and the Affable Bean site
being built.

The developer built the model site to address these concerns. To ensure that the system would
scale, the developer made sure that each web page corresponded to a custom page class with
common traits in a superclass (HomePageServlet, CartPageServlet, CategoryPageServlet, etc).
This separation of page code guarantees that students are taught by example how to arrange the
proper separation of concerns for the presentation layer of a web system. And they see a good
example of using inheritance. Also, using the page separation, we could teach students how to
decide where user actions should reside. For example, the add-to-cart action was processed in
the cart servlet. This enabled students to make changes with more confidence, and it precisely
demonstrates how to add more pages following the same pattern.

Finally, the developer separated the database classes, validation, and actions into a separate
compilation unit to clearly demonstrate how to keep general domain concerns like adding
products to a cart, creating a customer, placing an order, or reading products from the database,
separate from website presentation concerns like how to prepare a page or rendering HTML
elements.
This had a positive effect on students because it gave them patterns that they could naturally
follow without the need for detailed instructional aids. And it made them more confident to make
changes themselves. Large portions of the Affable Bean tutorial were rendered moot, while at the
same time it was much easier to present the organization of the code during online lessons.

[1-4] Manage Complexity using Code-Review and Debugging Modules

In this project, the action of checking out involves a transaction that stores customer and order
information in the database. To satisfy these requirements cleanly, the developer ensured that the
business logic code had separate customer and order services.

Unfortunately, the transaction code was non-trivial. The professor learned this the hard way by
copying and pasting portions of transaction code from the model project into the course project,
making the appropriate changes, and then running the code in hopes that any errors could easily
be found through debugging. The problem came when trying to find the errors – it was not easy.
The professor had to call on the developer for help and after a long and difficult but enlightening
debugging session we were able to track down and correct six significant errors and get the code
working. The session was so beneficial that we decided to give the students starter code that
contained the six errors, and part of their assignment was to find and fix the errors. In a live
Q&A session (that was recorded) we went through about half the errors and left the rest for the
students. We have done something similar every semester and this session always seems to be a
favorite with students.

The course materials associated with the Transactions assignment suffered from the same
problems as the course materials from the previous assignment where DAO classes were
involved, which meant the professor had to again create video lectures based on slides that
showed how the DAO pattern and transactions were implemented in the model project.

[1-5] Separate the View Data from the View Display

The MVVM (Model-View-ViewModel) pattern provides better separation of the model from the
view by encapsulating data into a view-model object and providing a single access point to data
for JSP pages. We incorporated the MVVM pattern in the second semester after the rewrite, and
it was relatively straightforward. Aside from the software engineering benefit, it had the
desirable side-effect of allowing the IDE to statically check the types of data in the view-model
(which it could not do without the view-model object). This in turn helped students catch more
errors at compile time. The Gradle build tool was incorporated into the project the first semester
after the rewrite. It effectively made the project IDE independent.
Takeaways after the First Revision: What We Did Right
Looking back at this experience, we did several things right – things we would recommend that
others do if they want to industrialize their project.
First, we kept a clear distinction between the model project and the course project throughout the
rewrite. The developer was responsible for the model project and the professor was responsible
for the course project. We both gave our input into both projects, but at the end of the day, the
model project reflected an approach that was a more consistent with industry practice, and the
course project reflected an approach that was tailored more to the learning abilities of our
particular students. The differences were not major, but we appreciated the flexibility that having
the model project granted us.
Another thing we did right was to emphasize good software engineering practices such as
version control, refactoring, and iterative development when rewriting the project. These
practices were second nature to the professional developer, but many professors take a less
rigorous approach to updating a project. Putting the project under version control was
particularly important, as it enabled the developer to make periodic releases that could be
reviewed and evaluated in depth by the professor. One thing we did not concern ourselves with
was any kind of time-boxed release cycle. Both of us had full-time jobs to worry about and it
was enough that we periodically discussed reasonable deadlines for when we needed certain
code. It certainly helped that our primary goal of eliminating EJB from the project was achieved
by the developer relatively early in the semester. The subsequent code releases were driven
mainly by our enthusiasm to get them done and introduce them to the students.
An important factor in the success we had is that the professional developer was invested in the
outcome. Not only was the developer motivated to rewrite the model project, but he was also
excited to share his knowledge about web development to the students. It helped that our
program had a mechanism for giving him an official instructor status in the course. It was also
important that the program was online because the developer and the professor were in entirely
different parts of the country.
Takeaways after First Revision: Where We Had Problems
One aspect of the rewrite that was disappointing was having to move away from the well-written
NetBeans e-commerce tutorial. The tutorial was developed by a NetBeans technical writer who
also wrote Java web tutorials. It is hard to convey just how important a well-written tutorial can
be until it is no longer available. It is akin to losing a good textbook. It would have been great if
we could have rewritten the tutorial while we rewrote the code. Unfortunately, we had neither
the time, the permission, or the expertise to do so. It is not surprising that there is a scarcity of
good web development textbooks on the market considering how quickly the technologies and
practices change.
A related problem, at least in the first semester after the rewrite, resulted from us continuing to
use portions of the NetBeans Tutorial. The first half of the project was not affected by the
rewrite, so we still assigned readings from the tutorial. The second half of the project was
affected, and the professor decided – probably incorrectly in retrospect – to keep the EJB
readings and show how the EJB approach and DAO pattern approach solved the same problem.
The difficulty was confounded by our move away from the NetBeans IDE and the GlassFish
server (towards IntelliJ and Tomcat). Some students shared their frustration in the course
evaluations: Course was a little rocky with the differences between NetBeans and IntelliJ. This
split between two different approaches diminished in subsequent semesters as the project
continued to evolve and the NetBeans tutorial was no longer used.
As mentioned earlier, we did not make heavy use of automated regression tests because use-
based acceptance tests were more relevant than unit tests in our project. However, many projects
in other courses taught in our program rely heavily on unit testing. Students are assigned to write
unit tests for projects, and instructors write test in order to facilitate automated grading.
Therefore, as a rule, we would encourage others to make automated regression testing a larger
part of a project rewrite than we did. In recent semesters we have discussed ways to incorporate
automated Selenium testing into our web development course, but currently this is still a low
priority. One reason is because we have developed a good submission system where students
upload their projects to a university web server, making them relatively easy to view and grade.
Finally, even though the developer used version control and iterative development for the model
project rewrite, the professor did not use version control in the rewrite of the course project. One
of the reasons was that the professor was focused on rewriting the assignments associated with
the project rather than rewriting the entire project.
Why a Second Revision?
After the first revision we were quite happy with the design of the code and its implementation.
But our satisfaction with it was conditional on a requirement that we had placed on the rewrite to
begin with: that the web project be Java-based. This requirement seemed fine for the back end of
the development stack, but for the front end it was becoming harder to justify. The top three
languages that employers want for front-end development are nearly always: HTML, CSS, and
JavaScript [16]. Even in 2016, before the original course was created, the professor attended a
SIGCSE Birds of a Feather meeting on Web Programming [17]. It was attended by people in
both academia and industry, and there was a consensus was that experience in front-end
frameworks like Angular and React were not as important as knowledge of JavaScript itself. As
Connolly noted in [10], this transition had already begun around 2010. Finally, the notion that
the technology we were using for front-end development (Java-based Servlets and JSP) was in
serious need of a JavaScript-based update, was mirrored by the experience of the professional
developer, who saw it in his own and other companies.
In general, the students agreed. These are excerpts from four different student surveys the
semester before we made the switch to JavaScript:

- Would be nice to focus more on JavaScript as that seems more real-world knowledge
instead of focusing on Java for web development.
- Use more relevant technologies. It would have been nice to get instruction in JavaScript
and other JavaScript-related technologies such as Node, React, or Angular.
- The two topics that immediately come to mind that would be invaluable to students moving
in web development would be: more in-depth JavaScript frameworks and AJAX.
- I think we should add a little bit more about jQuery, AJAX and JavaScript.

The Second Project Redesign

For the second project design, we wanted to focus on JavaScript and a JavaScript framework.
We chose the Vue framework for several reasons: (1) Out of the three most popular JavaScript
frameworks – React, Angular, and Vue – Vue has a reputation for being the easiest to learn;
(2) Vue can be used fully or partially in a project, so it can be used in conjunction with other
technologies, even Servlets and JSP; and (3) the professional developer was already
experimenting with Vue at his job.
Student Assignments before and after Second Rewrite
The table below gives student assignments before and after the second rewrite. The “Before
Rewrite” column in this table gives the same assignments as the “After Rewrite” column in the
table related to the first rewrite.

# Before Rewrite # After Rewrite

1 Application Design – Come up with a custom 1 Application Design – Come up with a custom
design for the site design for the site
2 Page Views – Create pages with HTML/CSS and 2 Page Views in HTML – Create home and
Flexbox category pages with HTML and CSS
3 Connect to Database – Create/populate database 3 Page Views in Vue – Create home and category
and test pages using Vue
4 DAO Pattern – Use the DAO pattern to 4 Connect to Database – Setup your database and
dynamically populate a test category page display a table of categories and books
5 MVVM Pattern – Implement the category page 5 DAO Pattern and REST API – Create a Java-
by combining #2 with #4 and use view-model based REST API using the DAO pattern to
objects with servlets interface with the database
6 Using fetch – Use fetch API to access books and
categories
mid-term exam
6 Session Management – Implement shopping cart 7 State Management with Vuex – Use Vuex plugin
page and add-to-cart buttons on category page to update and access global state
7 Validation – Validate customer form using client- 8 Session Management – Implement shopping cart
side and server-side validation page and add-to-cart buttons on category page
8 Transactions – Implement transactions with 9 Client-Side Validation – Create a checkout form
create methods and validate the form data in the browser
9 Final Deliverable – Security and Ajax buttons 10 Server-Side Validation – Validate the checkout
for on the server
11 Transactions – Implement transactions with
create methods
12 Final Deliverable – Security, hardening, and
clean up the project

The next table compares Module 6 from before the rewrite and Module 7 after the rewrite, which
serve a similar purpose of saving state in shopping cart objects. Module 8 after the rewrite is a
continuation of this, but the topic was broken into two modules because we wanted to
sufficiently explain of the Vuex plugin for Vue.js.
 M6 Detail Before Rewrite (Assignments) M7 Detail After Rewrite (Assignments)
Session Management State Management with Vuex
1. Read: 1. Recordings:
(1) Head-First Servlets and JSP, Chapter 5: (1) Introduction to Vuex (Vue Mastery video)
Attributes and Listeners (2) Benefit of Vuex in Bookstore project [short video
(2) Servlets and JSP: A Tutorial, Chapter 3: by professional developer]
Session Management 2. Web:
2. Quiz: Session Management / JSTL (1) What is Vuex? [Vuex web site]
3. Assignment: Session Management (2) State / Mutations / Actions [Vuex web site]
4. Q&A: Attend live or view recording (3) Selected JavaScript concepts [W3Schools.com]
3. Assignment: State Management with Vuex
4. Q&A: Attend live or view recording

There are three more projects after the second rewrite. We knew that this was going to be a
challenging rewrite, so we gave the students (and ourselves) more milestones to meet. In
addition, we teach this course in both the Fall semester and in the Summer semester. The
Summer semester is shorter by nearly 4 weeks. We introduced the rewrite in the Fall semester,
knowing that we had more time in case we ran into difficulties. For the Summer semester, we
will definitely combine assignments 2 and 3 – we will jump right into Vue without requiring an
HTML-only version of their pages. We will also combine assignments 6 and 7, since the
shopping cart and Vuex are both associated with the global state. We may consider combining
assignments 9 and 10 also, but this would be more difficult – it turned out that both client-side
validation and server-side validation presented their own unique challenges.

During the second revision, we continued to use version control, refactoring, and iterative
development. However, in the first revision, we also focused more on programming and design
principles like patterns and separation of concerns. In the second revision, we were using a
framework, which already came with its own set of best practices, so our concerns were
different. We had to think more about how difficult these different approaches to JavaScript
would be for our students.
[2-1] Use a JavaScript Framework
It may seem odd that in our first revision we spoke about moving away from frameworks while
in our second revision we are advocating frameworks. But for our circumstances, both of these
decisions made sense. As we mentioned earlier, the students taking this course had a Java
programming course as a prerequisite. In the first revision, moving away from the EJB
framework to Java with web-based design patterns did not significantly complicate things for the
students, and it actually simplified our explanation of what the code was doing. In contrast, most
of our students are completely unfamiliar with JavaScript, so it makes sense to go with a
framework in that case. It would have been theoretically possible to design the course using only
JavaScript and perhaps jQuery in our front end, but that would have been daunting to students
with no knowledge of JavaScript. Furthermore, most front-end web developers are using a
framework, and all of these frameworks have similarities.
[2-2] Commit to Your JavaScript Framework
This is one principle we did not expect to observe. Before we started on the second revision, we
had already decided on using the Vue JavaScript framework for reasons already mentioned. One
of those reasons was that Vue had a reputation for being progressive, which means that you can
use the framework as much or as little as you want. When the professional developer began
writing the revised code, he incorporated portions of Vue into code with significant JavaScript-
only modules. There were even bits of Java servlet code in the application, so that we could
continue to run the entire project inside of Tomcat. While the application worked, it was
complex, and it was not cohesive.
When the professor tried to modify the course project using the model project as a reference, he
had a very difficult time doing so. In particular, he had a hard time understanding why some code
worked the way it did. This was important, because we needed to have a consistent narrative to
present to the students. We had to think about other course material like readings, video
recordings, and assessments. We had access to excellent video tutorials though the university.
However, the Vue tutorials showed how to build Vue-centric applications; they did not show
how to incorporate Vue elements into existing applications with existing technologies. After
some discussion, the developer decided that he would begin a new GitHub repository and
experiment with building the front end entirely in the Vue style: as a single-page application with
single-file components. This approach turned out to be extremely successful. One thing that
really helped were the excellent tutorials at the Vue Mastery web site. Having abandoned the
excellent NetBeans e-commerce tutorial due to evolving technologies, it was refreshing to have
found equally effective video tutorials for the technology we were now using. Once we had
committed to the Vue approach to creating applications, we found that we had access to many
resources for course materials, and it simplified the learning curve of adopting the framework.
[2-3] Cleanly separate the back end with a REST API
Using a REST API was something that we knew we were going to do when we decided to make
the switch to a more JavaScript-centric project. We knew that making the transition to a
JavaScript-based front end was going to be a large challenge, and we wanted to keep the back
end as close to the original as possible. That meant still using the DAO pattern (with JDBC) and
model classes. Because we created services for important actions, it also meant that the much of
the transaction code could be reused. We still had the issue of getting our data into a format
consistent with a REST API. For this we used Java the helper library Jersey to help build the API
itself, and the Jackson library to convert our JSON model classes from Java to JSON and back
again. We were happy that this part of the transition went well, and it left us in a good position to
modify the back end without doing anything to the front end if we ever feel a need to do so.
Takeaways after the Second Revision: What We Did Right
There are a few things that turned out very well in this rewrite, even though we did not always
expect them to. First, we are very happy that we accomplished the rewrite when we did. After a
major project rewrite in 2017, it was a little overwhelming to undertake another major rewrite in
2019. Usually, our program suggests that we significantly refresh our courses every three to five
years, and they provide support (in other words, money) to help us do that. We did this rewrite
without any support from our program, but we both felt that we had a serious problem with the
course by not including more JavaScript. We feel that for the next few years any rewrite will be
incremental to our existing code base and much more manageable. Also, despite the hard work in
doing a major rewrite, it has an effect on the instructors. They may be slightly less prepared, but
they are more enthusiastic, and this has a positive effect on the students.
The other thing we did right was to (eventually) commit to our framework’s style of doing
things. Had we not done this, the course would have been significantly more difficult for the
students to understand, and harder for us to teach. As mentioned above, we wrestled with this
decision. A turning point came when the developer commented that he would like to do a single-
page application (Vue-style) eventually. It wasn’t long after this that we decided: if that is what
we are ultimately moving towards, then we should just do it now.
Takeaways after Second Revision: Where We Had Problems
A problem with any major rewrite is that the first semester after the rewrite can be a bit
unorganized, and this rewrite was no exception. Students sometimes had to remind us of quiz
questions that were no longer relevant, sometimes we had to add reading material in the middle
of the week because students needed background on a topic we forgot to provide, and sometimes
the project descriptions for a particular assignment were still works in progress. As these types of
problems occurred with our first rewrite as well, we expect some minor hiccups. To mitigate the
effect of these problems, we try to be as open and honest with the students as possible, starting
with the first day of class. We let them know that the course is undergoing a revision, and we ask
for their patience. In return, the students get to learn more cutting edge and relevant technologies,
and we are patient with them as well – we build in an extra couple of days to each project if we
need to slip the due date, and we also build some time into the end of the semester in case any
module needs to be pushed back.
Student Reactions after the Second Rewrite
At the end of the semester after the second rewrite, we posted a discussion topic online, where
we encouraged students to give their feedback on the bookstore project. We asked several
questions, including:

• What is your programming background?

• How difficult or time-consuming was the project?
• Which portions of the project did you like or dislike? Which portions should we
emphasize less or more in future courses?
One surprise was that most of the students felt that the course was about average in difficulty.
We had suspected that the course was more difficult than the average course in this program.
Though some students mentioned they were a bit overwhelmed by the end with the volume of
various information they had to retain.
Here are some student comments about challenges and potential changes that we are taking very
seriously.

– The transaction assignment felt like I barely understood all of the moving pieces, but the
debugging strange code experience was invaluable.

– Please don’t make me keep building new projects every week. […] I would suggest that
Git(hub) be made part of the project.

– I would consider integrating user testing throughout the design process.

– I would generally prefer bigger assignments but due every other week or so.
 – I almost think this course could be broken up over 2 semesters if some more advanced topics
were covered in the 2nd semester.

– I would consider leveraging a CSS framework such as Bootstrap or Material Design.

Finally, we asked this question related to technologies used in the project:

• This is the first semester we used a JavaScript framework. Should we have stuck with
Java? Should we use a different JavaScript framework? What are folks in industry
looking for?

Recall that many of our students are working professionals, so we expected that some of them
would have insight into this. Students who did not have experience in web development
generally deferred to others on this question. What follows is a sampling of interesting student
responses.

– I thought Vue was great. The Mastery videos were exceptional, and it seemed way easier to
me than using straight Java or some MVC Framework (Struts or whatever).

– Using Vue was great in my opinion! Yes, it does seem like React and Angular are the more
prominent ones companies are hiring for at the moment, but it was easy to learn the basics.

– Definitely keep this course in JS! Mentioning I was learning the basics at work got
immediate interest. We use React where I work.

– I would recommend spending a little more time on javascript including side exercises on
how to use promises with async REST calls.

– Javascript and python seem to be two of the biggest languages in job postings I see.

– I think using a JS framework is a must. I don’t think it is majorly important which

framework is used as long as it is one of the major frameworks.

– Most of the jobs in North America are geared towards React and Angular.

In short, the move to JavaScript was a welcome one, and no one wanted to go back to a Java-
based system. Though there is some interest in Angular and React.

Figure 1 shows a long-term view of student surveys for the course. The ratings go from 1 to 6,
and our course ratings are consistently higher than the average for the department (Computer
Science) or for the college (Engineering). The most significant data points on this chart are
between the first two semesters. The jump in ratings occurred when the professional developer
joined the course.
 Figure 1 Student survey results for course effectiveness compared to collage average

A Conversation between the Professor and the Developer

Sometime after the second rewrite, we came together online to share our individual thoughts and
experiences regarding the rewrites. Much of what we discussed – particularly regarding the
model project and the course project – was emphasized in this paper. But there were also a few
selected personal experiences that we thought were relevant, and we included them here for
completeness.
Developer The most difficult thing during these rewrites is to keep the code simple and realistic
at the same time. Whether or not you [the professor] would go and simplify further – which
sometimes happened – the clarity of the code even in the model project was pretty much
paramount. The code had to be dead simple, more well-organized than the original Affable
Bean. My constraint was: Don’t use anything fancy. Don’t use frameworks to begin with. And
then when we decided to use frameworks, because the world has gone that way for JavaScript
developers, the challenge was still to keep things simple. The less code you write, the more
powerful the educational experience is. So, if I was giving advice to other developers, who
wanted to develop not toy projects but more well-organized projects, it would be: You have to
keep things as small as possible in terms of code. Lots of little classes are better than a few big
classes in general anyway, but also, do things without 3rd party libraries that you might be
familiar with. So throw out everything that makes the project super nice and easy, because it’s
all bloat, and focus on what matters for the patterns that you’re trying to get across. I feel like
we achieved that balance with Vue in the second rewrite.
Professor The rewrites were a lot of work – as mundane as that seems. When I compare it to my
Software Engineering class, I have probably over 100 videos for that class. I’m due to revise it,
and I don’t anticipate those videos changing a great deal. That’s as opposed to web-application
development, where I want to make as few videos as possible. I want to rely on our university’s
media resources as much as possible, or something like the Vue Mastery courses. I want to find
those other resources because this is such a fast-changing course. I want to make sure that I can
swap things out quickly. I may need to do a major refresh for the Software Engineering course
once every five years, but for the web development course it’s more like every two years, and
sometimes that doesn’t even feel like enough.
Developer There’s a whole other theme here, which is how do you [the professor] adapt to all
this. You simplified where necessary, you didn’t take the model project as gospel, and you
addressed complexity at one point by switching to present the code with bugs and get them
[students] to fix it, which forces everyone to understand all about the code.
Professor I adapted by trying to understand your code, trying to fit that code into the bookstore
project, but only if I understood it. Sometimes I would purposely hold off asking you questions
for a couple of days, because I wanted to understand what was going on. If I didn’t try to
develop my own understanding initially, and instead just started asking you questions about it, I
don’t think I would have understood it that well.
Developer Well also I may have just said: This is just the way we do it. But for people like me
[professional developers] coming in trying to help, “This is the way we do it” is not an effective
argument.
Professor I knew I could ask you, but I wanted to first see if I could figure this out for myself just
by looking at your code or reading tutorials, because that’s how the students are going to have
to try to tackle it – they’re going to have to try to figure it out for themselves. I was basically
playing the role of a student because that’s what I was.
Developer The bottom line is, if you develop software iteratively, the best courses are going to
be iteratively developed.

Conclusions

Every software development course will be different, and every course project will be different,
but industry practice changes continuously, and if you want to keep up, it means you have to
evaluate your project regularly and update it when appropriate. The best way to keep the code up
to date is to use common-sense software engineering practices to write and maintain it.
To rewrite your course project with industry practice in mind, you should first have some idea
what developers in industry are doing. If you are a professor, you can do this by talking to
professional developers, who are often eager to share their knowledge; you can also attend
conferences, panels, or discussions like the one in [10]; and you can ask your students, who often
have a better understanding of what employers in industry want than professors do. Conversely,
if you are a developer who wants to share their knowledge, talk to a local university, or get
involved in one of the many online computing or IT programs.
When you actually start your rewrite, make your life easier by leveraging a model project that
you can use to inspire your course project. Many textbooks and online tutorials use running
examples that are excellent candidates for model projects. For example, the Vue Mastery video
tutorials [18] use a running project that we could have easily adapted into a course project had
we not already had one we liked. We also teach a mobile development course using a Big Nerd
Ranch guide [19] as our textbook, and we use selected projects from that text as model projects.
When you rewrite the project, use a version control system, preferably GitHub. Write or rewrite
the project iteratively, focusing on functionality or design changes in your releases, as you would
in an industry setting. Use refactoring whenever you can to strengthen your design and use
automated regression testing whenever you can to make sure your code continues to work. If you
do use a model project, use it to inform how you modify the course project, but always keep the
learning environment in mind, like how much time you have in the course, how you will
partition your project into assignments, and what the students can handle based on their abilities.
Updating your project may seem like a daunting task, and it can be. The second rewrite of our
project was particularly challenging due to the completely new approach we took to our front-
end. However, when you consider that JavaScript frameworks like Angular and React have been
around for nearly ten years now, it makes sense that we had to run to catch up to that technology
based on where we started. Now that we have accomplished that, we are optimistic that keeping
the project up to date will be more manageable.
Our plan for project changes going forward is focused more on functionality than technology and
methodology, and we will continue to evaluate industry trends as they arise. The following list
gives some changes we are looking into along with their anticipated difficulty.

Relatively Easy
• Teach the use of Git for code management, even locally to start with.
• Teach students the basics of grid-based design for robust site layouts.
• Integrate dynamic address validation into address capture so addresses are suggested.
• Make use of the OpenAPI specification language and Postman tools to create or manage our
API on the server side.
Medium Difficulty
• Incorporate Vue 3.0 changes into the model project.
• Develop a login-based membership for each Bookstore so customers have accounts – in
particular we could show how to manage password hashes properly.
• Implement a members-themed bookstore with the same pages and perhaps discounted prices
on certain books.
• Show students how to cache books in-memory on the server, and how to manage cache
expiration.
• Change the pages to have better User Experience (UX design)
• Use an overlay to display cart contents and initiate checkout.
• Allow cart changes on the checkout page with price updates.
• Implement search by title / author using SOLR or ElasticSearch on the server side.
Hard
• Develop and use a third-party “payment-service” to handle credit cards.
• Attack the Bookstore API using API security tools.
We are always discussing how to improve the course, but significant changes (medium and hard)
will only occur once a year. They will be introduced in the Fall semester, when we typically have
less students and more time.

We have described two major revisions that we undertook in the process of “industrializing” our
web application project. The first revision was built on classical web technologies that, despite
their age, are still being used effectively in industry today. The second revision made the leap to
modern JavaScript frameworks, which are have become the new normal in web development.
Both revisions were motivated by industry trends and student feedback. While the project
rewrites were challenging, we believe that we are now in a better position to maintain and evolve
the course project as the practice of web development continues to evolve, and we hope that our
experience will encourage others to industrialize their web development projects as well.

References

[1] M. Sabin, P. Snow, and B. Viola (2016). “Industry and faculty surveys call for
increased collaboration to prepare information technology graduates” Journal of
Computing Sciences in Colleges. 31(6). pp. 70–78.
[2] F. Rahman (2018). “Integrating Project-Based Learning in Mobile Development
Course to Enhance Student Learning Experience” Proceedings SIGITE 2018.
[3] R. Caceffo, G. Gama, and R. Azevedo (2018). “Exploring Active Learning Approaches
to Computer Science Classes.” Proceedings SIGCSE 2018.
[4] M. Martin and R. Martin (2006). Agile Principles, Patterns, and Practices in C#.
Prentice Hall.
[5] D. Delaney, and G.G. Mitchell (2002). “PBL Applied to Software Engineering Group
Projects” Proceedings International Conference on Information and Communication in
Education. pp. 1093–1098.
[6] D.F. Rico and H.H. Sayani (2009). “Use of Agile Methods in Software Engineering
Education” 2009 Agile Conference, Chicago. pp. 174–179.
[7] B. Bruegge, S. Krusche, and L. Alperowitz (2015). “Software Engineering Project
Courses with Industrial Clients” ACM Transactions on Computing Education. 15, 4,
Article 17. 31 pages.
[8] A. Pletch and A. Agajanian (2007). “A software engineering project that looks like the
real world” Journal of Computing Sciences in Colleges. 22, 6. pp. 92–99.
[9] K. Umapathy and F. Wallace (2010). “The Role of the Web Server in a Capstone Web
Application Course” Information Systems Education Journal. v8 n62.
[10] C. S. Miller, J. Zheng, R. Connolly, and A. Olagunju (2013). “Keeping up with Web
Development Trends. In Proceedings of the 14th Annual ACM SIGITE Conference on
Information Technology Education.
[11] C. Miller and R. Connolly (2015). “Introduction to the Special Issue on Web
Development” ACM Transactions on Computing Education. March 2015.
[12] P. Alston, D. Walsh, and G. Westhead (2015). “Uncovering ‘Threshold Concepts’ in
Web Development: An Instructor Perspective” ACM Transactions on Computing
Education. March 2015.
[13] Y. Liu and G. Phelps (2011). Challenges and professional tools used when teaching
web programming. Journal of Computing Sciences in Colleges. v26, n5 pp. 116–121.
[14] NetBeans E-Commerce Tutorial.
https://netbeans.org/kb/docs/javaee/ecommerce/intro.html
[15] G. Kulczycki and S. Atkinson (2018). “Why Educators Should Team with Industry
Professionals in Software Development Education”. In Proceedings 2018 ASEE Annual
Conference and Exposition.
[16] Indeed.com. https://www.indeed.com/career-advice/careers/what-does-a-front-end-
developer-do Last viewed: January 2020.
[17] Birds of a Feather: Web Programming. SIGCSE 2016 Final Program, p. 37.
https://sigcse2016.sigcse.org/docs/SIGCSE2016-Final-Program.pdf
[18] https://www.vuemastery.com/
[19] B. Phillips, C. Stewart, K. Marsicano, and B. Gardner (2019). Android Programming:
The Big Nerd Ranch Guide, 4th Edition. Big Nerd Ranch Guides.