[
https://issues.apache.org/jira/browse/QUARKS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15209043#comment-15209043
]
ASF GitHub Bot commented on QUARKS-36:
--------------------------------------
Github user queeniema commented on a diff in the pull request:
https://github.com/apache/incubator-quarks-website/pull/18#discussion_r57226356
--- Diff: site/recipes/recipe_different_processing_against_stream.md ---
@@ -0,0 +1,150 @@
+---
+title: Recipe 4. Applying Different Processing Against a Single Stream
+---
+
+In the previous [example](recipe_value_out_of_range), we learned how to
filter a stream to obtain the interesting sensor readings and ignore the
mundane data. Typically, a user scenario is more involved, where data is
processed by executing multiple stream operations sequentially. Consider the
following scenario, for example.
+
+Suppose a package delivery company would like to monitor the gas mileage
of their delivery trucks using embedded sensors. They would like to apply
different analytics to the sensor data that can be used to make more informed
business decisions. For instance, if a truck is reporting consistently poor
mileage readings, the company might want to consider replacing that truck to
save on gas costs.
+
+In this instance, we can apply different processing against the stream of
mileage readings from the sensor and generate warnings when poor gas mileage is
detected.
+
+## Setting up the application
+
+We assume that the environment has been set up following the steps
outlined in the [Getting Started Guide](../docs/quarks-getting-started). Let's
begin by creating a `DirectProvider` and `Topology`. We choose a
`DevelopmentProvider` so that we can view the topology graph using the console
URL (refer to the [Application Console](../docs/console) page for a more
detailed explanation of this provider). The initial mileage value has also been
defined.
+
+```java
+ public class TruckSensor {
+ /**
+ * Hypothetical value for initial gas mileage
+ */
+ static double currentMileage = 10.5;
+
+ public static void main(String[] args) throws Exception {
+
+ DirectProvider dp = new DevelopmentProvider();
+
+
System.out.println(dp.getServices().getService(HttpServer.class).getConsoleUrl());
+
+ Topology top = dp.newTopology("TruckSensor");
+
+ // The rest of the code pieces belong here.
+ }
+ }
+```
+
+## Generating mileage sensor readings
+
+The next step is to simulate a stream of gas mileage readings. In our
`main()`, we use the `poll()` method to generate a flow of tuples (readings),
where each tuple arrives every second.
+
+```java
+ // Generate a stream of mileage sensor readings.
+ Random r = new Random();
+ TStream<Double> mileage = top.poll(() -> {
+ // Change current mileage by some random amount between -0.4 and
0.4.
+ double newMileage = -0.4 + (0.4 + 0.4) * r.nextDouble() +
currentMileage;
+ currentMileage = newMileage;
+ return currentMileage;
+ }, 1, TimeUnit.SECONDS);
+```
+
+## Applying different processing to the stream
+
+The company can now perform analytics on the `mileage` stream to generate
poor gas mileage warnings by starting with the original stream and altering it.
First, we filter out values that are out of range. Then, we tag the stream with
the _mileage_ tag for easier viewing in the console (we add this tag after
every step). Next, we truncate the reading to one decimal place. We then use
`peek` to print out the current mileage so that we can get a sense of the
truck's current state. After, we keep the mileage readings that are considered
"poor." Finally, we terminate the stream by printing out warnings for poor gas
mileage.
+
+```java
+ DecimalFormat df = new DecimalFormat("#.#");
+
+ // Perform analytics on mileage readings to generate poor gas mileage
warnings.
+ mileage = mileage.filter(tuple -> tuple >= 7.0 && tuple <= 14.0);
--- End diff --
I thought that performing the steps separately would make it easier to
follow, but I agree that it would be cleaner to use the fluent style. I will do
that for this and future recipes.
> Recipe creation for "Re-using a stream" and "Detect a sensor value out of
> expected range"
> -----------------------------------------------------------------------------------------
>
> Key: QUARKS-36
> URL: https://issues.apache.org/jira/browse/QUARKS-36
> Project: Quarks
> Issue Type: Improvement
> Components: Documentation
> Reporter: Queenie Ma
> Assignee: Queenie Ma
> Priority: Minor
> Labels: documentation, enhancement, recipes
>
> I will write up two recipes for:
> * Apply different processing against a single stream
> * Detect a sensor value out of expected range
> ** simple filtering
> ** deadband filter
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
