techreview/techreview.latex

\documentclass[10pt, draftclsnofoot,onecolumn, compsoc]{IEEEtran}

\def\changemargin#1#2{\list{}{\rightmargin#2\leftmargin#1}\item[]}
\let\endchangemargin=\endlist

\usepackage{todonotes}
\usepackage{caption}
\usepackage{pgfgantt}
\linespread{1}
\begin{document}

\title{Fenceless Grazing Tech Review - Danila Fedorin}
\author{Danila Fedorin, \and Matthew Sessions, \and Ryan Alder}
\maketitle

\begin{abstract}
    The Fenceless Grazing Collar System aims to reduce the burden
    on farmers caused by the need of constant manual herding of livestock.
    The project will use LoRa wireless technology, and will prevent
    animals from leaving prescribed grazing areas through the use of
    an auditory or electrical stimulus. The project will additionally provide
    data gathering features. As a member of the FGC team, I will be
    responsible for creating the smart application that will be used
    to control the wireless collars, as well as some supporting
    software such as an HTTP API server.
\end{abstract}

\pagebreak
\tableofcontents

\pagebreak

% TODO: She wanted something with "my role"?
% TODO: She wanted a more specific abstract.

\section{Role}
My role in this project is the development of the smart application which
will be used to control the Fenceless Grazing Collars in the field. This
includes the actual application, as well as the software to support
the app, such as a web server for authentication and data retrieval.

\section{Team Goal}
The goal of the Fenceless Grazing Collar (FGC) System is to reduce
the amount of manual labor required for keeping farm animals. The FGC system
does this by automating the process of keeping animals within their prescribed
grazing area through the use of GPS location tracking, as well as audio
and electric stimuli. Additionally, the FGC aims to provide information
about the behavior of the farm animals to their keepers, with the goal
of improving their understanding of the livestock.

\section{Selection Criteria}
Because there is no ideal technical solution, the tradeoffs
of every possible technical solution must be analyzed through specific
critera. The Fenceless Grazing Collar system is intended for actual
use in the field by non-technical personnel, and therefore has
the following concrete design concerns:

\begin{itemize}
    \item \emph{Accessibility:} The system must be configurable and usable
        without a significant learning curve. This means, among other things,
        that the user interface of the system must be in some way familliar
        to the users (farmers).

    \item \emph{Cost:} The entire idea of the project is to reduce the amount
        of time and resources that is currently spent by farmers on herding
        livestock. If the system is not cost-effective, it does not efficiently
        replace farmers, and therefore, is not worth it to the users.

    \item \emph{Maintainability:} While this metric is not necessarily reflected
        externally, it's nonetheless an important consideration. The software
        written for this project must be easy to support and maintain in the future.
        This is a goal for most long-term projects.

    \item \emph{Reliability:} The system must be reliable, since failures may lead
        to loss of livestock or property. This means that communication between
        the various components of the project must be effective and consistent,
        and that bugs occurring in the codebase have a high cost to the users.
\end{itemize}

\section{Responsibilities}
\subsection{Smart Device Application}
A major component of this project is the creation
of an application that is capable of adjusting
the settings of the wireless collar devices. This
section describes the components of this application.

\subsubsection{Platform}
Either the Android or the iOS platform could be used
for the smart application. These platforms require entirely
different tooling and codebases, as well as different types
of devices (Apple phones only run iOS, while Android devices
only run Android).

From the perspective of \emph{Accessibility}, Android is better
suited for this project. This is because the Android platform
makes up more than half of the market share in the United States \cite{android-share},
with a majority of the remaining share taken up by Apple iOS. Furthermore,
because Android devices are on average 50\% cheaper than Apple devices\cite{iphone-price}, the barrier
to purchasing new technology to accomodate the smart application would
be lower if Android was used. This is also a benefit from the \emph{Cost} perspective.

Because the Android platform has advantages in terms of both the \emph{Accessibility}
and the \emph{Cost} aspect, this is the optimal technology to use for the
FGC project.

\subsubsection{Language}
There exists a variety of available technologies and techniques suitable
for creating an Android application. The most common way for developing
Android apps is using the Java programming language,
utilizing the standard Android tooling. Such tooling includes
the Android Studio Integrated Development Environment (IDE),
and the Gradle build system. However, since Android's creation,
multiple other ways of developing Android applications have been introduced. For
example, technologies such as the Ionic Framework \cite{ionic} and
React Native \cite{react-native} have been created, allowing for the creation
of Android applications using the JavaScript programming
language. More recently, Google announced that JetBrains' Kotlin
language will be made an official language of the Android
platform \cite{android-kotlin}.
%https://ionicframework.com/
%https://facebook.github.io/react-native/
%https://www.theverge.com/2017/5/17/15654988/google-jet-brains-kotlin-programming-language-android-development-io-2017

The \emph{Maintainability} persepctive is most imprtant for decisions
in this area: The chosen language may significantly affect the difficulty
of developing and maintaining the smart application. From this perspective,
JavaScript-based frameworks such as Ionic and React Native are
at a disadvantage. They have weak type systems, which means that they
do not undergo a process called "type checking". This, in turn,
means that certain bugs that can easily be detected in other languages may
go unnoticed in a JavaScript program until they are observed in practice, making
it harder to ensure high software quality. Furthermore, the weak type system
property is also detrimental in terms of \emph{Reliability}: if bugs may
slip directly into the real-world usage of the application, there is
no way to guarantee consistent good behavior.

Between Java and Kotlin, Kotlin has a still stronger type system, helping
prevent more bugs at compile-time than Java. It is also a language
with less "boilerplate" code, which eases maintenance and
reduces needless complexity in resulting software. Both
of these are benefits to \emph{Maintainability}. Besides this,
because Kotlin is a language that runs on the Java Virtual Machine,
there are no features of the Android platform that can be done
with Java and not with Kotlin. As such, Kotlin is at the very
least equally as powerful as Java, and with the benefits outlined
above, it should be the language of choice for the project.

\subsubsection{Backwards Compatibility}
Because vendors can customize the Android operating system prior
to using it on their products, a variety of Android devices
run an "outdated" version of the Android platform, resulting
in a severe fragmentation of the overall codebase. Since maintaining
compatibility with every Android version on the market is not viable,
the project will focus on the version of Android supported by 95\%
of Android devices at the time the project implementation begins.
This will allow the project to target a majority of available
devices, while at the same time not being bogged down by the
compatibility requirements with very old version of Android.

\subsection{Data Storage}
Data storage is a major component of the fenceless grazing project.
It is important that the collars collect and store meaningful data
about the animals in the field, to be analyzed by the client.

\subsubsection{Type of Data Collected}
The data collected will consist of GPS coordinates of the animal,
taken every 15 seconds, as well as instances of the activation
of the collars' sound and shock features. This way, the client
can monitor the locations and habits of the animals, as well
as quantitatively assess the number of items that the animals
attempt to leave the prescribed area. Each data point will
be associated with the collar that produced it, such that
behaviors of individual animals can be easily analyzed.

\subsubsection{Storage Server}
Two major categories of storage servers are available at the
present time: SQL and NoSQL databases. SQL-based systems
store data in relational format, turning each piece of
data into a collection of related entries in one or more
tables. On the other hand, NoSQL systems store data in
arbitrary formats (i.e., as potentially more complex entities
than entries in a table). 

SQL and NoSQL are largely equivalent in terms of the criteria
presented at the top of this document. However, because
SQL systems enforce a particular format for data (in
contrast to NoSQL systems, which allow data of various,
unpredictable formats), and because the type of data
that will be stored by the FGC project is known ahead
of time, SQL systems offer a slight advantage to
\emph{Maintainability}. This is because "invalid" data
can be detected and reported immediately as it is stored in
the database. External applications that access the database
(such as the API server) may contain bugs pertaining to
data storage, and having an additional layer of verification
in the storage server will help detect and fix those bugs.

Among SQL systems, three are most commonly used: MariaDB
\cite{mariadb}, MySQL\cite{mysql}, and SQLite. SQLite
is a simple SQL-based database system: it doesn't use
a standalone server, unlike MariaDB and MySQL, and
is simply used from inside other applications as a library.
MySQL and MariaDB, on the other hand, are server-based
database systems. Applications needing to store information
into the databases must first establish a connection to
the database server. MariaDB and MySQL are nearly identical
in terms of functionality, although MariaDB has a more
permissive license.

In terms of \emph{Maintainability}, SQLite is at a slight
disadvantage to the rest of the SQL-based systems due to
its restricted feature set. SQLite supports a subset of
the operations supprted by MySQL and MariaDB, and therefore
may be restrictive in the long run. In terms of \emph{Cost},
MySQL is at a disadvantage due to its prohibitive license:
it is non-free software in terms of price, and although
it has a "free" version, this version receives security
updates and fixes at a slower pace. Since MariaDB
is entirely free and open source, but maintains
the features of MySQL, it is best choice for this project.

\subsubsection{Storage Hardware}
Because MariaDB and MySQL require a server machine, such
a machine must be part of the final design. This
can be achieved with a standard server computer,
a VPS host, or a single-board computer such as a Raspberry Pi \cite{raspi}.

The Raspberry Pi is a promising option in terms of both
\emph{Cost} and \emph{Maintainability}. It is a small, single-board
computer that costs approximately \$30, and is fully
capable of running a Linux distribution such as
Debian (or Raspbian). After the initial cost
of the purchase, the Raspberry Pi will not consume
significant amounts of power, and thus remain very cheap
in the long run. The advantage to maintainability is
due to its official support for various additional
hardware modules, such as modules for the LoRa
protocol used in other parts of the project. By
combining the functionality of the LoRa receiver
and the API server, the complexity of the overall
system can be greatly reduced, making it easier
to design and maintain.

A VPS host would have both benefits and drawbacks
in terms of \emph{Maintainability} and \emph{Cost},
although it is superior in terms of \emph{Reliability}.
A Virtual Private Server is a Linux server that is hosted
by another company for a monthly or yearly fee. The costs
of such servers are fairly small: common VPS packages
cost around \$5 per month, which is an adequate price
for such a product. However, unlike the Raspberry Pi,
these costs would accumulate over time, since a VPS
is a subscription-based service. Furthermore, unlike
the Raspberry Pi, the VPS does not support any additional
hardware. Therefore, another device would need to
be constructed to receive data from the Fenceless Grazing
Collars in the field, and forward that data to the VPS
for storage. This increases the complexity of the system,
thereby making software for it more difficult to develop and
maintain. The main advantage of a VPS host is that it
will be guaranteed to remain functional at all times
without the need for additional support, preventing
unexpected outages and therefore increasing reliability.

For this project, a standard server machine is practically
the worst of both worlds. Unlike the Raspberry Pi, which
has support for additional hardware through a standardized
and officially supported interface, a regular server computer
would require additional modification to be able to interface
with LoRa devices in the field (or, just like the VPS host,
it would require an additional dedicated device to receive
and forward LoRa communication). Furthermore, unlike
a VPS host, it will potentially require support (in 
events such as power outages or network failures), which
may result in temporary failures, a major downside from
the perspective of \emph{Reliability}.

Between a VPS host and a Raspberry Pi, the latter appears
better suited for the project due the simplicity of integrating
it into the system. No additional hardware or components
would be necessary, reducing the surface area for failures
(thereby benefitting \emph{Reliability}), and the cost
after the initial investment would be minimal, benefitting \emph{Cost}.
As such, a Raspberry Pi should be used for this project.

\subsection{App API Server}
An API server is needed to allow users of the Android
smart application to interact with the fenceless collars
deployed on farm animals. Smartphones do not have
hardware that can communicate using the LoRa protocol,
which is used for collars. As such, an intermediate
device - a server that can communicate with both smartphones
and LoRa - must be used.

\subsubsection{Server Hardware}
It is possible to use the aforementioned Linux storage machine
as the hardware for the API server. This would have benefits
in terms of \emph{Cost} and \emph{Maintainability},
while having certain drawbacks in terms of \emph{Reliability}.
It would be cheaper to use the existing hardware for the API
server: no further purchases would be necessary besides
the Raspberry Pi, VPS, or other server described
in the sections above. Furthermore, such a configuration
would be maintainable, since it eliminates the complexity
of managing two separate server instances and their communication
with each other. On the other hand, this approach
would couple the health of the API server to the health
of the database server: if one suffers a hardware or critical
software failure, so will the other. This means that
the API/data server will be a major point of failure.

The alternative approach would be to have a separate
API server. Since no special-purpose hardware would
be needed for this task, by the logic in the Storage Hardware
section, a VPS host would tbe most likely candidate for
such a server. This would bring in the advantage
of \emph{Reliability}, but could complicate the system
making it less \emph{Maintainable}. Furthermore,
since such a configuration would introduce the need
for communication between the API server and the data
server, this exposes more area for bugs and faults.

Because it is cheaper and less complex to set up
the API server on the same hardware as the data
server (the Raspberry Pi), this should be the
configuration of choice for this project.

\subsubsection{Server Language}
Virtually any language can be used for developing an API.
Python \cite{python} and Rust are some of the viable
options for this project.

Unlike Python, Rust a complicated type system, which is one of its
main selling points. The type system prevents many
classes of bugs that are common in software products,
especially those that use concurrency. It is therefore,
in a way, more \emph{Maintainable} than th other alternatives,
by the same logic that made Koltin more maintainable than
the alternatives for smart application development.

Python is a dynamically typed language, and as such does
not benefit from type checking directly. It thus suffers
in comparison to Rust in terms of maintainability. However,
Python's main advantage for this project is that it is
the official language of the Raspberry Pi, and therefore
can be used for certain hardware manipulation tasks
that are more difficult in other languages. Because
the API server will be tied to LoRa, which is an external
hardware module, using Python for the entire
project will make the end product \emph{more} maintainable,
since there will be no need for additional frameworks,
libraries, or other components to bridge the gap between
the implementation language and the hardware.

Because of its first-class support for hardware manipulation
on the Raspberry Pi, Python is significantly better for
this project than other possible languages.

\subsubsection{Server Software}
Special software is typically used to expose a web application
to the outside world (which is necessary for other components,
such as the smart application, to access the API server). Apache,
nginx, and Gunicorn\cite{gunicorn} are valid options for this purpose.

Gunicorn is superior in terms of \emph{Maintainability} due to
its simplicity. Whereas both Apache and nginx are general-purpose
server software, which have powerful configuration options and
complex execution models, Gunicorn does one thing: host Python
web applications. Since the API server is not intended to be
a complex system, it will not benefit from additional configurability
provided by Apache or nginx, and will therefore reduce the cognitive
load on team members as they work on the project.

\subsubsection{Authentication}
JWT and Cookie-based approaches can be used to perform
authentication in the API server.

The idea of JWT is that a JSON (JavaScript Object Notation) object, containing
session information (such as the identity of the current user),
is encrypted with information from the server. The encrypted
version of this object is then sent to the user, and can be
used as a "proof of identity". Since only the server can decrypt
the token, the user cannot deliberately make changes to it, preventing
security breaches. Once a user logs in, a JWT token will be generated,
containing the identity of the user and an expiration date, and
returned to the app. The app will then use the token for further
requests. This technology is useful in terms of \emph{Maintainablity},
since it is widely supported by most programming languages, and does
not require the use of a browser. Thus, if the project migrates
to other platforms in the future, the technical cost of implementing
authentication on these new platforms will be negligible.

Cookie-based authentication systems are commonly used in web applications,
serving as a different way to avoid authentication on every API or web request. However,
this approach will not generalize well. Using cookie or session-based
authentication requires more extensive bookkeeping on the client side, which
complicates the implementation of other clients. In the future, it is
likely that the smart application will be ported to other platforms,
including iOS and Web. To ease this expansion, the approach
requiring the least additional implementation overhead is preferred.
Because of this criterion, JWT-based authentication is better suited
for the API server.

Because of the above issues with Cookie-based authentication, JWT
should be used for this project due to its benefits to \emph{Maintainability}.

\subsubsection{API}
There are several ways of communicating data to the mobile application
from the server. Because writing custom code to encode / decode data
sent between the android application (client) and the server is
time consuming and prone to errors, priority is given to existing
encoding / decoding technologies. Of these technologies, Google's
ProtoBuf \cite{protobuf}, XML, and JSON are the most viable.

% TODO I guess you can talk about protobuf need to regenerate shit

JSON should be used for this project because of the ease with which it can be decoded,
as well as due to its compatibility with the JavaScript ecosystem.
Virtually every language (including Kotlin and Python) has support
for JSON decoding that is well-tested and supported. This makes
JSON the most standard choice for an interchange format. These
benefits give a huge boost to \emph{Maintainability}, since
little additional work needs to be done to handle JSON in most
modern systems.

\pagebreak
\begin{thebibliography}{99}

    \bibitem{android-share}Alex Cocotas, \textit{Android Bounces Back From U.S. Market Share Decline} \\
    \texttt{https://www.businessinsider.com/android-stops-us-market-share-decline-2013-5}

    \bibitem{iphone-price}Amit Chowdhry, \textit{Average iPhone Price Increases To $687 And Android Decreases To $254, Says Report} \\
    \texttt{https://www.forbes.com/sites/amitchowdhry/2015/02/03/average-iphone-price-increases-to-687-and-android-decreases-to-254-says-report/\#437c18ac539e}

    \bibitem{ionic}\textit{Ionic Framework} \\
    \texttt{https://ionicframework.com/}

    \bibitem{react-native}\textit{React Native} \\
    \texttt{https://facebook.github.io/react-native/}

    \bibitem{android-kotlin}Paul Miller, \textit{Google is adding Kotlin as an official programming language for Android development} \\
    \texttt{https://www.theverge.com/2017/5/17/15654988/google-jet-brains-kotlin-programming-language-android-development-io-2017}

    \bibitem{mariadb}\textit{MariaDB} \\
    \texttt{https://mariadb.org/}

    \bibitem{mysql}\textit{MySQL} \\
    \texttt{https://www.mysql.com/}

    \bibitem{raspi}\textit{Raspberry Pi} \\
    \texttt{https://www.raspberrypi.org/}

    \bibitem{python}\textit{Python} \\
    \texttt{https://www.python.org/}

    \bibitem{gunicorn}\textit{GUnicorn} \\
    \texttt{https://gunicorn.org/}

    \bibitem{protobuf}\textit{Protocol Buffer} \\
    \texttt{https://developers.google.com/protocol-buffers}
\end{thebibliography}

\end{document}