1. Team Seeker: Gamblers
Anonymous meeting finder
web application
Information Systems Development Project
Year 2 (2014/2015)
Diploma in Information Systems
Trinity College Dublin
23rd March 2015

2. 2 | P a g e
Abstract
This document outlines how Team Seeker approached developing a mobile app for Gamblers
Anonymous Ireland. Gamblers Anonymous Ireland were having trouble disseminating information
about the organisation and meetings to those in need.
We reviewed the situation with a representative from Gamblers Anonymous and determined that a
mobile app was the most appropriate way of responding. We proceeded to compile a list of more
detailed requirements from the client and develop a mobile app on that basis.
As a result of this process we’ve delivered a mobile formatted HTML WebApp to Gamblers
Anonymous using HTML5, JavaScript and jQuery Mobile that they can host on their existing servers,
without imposing extra costs to upgrade their infrastructure or retrain their existing volunteer
webmaster.

3. 3 | P a g e
Acknowledgments
The project team would like to give thanks to our family, friends and pets who have supported us all
the way through this project with an understanding to our commitment. We would also like to give
thanks to our supervisor Howard Shortt for all his guidance, encouragement and advice throughout
the project. His patience and knowledge was inspirational for the whole team. We would also like to
extend our gratitude to our sponsor in Gamblers Anonymous for their support and patience.
We are also indebted to Dr Simon McGinnes and all our lecturers over the past two years for their
tutelage in providing us with the knowledge that was invaluable during the development of our
application over the course of this year.
We hope that all those that use our web application gain something from all our hard work.

4. 4 | P a g e
Declaration
We, the undersigned, declare that this dissertation is entirely our own work and not previously
submitted to Trinity College Dublin.
We agree that Trinity College Dublin may lend or make copies of this document for educational
purposes, if requested.
Paul Flood ____________________________
Margaret Moore ____________________________
Bernard McGinley ____________________________
Colm Kennedy ____________________________
Peter Byrne ____________________________

5. 5 | P a g e
Document Version History
Version Date Editor Comments
1.00 20-11-2014 Peter Document template created
1.01 3-12-2014 Peter Updated with client background
1.02 17-12-2014 Bernard Updated technologies used
1.03 19-12-2014 Paul Added Project details
1.04 12-1-2015 Margaret Added Design details

6. 6 | P a g e
Contents
Abstract...................................................................................................................................................2
Acknowledgments...................................................................................................................................3
Declaration..............................................................................................................................................4
Document Version History......................................................................................................................5
List of Tables ...........................................................................................................................................8
List of Figures ..........................................................................................................................................8
List of Abbreviations ...............................................................................................................................8
Chapter List.............................................................................................................................................9
1 Introduction ..................................................................................................................................10
1.1 Client Background.................................................................................................................10
1.2 Overview of Project ..............................................................................................................10
1.3 The Business Problem...........................................................................................................10
1.4 Objective of the project........................................................................................................11
1.5 Proposed solution.................................................................................................................11
1.6 Existing systems and processes ............................................................................................12
1.6.1 Issues with current systems..............................................................................................12
1.7 Relationships to existing systems / integration....................................................................12
2 Requirements................................................................................................................................14
2.1 Summary of requirements....................................................................................................14
2.1.1 User Stories and how they were addressed .................................................................14
2.2 UML Use Case Diagram.........................................................................................................18
2.3 Entity Relationship Diagram..................................................................................................19
3 Project Management ....................................................................................................................20
3.1 Project Structure...................................................................................................................20
3.1.1 Project Scope ................................................................................................................20
3.1.2 Constraints....................................................................................................................21
3.1.3 Assumptions..................................................................................................................21
3.1.4 Critical Success Factors .................................................................................................21
3.1.5 Project Life Cycle...........................................................................................................22
3.1.4 Project Schedule ...........................................................................................................22
3.2 Chosen methods (with reasons) ...........................................................................................23
3.3 Project Goals.........................................................................................................................23
3.4 Overall project schedule (Gantt)...........................................................................................24
3.5 Team Organisation................................................................................................................25
3.6 Team Brainstorming..............................................................................................................25
3.7 Communication Plan.............................................................................................................25
3.8 Project Close .........................................................................................................................26

7. 7 | P a g e
3.9 Outline each phase (breakdown of sprints)..........................................................................26
3.10 Which tools were used .........................................................................................................27
Appery.io.......................................................................................................................................27
Github .............................................................................................. Error! Bookmark not defined.
AppGyver ......................................................................................................................................27
Brackets.........................................................................................................................................28
Sublime Text..................................................................................................................................28
Cloud 9 ..........................................................................................................................................28
Xcode.............................................................................................................................................28
Android Studio ..............................................................................................................................28
4 System design ...............................................................................................................................29
4.1 Chosen technologies with reasons .......................................................................................29
Google Maps API...........................................................................................................................29
CSS.................................................................................................................................................29
Javascript.......................................................................................... Error! Bookmark not defined.
jQuery and jQuery Mobile ............................................................................................................29
4.2 System architecture / topology – UML deployment diagram ..............................................30
4.3 Design history .......................................................................................................................37
5 Design and System testing............................................................................................................38
5.1 Describe the development process used..............................................................................38
5.2 Discuss pros and cons of development process used...........................................................38
5.3 What unit / system testing was done and by whom ............................................................38
6 Implementation ............................................................................................................................39
6.1 Discuss process of making system live – data loading / rollout / user acceptance..............39
6.2 Illustrate and explain the main aspects of the final system .................................................39
7 Conclusions ...................................................................................................................................41
7.1 Reflect on the process and the outcome..............................................................................41
7.2 Successes - Stories ................................................................................................................41
7.3 Failures - Stories....................................................................................................................41
7.4 Lessons Learned....................................................................................................................42
7.5 Further development............................................................................................................42
References ............................................................................................................................................43
Appendices............................................................................................................................................44
Unlicense...........................................................................................................................................44

8. 8 | P a g e
List of Tables
Table 1 Locations ..................................................................................................................................19
Table 2 Meetings...................................................................................................................................19
Table 3 Team Roles...............................................................................................................................25
List of Figures
Figure 1 UML Use Case .........................................................................................................................18
Figure 2 Proposed Entity Relationship Diagram ...................................................................................19
Figure 3 Project Life Cycle.....................................................................................................................22
Figure 4 Version One Product Backlog..................................................................................................23
Figure 5 Project Gantt chart..................................................................................................................24
Figure 6 Project Phases.........................................................................................................................26
Figure 7 UML Deployment Diagram .....................................................................................................30
Figure 8 UML Sequence Diagram..........................................................................................................30
Figure 9 Home Page..............................................................................................................................31
Figure 10 Meeting Finder......................................................................................................................32
Figure 11 Contact Us.............................................................................................................................33
Figure 12 Questions and Informations .................................................................................................34
Figure 13 News and Updates................................................................................................................35
Figure 14 Site Map................................................................................................................................36
List of Abbreviations
G.A. Gamblers Anonymous
JS JavaScript
API Application Programming Interface
DOM Document Object Mark-up
HTML Hypertext Mark-up Language
IDE Integrated Development Environment
PMBOK Project Management Body of Knowledge
PHP An open-source server-side scripting language
JSON JavaScript Object Notation
AJAX Asynchronous JavaScript and XML

9. 9 | P a g e
Chapter List
1. Introduction
In which we introduce the Team, the Client and the nature of the problem and proposed
solution
2. Requirements
In which we detail the client requirements
3. Project Management
In which we detail the project management approach we took to manage the
implementation of the proposed solution
4. System Design
In which we detail the proposed solution
5. Design and System Testing
In which we detail the development of the proposed solution
6. Implementation
In which we detail the implementation of the proposed solution
7. Conclusions
In which we draw our conclusions from the process and reflect on what we have
accomplished

10. 10 | P a g e
1 Introduction
The Seeker team comprises of Bernard McGinley, Paul Flood, Margaret Moore, Colm Kennedy and
Peter Byrne. We, as Diploma students in Trinity College Dublin, were approached by Gamblers
Anonymous (GA) Leinster division, to provide a solution to a problem they have.
We came together as a team to decide a project. We had 2 on the table proposed by our team
members. A more traditional choice of a consultancy timesheet and client management tool for a
local Business Innovation Centre, and the Gamblers Anonymous mobile web application. The
consultancy database was deemed too similar to a previous year’s project. As a team we decided
that we’d be happier seeing a product of our efforts in use for a good cause.
1.1 Client Background
Gamblers Anonymous Leinster are a division of the worldwide Gamblers Anonymous. The
fellowship of Gamblers Anonymous came about as a result of two men meeting during the month of
January in 1957. Both men began to meet regularly and as time passed neither had returned to
gambling (Gamblers Anonymous, n.d.). Gamblers Anonymous now arrange regular meetings that
are held in many locations around the world and through the power of attending meetings on a
regular basis, it gives members of the fellowship an opportunity to get their lives back on track and
an ability to lead a normal life. Almost 44% of the Irish population play the national lottery regularly.
We spend over €5 billion a year on gambling and finally and most important only 1% of Irish people
who need treatment for gambling addiction actually receive it (Administrator, 2011). Our aim is to
help people with gambling addiction and to get make more people aware of the help and support
that are out there. The biggest issue that they face is getting this information out to the public.
1.2 Overview of Project
This leads us to the project at hand. Team Seeker, working with the client, identified a need for a
mobile friendly information service. The purpose of this project is to provide an easier way for the
person on the go to gain access to the required information that will help them understand
compulsive gambling as an addiction and also give the user the required information to get them to
a meeting.
With these requirements in mind, team Seeker engaged with the client to develop a mobile web
application. The information and functionality contained within the web application must adhere to
client’s requirements. In essence they are looking to provide a free, easy to use and navigate,
mobile application, which will provide current and relevant information to the end user while
maintaining their anonymity. All of these elements have been the core of the build process and
have provided team Seeker with the wireframe to proceed in the development of this web
application.
1.3 The Business Problem
After meeting with the client, Gamblers Anonymous Leinster office, we were asked if we could
develop a solution to their problem. They were looking for something that could help them answer
the most asked questions in their mailbox.
Gamblers Anonymous were looking for a way to get meeting information to members and non-
members alike, in a simple and clear manner and if possible get this information to a mobile device
since this is now the easiest way of giving information. The information they primarily want to
supply to the end-user is meeting information, location, start times, which days meetings are on, etc.

11. 11 | P a g e
They were also looking for a way to answer the more commonly asked questions on their website,
including:
1. “Where is the nearest Gamblers Anonymous meeting to me?”
2. “What do I need to do to attend a Gamblers Anonymous meeting?
3. “I need help, can I talk to someone?”
4. “I have a family member who needs help. What can I do?”
On reflection of the problem at hand, we, team ‘Seeker’ decided, in conjunction with the client
representative, that we would develop a mobile web application to address this need.
1.4 Objective of the project
Gamblers Anonymous (http://www.gamblersanonymous.ie) is a worldwide organization that
helps people overcome gambling addiction. People from all walks of life can develop addiction.
Throughout Ireland every county has G.A. meetings. These meetings are not always held in the same
place or at the same time. We want people to be able to find their nearest meeting, the time it’s due
to start and whether it’s been cancelled or not.
Most people these days have a smart phone or access to one. We want easy access to the G.A. on
their mobile device. This will be easy to navigate and find the information that’s on the web site.
This web application will also be able to give their nearest meetings. We will be able to show this by
using GPS. If the member has no GPS facility on their phone we will default to an overview of Ireland
that the user can then navigate in a fashion consistent with user expectations.
Because of the nature of the site we will, as far as is practicable, have total anonymity. No
information of the member will show up on the site. In addition to that we will also block ads from
coming onto the screen. This will stop any gambling ads or other triggers from coming up on the site.
Anybody that looks at the web app for the first time will be able to get any literature needed before
they go in to the meeting. Also on the application will be a link to the 12 steps page.
The main factor for us is to make sure that our application is like no other application currently
available in Ireland. We have also been informed that whatever we produce will become the
national standard for GA Ireland, as in our design and functionality will then be implemented into
the current GA website.
The estimated cost of this project is €0.00
1.5 Proposed solution
Gamblers Anonymous required a mobile web application that will work with data from their existing
website and provide an easy to use meeting finder. Working with the client, team Seeker agreed
that the web application would comprise of the following requirements:
- The web application would contain some static data including The 12 step programme, The
Unity Programme, the “Just for today” quotes, FAQ’s.
- The application would have an easy to use map/meeting finder
- The information supplied to the user could be updated in one location that would feed their
website and the web application
- The web application would not record any user data so as to maintain their anonymity.
- The web application could be used on mobile device that had internet access.

12. 12 | P a g e
Team Seeker took these requirements on board and after careful consideration, decided that using
the Appery.io framework was the best course of action to deliver a modern looking application in a
timely fashion. The client agreed and the project was started. The project team also suggested that
the creation of a database for all meeting information would be of considerable benefit to the
project and to their existing website.
On reflection of the database proposal, the project team and the client, decided that the online
database would fall outside of the scope of the original project, but would be worked on after the
project had been submitted, as it would mean migrating the live site from its current shared hosting
environment to a provider/package with a higher level of functionality. The team have also agreed
to continue to work with the client to develop the web application to completion and to assist them
with the creation and integration of the online meeting database.
1.6 Existing systems and processes
Gamblers Anonymous currently have a website (www.gamblersanonymous.ie) which provides
information that compulsive gamblers find useful. The website is primarily built with PHP and
JavaScript.
1.6.1 Issues with current systems
Unfortunately their current website is not mobile friendly. With the huge increase in the number of
mobile users over the past few years, Gamblers Anonymous feel that they should provide a more
suitable solution. With mobile technology being the more prevalent platform for accessing
information today, their existing website is no longer suitable. Currently a person wishing to find
information about a meeting would have to go through a large series of clicks to find the information
they require. On a mobile device and at present this is not any easy task, which Gamblers
Anonymous believe is stopping people getting the correct information regarding meeting locations
and start times.
1.7 Relationships to existing systems / integration
Gamblers Anonymous current website provides a large amount of information to the general public
regarding compulsive gambling. This information allows people to seek help and advice and read
some personal stories regarding compulsive gambling. These stories are provided by current
members of their fellowship. The website is composed of primarily PHP pages with some basic
JavaScript functionality, but the site is not mobile friendly. The current website is not using a CMS
(Content Management System) and as a result updating information can be a lengthy task and menu
pages have to be updated in numerous locations. As a result of this there is no consistency with the
data in the site. The website update process is also time consuming as it requires FTP access to
download a file, modify it, save it and upload.
The client has requested that information contained in the web application is to be updated in only
one location on their existing website, ensuring that there is no overlap of workload and data
consistency is guaranteed. The project team agreed with the client on a single place for data entry
but for this to be beneficial to the existing website a Content Management System will be required
for their existing website. This also falls outside of the scope of the project. The client has also
expressed a desire for the web application to provide information on meetings based in the United
Kingdom and Scotland. In response to this request, the project team have explained that this
request will be addressed after the submission of the project to the college, when time is not a
limiting factor to the projects development.

13. 13 | P a g e
Using the existing data provided by the www.gamblersanonymous.ie website, we have added links
within the web application to their website.

14. 14 | P a g e
2 Requirements
2.1 Summary of requirements
2.1.1 User Stories and how they were addressed
As a user, I want to access the app on any mobile device, so I can always access the app
We decided to implement this requirement by developing the application as a mobile web
application, allowing the user to access from any connected device, and removing the requirement
to maintain a separate codebase for each potential platform
As a user, I want to get Meeting information so that I know what the meeting will be about
We decided to implement this requirement by adding an info-window to the meeting marker on the
google map, as we felt this would be a familiar and natural usage for most users
As a user, I want to get up to date data so that I know have info on meetings
We decided to implement this requirement by linking the news content within the app to the live
Gamblers Anonymous website
As a user, I want filter on start time, so that I can easily find meetings I will be able to attend
We decided to implement this requirement by running the markers array through a filter based on
the current time before re-populating the page.
As a user, I want filter pinning, so I can find the next or nearest pinning meeting
We decided to implement this requirement by setting a custom icon on pinning meetings on the
map
As a user, I want filter on closed, so I can avoid open meetings
We decided to implement this requirement by setting a custom icon on closed meetings on the map
As a user, I want filter on open, so I can avoid closed meetings
We decided to implement this requirement by setting a custom icon on open meetings on the map
As a user, I want to be able to get access literature about first meeting so that know about the
meeting
We decided to implement this requirement by pulling data from the existing FAQ section form the
live website within the mobile application.

15. 15 | P a g e
As a user, I want to be able to see calendar for meetings so that I know when the meetings are on
We decided to implement this requirement by adding a separate page with a table populated from
the meetings array – flagged for future development
As a user, I want to be able to export Calendar ‘.ics’ file, so that I can save meetings to my local
device
We decided to implement this requirement by creating a downloadable .iCal file from the meetings
array – flagged for future development
As a user, I want to be able to get a one click to call helpline so that I have quick contact with a
support group
We decided to implement this requirement by adding a formatted contact us page, with phone links
to bring up the native phone handler on the device, phone app on mobile devices, Skype/link, etc.
on desktops or tablets
As a user, I want to be able to find based on current location, so that I can find a meeting nearby
wherever I am
We decided to implement this requirement by automatically centring the map on the user’s location
if enabled, or on the whole of Ireland if not. Users can then manipulate the map in a manner natural
to them to view surrounding meetings, zoom in or out. Or they can use the page controls to see
specific days or counties
As a user, I want to see on interactive map closest meetings so that I can plan my closest meeting
We decided to implement this requirement by adding a google map to the site, and layering the
meetings on this as standard markers, in order to keep the interaction as natural and conformant to
user expectations as possible
As a user, I want to be able to free type a location if I don't have a GPS enabled device or I have
the GPS feature disabled, so that I can find my closest meeting
We decided to implement this requirement by adding a free search text box, linked to the google
maps address search field, and update the map centre point and zoom based on this – flagged for
future development
As a user, I want to know my 3 closest meetings so that I have a choice of meetings
We decided this requirement was already sufficiently addressed in the interactive map above, and
that the 3 meeting rule was not relevant in the context of the map application

16. 16 | P a g e
As a user, I want to specify search range so that I can change the range to my closest meeting
We decided to implement this requirement through the use of the google maps zoom function.
Meetings outside the range of the window would not be visible to the user.
As a user, I want no ads on site so that no gambling ads are on the screen
We decided to implement this requirement by hosting the app on the gamblers anonymous website,
so we would have control of the hosting environment and ensure that no ads were present.
As a user, I want a low click count so that I can quickly get the information I need
We decided to implement this requirement by adding the map page as a first level subpage from the
home page, and set it to automatically load the meetings for that day. We also felt that the use of
different icons for the different meeting types would convey that information to the user quickly
without them having to set a large number of options in advance.
As a user, I want mail link to organisers so that I can keep in touch with the organisers
We decided to implement this requirement by adding a contact link to the page, using the same
contacts as on the live website.
As a user, I want easy navigation and search so that I can find what I need quickly
We decided to implement this requirement by using a standard google map, which we felt the end
users would already be familiar with. We added large icons to the map to allow for ease of use for
less dextrous users.
As a user, I want updated content in one location so that I can quickly see what has been updated
We decided to implement this requirement by pulling the news content from the live website
As a user, I want to maintain anonymity so that nobody know who I am
We decided to implement this requirement by pushing all the logic into the client device. All that is
recorded on the GA servers is the page request.
As a user, I want easy to read font so that I can read the text
We decided to implement this requirement by defaulting to a Sans Serif font
As a user, I want no resize page for info so that everything is readable
We decided to implement this requirement setting the default font size and layout to maximise
readability, preventing the user from having to manually zoom in as may be the case on a desktop
styled app

17. 17 | P a g e
As a user, I want to have buttons to a decent sized and not overlapping so that the screen is usable
We decided to implement this requirement by following good design practice
As a user, I want a scrollbar notice if meeting cancelled so that I know that the meeting is
cancelled
We decided to implement this requirement by adding a ticker to the news page, pulling info from
the live website
As a user, I want to have it multi language so that more than English speaking people can avail of
its services
We decided to implement this requirement by adding a script to detect the user language of the
device, and offer a google translate option if it’s not English – flagged for future development
As a user, I want Gam-Anon info so that I can understand the process
We decided to implement this requirement by adding a page containing this info, pulled from the
live website
As a user, I want a link to 12 steps so that I have a program of recovery
We decided to implement this requirement by adding a page containing this info, pulled from the
live website
As a user, I want to have a list of counselling links so that I have contact information for extra
support
We decided to implement this requirement by adding a page containing this info, pulled from the
live website
As a user, I want a ‘Free Time Calc’ so that I know how long it has been since my last bet
We decided to implement this requirement by linking to the existing free time calculator on the
Gamblers Anonymous website

18. 18 | P a g e
2.2 UML Use Case Diagram
Below is a diagram showing how users access the different types of information from within the web
application.
Figure 1 UML Use Case
The UML Use Case above shows the Seeker accessing the app to:
 Check news
 Find a meeting
 Calculate the time since their last bet
 Contact Gamblers Anonymous in their area
It also shows the Google Maps servers feeding map data to the embedded map within the app, and
the Gamblers Anonymous representatives listed on the Contact Us page receiving Phone Calls or
Emails

19. 19 | P a g e
2.3 Entity Relationship Diagram
By using the data below we can create the required tables and relationships. This database would
have been accessed by jQuery and would return arrays of meetings based on the search criteria
entered. Ultimately this was not implemented on the grounds of user privacy, as we wanted nothing
server side to be aware of the users actions within the app, and due to the migration of the
webserver this would have mandated, which was deemed an unreasonable imposition on the
resources of Gamblers Anonymous.
Figure 2 Proposed Entity Relationship Diagram
The database itself will be made up of the following tables
Table 1 Locations
Coordinates (PK) Notes Address
Array in form [Latitude,
Longitude]
String String
The Coordinates of the meeting Any special notes about the
location
The address of the location
Table 2 Meetings
Weekday (PK) Starttime (PK) Coordinates
(PK, FK)
IsGamanon IsPinning IsOpen
String Array in form
[Hour,
Minute]
Array in form
[Latitude,
Longitude]
Boolean Boolean Boolean
The day of the
week the
meeting is
held
The time the
meeting
commences
Reference to
the location in
which the
meeting is
held
Is the meeting
a Gam-Anon
meeting?
Is the meeting
a Pinning
meeting?
Is the meeting
Open?

20. 20 | P a g e
3 Project Management
“Application of knowledge, skills and techniques to execute projects effectively and efficiently. It’s a
strategic competency for organizations, enabling them to tie project results to business goals”
(Project Management Institute, 2008)
Project Model
Using Project Management Body of Knowledge (PMBOK) we were able to use the five process
groups: initiate plan execute, monitor and control and close the project. We used this methodology
in our project management class so we used that knowledge to our advantage. The app will also be
updated and maintained when the project is finished.
3.1 Project Structure
3.1.1 Project Scope
We hope to implement the app by uploading it to the Gamblers Anonymous web site.
Learn about JavaScript and HTML 5 through video tutorials, and other free resources such as
W3Schools.
We wanted to keep cost to a minimum by using free software.
This application is a massive change for Gamblers Anonymous moving forward. It will make it very
easy to find new meetings on our navigational search engine and information for new members
through the mobile first pages. This is the first web application that Gamblers Anonymous Ireland
has created.
We created a storyboard and designs for the front of the app for the client to see and change as they
saw fit. Using Version One to implement agile methodology we were able to alter the requirements
during the execution phase.
The application will be supported on Android and iOS, on tablets and smart phones.
When the project is finished Team Seeker in partnership with the client will work on the app
elements that were initially out scope of the project or that fell out of scope due to setbacks with
the development and implementation. This will include training of the client and maintaining and
support of the application. There is also a possibility that the application will be used in other
countries.

21. 21 | P a g e
3.1.2 Constraints
Lack of programming experience.
The only experience members of the team had were the modules taken within the course, covering
basic HTML, JavaScript and Visual Basic technologies.
Time.
In addition to the workload for this module, team members had to cope with the additional
assignments and study necessitated by the course, as well as the 2 main coders dealing with on call
and out-of-hours requirements, along with business travel throughout the year.
Budget.
As this was a college project for a voluntary fellowship there was no budget to deliver this. We had
to use free student versions of applications and platforms with often limited functionality. We also
could not mandate the use of licensed or commercial software as the client also has a very limited
budget to work with.
3.1.3 Assumptions
- That the project team will assign Thursday evenings and Saturdays to work on this project.
- Issues encountered will be resolved in a timely manner.
- The project charter will precisely reflect the scope.
- The client will use the application when the project is completed.
- The client will appoint someone outside of the project team capable of maintaining the
product once released.
- The client will be available for input of information towards the project.
- That the client wants a fully functional application at the end of the project.
- The client wants the application to work in the Ireland.
- All team members will participate equally to the project.
- All team member will stay for the period of the project.
3.1.4 Critical Success Factors
The most critical factor of the project was to get it finished by the 23rd
of March. We also needed to
use everybody’s skills to achieve our goals. Sticking to our sprints was a critical part of the success of
our app; we were able to judge how well we were going in terms to the time frame of the project.
Security processes and procedures must be in place before any sensitive data is accessed.
- G.A. is more accessible to people
- Makes it easier to find closest meetings
- One click phone support to member
- No ads on the screen to stop gambling ads
- No personal information stored
- To have the app working on all mobile devices

22. 22 | P a g e
3.1.5 Project Life Cycle
The project was split into the five process groups of PMBOK with each having different goals and
milestones. To achieve our goals we had practical milestones to reach with each person participating
to move us onto the next process.
Figure 3 Project Life Cycle
3.1.4 Project Schedule
At the start of the term we decided to make a schedule for the year. After primary discussions we
created a project starting point timetable for the main project achievements. Most of us had never
used agile before and never had a project of this magnitude or difficulty so we thought that this
would be very important for the rest of the project. We also felt that as we go on in the project and
learning in various classes that the scheduling would improve. At the start of each week we each
placed into a schedule the days we can work on the project our class times and holidays. With that
schedule created we were able to assign tasks and get cover for people that couldn't make those
dates. It was suggested that we do a minimum of 160 hours each in total. We all committed to those
hours and that included Thursdays, Saturdays and working from home. Near to the end of the year
we agreed to come in on Monday and Friday evenings and Sunday mornings.
The team assigned group and individual deadlines that we couldn't miss, and by achieving these
gave us confidence going forward to the next one.

23. 23 | P a g e
3.2 Chosen methods (with reasons)
We researched different methodologies and tested against our project and decided that agile was
the best for us. We started using this early on in the project as this was known to us through our
CS2013 class. The platform that we used for agile was Version One. One of the main factors of using
Version One is that it’s free.
Version One allowed us to put user stories up, assign then into sprints that were in feasible timelines
and to have an overall plan going forward.
Figure 4 Version One Product Backlog
Product Backlog Sprint Backlog Weeks Potential Working App
We continued to use this cycle until the project was finished.
3.3 Project Goals
Team Seeker have agreed that the goals to be completed for this project are as follows:
- Provide a working prototype web application for the client based on the client’s
requirements.
- Educate the client in the ongoing maintenance and management of the application.
- Produce a comprehensive document to detail the project’s development from start to finish
(submission)
- Provide a presentation to the client and the college outlining the web application
functionality and demonstrating its workings.
- Use the skills and techniques amassed over the past two years in college and the existing
knowledge the team and provide evidence that said knowledge was understood and used
appropriately.

24. 24 | P a g e
- Develop a web application to allow users to locate the nearest Gamblers Anonymous
meeting based on their current location.
- Allow the user to do one-click calling to a predefined contact number or email address.
- Allow users to search for meetings based on a drop down list of the days of the week.
- Allow users to search for meetings based on a list of counties.
- Provide the user with information on the meeting of their choice, including start time, room
number or any other relevant meeting information.
- Provide the user with information relating to the Gamblers Anonymous 12 step programme.
- Provide the user with information relating to new and updates (content to be retrieved from
the existing website).
- Provide the user with information on the “Unity programme”.
- Provide the user with the FAQ information already available on the existing Gamblers
Anonymous website.
- Have a working prototype for the client at least 4 weeks before the presentation date (End
of February).
3.4 Overall project schedule (Gantt)
Figure 5 Project Gantt chart

25. 25 | P a g e
3.5 Team Organisation
The team was made up of five individuals with many different backgrounds and experiences. The
tasks were divided out depending on the team’s strengths. The remaining tasks were then divided
out into the chapters to be finished. We wanted everybody to gain experience in all aspects of the
projects so we sometimes had two people working on the same section.
Table 3 Team Roles
Project Role Responsibility Team Member
Project Sponsor Client representative Liam
Documentation, Design,
Coding
Additional development work Peter Byrne
Documentation, Design,
Testing
Primary design work Margaret Moore
Documentation, Project
Manager, Testing
Primary documentation work Paul Flood
Documentation, Coding,
Testing
Primary development work Bernard McGinley
Documentation, Testing Additional design work Colm Kennedy
3.6 Team Brainstorming
At our second meeting we had a brainstorming session. In brainstorming all ideas were though
thoroughly and in some we took ideas and added them to our final draught. Some of the
brainstorming ideas were:
1. Using app on different devices
2. Using a platform to design the app
3. Using GPS and interactive map to find meetings
4. Able to access a calendar to see meeting dates
5. Use free software to keep the app free.
6. To have links to counselling
7. To keep it ad free to block gambling ads
3.7 Communication Plan
We had a few obstacles at the start of the project getting off the ground. Communications would
clearly be one of the larger obstacles in our path.
At the start of the project we all sat down and discussed the best way of communicating with each
other. It was decided that getting in contact through a phone was the wisest decision. We set up a
group chat in WhatsApp. In this we also included our supervisor for communicating with him directly
with the group. We had a few obstacles at the start of the project as we all had a lot of different
assignments and another group project so we set up a WhatsApp group to keep everybody informed
of what’s going on and a Google drive account to upload our documentation and notes. With most
of our team in full time employment it was imperative that we kept in contact for the full course of
the project.
We already had a client liaison representative that knew and dealt with the client. This worked well
when the client was unavailable to come into the meetings. We had most Thursdays free so we used
that free time to meet up to assign work and to see where we were in relation with the sprints. After
Christmas we decided to meet up on a Saturday for a few hours to do work. On a Tuesday and

26. 26 | P a g e
Wednesday after class we had face to face meetings to organise work for Thursday night. Bernard
took meeting minutes and Paul recorded the meeting for use later in documentation and minutes.
Using the minutes we were able to document when and where certain ideas came from, and were
able to refer back to earlier meetings for discussions around decisions that had needed to be made.
We spoke about using Skype if we needed to but we never had to use it.
Before we set up WhatsApp we used our college email account. This was ok at the start but after a
while we had to browse through each email to find the relevant information so this wasn’t feasible
long-term.
3.8 Project Close
This is the last phase of the project life cycle. In it we finished our testing, programming and
documentation. Paul made sure that all criteria was met in the correct timeframe. We handed the
app over to our sponsor in G.A. We arranged a meeting with our sponsor and went through the
requirements that they wanted. Future development and maintenance was discussed and expanding
it to encompass England, Scotland and Wales. The application was then handed over then sponsor.
Figure 6 Project Phases
3.9 Outline each phase (breakdown of sprints)
Phases / Iterations
Version 0.1 - Static content created within the Appery.io environment the app showed the current
location of the user on a map of Ireland. Working with Appery.io, we found that creating the user
interface was straightforward. There are some very intuitive online demonstrations. The one that
was of most use was the “Using the Google Maps API” tutorial located at
http://devcenter.appery.io/tutorials/using-the-google-maps-api . This gave the team a good basic
understanding of how we could integrate the Google Maps API into our web application.
Version 0.2 - Created menus to control the map within Appery.io. It could zoom and centre on a
specific meeting location based on a drop down menu selection, but could not dynamically assign
markers. With these menu controls working but the markers causing problems we completed more
reference work to try and locate solutions to our marker problem. Appery.io was proving to be a
very difficult tool to use for our purposes, as what would traditionally be back-end or server side
functionality, we had restricted ourselves to performing within the client device for anonymity
purposes.
Version 0.3 - After 6 weeks of trying to get simple JavaScript queries to run successfully in Appery.io
we, as a team, decided to abandon the appery.io platform and return to a purely textual
development environment. It was proving too time consuming to continue to try and get our code
to work with the Appery.io framework.

27. 27 | P a g e
3.10 Which tools were used
We chose to develop the app in HTML5 and JavaScript rather than develop native apps using Xcode
or Android Studio to allow us to maintain a single code base, and to develop the application in a
consistent cross-platform fashion. Any HTML5 content could be reliably displayed on any platform
that supported a basic web browser.
Appery.io
Appery.io is a web development platform that initially allowed us to rapidly develop the application
GUI. In our initial examination it seemed to operate in a manner very similar to Visual Basic, which
we had experience of from CS1104 and CS1106. Unfortunately we found that as development
progressed we struggled more and more to implement application logic within the framework, and
that relatively simple page manipulation was taking inordinately long times. We also struggled to
interact with the Google Maps API in the desired manner via the Appery interface. After twelve
weeks of trying to get our code to work and integrate into the application we discovered that this
was not an easy process. The tutorials on their website were of little use as many of the tutorials are
based on different version of the product and there was no uniformity within the application itself.
Appery was forcing us to learn their way of applying code within their application, which would not
be easy to maintain in the long run.
After long consideration and a very intense team meeting it was decided that we would scrap
Appery.io and continue with a HTML5 and JavaScript solution. This decision was not taken lightly as
it mean the development of the project was knocked back over two months.
This decision had a major impact on the progress of the project as we had to throw 2 months of
attempted development work away.
Ultimately we abandoned this platform, and the work we had done in it, as the code it generated
when exporting was not easily extended with our limited knowledge of our chosen technologies.
GitHub
After abandoning Appery.io and losing the advance functionality that came with it. We moved to a
git repository to hold our data.
AppGyver
When the project team decided to no longer use the Appery.io wireframe, the project team were
faced with finding a suitable alternative. After some investigation into the available platform tools
available to the project team, we decided on using AppGyver. The tool comprises of many similar
elements that Appery.io had but integrating our functionality code into AppGyver was easier than
the experience we faced with its predecessor. Unfortunately team Seeker were behind on the
project so it was decided that we would focus on the visual elements of the web application so that
we would have something to show for the work that was already completed.
Using AppGyver we were able to produce the required page wireframe for the web applications that
had a very user friendly interface. Team Seeker already had a working version (in HTML5 and
JavaScript) of how the web application would work. AppGyver allowed us to apply our existing
JavaScript into our newly created web application, and will ultimately allow for native app creation
from our current web only content

28. 28 | P a g e
Brackets
Adobe Brackets is a free editor designed for web development, which links to the chrome browser
for live display of changes made. This allowed us to work on local copies of the HTML and JavaScript
files and see the impact of changes made, without having to wait for the Gamblers Anonymous
Webmaster to manually load files to the website
Sublime Text
Although lacking the live preview of Brackets, Sublime had many power user features that made
editing large swathes of the Data Set relatively quick and painless. We made great use of its multiline
editing ability.
Cloud 9
After abandoning Appery.io Cloud 9 became our next main development environment. Its cloud
based nature was great for collaborative work. And it integrated with GitHub, so changes made in it
were consistent with Check-ins from Sublime and Brackets users, but less advanced users could
operate without needing to be fully aware of what was happening in the background.
Xcode
Xcode was used purely for its iOS simulator, which allowed us to test the app on a wide variety of
iPhone and iPad models in a short space of time.
Android Studio
Similarly, Android Studio was used for its android virtual device facility, allowing us to see how the
app would look on various different android display sizes.

29. 29 | P a g e
4 System design
4.1 Chosen technologies with reasons
Google Maps API
We chose the use the Google Maps API due to the wealth of documentation available for
development, and for the immediate familiarity users would have. By loading the API and interacting
with it locally, the only data that is transmitted is the actual raw map data that is rendered within
the app. Markers, etc. are all client side only. We were able to confirm this in testing by setting
devices to “Airplane Mode” with the page loaded, and continue to operate with the only visible
impact being the “Sorry, we have no imagery here” warning displayed by the embedded map.
CSS
CSS allowed us to develop the app quickly, without getting hung up on stylistic choices early in the
process, and allowing them to be retrofitted at a later date without impacting functionality.
JavaScript
JavaScript allowed us to process much of the application logic on the client side, preventing
repeated calls to server-side services that may have compromised user anonymity.
jQuery and jQuery Mobile
JQuery is a JavaScript library that allowed us to perform actions asynchronously, and to better
manage events, user interaction and page manipulation. Using this we were able to pull the content
from the existing website into the app without having to manually recreate it, and we were able to
ensure that any change made to content on the live website would be reflected within the app on
load.

30. 30 | P a g e
4.2 System architecture / topology – UML deployment diagram
Figure 7 UML Deployment Diagram
Overview of system design – UML class and sequence diagrams, navigation map, wireframes for
User interface
Figure 8 UML Sequence Diagram

31. 31 | P a g e
Figure 9 Home Page
Home Page:
The home page contains a copy of the introduction on
the www.gamblersanonymous.ie website.
From the home page the 4 key areas for the user are
clearly defined and are mapped as follows:
Find a meeting
Contact Us
Questions and Information
News and Updates
These links bring the user to the required pages and
offer an easy to follow map of the application.

32. 32 | P a g e
Figure 10 Meeting Finder
Find a Meeting Page:
The Find a meeting page allows the user to locate
meetings based on their choice of search methods
Search by Day, allows the user to show only meetings
that are running the selected day.
Search by County, allows the user to search for
meetings based on their county search.
The default view will show all meetings running on
today. The initial zoom is set to the whole of Ireland.
As the nearest meeting maybe in a neighbouring
county we decided not to filter the results by county,
instead the app would zoom into the county allow the
user to see neighbouring county meetings on the day
selected.
In Production this was amended to include the map
controls is a side panel opened via a menu button

33. 33 | P a g e
Figure 11 Contact Us
Contact Us Page:
The Contact Us page allows the user to do one-click
calls to the available numbers.
There is also the option to send an email to
info@gamblersanonymous.ie, which is their
monitored mailbox.
Currently these are the only contact numbers for
Gamblers Anonymous Ireland.

34. 34 | P a g e
Figure 12 Questions and Information
Questions and Information Page:
The Questions and Information page has links that
allow the user access a collection of information. The
information is useful for Gamblers Anonymous
members, family and friends.
There is also a link to a Gam-Anon page to Ireland.
This provides information for family and friends of
gamblers.
The information page also links to the 12 Step
program, the Unity program and the ‘Just for today’
pages.

35. 35 | P a g e
Figure 13 News and Updates
News and Updates Page:
The New and Updates page is linked directly to the
updates page on the www.gamblersanonymous.ie
website. Updating the content on the website in one
location was also a requirement from the client.

36. 36 | P a g e
Figure 14 Site Map

37. 37 | P a g e
4.3 Design history
Initial designs for the app were back of the envelope type sketches with the client representative.
This built up a basic blueprint that we would refine and re-implement as the development platform
changed.
Our next step was to layout the design in Appery.io, which due to its drag and drop nature
proceeded rapidly, with only minor changes needed to accommodate the development realities.
The same layout was then recreated by hand in the native HTML version of the app and in the
AppGyver environment, as shown in section 4.2. Tweaks to layout made at this point were replicated
to the native HTML environment.
The final HTML design was based on the above, with minor tweaks to better take advantage of
functionality offered by the jQuery Mobile toolset.

38. 38 | P a g e
5 Design and System testing
5.1 Describe the development process used
Development followed a hybrid of waterfall and agile practices. Our initial process was very much in
the waterfall style, with large chunks of time spent setting up the platform and the front end display,
before launching into a series of sprints incrementally adding functionality. After our switch from
Appery to native HTML5 and JavaScript we followed a much more consistent Agile approach of
incremental improvements and modifications. We would deliver basic functionality to show the
client, and layer on elements and additional functionality as we proceeded through sprints, with the
client giving direction on features he expected to see, or that he was inspired to request through
additional usage.
5.2 Discuss pros and cons of development process used
The agile methodology allowed us to implement and demonstrate specific features, with minimal
conflict over usage. A particular function could be written, and changes to the web page needed to
implement them could be made, allowing the site to be functional almost continuously throughout
the development process, and without long delays waiting for the coding team to catch up to the
design team.
5.3 What unit / system testing was done and by whom
Using the www.jsfiddle.net website each member of the project team was able to test each piece of
code and its functionality as it was developed. The site was very useful as it gave the team the
ability to test and try each section of the code in isolation. The results were instantly visible.
The stages for testing were broken down as follows
- Test the HTML5 code
- Test the JavaScript for the Google Maps API
- Test the Marker array creation
- Test the Map clearing on each day selected
- Test the information provided on each marker
- Ensure that no duplicate or incorrect information was shown on each marker
- Test each link and verify that the correct page shows for the users selection

39. 39 | P a g e
6 Implementation
6.1 Discuss process of making system live – data loading / rollout / user acceptance
With the two month set back in the development stage the project completion date has slipped to
the end of May 2015. The client is aware of this and as a result they have agreed to a go live date of
1st June. The team have agreed that the web application will be accessible from the
www.gamblersanonymous.ie home page. We are also looking at other ways of advertising this new
service with other support groups. As of March 23rd the system is not live and is still in
development stage. Team Seeker have agreed with the client that a number of members will be the
user test group and they will have access to the web application from 23rd May onwards.
The current data loading process will be maintained by a member of team Seeker until a written
support manual is completed and presented to the client. All web application static data will be
retrieved from the existing website. In relation to meeting data, a member of team Seeker will
provide the client with the required support until the official handover on 1st June.
The results from the user acceptance testing is to be documented and discussed by team Seeker and
any bug fixes will be addressed in a timely manner. If there are any major bugs team Seeker have
agreed to work through the resolution stage until the client is happy with the end product.
If there are any feature changes or enhancements that the client would like, we have agreed that
these fall outside the scope of the project and can be addressed in the future but the work may or
may not be carried out by team Seeker. We will however aid the client as best we can.
As stated earlier, the current meeting information is stored in a single JavaScript file. This will be
moved to an online database so that meeting information can be updated easily and in one location.
The work completed to date will be released to the client under the “unlicense” license. The team
discussed the various open source licenses available to issue the software under, and determined
that this gave the client the most possible freedom to use and adjust the code delivered to suit their
changing requirements, and to expand the scope internationally, without needing to review and
comply with any licensing requirements. This may seem a moot point, as HTTP source is always
available, but as specific licenses may require the client to release any future changes under the
same license this may not always be suitable. If any professional development work is later required
it may be the case that the Designer or Coder will object to this restriction being placed upon them.
The “unlicense” specifically sidesteps this issue by disclaiming any interest in the software upon
release.
6.2 Illustrate and explain the main aspects of the final system
The main aspects of the mobile web application are the use of relaxing friendly and easy to navigate
menu system, the fact that data content within the web application is pulled directly from the
existing website (reducing the required time to complete updates and ensuring data consistency),
using JavaScript and JQuery we can isolate meeting information based on the chosen day of the
week or the selected county. Using these controls we are able to manipulate the markers that
populate the Google Maps, and each marker relates to a specific meeting.
By using the GPS on their mobile device, the application will zoom into their current location, or to
the default address that has been supplied. From there, the user can easily see what meetings are
close by or close to the supplied address. Meetings are displayed on the Google map by using
different icons for meeting types, which include Open or Closed and different colours are used to
display different categories including standard meeting, Pinning meeting (to celebrate anniversaries
of Gamblers Anonymous members or a Gam-Anon meeting (for family and friends of compulsive
gamblers).

40. 40 | P a g e
The Meeting Finder operates on a list of meetings, which are currently stored as objects in an array.
It also stores a list of counties within Ireland, also stored as objects in an array.
On loading the page, the app embeds a google map of Ireland using a jQuery ready call to insert the
map into the loaded page, sets up the event listeners detailed below, and insert the list of counties
into the menu controls. It then determines the current day and time, and steps through the array of
meetings looking for meetings on that day, and starting after that time. It then overlays the map
with these meetings locally on the device. It then checks if the user has allowed location services on
their device. If so it will centre the map on the user’s location and add a marker showing their
location.
The app also contains controls to allow the user to view meetings for different days of the week, to
centre the map on a given county, or to return to their location. These controls operate using the
HTML5 DOM Event Listener functionality to allow the map element to listen for button presses and
react appropriately from within the function that created the map. We found that trying the more
traditional onclick calls from the buttons directly was unreliable at updating the content. When a
given day is selected the app again steps through the meetings array looking for matches for the day
property, but does not filter on start time. The counties control resets the centre point and zoom of
the map to the centre point of the county.
The Meetings and Counties are stored in separate .js files to allow for more flexibility in retrofitting
database or JSON calls to an external source once the live website is upgraded.
The Contacts page is populated using static content currently, but will be replaced with an AJAX call
once the live website is upgraded. It includes the tel: and mailto: prefixes to enable native device
handling of calls or emails.
The remaining pages hosting content from the website do so using jQuery to trigger an AJAX call to
load the content of a live website <div> tag into the page.
The site buttons and controls are formatted using jQuery Mobile to allow for optimal display across
various device sizes, and to better emulate device native controls.

41. 41 | P a g e
7 Conclusions
7.1 Reflect on the process and the outcome
Looking back over the project as whole the team felt that while certain aspects could have been
handled better, the agile approach lends itself to rapid development and response to changing user
requirements. This incremental improvement in functionality is very powerful in developing
applications of this nature, given the restrictions in place, and it’s clear how in a larger project with
sufficient resources in place much larger projects can be brought to task to deliver highly functional
software. Our biggest issue overall was our falling prey to the sunk cost fallacy, we delayed throwing
out the work we’d performed in Appery.io, because we felt like we’d spent too much time on it
already to start over. In the end, the project delivered is of a higher value to the client do to its
standards compliance, and low barrier to management
7.2 Successes - Stories
One of the key successes of the project was the ability to integrate our JavaScript and jQuery code so
that we could create an array of meetings and present them into the Google Maps. This was the
basis of the whole project and the team are delighted to see it working correctly. Filtering the
meetings per day gives the end user just the right information they require without being
overloaded with unnecessary data. The user is then able to select any day of the week and the
meetings that are available on that day are shown.
The second biggest success was the ability to migrate our code from the Appery.io wireframe into
the AppGyver application, which is a much easier to use application development tool. This alone
was a great success as the team felt that we had not lost all our work because of the difficulty in
getting our application to work in Appery.io.
The third and by no means the least of our success was the ability of the team to actually work as a
team and pull together when things didn't work out the way we were hoping. With the loss of 2
months through development issues, we were able to pull together, identify the areas of the project
that needed the most attention and as a team continue through our big setback.
7.3 Failures - Stories
The uphill struggle trying to get our code to work in the Appery.io wireframe. This was a result of us
working against the platform. If we had been developing in a more normal Server side language,
with display only on the client this would have been much less painful
The loss of development time resulted in the team not getting to create the online meeting
database. We do intend to develop a DB backend to this, although it has not yet been determined if
it shall be done in MySQL on the server as part of the initial page load, or Web SQL in client side
storage.
The timing of the database lectures combined with a lack of pre-existing knowledge within the team
worked to prevent the team from proceeding with creating a working online database in the time
available.

42. 42 | P a g e
7.4 Lessons Learned
Take time to research the platform and tools before starting the project.
Plan the project and identify roles as soon as possible
Work in pairs or smaller groups to ensure that there is no duplication on work and that the workload
is shared evenly.
Communication is key throughout any project. Regular meetings with status updates is vital to
ensure everyone is informed and knows what's ahead.
Identify achievable milestones throughout the project and enjoy the satisfaction when these
milestones have been reached / passed.
Keep the team informed on all personal aspects that can impede the project.
Work smarter - use the knowledge from lectures and apply it to each project you are involved in.
7.5 Further development
Team Seeker have agreed with the client that we will continue to work on the development of the
web application after the submission date of the project to Trinity College. We have also agreed
that we will work with their current webmaster on the implementation of a meeting database that
will allow for easier updating of meeting information in one location. Team Seeker, in conjunction
with the client have also agreed that we will work on other ‘out of scope’ requests that the client
brought up in the meetings held.
Team Seeker will also document how further updates to the web application can be managed by a
representative from Gamblers Anonymous. The instructions will cover all aspects of the application
and maintenance and it will be part of the final handover for the completed project.

43. 43 | P a g e
References
Administrator, 2011. Facts. [Online]
Available at: http://www.gambleaware.ie/index.php/facts.html
[Accessed 15 11 2014].
Gamblers Anonymous, n.d. Little Red Book. s.l.:Gamblers Anonymous.
Project Management Institute, 2008. A Guide to the Project Management Body of Knowledge
(PMBOK® Guide). Fourth Edition ed. s.l.:Project Management Institute.

44. 44 | P a g e
Appendices
Unlicense
This is free and unencumbered software released into the public domain.
Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.
In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
For more information, please refer to http://unlicense.org