edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QUARKS-159) Update website to follow style guide
Date Fri, 29 Apr 2016 20:56:12 GMT

    [ https://issues.apache.org/jira/browse/QUARKS-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264719#comment-15264719
] 

ASF GitHub Bot commented on QUARKS-159:
---------------------------------------

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 ...


> Update website to follow style guide
> ------------------------------------
>
>                 Key: QUARKS-159
>                 URL: https://issues.apache.org/jira/browse/QUARKS-159
>             Project: Quarks
>          Issue Type: Improvement
>          Components: Documentation, Web Site
>            Reporter: Queenie Ma
>            Assignee: Queenie Ma
>
> The style guide is located in [README.md|https://github.com/apache/incubator-quarks-website/blob/master/README.md].
See QUARKS-153.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message