Mailing-List: contact dev-help@quarks.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@quarks.incubator.apache.org
From: dlaboss <git@git.apache.org>
To: dev@quarks.incubator.apache.org
Reply-To: dev@quarks.incubator.apache.org
References: <git-pr-53-incubator-quarks-website@git.apache.org>
In-Reply-To: <git-pr-53-incubator-quarks-website@git.apache.org>
Subject: [GitHub] incubator-quarks-website pull request: [QUARKS-159] Update
 website...
Content-Type: text/plain
Message-Id: <20160429205522.C9ED1DFC6F@git1-us-west.apache.org>
Date: Fri, 29 Apr 2016 20:55:22 +0000 (UTC)

Github user dlaboss commented on a diff in the pull request:

    https://github.com/apache/incubator-quarks-website/pull/53#discussion_r61643402
  
    --- Diff: site/recipes/recipe_adaptable_deadtime_filter.md ---
    @@ -4,63 +4,63 @@ title: Using an adaptable deadtime filter
     
     Oftentimes, an application wants to control the frequency that continuously generated analytic results are made available to other parts of the application or published to other applications or an event hub.
     
    -For example, an application polls an engine temperature sensor every second and performs various analytics on each reading - an analytic result is generated every second.  By default, the application only wants to publish a (healthy) analytic result every 30 minutes.  However, under certain conditions, the desire is to publish every per-second analytic result.
    +For example, an application polls an engine temperature sensor every second and performs various analytics on each reading &mdash; an analytic result is generated every second. By default, the application only wants to publish a (healthy) analytic result every 30 minutes. However, under certain conditions, the desire is to publish every per-second analytic result.
     
     Such a condition may be locally detected, such as detecting a sudden rise in the engine temperature or it may be as a result of receiving some external command to change the publishing frequency.
     
     Note this is a different case than simply changing the polling frequency for the sensor as doing that would disable local continuous monitoring and analysis of the engine temperature.
     
    -This case needs a *deadtime filter* and Quarks provides one for your use!  In contrast to a *deadband filter*, which skips tuples based on a deadband value range, a deadtime filter skips tuples based on a *deadtime period* following a tuple that is allowed to pass through.  E.g., if the deadtime period is 30 minutes, after allowing a tuple to pass, the filter skips any tuples received for the next 30 minutes.  The next tuple received after that is allowed to pass through, and a new deadtime period is begun.
    +This case needs a *deadtime filter* and Quarks provides one for your use! In contrast to a *deadband filter*, which skips tuples based on a deadband value range, a deadtime filter skips tuples based on a *deadtime period* following a tuple that is allowed to pass through. For example, if the deadtime period is 30 minutes, after allowing a tuple to pass, the filter skips any tuples received for the next 30 minutes. The next tuple received after that is allowed to pass through, and a new deadtime period is begun.
     
    -See ``quarks.analytics.sensors.Filters.deadtime()`` and ``quarks.analytics.sensors.Deadtime``.
    +See `quarks.analytics.sensors.Filters.deadtime()` (on [GitHub](https://github.com/apache/incubator-quarks/blob/master/analytics/sensors/src/main/java/quarks/analytics/sensors/Filters.java)) and `quarks.analytics.sensors.Deadtime` (on [GitHub](https://github.com/apache/incubator-quarks/blob/master/analytics/sensors/src/main/java/quarks/analytics/sensors/Deadtime.java)).
     
     This recipe demonstrates how to use an adaptable deadtime filter.
     
    -A Quarks ``IotProvider`` and ``IoTDevice`` with its command streams would be a natural way to control the application.  In this recipe we will just simulate a "set deadtime period" command stream.
    +A Quarks `IotProvider` ad `IoTDevice` with its command streams would be a natural way to control the application. In this recipe we will just simulate a "set deadtime period" command stream.
     
     ## Create a polled sensor readings stream
     
     ```java
    -        Topology top = ...;
    -        SimulatedTemperatureSensor tempSensor = new SimulatedTemperatureSensor();
    -        TStream<Double> engineTemp = top.poll(tempSensor, 1, TimeUnit.SECONDS)
    -                                      .tag("engineTemp");
    +Topology top = ...;
    +SimulatedTemperatureSensor tempSensor = new SimulatedTemperatureSensor();
    +TStream<Double> engineTemp = top.poll(tempSensor, 1, TimeUnit.SECONDS)
    +                              .tag("engineTemp");
     ```
     
     It's also a good practice to add tags to streams to improve the usability of the development mode Quarks console.
     
    -## Create a deadtime filtered stream - initially no deadtime
    +## Create a deadtime filtered stream&mdash;initially no deadtime
     
    -In this recipe we'll just filter the direct ``engineTemp`` sensor reading stream.  In practice this filtering would be performed after some analytics stages and used as the input to ``IotDevice.event()`` or some other connector publish operation.
    +In this recipe we'll just filter the direct ``engineTemp`` sensor reading stream. In practice this filtering would be performed after some analytics stages and used as the input to ``IotDevice.event()`` or some other connector publish operation.
     
     ```java
    -        Deadtime<Double> deadtime = new Deadtime<>();
    -        TStream<Double> deadtimeFilteredEngineTemp = engineTemp.filter(deadtime)
    -                                      .tag("deadtimeFilteredEngineTemp");
    +Deadtime<Double> deadtime = new Deadtime<>();
    +TStream<Double> deadtimeFilteredEngineTemp = engineTemp.filter(deadtime)
    +                              .tag("deadtimeFilteredEngineTemp");
     ```
     
     ## Define a "set deadtime period" method
     
     ```java
    -    static <T> void setDeadtimePeriod(Deadtime<T> deadtime, long period, TimeUnit unit) {
    -        System.out.println("Setting deadtime period="+period+" "+unit);
    -        deadtime.setPeriod(period, unit);
    -    }
    +static <T> void setDeadtimePeriod(Deadtime<T> deadtime, long period, TimeUnit unit) {
    +    System.out.println("Setting deadtime period="+period+" "+unit);
    +    deadtime.setPeriod(period, unit);
    +}
     ```
     
     ## Process the "set deadtime period" command stream
     
    -Our commands are on the ``TStream<JsonObject> cmds`` stream.  Each ``JsonObject`` tuple is a command with the properties "period" and "unit".
    +Our commands are on the ``TStream<JsonObject> cmds`` stream. Each ``JsonObject`` tuple is a command with the properties "period" and "unit".
     
     ```java
    -        cmds.sink(json -> setDeadtimePeriod(deadtimeFilteredEngineTemp,
    -            json.getAsJsonPrimitive("period").getAsLong(),
    -            TimeUnit.valueOf(json.getAsJsonPrimitive("unit").getAsString())));
    +cmds.sink(json -> setDeadtimePeriod(deadtimeFilteredEngineTemp,
    +    json.getAsJsonPrimitive("period").getAsLong(),
    +    TimeUnit.valueOf(json.getAsJsonPrimitive("unit").getAsString())));
     ```
     
     ## The final application
     
    -When the application is run it will initially print out temperature sensor readings every second for 15 seconds - the deadtime period is 0.  Then every 15 seconds the application will toggle the deadtime period between 5 seconds and 0 seconds, resulting in a reduction in tuples being printed during the 5 second deadtime period.
    +When the application is run it will initially print out temperature sensor readings every second for 15 seconds&mdash;the deadtime period is 0. `Then every 15 seconds the application will toggle the deadtime period between 5 seconds and 0 seconds, resulting in a reduction in tuples being printed during the 5 second deadtime period.
    --- End diff --
    
    A  backtick was added: `Then every 15 ...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---