Trimming examples.

Geoffrey Challen
1 parent 390e2adc
Showing 2 changed files with 72 additions and 140 deletions
related.tex
usage.tex
@@ -16,27 +16,22 @@ separation of cross-cutting concerns in software. The programmer can express
 cross cutting concerns in stand alone modules, or aspects. Aspects are
 composed of advice, which specifies a computation to be performed as well as
 points in the program at which that computation should be performed.
-Aspects are integrated into a program through a weaving step that integrates
-the aspects into the codebase. Support for dynamic weaving~\cite{weaving} is
-also available.
-
 Abstractly, aspects provide an interesting framework on top of which we could
 realize \texttt{maybe} blocks. At runtime, different aspects could be weaved
 depending on the framework decisions. Aspects would also allow ``chained''
 \texttt{maybe} blocks through the use of multiple join points and point-cuts.
-Unfortunately, dynamic weaving and unweaving can be expensive, requiring the
-use of a JIT. Fundamentally, however, the goals of AOP and the \texttt{maybe}
-statement differ, with AOP focusing on modularity and \texttt{maybe} focused
-on increasing runtime flexibility in the face of uncertainty.
+Fundamentally, however, the goals of AOP and the \texttt{maybe} statement
+differ, with AOP focusing on modularity and \texttt{maybe} focused on
+increasing runtime flexibility in the face of uncertainty.
  
 \texttt{maybe} shares similaries with language-based approaches to managing
 energy consumption in wireless sensor networks such as
 Eon~\cite{sensys07-eon} and Levels~\cite{sensys07-levels}. However, these
 approaches still require programmers to express certainty by associating code
-with particular energy states, rather than allowing the runtime system to
-determine which energy states are appropriate as the \texttt{maybe} system
-would be able to do. \texttt{maybe} can also enable adaptation driven by
-goals other than energy management.
+with particular energy states, rather than allowing the system to determine
+which energy states are appropriate as the \texttt{maybe} system would do.
+\texttt{maybe} can also enable adaptation driven by goals other than energy
+management.
  
 Enabling more adaptive mobile systems is a challenge with a long history dating
 back to work on systems such as Odyssey~\cite{odyssey-sosp97}. However, a
@@ -2,158 +2,95 @@
 \label{sec-usage}
  
 The \texttt{maybe} system is inspired by our frustrations building smartphone
-apps and confronting the uncertainties of mobile systems programming. In this
-section we describe several ways to use the \texttt{maybe} system drawn from
-our own experiences, including for a smartphone service, a smartphone app, an
-M2M app utilizing smartphones, and within the Android platform itself.
+apps that confront the uncertainties inherent to mobile systems programming.
+In this section we describe several examples of how to use the \texttt{maybe}
+statement drawn from our own experiences.
  
 \subsection{PocketParker App}
  
-\begin{comment}
-
-\begin{figure}[t]
- \begin{minted}[fontsize=\footnotesize]{java}
-string detectParkingEvent() {
- maybe {
- // Use app-specific algorithm
- } or {
- // Use Google Play services
- }
-}
- \end{minted}
- 
- \vspace*{-0.2in}
- \caption{\textbf{Activity recognition using \texttt{maybe}.} \texttt{maybe}
- expresses the uncertainty of whether to use our customized app-specific
-parking detection algorithm or rely on the Google Play services framework
-activity recognition.}
- 
- \label{fig-activityrecognition}
- \vspace*{-0.1in}
-\end{figure}
-
-\end{comment}
-
-PocketParker~\cite{ubicomp14-pocketparker} estimates the availability of
-parking spaces in parking lots. It does this by automatically detecting users
-of the app parking in, and departing from parking lots. To
-detect these events without the need for explicit user input, we used the
-accelerometer of the user's smartphone to detect whether a user is driving or
-walking. Based on the detected activity and past histories, we could infer
-whether a user had parked her car or departed. We needed to do this in
-an energy efficient way so that the battery on the user's phone would not
-drain because of our app. We developed a custom activity recognition
-algorithm to determine the user's activity from the accelerometer values
-sampled during the last time interval. In order to reduce battery
-consumption, we duty cycled the sampling of the accelerometer.
-
-Towards the end of our development, Google released their own activity
-recognition API as a part of their Google Play Services framework. We had to
-conduct several small-scale tests to determine the better of the two
-algorithms in terms of energy consumption and accuracy. There was no clear
-winner between the two and we decided to use the Google's API as it was a third
-party library with an actively maintained codebase. 
-Supporting both algorithms, switching between them at runtime, and assessing
-the resulting impact would have required a significant development effort.
+PocketParker~\cite{ubicomp14-pocketparker} estimates parking lot availability
+by using the smartphone's accelerometer to detect users entering and leaving
+parking spots. To do this is an energy-efficient manner, we initially
+developed a custom activity recognition algorithm that duty-cycled the
+accelerometer to conserve energy. Towards the end of our development, Google
+released their own activity recognition API as a part of their Google Play
+Services framework. Based on several small-scale tests there was no clear
+winner when comparing the two algorithms, and so we decided to use Google's
+implementation to offload the maintenance burden. Supporting both algorithms,
+switching between them at runtime, and assessing the resulting impact on a
+larger user population would have required a significant amount of
+development effort.
  
 Such runtime decisions fit naturally into the \texttt{maybe} framework.
-Instead of having to choose based on small-scale local testing, the \texttt{maybe} 
-system can gradually transition an application's users from mature, but 
-inexpensive to maintain application logic to a potentially immature system-wide 
-library implementation. As the library implementation matures and improves, the
-\texttt{maybe} system can conduct repeated testing and
-move more users over to the third-party implementation. For some
-users and on some devices, the third-party implementation may never
-outperform the app-specific algorithm, in which cases both alternatives can
-coexist safely.
+Instead of having to choose based on small-scale local testing, the
+\texttt{maybe} system can manage the transition from a mature but
+app-specific and expensive to maintain algorithm to a potentially-immature
+but canonical library implementation. As the library implementation improves
+and begins to out-perform the hand-tuned alternative, the \texttt{maybe}
+system can conduct repeated testing and move more users over to the library
+implementation. For some users or on some devices, the library implementation
+may never outperform the app-specific algorithm, in which cases
+\texttt{maybe} allows both alternatives to coexist safely while ensuring that
+each user enjoys whichever approach is most effective for them.
  
 \subsection{\texttt{\large PhoneLab} Conductor}
  
-\begin{comment}
-
-\begin{figure}[t]
- \begin{minted}[fontsize=\footnotesize]{java}
-maybe {
- // policy A
-} or {
- // policy B
-} or {
- // policy C
-} better {
- if (lostLogLines > 0) {
- return Integer.MAX_VALUE;
- } else {
- return w1*bytesOverCellular + w2*energy;
- }
-}
- \end{minted}
- 
- \caption{\textbf{\PhoneLab{} Conductor Upload Logic Using \texttt{maybe}.}}
- 
- \label{fig-upload}
-\end{figure}
-
-\end{comment}
-
 \PhoneLab{} is a large scale smartphone platform testbed at the University at
 Buffalo~\cite{phonelab-sensemine13,phonelab-url}. We leverage the Android
 \texttt{logcat} subsystem as a data collection mechanism---experiment apps
 write their data into a system-wide log buffer and we collect and upload this
 data on their behalf.
  
-We developed an app called \PhoneLab{} Conductor for this purpose. Due to the
-uncertainties we faced when developing this tool, we developed a specialized
+We developed an app called the \PhoneLab{} Conductor for this purpose which
+provides a good example of custom \texttt{maybe} evaluation logic. The goal
+of our app is to collect data reliably while minimizing energy consumption,
+storage usage, and metered data usage. With the \texttt{maybe} statement
+branching between multiple policies for uploading data---such as always
+waiting until the user reaches a plug, or always initiating an upload once
+the storage allocated is 50\% full---the evaluation logic would provide the
+lowest possible score if data had been lost, or otherwise a score combining
+the multiple attributes the app is trying to minimize.
+
+Due to the uncertainties we faced during development, we implemented a
 configuration interface that periodically retrieves parameters from our
-servers and uses them to reconfigure variable components of the app. This
-allows us to control aspects of program behavior such as the amount of storage
-space we use on each device for log buffers, how often we check for updates,
+server and uses them to reconfigure variable components of the app. This
+allows us to control aspects of program behavior such as the amount of
+storage space we use on each device for logs, how often we check for updates,
 and how to decide whether to upload data. Several of these features have
 proven essential after deployment---for example, when an upload policy that
-worked on an earlier version of Android abruptly stopped working on a newer
-version. Development of this app would have been considerably easier using
-\texttt{maybe}, which could automate the process of pushing policies to clients
-in an energy-efficient way, and enable much more fine-grained and goal-driven adaptation than we are currently performing.
-
-The \PhoneLab{} Conductor also provides a good example of custom
-\texttt{maybe} evaluation logic. The primary goal of our app is to collect
-data reliably while minimizing energy consumption, storage usage, and metered
-data usage. With the \texttt{maybe} statement branching between multiple
-policies for uploading data---such as always waiting until the user reaches a
-plug, or always initiating an upload once the storage allocated is 50\%
-full---the evaluation logic would provide the lowest possible score if data
-had been lost, or otherwise a score combining the multiple attributes the app is
-trying to minimize.
+worked previously abruptly stopped working on a newer Androiod version.
+Development of this app would have been considerably easier using
+\texttt{maybe}, which could automate the process of pushing policies to
+clients in an energy-efficient way, and enable per-user goal-driven
+adaptation.
  
-\subsection{Navjack Sensing Platform}
  
-% 12 Oct 2014 : GWA : Code example here is just too gross. Definitely not
-% going to use it.
+\subsection{Navjack Sensing Platform}
  
 The Navjack project is exploring hijacking in-car navigation devices built
 from repurposed smartphones~\cite{sustain-hotmobile14} and deployed in
 personal vehicles to enable city-scale sensing. Volunteers install a device
 that acts as a dedicated navigational aid and car performance monitor but
-also senses data both while the car is moving and stationary, utilizing the
-car's battery for power, the car's driver for maintenance, and new
-inexpensive machine-to-machine (M2M) data plans offered by cellular carriers
-for telemetry.
-
-Navjack's goal is to produce high-quality data in response to queries without
-draining the car's battery, while consuming as little cellular data as
-possible. Many uncertainties specific to this app complicate the process.
-Some car cigarette lighters and USB charging docks provide power while the
-vehicle is off, while some do not. Users drive their vehicles for different
-durations and at different frequencies. Furthermore, cellular coverage varies,
-altering the energy-per-bit required to offload data. All of these factors
-complicate post-deployment adaptation.
-
-\texttt{maybe} statements in Navjack can be used to control the rate at which
-data is sampled, the set of sensors that are used, and the conditions under
-which uploads are attempted. This app provides an example of an adaptation
-state space that can potentially get quite large, and so it may provide a
-good chance to evaluate our ability to perform pre-deployment simulations to
-reduce the state space and success of post-deployment clustering techniques
-to identify differences between users that impact app alternative choices.
+also continuously collects sensor data, utilizing the car's battery for
+power, the car's driver for maintenance, and inexpensive machine-to-machine
+(M2M) data plans for telemetry.
+
+Navjack's goal is to produce high-quality data in response to queries while
+minimizing cellular data usage and car battery energy consumption. Many
+uncertainties specific to this app complicate the process. Some car cigarette
+lighters and USB charging docks provide power while the vehicle is off, while
+some do not. Users drive their vehicles for different durations and at
+different frequencies. Cellular coverage varies, altering the energy-per-bit
+required to offload data. All of these factors complicate post-deployment
+adaptation.
+
+\texttt{maybe} statements in Navjack can be used to control the sampling
+rate, the set of sensors that are used, and the conditions under which
+uploads are attempted. This app provides an example of an adaptation state
+space that can potentially get quite large, and so it may provide a good
+chance to evaluate both our ability to perform pre-deployment simulations to
+reduce the state space and the success of post-deployment clustering
+techniques to identify salient user differences.
  
 \subsection{Android Platform Services}