Flink exposes a metric system that allows gathering and exposing metrics to external systems.
You can access the metric system from any user function that extends RichFunction by calling getRuntimeContext().getMetricGroup()
.
This method returns a MetricGroup
object on which you can create and register new metrics.
Flink supports Counters
, Gauges
, Histograms
and Meters
.
A Counter
is used to count something. The current value can be in- or decremented using inc()/inc(long n)
or dec()/dec(long n)
.
You can create and register a Counter
by calling counter(String name)
on a MetricGroup
.
Alternatively you can also use your own Counter
implementation:
A Gauge
provides a value of any type on demand. In order to use a Gauge
you must first create a class that implements the org.apache.flink.metrics.Gauge
interface.
There is no restriction for the type of the returned value.
You can register a gauge by calling gauge(String name, Gauge gauge)
on a MetricGroup
.
Note that reporters will turn the exposed object into a String
, which means that a meaningful toString()
implementation is required.
A Histogram
measures the distribution of long values.
You can register one by calling histogram(String name, Histogram histogram)
on a MetricGroup
.
Flink does not provide a default implementation for Histogram
, but offers a Wrapper that allows usage of Codahale/DropWizard histograms.
To use this wrapper add the following dependency in your pom.xml
:
You can then register a Codahale/DropWizard histogram like this:
A Meter
measures an average throughput. An occurrence of an event can be registered with the markEvent()
method. Occurrence of multiple events at the same time can be registered with markEvent(long n)
method.
You can register a meter by calling meter(String name, Meter meter)
on a MetricGroup
.
Flink offers a Wrapper that allows usage of Codahale/DropWizard meters.
To use this wrapper add the following dependency in your pom.xml
:
You can then register a Codahale/DropWizard meter like this:
Every metric is assigned an identifier and a set of key-value pairs under which the metric will be reported.
THe identifier is based on 3 components: the user-defined name when registering the metric, an optional user-defined scope and a system-provided scope.
For example, if A.B
is the system scope, C.D
the user scope and E
the name, then the identifier for the metric will be A.B.C.D.E
.
You can configure which delimiter to use for the identifier (default: .
) by setting the metrics.scope.delimiter
key in conf/flink-conf.yaml
.
You can define a user scope by calling MetricGroup#addGroup(String name)
, MetricGroup#addGroup(int name)
or Metric#addGroup(String key, String value)
.
These methods affect what MetricGroup#getMetricIdentifier
and MetricGroup#getScopeComponents
return.
The system scope contains context information about the metric, for example in which task it was registered or what job that task belongs to.
Which context information should be included can be configured by setting the following keys in conf/flink-conf.yaml
.
Each of these keys expect a format string that may contain constants (e.g. “taskmanager”) and variables (e.g. “<task_id>”) which will be replaced at runtime.
metrics.scope.jm
metrics.scope.jm.job
metrics.scope.tm
metrics.scope.tm.job
metrics.scope.task
metrics.scope.operator
There are no restrictions on the number or order of variables. Variables are case sensitive.
The default scope for operator metrics will result in an identifier akin to localhost.taskmanager.1234.MyJob.MyOperator.0.MyMetric
If you also want to include the task name but omit the task manager information you can specify the following format:
metrics.scope.operator: <host>.<job_name>.<task_name>.<operator_name>.<subtask_index>
This could create the identifier localhost.MyJob.MySource_->_MyOperator.MyOperator.0.MyMetric
.
Note that for this format string an identifier clash can occur should the same job be run multiple times concurrently, which can lead to inconsistent metric data. As such it is advised to either use format strings that provide a certain degree of uniqueness by including IDs (e.g <job_id>) or by assigning unique names to jobs and operators.
Important: For the Batch API, <operator_id> is always equal to <task_id>.
You can define a user variable by calling MetricGroup#addGroup(String key, String value)
.
This method affects what MetricGroup#getMetricIdentifier
, MetricGroup#getScopeComponents
and MetricGroup#getAllVariables()
returns.
Important: User variables cannot be used in scope formats.
Metrics can be exposed to an external system by configuring one or several reporters in conf/flink-conf.yaml
. These
reporters will be instantiated on each job and task manager when they are started.
metrics.reporter.<name>.<config>
: Generic setting <config>
for the reporter named <name>
.metrics.reporter.<name>.class
: The reporter class to use for the reporter named <name>
.metrics.reporter.<name>.interval
: The reporter interval to use for the reporter named <name>
.metrics.reporter.<name>.scope.delimiter
: The delimiter to use for the identifier (default value use metrics.scope.delimiter
) for the reporter named <name>
.metrics.reporters
: (optional) A comma-separated include list of reporter names. By default all configured reporters will be used.All reporters must at least have the class
property, some allow specifying a reporting interval
. Below,
we will list more settings specific to each reporter.
Example reporter configuration that specifies multiple reporters:
Important: The jar containing the reporter must be accessible when Flink is started by placing it in the /lib folder.
You can write your own Reporter
by implementing the org.apache.flink.metrics.reporter.MetricReporter
interface.
If the Reporter should send out reports regularly you have to implement the Scheduled
interface as well.
The following sections list the supported reporters.
You don’t have to include an additional dependency since the JMX reporter is available by default but not activated.
Parameters:
port
- (optional) the port on which JMX listens for connections.
In order to be able to run several instancesof the reporter on one host (e.g. when one TaskManager is colocated with the JobManager) it is advisable to use a port range like 9250-9260
.
When a range is specified the actual port is shown in the relevant job or task manager log.
If this setting is set Flink will start an extra JMX connector for the given port/range.
Metrics are always available on the default local JMX interface.Example configuration:
Metrics exposed through JMX are identified by a domain and a list of key-properties, which together form the object name.
The domain always begins with org.apache.flink
followed by a generalized metric identifier. In contrast to the usual
identifier it is not affected by scope-formats, does not contain any variables and is constant across jobs.
An example for such a domain would be org.apache.flink.job.task.numBytesOut
.
The key-property list contains the values for all variables, regardless of configured scope formats, that are associated
with a given metric.
An example for such a list would be host=localhost,job_name=MyJob,task_name=MyTask
.
The domain thus identifies a metric class, while the key-property list identifies one (or multiple) instances of that metric.
In order to use this reporter you must copy /opt/flink-metrics-ganglia-1.5.1.jar
into the /lib
folder
of your Flink distribution.
Parameters:
host
- the gmond host address configured under udp_recv_channel.bind
in gmond.conf
port
- the gmond port configured under udp_recv_channel.port
in gmond.conf
tmax
- soft limit for how long an old metric should be retaineddmax
- hard limit for how long an old metric should be retainedttl
- time-to-live for transmitted UDP packetsaddressingMode
- UDP addressing mode to use (UNICAST/MULTICAST)Example configuration:
In order to use this reporter you must copy /opt/flink-metrics-graphite-1.5.1.jar
into the /lib
folder
of your Flink distribution.
Parameters:
host
- the Graphite server hostport
- the Graphite server portprotocol
- protocol to use (TCP/UDP)Example configuration:
In order to use this reporter you must copy /opt/flink-metrics-prometheus-1.5.1.jar
into the /lib
folder
of your Flink distribution.
Parameters:
port
- (optional) the port the Prometheus exporter listens on, defaults to 9249. In order to be able to run several instances of the reporter on one host (e.g. when one TaskManager is colocated with the JobManager) it is advisable to use a port range like 9250-9260
.Example configuration:
Flink metric types are mapped to Prometheus metric types as follows:
| Flink | Prometheus | Note |
|---|---|---|
| Counter | Gauge | Prometheus counters cannot be decremented. |
| Gauge | Gauge | Only numbers and booleans are supported. |
| Histogram | Summary | Quantiles .5, .75, .95, .98, .99 and .999 |
| Meter | Gauge | The gauge exports the meter’s rate. |
All Flink metrics variables (see List of all Variables) are exported to Prometheus as labels.
In order to use this reporter you must copy /opt/flink-metrics-statsd-1.5.1.jar
into the /lib
folder
of your Flink distribution.
Parameters:
host
- the StatsD server hostport
- the StatsD server portExample configuration:
In order to use this reporter you must copy /opt/flink-metrics-datadog-1.5.1.jar
into the /lib
folder
of your Flink distribution.
Note any variables in Flink metrics, such as <host>
, <job_name>
, <tm_id>
, <subtask_index>
, <task_name>
, and <operator_name>
,
will be sent to Datadog as tags. Tags will look like host:localhost
and job_name:myjobname
.
Parameters:
apikey
- the Datadog API keytags
- (optional) the global tags that will be applied to metrics when sending to Datadog. Tags should be separated by comma onlyExample configuration:
In order to use this reporter you must copy /opt/flink-metrics-slf4j-1.5.1.jar
into the /lib
folder
of your Flink distribution.
Example configuration:
By default Flink gathers several metrics that provide deep insights on the current state. This section is a reference of all these metrics.
The tables below generally feature 5 columns:
The “Scope” column describes which scope format is used to generate the system scope. For example, if the cell contains “Operator” then the scope format for “metrics.scope.operator” is used. If the cell contains multiple values, separated by a slash, then the metrics are reported multiple times for different entities, like for both job- and taskmanagers.
The (optional)”Infix” column describes which infix is appended to the system scope.
The “Metrics” column lists the names of all metrics that are registered for the given scope and infix.
The “Description” column provides information as to what a given metric is measuring.
The “Type” column describes which metric type is used for the measurement.
Note that all dots in the infix/metric name columns are still subject to the “metrics.delimiter” setting.
Thus, in order to infer the metric identifier:
| Scope | Infix | Metrics | Description | Type |
|---|---|---|---|---|
| Job-/TaskManager | Status.JVM.CPU | Load | The recent CPU usage of the JVM. | Gauge |
| Time | The CPU time used by the JVM. | Gauge |
| Scope | Infix | Metrics | Description | Type |
|---|---|---|---|---|
| Job-/TaskManager | Status.JVM.Memory | Heap.Used | The amount of heap memory currently used (in bytes). | Gauge |
| Heap.Committed | The amount of heap memory guaranteed to be available to the JVM (in bytes). | Gauge | ||
| Heap.Max | The maximum amount of heap memory that can be used for memory management (in bytes). | Gauge | ||
| NonHeap.Used | The amount of non-heap memory currently used (in bytes). | Gauge | ||
| NonHeap.Committed | The amount of non-heap memory guaranteed to be available to the JVM (in bytes). | Gauge | ||
| NonHeap.Max | The maximum amount of non-heap memory that can be used for memory management (in bytes). | Gauge | ||
| Direct.Count | The number of buffers in the direct buffer pool. | Gauge | ||
| Direct.MemoryUsed | The amount of memory used by the JVM for the direct buffer pool (in bytes). | Gauge | ||
| Direct.TotalCapacity | The total capacity of all buffers in the direct buffer pool (in bytes). | Gauge | ||
| Mapped.Count | The number of buffers in the mapped buffer pool. | Gauge | ||
| Mapped.MemoryUsed | The amount of memory used by the JVM for the mapped buffer pool (in bytes). | Gauge | ||
| Mapped.TotalCapacity | The number of buffers in the mapped buffer pool (in bytes). | Gauge |
| Scope | Infix | Metrics | Description | Type |
|---|---|---|---|---|
| Job-/TaskManager | Status.JVM.Threads | Count | The total number of live threads. | Gauge |
| Scope | Infix | Metrics | Description | Type |
|---|---|---|---|---|
| Job-/TaskManager | Status.JVM.GarbageCollector | <GarbageCollector>.Count | The total number of collections that have occurred. | Gauge |
| <GarbageCollector>.Time | The total time spent performing garbage collection. | Gauge |
| Scope | Infix | Metrics | Description | Type |
|---|---|---|---|---|
| Job-/TaskManager | Status.JVM.ClassLoader | ClassesLoaded | The total number of classes loaded since the start of the JVM. | Gauge |
| ClassesUnloaded | The total number of classes unloaded since the start of the JVM. | Gauge |
| Scope | Infix | Metrics | Description | Type |
|---|---|---|---|---|
| TaskManager | Status.Network | AvailableMemorySegments | The number of unused memory segments. | Gauge |
| TotalMemorySegments | The number of allocated memory segments. | Gauge | ||
| Task | buffers | inputQueueLength | The number of queued input buffers. | Gauge |
| outputQueueLength | The number of queued output buffers. | Gauge | ||
| inPoolUsage | An estimate of the input buffers usage. | Gauge | ||
| outPoolUsage | An estimate of the output buffers usage. | Gauge | ||
| Network.<Input|Output>.<gate> (only available if taskmanager.net.detailed-metrics config option is set) |
totalQueueLen | Total number of queued buffers in all input/output channels. | Gauge | |
| minQueueLen | Minimum number of queued buffers in all input/output channels. | Gauge | ||
| maxQueueLen | Maximum number of queued buffers in all input/output channels. | Gauge | ||
| avgQueueLen | Average number of queued buffers in all input/output channels. | Gauge |
| Scope | Metrics | Description | Type |
|---|---|---|---|
| Job (only available on JobManager) | restartingTime | The time it took to restart the job, or how long the current restart has been in progress (in milliseconds). | Gauge |
| uptime |
The time that the job has been running without interruption.
Returns -1 for completed jobs (in milliseconds). |
Gauge | |
| downtime |
For jobs currently in a failing/recovering situation, the time elapsed during this outage.
Returns 0 for running jobs and -1 for completed jobs (in milliseconds). |
Gauge | |
| fullRestarts | The total number of full restarts since this job was submitted (in milliseconds). | Gauge |
| Scope | Metrics | Description | Type |
|---|---|---|---|
| Job (only available on JobManager) | lastCheckpointDuration | The time it took to complete the last checkpoint (in milliseconds). | Gauge |
| lastCheckpointSize | The total size of the last checkpoint (in bytes). | Gauge | |
| lastCheckpointExternalPath | The path where the last external checkpoint was stored. | Gauge | |
| lastCheckpointRestoreTimestamp | Timestamp when the last checkpoint was restored at the coordinator (in milliseconds). | Gauge | |
| lastCheckpointAlignmentBuffered | The number of buffered bytes during alignment over all subtasks for the last checkpoint (in bytes). | Gauge | |
| numberOfInProgressCheckpoints | The number of in progress checkpoints. | Gauge | |
| numberOfCompletedCheckpoints | The number of successfully completed checkpoints. | Gauge | |
| numberOfFailedCheckpoints | The number of failed checkpoints. | Gauge | |
| totalNumberOfCheckpoints | The number of total checkpoints (in progress, completed, failed). | Gauge | |
| Task | checkpointAlignmentTime | The time in nanoseconds that the last barrier alignment took to complete, or how long the current alignment has taken so far (in nanoseconds). | Gauge |
| Scope | Metrics | Description | Type |
|---|---|---|---|
| Job (only available on TaskManager) | <source_id>.<source_subtask_index>.<operator_id>.<operator_subtask_index>.latency | The latency distributions from a given source subtask to an operator subtask (in milliseconds). | Histogram |
| Task | numBytesInLocal | The total number of bytes this task has read from a local source. | Counter |
| numBytesInLocalPerSecond | The number of bytes this task reads from a local source per second. | Meter | |
| numBytesInRemote | The total number of bytes this task has read from a remote source. | Counter | |
| numBytesInRemotePerSecond | The number of bytes this task reads from a remote source per second. | Meter | |
| numBytesOut | The total number of bytes this task has emitted. | Counter | |
| numBytesOutPerSecond | The number of bytes this task emits per second. | Meter | |
| Task/Operator | numRecordsIn | The total number of records this operator/task has received. | Counter |
| numRecordsInPerSecond | The number of records this operator/task receives per second. | Meter | |
| numRecordsOut | The total number of records this operator/task has emitted. | Counter | |
| numRecordsOutPerSecond | The number of records this operator/task sends per second. | Meter | |
| numLateRecordsDropped | The number of records this operator/task has dropped due to arriving late. | Counter | |
| currentInputWatermark |
The last watermark this operator/tasks has received (in milliseconds).
Note: For operators/tasks with 2 inputs this is the minimum of the last received watermarks. |
Gauge | |
| Operator | currentInput1Watermark |
The last watermark this operator has received in its first input (in milliseconds).
Note: Only for operators with 2 inputs. |
Gauge |
| currentInput2Watermark |
The last watermark this operator has received in its second input (in milliseconds).
Note: Only for operators with 2 inputs. |
Gauge | |
| currentOutputWatermark | The last watermark this operator has emitted (in milliseconds). | Gauge | |
| numSplitsProcessed | The total number of InputSplits this data source has processed (if the operator is a data source). | Gauge |
| Scope | Metrics | User Variables | Description | Type |
|---|---|---|---|---|
| Operator | commitsSucceeded | n/a | The total number of successful offset commits to Kafka, if offset committing is turned on and checkpointing is enabled. | Counter |
| Operator | commitsFailed | n/a | The total number of offset commit failures to Kafka, if offset committing is turned on and checkpointing is enabled. Note that committing offsets back to Kafka is only a means to expose consumer progress, so a commit failure does not affect the integrity of Flink's checkpointed partition offsets. | Counter |
| Operator | committedOffsets | topic, partition | The last successfully committed offsets to Kafka, for each partition. A particular partition's metric can be specified by topic name and partition id. | Gauge |
| Operator | currentOffsets | topic, partition | The consumer's current read offset, for each partition. A particular partition's metric can be specified by topic name and partition id. | Gauge |
| Scope | Metrics | User Variables | Description | Type |
|---|---|---|---|---|
| Operator | millisBehindLatest | stream, shardId | The number of milliseconds the consumer is behind the head of the stream, indicating how far behind current time the consumer is, for each Kinesis shard. A particular shard's metric can be specified by stream name and shard id. A value of 0 indicates record processing is caught up, and there are no new records to process at this moment. A value of -1 indicates that there is no reported value for the metric, yet. | Gauge |
Flink allows to track the latency of records traveling through the system. To enable the latency tracking
a latencyTrackingInterval
(in milliseconds) has to be set to a positive value in the ExecutionConfig
.
At the latencyTrackingInterval
, the sources will periodically emit a special record, called a LatencyMarker
.
The marker contains a timestamp from the time when the record has been emitted at the sources.
Latency markers can not overtake regular user records, thus if records are queuing up in front of an operator,
it will add to the latency tracked by the marker.
Note that the latency markers are not accounting for the time user records spend in operators as they are bypassing them. In particular the markers are not accounting for the time records spend for example in window buffers. Only if operators are not able to accept new records, thus they are queuing up, the latency measured using the markers will reflect that.
All intermediate operators keep a list of the last n
latencies from each source to compute
a latency distribution.
The sink operators keep a list from each source, and each parallel source instance to allow detecting
latency issues caused by individual machines.
Currently, Flink assumes that the clocks of all machines in the cluster are in sync. We recommend setting up an automated clock synchronisation service (like NTP) to avoid false latency results.
Metrics can be queried through the Monitoring REST API.
Below is a list of available endpoints, with a sample JSON response. All endpoints are of the sample form http://hostname:8081/jobmanager/metrics
, below we list only the path part of the URLs.
Values in angle brackets are variables, for example http://hostname:8081/jobs/<jobid>/metrics
will have to be requested for example as http://hostname:8081/jobs/7684be6004e4e955c2a558a9bc463f65/metrics
.
Request metrics for a specific entity:
/jobmanager/metrics
/taskmanagers/<taskmanagerid>/metrics
/jobs/<jobid>/metrics
/jobs/<jobid>/vertices/<vertexid>/subtasks/<subtaskindex>
Request metrics aggregated across all entities of the respective type:
/taskmanagers/metrics
/jobs/metrics
/jobs/<jobid>/vertices/<vertexid>/subtasks/metrics
Request metrics aggregated over a subset of all entities of the respective type:
/taskmanagers/metrics?taskmanagers=A,B,C
/jobs/metrics?jobs=D,E,F
/jobs/<jobid>/vertices/<vertexid>/subtasks/metrics?subtask=1,2,3
Request a list of available metrics:
GET /jobmanager/metrics
Request the values for specific (unaggregated) metrics:
GET taskmanagers/ABCDE/metrics?get=metric1,metric2
Request aggregated values for specific metrics:
GET /taskmanagers/metrics?get=metric1,metric2
Request specific aggregated values for specific metrics:
GET /taskmanagers/metrics?get=metric1,metric2&agg=min,max
Metrics that were gathered for each task or operator can also be visualized in the Dashboard. On the main page for a
job, select the Metrics
tab. After selecting one of the tasks in the top graph you can select metrics to display using
the Add Metric
drop-down menu.
<subtask_index>.<metric_name>
.<subtask_index>.<operator_name>.<metric_name>
.Each metric will be visualized as a separate graph, with the x-axis representing time and the y-axis the measured value. All graphs are automatically updated every 10 seconds, and continue to do so when navigating to another page.
There is no limit as to the number of visualized metrics; however only numeric metrics can be visualized.


Untitled Blog
: Setup
Local directory
Parent directory does not exist.
Remote server
Remote directory
Remote user name
Remote password


Many years ago I wrote a fairly straight-forward port of Python’s doctest to Javascript. I thought it was cool, but I didn’t really talk about it that much. Especially because I knew it had one fatal flaw: it was very unfriendly towards programming with callbacks, and Javascript uses a lot of callbacks.
On a recent flight I decided to look at it again, and realized fixing that one flaw wasn’t actually a big deal. So now doctest.js really works. And I think it works well: doctest.js.
I have yet to really use doctest.js on more than a couple real cases, and as I do (or you do?) I expect to tweak it more to make it flow well. But having tried a couple of examples I am particularly liking how it can be used with callbacks.
Testing with callbacks is generally a tricky thing. You want to make assertions, but they happen entirely separately from the test runner’s own loop, and your callbacks may not run at all if there’s a failure.
I came upon some tests recently that used Jasmine, a BDD-style test framework. I’m not a big fan of BDD but I’m fairly new to serious Javascript development so I’m trying to withhold judgement. The flow of the tests is a bit peculiar until you realize that it’s for async reasons. I’ll try to show something that roughly approximates a real test of an XMLHttpRequest API call:
it("should give us no results", function() {
runs(function () {
var callback = createSpy('callback for results');
$.ajax({
url: '/search',
data: {q: "query unlikely to match anything"},
dataType: "json",
success: callback
});
});
waits(someTimeout);
runs(function () {
expect(callback).toHaveBeenCalled();
expect(callback.mostRecentCall.args[0].length).toEqual(0);
});
});
So, the basic pattern is it() creates a group of tests, and each call to run() is a set of items to call sequentially. Then between these run blocks you can have signals to the runner to wait for some result, either a timeout (which is fragile), or you can setup specific conditions.
Another popular test runner is QUnit; it’s popular particularly because it’s what jQuery uses, and my own impression is that QUnit is just very simple and so least likely to piss you off.
QUnit has its own style for async:
test("should give us no results", function () {
stop();
expect(1);
$.ajax({
url: '/search',
data: {q: "query unlikely to match anything"},
dataType: "json",
success: function (result) {
ok(result.length == 0, 'No results');
start();
}
});
});
stop() confused me for a bit until I realized what they were really referring to stopping the test runner; of course the function continues on regardless. What will happen is that the function will return, but nothing will have really been tested — the success callback will not have been run, and cannot run until all Javascript execution stops and control is given back to the browser. So the test runner will use setTimeout to let time pass before the test continues. In this case it will continue once start() is called. And expect() also makes it fail if it didn’t get at least one assertion during that interval — it would otherwise be easy to simply miss an assertion (though in this example it would be okay because if the success callback isn’t invoked then start() will never be called, and the runner will timeout and signal that as a failure).
So… now for doctest.js. Note that doctest.js isn’t "plain" Javascript, it looks like what an interactive Javascript session might look like (I’ve used shell-style prompts instead of typical console prompts, because the consoles didn’t exist when first I wrote this, and because >>>/... kind of annoy me anyway).
$ success = Spy('success', {writes: true});
$ $.ajax({
> url: '/search',
> data: {q: "query unlikely to match anything"},
> dataType: "json",
> success: success.func
> });
$ success.wait();
success([])
With doctest.js you still get a fairly linear feel — it’s similar to how Jasmine works, except every $ prompt is potentially a place where the loop can be released so something async can happen. Each prompt is equivalent to run() (though unless you call wait, directly or indirectly, everything will run in sequence).
There’s also an implicit assertion for each stanza, which is anything that is written must be matched ({writes: true} makes the spy/mock object write out any invocations). This makes it much harder to miss something in your tests.
Update: just for the record, doctest has changed some, and while that example still works, this would be the "right" way to do it now:
$.ajax({
url: '/search',
data: {q: "query unlikely to match anything"},
dataType: "json",
success: Spy("search.success", {wait: true, ignoreThis: true})
});
// => search.success([])
There is a new format that I now prefer with plain Javascript and "expected output" in comments. Spy("search.success", {wait: true, ignoreThis: true}) causes the test to wait on the Spy immediately (though the same pattern as before is also possible and sometimes preferable), and in all likelihood jQuery will set this to something we don’t care about, so ignoreThis: true keeps it from being printed. (Or maybe you are interested in it, in which case you’d leave that out)
Anyway, back to the original conclusion (update over)…
I’ve never actually found Python’s doctest to be a particularly good way to write docs, and I don’t expect any different from doctest.js, but I find it a very nice way to write and run tests… and while Python’s doctest is essentially abandoned and lacks many features to make it a more humane testing environment, maybe doctest.js can do better.
Automatically generated list of related posts:
- Doctest for Ruby Finally, someone wrote a version of doctest for Ruby. Recently...
- A Doctest Wishlist Lately I’ve been doing most of my testing with doctest,...
- Atom Models I’ve been doing a bit more with Atom lately. First,...
- Java BDD I notice there’s another Behavior Driven Development framework for Java...
Hi Ian,
let me first thank you for the information you share with us on your blog. I come here on a regular basis and always I find something new.
I am going to look into doctest.js over the upcomming weekend. As far as I remeber you are also a user of nosetests. I am currently working on a codebasis which is 80% Python and 20% JavaScript. So I want to integrate my JavaScript tests into the “python setup.py nosetests” testrun. What could be the simplest way to do that? Use the NoseJS plugin or integrating Qunit if this is possible…?
Cheers, Mark
I haven’t really explored unattended testing with Javascript, but I’d be curious what you find.
After hours of reading through posts and manuals I think I have now a far better picture of what is available. I will try out node.js for the testing. There is even node-qunit available which looks promising.
I still want to run the tests from python. Do you know if someone build a Python – Node.js bridge? So far I could not find something like that.


Bison Hacks Live Site
Starting Soon
{{ displayStartTime }}
Now
{{displayEvent.name}}
@
{{displayEvent.location}}
Amira
Safety Net
Where it Matters!
Mecca Analytics
MoM
ShareEat
The Hub
CryptoTracker
HealthyEatOut
CreditGoogles
POPout
Tourista


160708.bib
@article{KAWASAKI1997177,
title = {Modeling Spatio-Temporal Patterns Generated byBacillus
subtilis},
journal = {Journal of Theoretical Biology},
volume = {188},
number = {2},
pages = {177--185},
year = {1997},
note = {},
issn = {0022-5193},
doi = {http://dx.doi.org/10.1006/jtbi.1997.0462},
url = {http://www.sciencedirect.com/science/article/pii/S0022519397904628},
author = {K. Kawasaki and A. Mochizuki and M. Matsushita and T.
Umeda and N. Shigesada},
abstract = {Colonies of bacteria,Bacillus subtilis, that grow on
the surface of thin agar plates show various
morphological patterns in response to environmental
conditions, such as the nutrient concentration, the
solidity of an agar medium and temperature. For
instance, the colony pattern shows a dense-branching
morphology with a smooth circular envelope (DBM-like)
in a nutrient-poor semi-solid agar medium, and it turns
to a simple disk-like colony as both the nutrient
concentration and the agar's softness increase. These
patterns have been shown to involve cell movement
inside colonies. In a DBM-like colony, individual cells
actively move, particularly in the expanding periphery
of the colony, while they become immotile at the inner
region of the colony where nutrient is very low. In a
disk-like colony, cells are highly active in the whole
region of the colony. Based on such experimental
observations, we develop a diffusion-reaction model, in
which density dependent cell movements are incorporated
by the level of nutrient concentration available for
the cell. Numerical simulations of the model under
different environmental conditions closely reproduce
various colony patterns ranging from DBM-like pattern
to the homogeneous disk-like one in a unifying manner.
The analysis also predicts the growth velocity of a
colony as a function of the nutrient concentration.}
}
@article{doi:10.7566/JPSJ.84.114002,
author = {Ryojiro Honda and Jun-ichi Wakita and Makoto Katori},
title = {Self-Elongation with Sequential Folding of a Filament
of Bacterial Cells},
journal = {Journal of the Physical Society of Japan},
volume = {84},
number = {11},
pages = {114002},
year = {2015},
doi = {10.7566/JPSJ.84.114002},
url = {http://dx.doi.org/10.7566/JPSJ.84.114002},
eprint = {http://dx.doi.org/10.7566/JPSJ.84.114002}
}
@article{PhysRevE.52.5297,
title = {Lattice-gas model for collective biological motion},
author = {Zolt\'an Csah\'ok and Tam\'as Vicsek},
journal = {Phys. Rev. E},
volume = {52},
issue = {5},
pages = {5297--5303},
numpages = {0},
year = {1995},
month = nov,
publisher = {American Physical Society},
doi = {10.1103/PhysRevE.52.5297},
url = {http://link.aps.org/doi/10.1103/PhysRevE.52.5297}
}


+919059332123
better education for better world
education is a journey not a race
character is a wish for a perfect education
Edifying


Preparation time
less than 30 mins
Cooking time
30 mins to 1 hour
Serves
Serves 4
You'll need to take a trip to an oriental supermarket to find all the ingredients for this seafood stir-fry.
Separate the crab head from the body. Discard the dead man’s fingers. Cut the body into four pieces. Cut off the claws and split them without removing the meat. Cut the head into two, reserving any juice from the crab.
For the chilli and black bean paste, blend all the ingredients together in a food processor to form a paste.
For the pepper and chilli paste, place the ginger, garlic, coriander roots, fresh turmeric, green peppercorns, caster sugar and dried chilli in a pestle and mortar. Pound to form a paste.
To prepare the garnish, separate the greens from the whites of the Chinese chives and coriander. Keep separate and chop.
Heat a wok until hot, add a glug of vegetable oil. Briefly fry the black bean chilli paste followed by the pepper and chilli paste. Cook the ginger with the whites of the Chinese chives. Add the crab pieces and toss in the sauce. Add the whites of the coriander and the sugar, fish sauce and vinegar. Add any reserved crab juices and the greens from Chinese chives and Chinese coriander. Garnish with the remaining herbs.


| Total net profit | -16.64 | Gross profit | 6.28 | Gross loss | -22.92 |
| Profit factor | 0.27 | Expected payoff | -1.19 | ||
| Absolute drawdown | -16.64 | Maximal drawdown (%) | 14.97 (-896.41%) | ||
| Total trades | 14 | Profit trades (% of total) | 3 (21.43%) | Loss trades (% of total) | 11 (78.57%) |
| Long positions (won %) | 2 (0.0%) | Short positions (won %) | 12 (25.0%) | ||
| Largest | profit trade | 5.32 | loss trade | -2.47 | |
| Average | profit trade | 2.09 | loss trade | -2.08 | |
| Minimum | profit trade | 0.37 | loss trade | -0.49 | |
| Maximum | take profit in pips | 74.7 | stop loss in pips | -38.2 | |
| Average | take profit in pips | 29.6 | stop loss in pips | -31.0 | |
| Minimum | take profit in pips | -2.7 | stop loss in pips | -27.4 | |
| Maximum | Reward-Risk | 2.5 | Duration in minutes | 7203 | |
| Average | Reward-Risk | 1.0 | Duration in minutes | 966.1 | |
| Minimum | Reward-Risk | 0.0 | Duration in minutes | 4 | |
| Maximum | consecutive wins (profit in money) | 1.0 (0.59) | consecutive losses (loss in money) | 4.0 (-7.59) | |
| Average | consecutive wins | 1.0 | consecutive losses | 2.0 |
| Total net profit | -2.96 | Gross profit | 0.0 | Gross loss | -2.96 |
| Profit factor | 0.0 | Expected payoff | -1.48 | ||
| Absolute drawdown | -2.96 | Maximal drawdown (%) | 0.49 (-19.84%) | ||
| Total trades | 2 | Profit trades (% of total) | 0 (0.0%) | Loss trades (% of total) | 2 (100.0%) |
| Largest | profit trade | 0.0 | loss trade | -2.47 | |
| Average | profit trade | 0.0 | loss trade | -1.48 | |
| Minimum | profit trade | 0.0 | loss trade | -0.49 | |
| Maximum | take profit in pips | 8.6 | stop loss in pips | -38.2 | |
| Average | take profit in pips | 2.9 | stop loss in pips | -35.8 | |
| Minimum | take profit in pips | -2.7 | stop loss in pips | -33.4 | |
| Maximum | Reward-Risk | 0.3 | Duration in minutes | 180.0 | |
| Average | Reward-Risk | 0.1 | Duration in minutes | 92.0 | |
| Minimum | Reward-Risk | 0.0 | Duration in minutes | 4.0 | |
| Maximum | consecutive wins (profit in money) | 0.0 (0.0) | consecutive losses (loss in money) | 2.0 (-2.96) | |
| Average | consecutive wins | 0.0 | consecutive losses | 2.0 |
| Total net profit | -13.68 | Gross profit | 6.28 | Gross loss | -19.96 |
| Profit factor | 0.31 | Expected payoff | -1.14 | ||
| Absolute drawdown | -13.68 | Maximal drawdown (%) | 12.01 (-719.16%) | ||
| Total trades | 12 | Profit trades (% of total) | 3 (25.0%) | Loss trades (% of total) | 9 (75.0%) |
| Largest | profit trade | 5.32 | loss trade | -2.34 | |
| Average | profit trade | 2.09 | loss trade | -2.22 | |
| Minimum | profit trade | 0.37 | loss trade | -2.03 | |
| Maximum | take profit in pips | 74.7 | stop loss in pips | -32.8 | |
| Average | take profit in pips | 34.0 | stop loss in pips | -30.1 | |
| Minimum | take profit in pips | 4.9 | stop loss in pips | -27.4 | |
| Maximum | Reward-Risk | 2.5 | Duration in minutes | 7203.0 | |
| Average | Reward-Risk | 1.1 | Duration in minutes | 1111.8 | |
| Minimum | Reward-Risk | Duration in minutes | 28.0 | ||
| Maximum | consecutive wins (profit in money) | 1.0 (0.59) | consecutive losses (loss in money) | 3.0 (-6.37) | |
| Average | consecutive wins | 1.0 | consecutive losses | 2.0 |


When styling links with CSS, using something like border-bottom: 1px solid #f00
instead of text-decoration: underline
means more control over spacing, style (solid, dashed, dotted) and color. You might even use a background image for a fancy graphic underline.
With text-decoration
, linked images won’t get an underline unless there’s text in the same link. But with border-bottom
, they always get the border.
Since the border is on the a
element, not the image, you have to somehow find the a
elements based on their descendants. To my knowledge there is no CSS-only solution for that in modern browsers. Please let me know if I’m wrong.
The solution is simple with jQuery:
1
|
|
When the DOM becomes available, all links containing images get the image
class. You can then easily style them:
1 2 |
|
See it in action on my girlfriend’s new blog.
Since the page will still work fine without JavaScript, only look a little less attractive, I think this solution is quite acceptable, though a CSS-only solution would be better still.


Select this option if you want new files that have not been added to a VCS yet to be listed in the Commit Changes dialog.


This is a simple Akan name generator kindly fill in the required details below all of which are compulsary. The name originates from the Akan culture in Ghana where names are usually derived based on the day of birth and gender.


10th January 2018
Great news!
We have negotiated an extended 90 day license for you to use the IntelliJ Ultimate edition software from Jetbrains, the makers of IntelliJ. This is an extra 90 days of free access to this incredible tool.
Details on how to download and install this software are in this section of this course.
All you need to do to get your extended 90 day license is to email<EMAIL_ADDRESS>(note the email address carefully).
A Learn Programming Academy (LPA) team member will then reply with your unique coupon code, and a document explaining how you go about registering with Jetbrains on their website.
 This is a once off email to get the code to you, along with a PDF that contains the instructions you need. We won’t email you again after sending you the code!
Please note that LPA team members at that email address are not programmers, so are unable to to provide “support”. Please use the Q&A section of this course for any questions you may have.
Also note that you can still use the community edition of IntelliJ if you prefer, but I recommend you start off with IntelliJ Ultimate first.
Note: The LPA team works office hours (Australian time). Depending on the time of day or night in your part of the world, it might take 24-48 hours to get the coupon to you. In rare cases 72 hours. We do not make any commission out of giving you this code. We do it purely to give you an extended trial of IntelliJ for free. IntelliJ rocks our world.
NOTE: You already have a 30 day free trial when you download IntelliJ Ultimate. So there is no urgency to add the 90 day trial code. It will continue to work for 30 days, even without the code we will be sending you. In fact if you wait until your 30 day trial is ready to expire, you can apply the 90 day code at that time, to give you in total a 120 day trial!
In the meantime, you can go ahead and use the free community edition, or download the trial version of the Ultimate edition and get that 30 day trial while you wait for us to reply with the code. More info is in the IntelliJ video in this section of the course.
Enjoy!
regards
The LPA Team


This document strives to adhere to RFC 2119. In particular should be noted tat:
MUST This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.
MUST NOT This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification.
SHOULD This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
MAY This word, or the adjective “OPTIONAL”, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
Security Considerations
These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification.


--- layout: page title: Explanations permalink: /explanations/ inNav: 0 dropdownList: inRisk ---
What does risk really mean? The following is a list of pages on the site that try to address this question in different contexts.
{{ my_page.excerpt }}


{% load static %}
The full dataset is available in CSV format. Audio files can be downloaded from the accompanying URLs in the CSV.
Here are some sample audio files that have been submitted by Tarteel users: {% for file_url in file_urls %}
{% endfor %}


--- layout: archive title: Zulip Chat Archive permalink: /stream/113488-general/topic/symmetry.html ---
The symmetry
tactic won't turn a ≠ b
into b ≠ a
(at least it won't for my home-grown nats). This can be fixed with
attribute [symm] ne.symm
Unfortunately ne.symm
is in core so it's not so easy to tag it with this attribute. Is there a place in mathlib where this line could go?
data/logic.lean
?
That's imported by almost everything else, and it seems a fitting place.
{% endraw %}Last updated: Apr 24 2020 at 19:02 UTC


fade-in
Wait for it ...
fly-in-left + fade-in
twirl-in
fly-in-left
fly-in-right
fly-in-top
fly-in-bottom
rotate-in-left
rotate-in-right
drop-in
whoosh-in-left
whoosh-in-right
zoom-in
zoom-out
pan-left
pan-right
pan-up
pan-down


{% include favicon.html %} {% include style.html %}
Home
About Us
Products
Our Team
SMPV
Peptide
Science
Contact
{{ content }}


"ZABDI "gift of Jehovah. (1.) An ancestor of Achan (Joshua 7:1, 17, 18). He is probably the “Zimri” of 1 Chronicles 2:6. (2.) A Benjamite (1 Chronicles 8:19). (3.) Called “the Shiphmite,” one of David’s officers, who had charge of his vineyards (1 Chronicles 27:27). (4.) A Levite, one of the sons of Asaph (Nehemiah 11:17); probably the same as Zichri (1 Chronicles 9:15), and Zaccur (Nehemiah 12:35).
"ZABDI "gift of Jehovah. (1.) An ancestor of Achan (Joshua 7:1, 17, 18).
He is probably the “Zimri” of 1 Chronicles 2:6.
(2.) A Benjamite (1 Chronicles 8:19).
(3.) Called “the Shiphmite,” one of David’s officers, who had charge of his vineyards (1 Chronicles 27:27).
(4.) A Levite, one of the sons of Asaph (Nehemiah 11:17); probably the same as Zichri (1 Chronicles 9:15), and Zaccur (Nehemiah 12:35).


SCEs ionic lithium ceramic conductivity polymer Mater. electrolyte cathode Zhang high interface ion all‐solid‐state Energy Liu wt% Wang interfacial mAh Chen SCE cycles Chem. Copyright LiFePO composite metal Reproduced battery permission. fillers Adv. dendrite electrochemical LLZO contact ACS Figure anode performance structure Guo batteries Yang ions liquid resistance solid using application capacity electrolytes Li‐S layer room (Figure SCEs. Zhao cell Interfaces stable {border-style /LiTFSI LATP SCEs, Zhou membrane significant Appl. Chemical Sun Therefore, battery. density higher mechanical particles px;} quite transport #ffffff;} American LLTO LLZTO PEO PEO/LiTFSI Society. addition, developed migration nanowires suppress .La continuous energy good greatly ion‐conducting nanoparticles LAGP Lett. Li‐O Shen aligned current low surface Cui P(EO) Schematic Sci. applied batteries. conduction cycling different effectively reduce stability temperature Cheng ICEs Nano SPEs Shi practical Furthermore, Huang John Wiley Yao active ceramics co‐workers efficiency electrolyte. excellent framework growth growth. interfaces larger order pathway presents solid‐state Lee Li/Li Power Sources anode, cycle design high‐efficient lower matrix temperature. window °C. /LiClO Han Ionics Lin Soc. Solid Xie Zhu anode. improve large lithium‐ion phase present provide rate shows specific transfer LLZO‐P(EO) Li‐air conductive consisting construction enhance enhanced filler great mainly network novel particle pathways poor reaction research used /Li Kim Sons. Tsinghua University coulombic future illustration including inorganic integrated long promote px; results strength temperature, {font-family Dong Fan Gao However, LiNi Li‐ion Moreover, Nat. PAN/LiClO Shenzhen State Storage Wei Yan Yes Zheng achieve advantages b). channels charge/discharge chemical conductivity. construct develop discharge enhancement fabricated flexible font-size high‐voltage impedance interphase layers morphology rigid similar size soft uniform vol% .Mn Acta Ceramic Ding Electrochem. Electrochim. Gong ICEs, LiTFSI Liang Nan Rev. Science Song Table Tang Wan Zha a). as‐prepared bulk c). carbon cathode, charge constructing double; effective electric embedded form highly issues long‐range materials mechanism mixed preferentially reactions region reported resistance. resulting significance storage various versus volume wet .Co .Nb China Deng Eng. Environ. Generally, Goodenough Huo Ionic Issues Kang LLZO‐PEO LiClO Lithium Manthiram Meanwhile, PEO‐based PVDF/LiClO Pan Peng Remedies SCE, Tianjin Whereas, Xia Yin according anions batteries, battery, behavior border-color border-width chains commercial compared conductivity, constructed content. data development dispersed electrodes electrolyte, electrolytes. especially example, fast formation host improved interface. matrix. method obtained owing particles, phase, promising properties reduces researches solid; solve space strategy strength, sulfur systems template wide {font-style {font-weight µm) (C) (Li (weight Am. Angew. Batteries Cai Chem., Constructing Dai Dang Ed. Elsevier. Feng Graduate Guangdong ICEs. Int. Interfacial Janus Jin Langer NMR PAN PEO/LiClO PVDF Phys. Plan SCE. School SiO Tan Technical Wachsman Zuo activation adopted agglomeration alignment applications ascribed assembled as‐assembled bilayer bold cathode. compatible complex composition concentration conducting contact, courier; crucial demonstrated effect effects electrolytes, em; enable exhibit exhibits fabricate filler‐reinforced flux focused following formed garnet high‐performance high‐resolution hybrid impedance. important increase increases indicating interface, ion‐conductive isotope labeling materials, methods modified morphologies motion nanofiber nanosheets nanowires, networks nm) pellet performance. polarization polymer. potential power present, problems pt;} randomly ratio retention shown small special stability, steadily strategies strong suppression symmetric thermal thickness transportation transportation. typical voids voltage way °C, −),


SENIOR ADVOCATE OF NIGERIA BARR. PETER BROWN (SAN) TEL: 234-8042-138-545 E-MAIL<EMAIL_ADDRESS>Dear Friend , I am Barrister Peter Brown a member of Nigeria Bar Association (NBA).Your contact reached me through the World Business Encyclopaedia.Hence,I made up my mind to introduce this business to you in confidence for the mutual benefit of both of us. The sum of USD45M (Forty five Million United States) was lodged into a security company here in the Country by the late Head of State (GEN.SANI ABACHA) for safe-keeping. This money was lodged in security vaults / boxes and labelled as personal belongings and as such the security company does not know the true content of the boxes.This money was originally meant to be used for his political campaign. Because I was his family Attorney as such he confided in me with the relevant document papers relating to this deposit before he died of cardiac arrest. As a matter of fact we have concluded all arrangement with an offshore Security Company to move this money as a consignment through diplomatic means to their offshore affiliated office where you will be required to put claim to the consignment as the bonafide beneficiary of the consignment. You should know that this business is safety and 100% risk-free as it does not involve drug money or Terrorist fund. If you are interested to carry out this transaction with me, 20% will be for you for your assistance, 5% for general expenses, and 75% for us. You are required to send by e-mail immediately your Full name and Address, which I will use to draft an agreement that will guide and protect both of us in this transaction also which will be used to effect the change of ownership of the consignment to your name as the beneficiary of the consignment. Also send me your Telephone and Fax numbers for easy communication. Once you notify me your willingness by sending the above requirement.This transaction will be concluded within 7 (seven)working days. I will be waiting for your urgent reply.You can reach me on my Cell Telephone No: 234-8042-138-545 or my alternative E-mail<EMAIL_ADDRESS>Yours Faithfully, Barrister Peter Brown (SAN)


{% extends "layout.html" %} {% block page_title %} Example - Forms {% endblock %} {% block content %} {% include "includes/phase_banner_beta.html" %} {{formData | safe}} Where will the work happen? Where will the work happen? Address Building and street Town or city Country (optional) Postcode {% endblock %}


All ROS nodes for the package "camultiplex" are defined in this namespace. More...
Classes | |
| class | Drain_base |
| Interfaces with the file system. Converts sensor_msgs::Image into .jpg and .png format and stores them as images. More... | |
| class | Drain_independent |
| The non-nodelet version of Drain. More... | |
| class | Drain_nodelet |
| The nodelet version of of Drain. More... | |
| class | Source_base |
| Interfaces with the camera and publishes the image frames in the form of sensor_msgs::Image. More... | |
| class | Source_independent |
| The non-nodelet version of source. More... | |
| class | Source_nodelet |
| The nodelet version of source. More... | |
Variables | |
| const int | Default_drain_diversity = 3 |
| const int | Default_FPS = 60 |
| Default FPS value when no value was provided to rosrun or roslaunch. More... | |
| const std::string | Default_path = "/media/nvidia/ExtremeSSD" |
| const int | Default_source_diversity = 3 |
| const std::set< int > | Legal_FPS = {15, 30, 60, 90} |
| Acceptable FPS values supported by Intel RS435. More... | |
All ROS nodes for the package "camultiplex" are defined in this namespace.
When using the package "camultiplex" in practice to collect images from an Intel RS435 camera and store them in any filesystem, usually two nodes are involved: 1) a "source" that interfaces with the camera device, 2) a "drain" that interfaces with the file system. The "source" transforms the image frames into ROS-compatible format, transmits the packets across the ROS middleware infrastructure; the "drain" receives and restores the packets, then store them to the filesystem with .png or .jpg format.
Furthermore, depending on physical setup one may wish to run both nodes 1) on a single host or 2) on different hosts within a network.
In the case two nodes are run on the same host, it is more efficient to run them as nodelets which share the same memory space. This eliminates the overhead cause by TCP communication that is ubiquitous among any two "non-nodelet" nodes.
When two nodes are not run on the same host, however, TCP (or UDP) connection is the only solution. Nodelets are not possible.
Based on the reasoning described above, four different classes can be defined:
Drain_independent (non-nodelet)
It would turn out that for the drain- and the source-side, respectively, the difference between codes for the nodelet version and the independent version is very small but subtle. In order to promote code re-usability, two base classes that serve as common "anscestors" should be added:
The subtle difference between a nodelet and a non-nodelet is merely how they obtain their node handles. The base classes will implement 99% essential functionality but leave the methods that returns their (public) node handle and private node handle as pure virtual functions to be defined. Source_base and Drain_base, therefore, are abstract classes that cannot be instantiated.
Refer to external source for how node handles work: http://wiki.ros.org/roscpp/Overview/NodeHandles, http://wiki.ros.org/nodelet
| const int camera::Default_drain_diversity = 3 |
Definition at line 65 of file my_nodes.h.
| const int camera::Default_FPS = 60 |
Default FPS value when no value was provided to rosrun or roslaunch.
Definition at line 63 of file my_nodes.h.
| const std::string camera::Default_path = "/media/nvidia/ExtremeSSD" |
Definition at line 64 of file my_nodes.h.
| const int camera::Default_source_diversity = 3 |
Definition at line 66 of file my_nodes.h.
| const std::set<int> camera::Legal_FPS = {15, 30, 60, 90} |
Acceptable FPS values supported by Intel RS435.
Definition at line 62 of file my_nodes.h.


Telford paedophile booked hotel room for '13-year-old girl' in vigilante sting
by Nick HumphreysA Telford paedophile who booked a hotel room for what he believed was a 13-year-old girl was caught by vigilantes after going to meet her at McDonald’s.
Steven Frederick Jackson, 57, sent messages to the ‘girl’ over the course of six weeks in February and March last year.
Over the course of the communication, the decoy, an adult woman, constantly reminded him she was aged 13, but Jackson continued to send messages.
Prosecutor Wendy Miller told Shrewsbury Crown Court: “He made references to her bottom, said she could be a model and that he wanted to kiss her.
“He was messaging her nearly on a daily basis and asked her to send photos.
“He said he wished he was the same age as her and that he wanted a relationship.
“He later said she should block him because he had dangerous ideas.”
But the messages didn’t stop, and Jackson booked a hotel room in Derby, asked her if she was bringing her pyjamas and arranged to meet her at McDonald’s.
Motivations
At this point the decoy handed the information to police. She arrived at the fast food restaurant with two men to confront Jackson. He was then arrested.

Kevin Jones, defending, said: “It aggravates everything when there are hotel rooms booked and plans made.
“This is a man who has extremely low self-esteem and has had problems with relationships in the past.
"He was seeking some sort of comfort from this contact.”
Judge Peter Barrie told Jackson: “It is clear that there were sexual motivations behind the arrangement.
"You had been messaging her for six weeks to try and form a bond.”
He sentenced Jackson to a community order for 24 months, 45 rehabilitation days, 80 hours unpaid work and ordered him to go on a sexual offenders prevention programme.


| JIRA | Summary | Priority | Component | Reporter | Contributor |
|---|---|---|---|---|---|
| FALCON-47 | Falcon Replication should support configurable delays in feed, parallel, timeout and bulk transfer with variable frequency | Major | . | Shaik Idris Ali | Shaik Idris Ali |
| JIRA | Summary | Priority | Component | Reporter | Contributor |
|---|---|---|---|---|---|
| FALCON-10 | Add findbugs plugin and fix findbugs warnings for project | Major | . | Venkatesh Seetharam | Venkatesh Seetharam |
| FALCON-13 | super pom must reflect license, project website, ML and SCM changes post incubation | Minor | general | Venkatesh Seetharam | Venkatesh Seetharam |
| FALCON-33 | Add patch files to RAT ignore list | Trivial | general | Jarek Jarcec Cecho | Jarek Jarcec Cecho |
| FALCON-4 | Propose logo for Apache Falcon | Major | . | Amareshwari Sriramadasu | |
| FALCON-23 | Add website for Falcon | Major | general | Venkatesh Seetharam | Srikanth Sundarrajan |
| FALCON-29 | Add ability to tag/classify data sets and processes to enable discovery | Trivial | feed, process | Venkatesh Seetharam | Venkatesh Seetharam |
| FALCON-1 | Create packaging and scripts to install and try out Apache Falcon | Critical | . | Srikanth Sundarrajan | Srikanth Sundarrajan |
| FALCON-32 | Store test output in file rather then printing all the output into the console | Trivial | general | Jarek Jarcec Cecho | Srikanth Sundarrajan |
| FALCON-30 | Enable embedding pig scripts directly in a process | Major | process | Venkatesh Seetharam | Venkatesh Seetharam |
| FALCON-151 | Document the REST APIs for Falcon | Minor | docs | Venkatesh Seetharam | Raghav Kumar Gautam |
| JIRA | Summary | Priority | Component | Reporter | Contributor |
|---|---|---|---|---|---|
| FALCON-22 | Rename ivory to falcon in project | Trivial | general | Venkatesh Seetharam | Venkatesh Seetharam |
| FALCON-31 | File Installation-steps.txt contains old path to repository | Trivial | general | Jarek Jarcec Cecho | Jarek Jarcec Cecho |
| FALCON-8 | http://incubator.apache.org/falcon does not work | Critical | general | Nikhil Mulley | Venkatesh Seetharam |
| FALCON-34 | Minor corrections to falcon site | Trivial | general | Srikanth Sundarrajan | Srikanth Sundarrajan |
| FALCON-40 | Dead link on Getting Started page | Minor | docs | Ashish Paliwal | Srikanth Sundarrajan |
| FALCON-45 | Architecture diagram in Site / Docs still refer to Ivory | Major | docs, general | Srikanth Sundarrajan | Srikanth Sundarrajan |
| FALCON-41 | Update Ivory references in images to Falcon on Architecture page | Major | docs | Ashish Paliwal | Srikanth Sundarrajan |
| FALCON-46 | Flacon's instance retry service may hang because of an issue in InMemoryQueue | Critical | rerun | Shaik Idris Ali | Shaik Idris Ali |
| FALCON-49 | Dependency on oozie-client pulls in hadoop-auth-0.23.1 which is not necessary | Minor | oozie | Venkatesh Seetharam | Venkatesh Seetharam |
| FALCON-52 | Main module configured used with jetty:run has issues with app start | Major | . | Srikanth Sundarrajan | Srikanth Sundarrajan |
| FALCON-55 | Update suspends old oozie coords | Major | . | Shwetha G S | Shwetha G S |
| FALCON-56 | Update Falcon packing to include all source files | Major | general | Srikanth Sundarrajan | Srikanth Sundarrajan |
| FALCON-57 | Build fails if the source is not in scm | Trivial | general | Srikanth Sundarrajan | Srikanth Sundarrajan |
| FALCON-53 | Add -incubating to the version | Trivial | . | Jarek Jarcec Cecho | Jarek Jarcec Cecho |
| FALCON-58 | Gaps in release source / binary tarball | Trivial | . | Srikanth Sundarrajan | Srikanth Sundarrajan |
| FALCON-65 | Avoid bundling compilation path dependent configs in artifact and allow for config scan to seamlessly fallback to classpath if not found in default conf location | Major | general | Srikanth Sundarrajan | Srikanth Sundarrajan |
| JIRA | Summary | Priority | Component | Reporter | Contributor |
|---|---|---|---|---|---|
| FALCON-19 | Bump up the release version to 0.3-SNAPSHOT | Minor | general | Venkatesh Seetharam | Srikanth Sundarrajan |
| FALCON-44 | Update link to Wiki from placeholder to real wiki | Major | . | Ashish Paliwal | Srikanth Sundarrajan |
| FALCON-70 | Confirm if v0.3 branch is ready for release as per http://incubator.apache.org/guides/releasemanagement.html | Major | general | Srikanth Sundarrajan | Venkatesh Seetharam |