The current implementation of PrototypeJungle is a proof of concept. The core functionalities - the object model, the instantiation operation, the component system, the framework for geometry and rendering - are complete and well tested. However, the libraries of basic shapes and infographic elements are very sparse, the UI needs polish and extension, and documentation exists only for the conceptual level, not for the details. As a result, the system is unlikely to have immediate utility for most infographic projects. The question is, do the core capabilites represent something that, if propagated by filling in the sketches at the other levels, would be useful? I think so, since the output of coding effort in PrototypeJungle will have more flexibility in its use by non-programmers than is the case for previous approaches.
To start experimenting with the system immediately, you can execute and modify code examples in the scratch pad: two rectangles and barchart. No sign in is required. You can also try a sample build, which allows you to create items that can be subsequently inspected and edited. For this purpose, you will need to sign in (no registration is needed; you can sign in with your email or twitter account). Here is another sample build with different init
A PrototypeJungle application takes the form of a JavaScript property/value tree where nodes are sometimes connected by prototype chains, and where the leaves may be of any primitive type. Functions may appear in the tree, but only as leaves.
Somewhat more precisely:
1) Start with the ordinary notion of a JavaScript tree, the kind that is expressable in JSON, but allowing, unlike JSON, functions as leaves. (Click here for a graph-theoretic definition)
2) Next, allow prototype chains in the tree. This places another sort of graph over the first. It has the same nodes as the original tree, but a new set of edges - edges which join nodes A and B if B is the prototype of A. This second graph is acyclic too, but is rarely connected.
3) For algorithmic ease, add special properties __name__ and __parent__, where if the value of P on A is B, and B is a non-null object, B.__name__ === P, and B.__parent__ === A. Then algorithms can run efficiently up and down trees starting at any node. The minor caveat is needed that the result remains a tree if these internal properties are excluded
Done! The above steps define a restriction on the set of all possible JavaScript objects. I will refer to objects which satisfy these restrictions, loosely but concisely, as "Prototype Trees".
Prototype trees have the following virtues.
The code base defines exactly one global variable, prototypeJungle. Beneath prototypeJungle are the modules:
Code files generally specialize in one module or another, but sometimes add to more than one module.
It is convenient to implement Prototype trees in such a way that internal nodes inherit from prototypes om.LNode (list node) for arrays, and om.DNodes (dictionary node, for objects which are not arrays). This avoids polluting basic JavaScript namespaces, and leaves the result in compliance with the definitions given above.
Tree primitives:
om.DNode.mk();
creates a new DNode, and
om.LNode.mk();
a new LNode.
dpr.set(nm,ch);
Assigns ch as the child named nm of pr (a DNode). Then ch.parent() == dpr, ch.name() == nm, and pr[nm] == ch (child selection on DNodes is ordinary property selection)
lpr.pushChild(ch);
Pushes ch onto the end of the LNode lpr, and assigns lpr as the parent of ch. Then, lpr[lpr.length-1] == ch, ch.name() == lpr.length-1, and ch.parent() == lpr.
om.lift(obj);
Takes an "ordinary" Javascript tree, and turns it into om tree. Example:
om.lift({a:2,b:["a",4]});
will produce a DNode/LNode tree with matching structure. We will sometimes use the word "item" in what follows to refer to a DNode/LNode tree.
Click here for an example.
var om = prototypeJungle.om;
var root = om.DNode.mk();
var aa = om.DNode.mk();
var bb = om.LNode.mk();
root.set("a",aa); // adds aa as a child named "a" of root
root.set("b",bb);
// introducing the basic operations name and parent:
bb.name();
==>b
bb.parent() == root;
==>true
// let's add some atomic data
aa.x = 5; // set is not needed for atomic data
aa.f = function (x) {return x*x;}
// now for an LNode
var cc = om.LNode.mk();
cc.pushChild(om.DNode.mk().set("z",45));
cc.pushChild(5);
this yields:
--root--
/ \
a b
/ \
* [ *, 5]
/ \ /
x f z
/ \ /
5 function 45
where * is a DNode
This could also be built with
var root = om.lift({a:{x:5},b:[{z:45,5]})
root.a.f = function (x) {return x*x};
lift applies to "ordinary" JavaScript trees of the kind directly representable in the object notation.
As indicated parenthetically above, there is nothing wrong with having properties of DNodes that reference nodes in the tree other than children, as in
a.xx = b;
in the above example.Then xx is a cross-tree reference.
Restriction on names: names may include only letters, numerals, and the underbar, and may not start with a numeral.
Each externally stored item is referred to by a URL of the form
http://s3.prototypejungle.org/<path>
for example
http://s3.prototypejungle.org/sys/repo0/examples/TwoRectangles
To inspect this item, go to
http://prototypejungle.org/inspect?item=<itemUrl>
for example
http://prototypejungle.org/inspect?item=http://s3.prototypejungle.org/sys/repo0/examples/TwoRectangles
To view it without the machinery of the inspector (for example):
http://s3.prototypejungle.org/sys/repo0/examples/TwoRectangles/view
You can browse a small set of initial examples via the File pulldown on the top bar.
Nodes are constructed with om.DNode.mk() and om.LNode.mk(), rather than via the use of a "new". The definition of the mk method for DNode is:
om.DNode.mk = function () {
return Object.create(om.DNode);
}
Recall that Object.create(X) creates a new object with X as prototype.
DNode itself is introduced simply with:
om.DNode = {};
and LNode with:
om.LNode = [];
om.DNode itself serves as the prototype for instances. In the more conventional pattern, om.DNode would be a function, and
the prototype property of that function, not DNode itself, would be the prototype for the instances, via the new operator (note that if X = function (){}, new X()
is equivalent
to Object.create(X.prototype)
)
The function, function.prototype, new pattern has been in Javascipt all along, whereas the more direct Object.create was introduced in recent years, in version 1.8.5. PrototypeJungle employs the newer pattern, not so much for its intrinsic simplicity (though that's nice), but because this way of doing things has a major simplifying effect on the entire PrototypeJungle code base.
You will never see a "new" anywhere in the code. The convention is that for prototype X, X.mk is the creator/initializer (which may take arguments).
om.DNode.instantiate and om.LNode.instantiate are the implementation. The details are a little complicated, but it is the kind of complexity that you don't need to worry about unless you're curious. Instantiation "does the right thing".
Let T' be the instantiation of tree T. Then T' is a treewise copy of T, but omits its atomic-valued properties (which T' will acquire by inheritance, as will be seen in a moment). That is, with respect to the labeled parent/child relation, T is isomorphic to T', except for the omission of the atomic-valued properties. T' also has the same prototype structure as T, except that chains in T' are anchored back in T. The exact situation is this: consider corresponding nodes N and N' in T and T', that is, nodes appearing at the same paths from the roots of T and T'. Now consider the prototypes P and P' of N and N', that is, P and P' where P=Object.getPrototypeOf(N) and P'=Object.getPrototypeOf(N'). There are two cases. First, P might lie within T. Then P' is defined to be the corresponding node to P, treewise (ie the one at the same path). Second, P might lie outside of the tree T. Then P' is set to N itself. This is what I mean when I say that prototype chains in T' are anchored in T. If you follow a prototype chain C' in T', it will pass through nodes at the same paths as those of the corresponding chain C in T, as long as it is within the tree, but where it exits the tree, then it is anchored back over in T.
Here is the implementation.
A field in an item can be specified by a function rather than a literal value, and when data is bound to the item, the fields take on their computed values. For example, consider
// ccP is a circle with a caption
var ccP = geom.Shape.mk().withComputedFields();
ccp.scale = 2;
ccP.set("circle", geom.Circle.mk({
// a computed field
radius: [function (item,area) {return item.scale* Math.sqrt(area);}]
}));
ccP.set("caption",geom.Text.mk({
// and another
"text":[function (item,area) {return area}],
style:{height:13}}));
var iccP = ccP.instantiate(); // an instance
iccP.setData(100);
The result, iccP, is a captioned circle with area 20 (Math.sqrt(100) * ccP.scale), and caption "100".
setData is the general data binding method: whenever you wish to declare a way of binding data to any type of item, you should define this method on the relevant prototype. For items so declared using the withComputedFields method, setData is predefined to evaluate the computed fields, and replace them with their values.
The rules are apparent from the example: within an item to which withComputedFields has been applied, one-member arrays containing a function signify a computed field of the item. Such fields may appear at arbitrary depth. The function should take two arguments, the item, and the data value.
This construct becomes particularly useful in the context of mark sets ("mark" is a conventional term used in infographics to designate a shape whose parameters are set according to the data to be represented)
A mark set holds two arrays (as LNodes), one containing data, and the other shapes. The two arrays might be of different lengths, but where they correspond, each shape is normally bound to the corresponding data element, though they can be out of sync in the course of some computations.
geom.Marks is the prototype for mark sets. Continuing the example:
var marks = geom.Marks.mk([100,200,300],ccP);
geom.Marks.mk(data,proto) constructs an mark set, whose members are instantiations of proto, bound in sequence to the elements of data. In our example, this is an array of captioned circles with areas and captions 100,200, and 300.
Here is a simple but complete example depicting carbon footprints of the top emitters. Here is the unadjusted version, and a shortcut to the code.
Computational definitions of field values invoked by data binding will be familiar to users of D3. Mark sets are a little like D3 selections, but differ in that they are parts of the core object model, rather than selections from it (the object model being the DOM in the case of D3).
Items can be defined by computation in a more general manner than just described. This is done by defining "update" methods which compute the full state of an item in any way that is suitable to the application. When an item is displayed in the PrototypeJungle viewer or inspector, update methods are run at load time, and each time there is a change. Specifically, to update an item, a depth first traversal of the tree is done with the rule: when an update method is present for the current node, execute it. Traversal terminates at the point where update methods are found.
Here is an example:
//a collection of nested arcs
(function (pj) {
var om = pj.om;
var geom = pj.geom;
var item = pj.set("/examples/NestedArcs",geom.Shape.mk());
item.namedType();
//The arc prototype.
var ArcP=item.set("ArcP",geom.Arc.mk({radius:100,startAngle:0,endAngle:2*Math.PI})).hide();
item.radiusFactor = 0.9;
item.count = 10;
item.update = function () {
var om = prototypeJungle.om;
var arcs = om.LNode.mk().computed();
this.set("arcs",arcs);
var crad = this.ArcP.radius;
var cnt = this.count;
for (var i=0;i<this.count;i++) {
var ca = this.ArcP.instantiate().show();
arcs.pushChild(ca);
ca.setf("radius",crad); // freeze the radius
crad = crad * this.radiusFactor;
}
};
om.save(item);
})(prototypeJungle);
This yields
http://s3.prototypejungle.org/sys/repo0/examples/NestedArcs/view
via the build process. To inspect, see:
http://prototypejungle.org/inspect?item=http://s3.prototypejungle.org/sys/repo0/examples/NestedArcs
A few explanations are needed:
var item = pj.set("/examples/NestedArcs",geom.Shape.mk());
geom.Shape is the prototype for all displayable objects, and inherits from om.DNode. geom.Shape.mk() constructs an empty container to which other shapes can be added.
item.namedType();
This has a minor effect: an item x will be displayed as x:NestedArcs in the inspector if NestedArcs is the first object flagged as a named type in its prototype chain. There is nothing otherwise special about named types; any item can be flagged as such, affecting only display.
item.update = function () {
var om = prototypeJungle.om;
...
Why does om need redefinition in the update function? Isn't the definition of update inside the scope of the main function, where om is available? It may look that way, but, once the item is built, this is no longer the case. The update function is inserted into the item itself during the build process - it ends up as a leaf in the item's tree. So it needs to be able to run without assuming anything about the scope, with the single exception that the global prototypeJungle will have been defined. Of course, as a method of the item, it has full access to it via this.
var arcs = om.LNode.mk().computed();
When an item is declared computed, it is removed before saving, with the assumption that it will be recomputed by an update on reloading.
ca.setf("radius",crad); // freeze the radius
Normally, all atomic properties are editable in the inspector. The setf method, however, declares that the property in question should be "frozen", that is, closed from modification in the inspector. Only the inspector is affected, the property is not modified at the deeper JavaScript level (its descriptor is not modified).
Computed content can be modified in the inspector, and these modifications will be retained through subsequent updates, saves, and restores. The implementation keeps track of modifications, and, whenever an update is done, reapplies the modifications to the updated state.
Earlier sections implicitly introduced the fact that items can be saved and restored with their prototype structures and functions intact. But there is one more aspect of this process that needs mention: one file can reference items from others, often using them as prototypes. The prototype chain for an item might have elements from several separate files. Here is an example:
(function (pj) {
pj.om.restore(["http://s3.prototypejungle.org/sys/repo0/examples/NestedArcs"],
function () {
var om = pj.om;
var geom = pj.geom;
var item = pj.set("/examples/TwiceNestedArcs",geom.Shape.mk());
var n1 = item.set("n1",pj.examples.NestedArcs.instantiate());
var n2 = item.set("n2",pj.examples.NestedArcs.instantiate());
// adjust some parameters
n2.ArcP.radius = 30;
n2.ArcP.style.strokeStyle = "red";
om.save(item);
}
);
})(prototypeJungle);
Recall that http://prototypejungle.org/sys/repo0/examples/NestedArcs contains the definition of the prototype NestedArcs which appears in an earlier section. Here the restore operation loads that definition in, prior to defining a simple structure in which NestedArcs is instantiated. The details:
om.restore([<file0>,<file1>...</filen>],fn);
restores the indicated files in order, and when it is done, calls the function fn. fn might take one argument, and, if so, fn is called with an array consisting of the items restored from the files [<file0>,<file1>...</filen>]. Often, though, as in this example, the purpose of restoring files is to populate the prototypeJungle tree with particular items, and fn takes no arguments.
The TwoNestedArcs structure is saved in http://s3.prototypejungle.org/sys/repo0/examples/TwiceNestedArcs/view
The save algorithm notices when parts of what it is saving come from other files, and mentions them by reference in the saved structure. This usually involves splitting up prototype chains; earlier parts of the chain might come from one place, and later elements from another (an arbitrary number of sources might be involved). For example TwiceNestedArcs.n1, as saved, has six elements in its prototype chain: n1 itself, NestedArc, Shape,DNode, {} (the vanilla object built in om.js to be the prototype of DNode), and Object.prototype, the mother of all JavaScript objects. The first four are defined in the files: TwiceNestedArcs, NestedArcs, om, and om respectively.
If you are interested in visualizing the structure of a PrototypeJungle application, here is one way to do it. The fundamental operation, instantiate, takes a tree, and pulls off a copy, but leaves prototype chains anchored in the original. If instantiation is done several times in succession, a series of trees with their prototype backpointers arises. The same tree might be instantiated multiple times, in which case one arrives at a tree of trees. At each step, modifications are made - that is, parameters are set.
The components represent slices of this structure. So, for example, I might have the general arrow, next a selection of some parameters that I wish to apply to all of the arrows in my particular application, and finally the exact configuration of one particular arrow. The prototype chains connecting this tree of trees are each three long. Each tree is a separable component, and its representation can reside in its own file if desired, for re-use outside of a particular PrototypeJungle running instance.
A more extensive and realistic example of building up prototype chains from a series of saved items can be found in the bar chart example.
When you first sign in at PrototypeJungle, you choose a handle, and thereafter, all of your content will be stored under
http://s3.prototypejungle.org/yourHandle
(this is the only purpose of the handle). Within this filespace your content is organized into repos, of which you may allocate as many as you like. (Activities related to building items, including allocation of repos, are accessible from the "file" pulldown in the topbar.) Within repos, items should be given paths that correspond to the paths under which they will appear when loaded into PrototypeJungle. For example, the system handle is "sys", and all the content mentioned here appears within the repo "repo0". The item which is stored at
http://s3.prototypejungle.org/sys/repo0/examples/NestedArcs
gives itself the path /examples/NestedArcs, that is, the same pathname as the one at which the item is stored externally, relative to its repo. That is, the external tree structure of each repo mirrors a corresponding structure at runtime for the tree rooted at prototypeJungle.
The following is the relevant line of source code:
var item = pj.set("/examples/NestedArcs",geom.Shape.mk());
When you build a new item, the source code is initialized to a template that includes a line of this form, with the appropriate path.
More specifically, the process of building a new item is this: First, after choosing "New Build" from the File pulldown, choose where to put the item. At the time of clicking the "Build New Item" button on the file browser, template source code as just described will appear in the Ace Code Editor. Edit to taste, then click "build", and thence a new item is created.
An item can come into being in three ways. First, it can be built from a code file, as described above. Second, it can be a variant- the result of interactively modifying an existing item, and then storing the result with the "save as" option in the File pulldown. Finally, it might be an assembly, built in the UI starting from a blank slate, via an initial "New Item", followed by a series of insertions.
You will notice these distinctions in some of the operations of the UI. For example, only code-built items can be rebuilt (for other items this option is grayed-out in the File pulldown). You are not allowed overwrite a code-built item with a variant with a simple save; you must save the variant somewhere else, with "save as". The UI attempts to find a suitable name for new saves based on these distinctions.But the names are only suggestions; you can put things where you want.


{% extends 'layout.html' %} {% block pageTitle %} NHS.UK prototype kit - Gitpod installation guide {% endblock %} {% block beforeContent %} {{ breadcrumb({ items: [ { href: "/docs", text: "Home" } ], href: "/docs/install", text: "Install" }) }} {% endblock %} {% block content %}
Follow this Gitpod installer to add the Gitpod app to your Github workspace or organisation.
You will need to:
If your workspace or organisation already has Gitpod installed you can follow our guidance on how to configure a Github repository to Gitpod


The Dashboad Life
nav 1
nav 2
nav 3
Click!
Points:
0
To-do list
Fix page
new item
Get Location!
Show my location
Refresh!


Material : 4-Acetoxy-DiPT powder dissolved in distilled water at 2 drops per mg. Off-white powder from very reliable source.  Zara would describe it as worse than MDMA or 2C-B.
Zam (male) : body weight ~ 100 kg (220 lb). Zam's general entheogen sensitivity is average, though usually he prefers somewhat lighter doses than others. He chose to do 18 mg of 4-Acetoxy-DiPT.
Zara (female) : body weight ~75kg (160 lb). Zara's entheogen sensitivity is definitely higher than average, requiring less material than most people with most substances. She chose to do 10 mg of 4-Acetoxy-DiPT.
OVERVIEW
This experience came at the tail end of an MDE experience. The two reports have been separated out because we wanted to capture the MDE experience separately. However, it's difficult to know exactly how much or what type of effect the MDE had on the experience with the 4-Acetoxy-DiPT. The 4-Ace was done 3 hrs after taking the MDE, but the primary MDE effects were definitely gone at this point.
The effects here were experienced as a somewhat unsettling, especially for Zam who wasn't ever quite sure what to do with himself. Mood was neutral-ish, no strong push in any direction. There was a weird but not exactly bad body trembling / vibration. It seemed like the MDE and the 4-Ace didn't really mix smoothly and the transition was more like a somewhat rough jostling for receptors. We both definitely went from 'coming down' off the MDE to feeling mentally stimulated (not physically stimulated exactly). It felt like the effects were not quite strong enough to totally override the tail of the MDE, but enough to make sure we was definitely 'tripping' in a generic sort of way. Some pleasant and pretty visuals, fairly strong body vibrations, no significant mood lift (but this could be accounted for by the tail of the MDE).
One disconcerting note was the high pulse rate we both had even at T+4 hrs while lying down not moving much, also experientially high body temp.. moving around made us sweat. It seems hard to separate out the effects, but it could likely be a mild serotonin syndromey kinda thing with the mde & prozac & tryptophan, or it could be the combo of those with the tryptamine.. very hard to say, but still somewhat odd.
DETAILS
1:50 (T+0) - We each mixed the chosen number of drops into a small amount of grape juice. This potion is drunk on an empty stomach (neither of us had eaten a meal during the day, and nothing for the past 3 hours). Zam eats a few cherries to clear the taste. We both drink a bunch of water and then clean juice to get rid of the final remnants of taste.
2:27 (T+ :37) - Lights are definitely sparkly, like tryptamine looking through a crystal at lights effect. It's hard to focus eyes, feeling a little unsettled and odd. Breathing is somewhat shakey. Not in a bad way, but not particularly good either. These effects seem as though they might be the result of the mixture of the remaining MDE effects and the just starting 4-Ace.
We lie down to start watching 'Shakespeare in Love'. While the movie seems interesting and good, neither of us can quite settle in to be sure it's what we want to be doing. We both have a bit of the body feeling that we want to get up and do something, move around more, but going outside in the 40F damp weather seems like a pain, so we stay in.
Zam : Pulse 78 BPM lying on floor (normal resting pulse 60-70BPM)
2:57 (T+ 1:07) - Zara settles in much more with the experience and finds herself very much enjoying the experience of watching the movie. The somewhat uncomfortable body and mental feelings from 30 minutes ago fade pretty much into non-existence. Zam continues to feel somewhat unsettled.
4:10 (T+ 2:20) - Zam is still a little shakey. We finish 'Shakespeare in Love'. An excellent movie. Eat a few carrots and both take our temperature and pulse:
Zam : Ear temp 100.3 (avg of 3 temps taken) Zara : Ear temp 99.7 (avg of 3 temps taken)
4:27 (T+ 2:37) -
Zara : Blood Pressure 117/68 (normal 100/65) Pulse: 99 BPM (normal 65-70)
It is quite noteable that Zara's pulse was this high. While she doesn't feel at all bad, it's definitely a little weird to have her pulse so high while resting. Others should take note of this and keep track to make sure their pulse does not become dangerously high with this substance.
4:36 (T+ 2:46) - Vision is still very sparkly, crystal effects on candles and christmas lights. Eyes are definitely focusing differently than usual.
5:10 (T+ 3:20) -
Zara : Blood Pressure 103/60 Pulse 95 BPM
Zam : Blood Pressure 110/70 (normal 110/60) Pulse 85-90 BPM (normal 60)
7:00 (T+ 5:10) - Both lie down to sleep. Neither of us have much trouble.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


From: To: Algos:
Account Mnemonic:
First Round: Last Round:
Transaction ID:
Get Latest Block Generate Account Recover Account from Account Mnemonic Submit Transaction Get Account Details Get Tx From Account


The Haskell mode itself is very basic, but provides a base on which to build modules. The currently supported modules are:
The latest versions of the basic mode and the above modules.
The basic mode was written by Graeme E Moss, Tommy Thorn and Simon Marlow. Modules with their own links above are maintained by their authors; the rest are looking for a maintainer (please volunteer!). These modules support Haskell 98, except where stated, and have been tested on GNU Emacs versions 19.34 and 20.7, and XEmacs versions 21.1.14 and 21.4.x. Please mail bugs and suggestions to the maintainer of the appropriate module. General comments can be mailed to Stefan Monnier. When mailing, quote the version of the module or mode you are using, the version of Emacs you are using, and a small example of the problem or suggestion. Please check the list of known problems (towards the start of each relevant file) before doing so.
A guide on how to install and customise the mode.
To test the mode:


25 Nov 2019 Sijie Guo (@sijieg) & Markos Sfikas (@MarkSfik)
In a previous story on the Flink blog, we explained the different ways that Apache Flink and Apache Pulsar can integrate to provide elastic data processing at large scale. This blog post discusses the new developments and integrations between the two frameworks and showcases how you can leverage Pulsar’s built-in schema to query Pulsar streams in real time using Apache Flink.
A short intro to Apache Pulsar
Apache Pulsar is a flexible pub/sub messaging system, backed by durable log storage. Some of the framework’s highlights include multi-tenancy, a unified message model, structured event streams and a cloud-native architecture that make it a perfect fit for a wide set of use cases, ranging from billing, payments and trading services all the way to the unification of the different messaging architectures in an organization. If you are interested in finding out more about Pulsar, you can visit the Apache Pulsar documentation or get in touch with the Pulsar community on Slack.
Existing Pulsar & Flink integration (Apache Flink 1.6+)
The existing integration between Pulsar and Flink exploits Pulsar as a message queue in a Flink application. Flink developers can utilize Pulsar as a streaming source and streaming sink for their Flink applications by selecting a specific Pulsar source and connecting to their desired Pulsar cluster and topic:
// create and configure Pulsar consumer
PulsarSourceBuilder<String>builder = PulsarSourceBuilder
.builder(new SimpleStringSchema())
.serviceUrl(serviceUrl)
.topic(inputTopic)
.subsciptionName(subscription);
SourceFunction<String> src = builder.build();
// ingest DataStream with Pulsar consumer
DataStream<String> words = env.addSource(src);
Pulsar streams can then get connected to the Flink processing logic…
// perform computation on DataStream (here a simple WordCount)
DataStream<WordWithCount> wc = words
.flatmap((FlatMapFunction<String, WordWithCount>) (word, collector) -> {
collector.collect(new WordWithCount(word, 1));
})
.returns(WordWithCount.class)
.keyBy("word")
.timeWindow(Time.seconds(5))
.reduce((ReduceFunction<WordWithCount>) (c1, c2) ->
new WordWithCount(c1.word, c1.count + c2.count));
…and then get emitted back to Pulsar (used now as a sink), sending one’s computation results downstream, back to a Pulsar topic:
// emit result via Pulsar producer
wc.addSink(new FlinkPulsarProducer<>(
serviceUrl,
outputTopic,
new AuthentificationDisabled(),
wordWithCount -> wordWithCount.toString().getBytes(UTF_8),
wordWithCount -> wordWithCount.word)
);
Although this is a great first integration step, the existing design is not leveraging the full power of Pulsar. Some shortcomings of the integration with Flink 1.6.0 relate to Pulsar neither being utilized as durable storage nor having schema integration with Flink, resulting in manual input when describing an application’s schema registry.
Pulsar’s integration with Flink 1.9: Using Pulsar as a Flink catalog
The latest integration between Flink 1.9.0 and Pulsar addresses most of the previously mentioned shortcomings. The contribution of Alibaba’s Blink to the Flink repository adds many enhancements and new features to the processing framework that make the integration with Pulsar significantly more powerful and impactful. Flink 1.9.0 brings Pulsar schema integration into the picture, makes the Table API a first-class citizen and provides an exactly-once streaming source and at-least-once streaming sink with Pulsar. Lastly, with schema integration, Pulsar can now be registered as a Flink catalog, making running Flink queries on top of Pulsar streams a matter of a few commands. In the following sections, we will take a closer look at the new integrations and provide examples of how to query Pulsar streams using Flink SQL.
Leveraging the Flink <> Pulsar Schema Integration
Before delving into the integration details and how you can use Pulsar schema with Flink, let us describe how schema in Pulsar works. Schema in Apache Pulsar already co-exists and serves as the representation of the data on the broker side of the framework, something that makes schema registry with external systems obsolete. Additionally, the data schema in Pulsar is associated with each topic so both producers and consumers send data with predefined schema information, while the broker performs schema validation, and manages schema multi-versioning and evolution in compatibility checks.
Below you can find an example of Pulsar’s schema on both the producer and consumer side. On the producer side, you can specify which schema you want to use and Pulsar then sends a POJO class without the need to perform any serialization/deserialization. Similarly, on the consumer end, you can also specify the data schema and upon receiving the data, Pulsar will automatically validate the schema information, fetch the schema of the given version and then deserialize the data back to a POJO structure. Pulsar stores the schema information in the metadata of a Pulsar topic.
// Create producer with Struct schema and send messages
Producer<User> producer = client.newProducer(Schema.AVRO(User.class)).create();
producer.newMessage()
.value(User.builder()
.userName(“pulsar-user”)
.userId(1L)
.build())
.send();
// Create consumer with Struct schema and receive messages
Consumer<User> consumer = client.newCOnsumer(Schema.AVRO(User.class)).create();
consumer.receive();
Let’s assume we have an application that specifies a schema to the producer and/or consumer. Upon receiving the schema information, the producer (or consumer) — that is connected to the broker — will transfer such information so that the broker can then perform schema registration, validations and schema compatibility checks before returning or rejecting the schema as illustrated in the diagram below:
Not only is Pulsar able to handle and store the schema information, but is additionally able to handle any schema evolution — where necessary. Pulsar will effectively manage any schema evolution in the broker, keeping track of all different versions of your schema while performing any necessary compatibility checks.
Moreover, when messages are published on the producer side, Pulsar will tag each message with the schema version as part of each message’s metadata. On the consumer side, when the message is received and the metadata is deserialized, Pulsar will check the schema version associated with this message and will fetch the corresponding schema information from the broker. As a result, when Pulsar integrates with a Flink application it uses the pre-existing schema information and maps individual messages with schema information to a different row in Flink’s type system.
For the cases when Flink users do not interact with schema directly or make use of primitive schema (for example, using a topic to store a string or long number), Pulsar will either convert the message payload into a Flink row, called ‘value’ or — for the cases of structured schema types, like JSON and AVRO — Pulsar will extract the individual fields from the schema information and will map the fields to Flink’s type system. Finally, all metadata information associated with each message, such as the message key, topic, publish time, or event time will be converted into metadata fields in a Flink row. Below we provide two examples of primitive schema and structured schema types and how these will be transformed from a Pulsar topic to Flink’s type system.
Once all the schema information is mapped to Flink’s type system, you can start building a Pulsar source, sink or catalog in Flink based on the specified schema information as illustrated below:
Flink & Pulsar: Read data from Pulsar
- Create a Pulsar source for streaming queries
val env = StreamExecutionEnvironment.getExecutionEnvironment
val props = new Properties()
props.setProperty("service.url", "pulsar://...")
props.setProperty("admin.url", "http://...")
props.setProperty("partitionDiscoveryIntervalMillis", "5000")
props.setProperty("startingOffsets", "earliest")
props.setProperty("topic", "test-source-topic")
val source = new FlinkPulsarSource(props)
// you don't need to provide a type information to addSource since FlinkPulsarSource is ResultTypeQueryable
val dataStream = env.addSource(source)(null)
// chain operations on dataStream of Row and sink the output
// end method chaining
env.execute()
- Register topics in Pulsar as streaming tables
val env = StreamExecutionEnvironment.getExecutionEnvironment
val tEnv = StreamTableEnvironment.create(env)
val prop = new Properties()
prop.setProperty("service.url", serviceUrl)
prop.setProperty("admin.url", adminUrl)
prop.setProperty("flushOnCheckpoint", "true")
prop.setProperty("failOnWrite", "true")
props.setProperty("topic", "test-sink-topic")
tEnv
.connect(new Pulsar().properties(props))
.inAppendMode()
.registerTableSource("sink-table")
val sql = "INSERT INTO sink-table ....."
tEnv.sqlUpdate(sql)
env.execute()
Flink & Pulsar: Write data to Pulsar
- Create a Pulsar sink for streaming queries
val env = StreamExecutionEnvironment.getExecutionEnvironment
val stream = .....
val prop = new Properties()
prop.setProperty("service.url", serviceUrl)
prop.setProperty("admin.url", adminUrl)
prop.setProperty("flushOnCheckpoint", "true")
prop.setProperty("failOnWrite", "true")
props.setProperty("topic", "test-sink-topic")
stream.addSink(new FlinkPulsarSink(prop, DummyTopicKeyExtractor))
env.execute()
- Write a streaming table to Pulsar
val env = StreamExecutionEnvironment.getExecutionEnvironment
val tEnv = StreamTableEnvironment.create(env)
val prop = new Properties()
prop.setProperty("service.url", serviceUrl)
prop.setProperty("admin.url", adminUrl)
prop.setProperty("flushOnCheckpoint", "true")
prop.setProperty("failOnWrite", "true")
props.setProperty("topic", "test-sink-topic")
tEnv
.connect(new Pulsar().properties(props))
.inAppendMode()
.registerTableSource("sink-table")
val sql = "INSERT INTO sink-table ....."
tEnv.sqlUpdate(sql)
env.execute()
In every instance, Flink developers only need to specify the properties of how Flink will connect to a Pulsar cluster without worrying about any schema registry, or serialization/deserialization actions and register the Pulsar cluster as a source, sink or streaming table in Flink. Once all three elements are put together, Pulsar can then be registered as a catalog in Flink, something that drastically simplifies how you process and query data like, for example, writing a program to query data from Pulsar or using the Table API and SQL to query Pulsar data streams.
Next Steps & Future Integration
The goal of the integration between Pulsar and Flink is to simplify how developers use the two frameworks to build a unified data processing stack. As we progress from the classical Lamda architectures — where an online, speeding layer is combined with an offline, batch layer to run data computations — Flink and Pulsar present a great combination in providing a truly unified data processing stack. We see Flink as a unified computation engine, handling both online (streaming) and offline (batch) workloads and Pulsar as the unified data storage layer for a truly unified data processing stack that simplifies developer workloads.
There is still a lot of ongoing work and effort from both communities in getting the integration even better, such as a new source API (FLIP-27) that will allow the contribution of the Pulsar connectors to the Flink community as well as a new subscription type called Key_Shared
subscription type in Pulsar that will allow efficient scaling of the source parallelism. Additional efforts focus around the provision of end-to-end, exactly-once guarantees (currently available only in the source Pulsar connector, and not the sink Pulsar connector) and more efforts around using Pulsar/BookKeeper as a Flink state backend.
You can find a more detailed overview of the integration work between the two communities in this recording video from Flink Forward Europe 2019 or sign up to the Flink dev mailing list for the latest contribution and integration efforts between Flink and Pulsar.


Donald Trump Chides Fox News for Interviewing 'Losers' like Eric Swalwell
President Donald Trump criticized Fox News anchor Shannon Bream on Thursday after he watched her interview with Rep. Eric Swalwell.
by Charlie Spiering“Why do Shannon Bream and Fox News waste airtime on Democrat Rep. Eric Swalwell, who recently left the Presidential Primaries having attained a grand number of ZERO in the polls,” Trump wrote on Twitter.
Swalwell, who was recently the subject of a “fart-gate” controversy during an MSNBC interview with Chris Matthews, appeared on Bream’s show in the 11:00 p.m. hour on Wednesday night to talk about the case for impeaching President Trump
“I don’t even know how that is possible,” Trump commented. “Fox should stay with the people that got them there, not losers!”
Trump last called into Bream’s show in October 2018.


Mipui Privacy Policy
We promise to do nothing bad with any personal data we get from anyone. It will certainly not be sold or given to anyone else for any reason.
Any map you make is private. The only way to view a map is to know its ID, which is a part of the URL, and those IDs are random and cannot be guessed by other users unless you share it with them.
We pledge that your maps will never be shared with anyone without your knowledge and permission. The only exception is that Mipui admins might occasionally look at user maps for development and quality assurance purposes.
Despite the above, please avoid storing sensitive information on maps (e.g. credit card information).


Welcome
Mapochopocho Bistro
Original Kenyan pizza recipes, Delicious Modern varieties
Original Kenyan pizza recipes, Delicious Modern varieties
The modern pizza was originally invented in Naples, Italy but the word pizza is Greek in origin, derived from the Greek word pēktos meaning solid or clotted. The ancient Greeks covered their bread with oils, herbs and cheese. The first major innovation that led to flat bread pizza was the use of tomato as a topping. It was common for the poor of the area around Naples to add tomato to their yeast-based flat bread, and so the pizza began. While it is difficult to say for sure who invented the pizza, it is however believed that modern pizza was first made by baker Raffaele Esposito of Naples. In fact, a popular urban legend holds that the archetypal pizza, Pizza Margherita, was invented in 1889, when the Royal Palace of Capodimonte commissioned the Neapolitan pizzaiolo Raffaele Esposito to create a pizza in honor of the visiting Queen Margherita. Of the three different pizzas he created, the Queen strongly preferred a pie swathed in the colors of the Italian flag: red (tomato), green (basil), and white (mozzarella). Supposedly, this kind of pizza was then named after the Queen as Pizza Margherita.
At Mapochopocho Bistro pizza the original recipe remains while we include the modern varieties. Pizza has never tasted this good
Small Sh 300/=
Medium Sh 600/=
Large Sh 1,200/=
Thin Crust Sh 150/=
Thick Crust Sh 200/=
Deep Crust Sh 380/=
Cheese filled Sh 500/=
Stuffed Crust Sh 345/=
Pepperoni Sh 100/=
Mushrooms Sh 300/=
Onions Sh 120/=
Sausage Sh 150/=
Green peppers Sh 100/=
We offer Free Delivery for orders above
Sh, 1000/-


False, spam, or troll reports may result in being banned from this service.
Sellers may be notified of abusive false reports to help protect them.
Help with reporting
Contact info
We use this to contact you if we need more information.
This information will not be made public with exception of username, which will be displayed as initials in the report.
Collecting evidence
Please provide screenshots of the original asset(EG: Model comparisons, screenshots from a game, etc).
Here is an example of good evidence. These can be uploaded to Imgur or other image sharing sites.
First name and Last name
This is not your or their real life information! This is your and their Second Life username.
If their name is like "Chaser Zaks", you put "Chaser" as first name, "Zaks" as last name. If it looks like "Chasertester", you put "Chasertester" as first name and "Resident" as last name.
Comments
If you have information you want to put out about the seller, such as hostile interactions, false review flagging, etc. Please feel free to bring it up here.
Consent and Liability
This is to ensure people do not file false claims.
Consenting to contact is not required to submit a report, but lets us know if you would be willing to help follow up evidence reports.


Do you want to add popcorn bots to your server and listen to music?
Invite them now and listen to the music!
Do you want to see the code for this bot?
Click on the button below to visit my Github!
If you want to serve this bot better and better, donate it!
Small donations are a good motive for developers.


“strive 8/7 ~ 8/13”
Use
-
[Gem] virtus
-
[Gem] sorcery
- authentication for Rails
-
[Gem] capybara-webkit
- A Capybara driver for headless WebKit to test JavaScript web apps
-
[Gem] capybara
- Acceptance test framework for web applications
-
[Gem] database_cleaner
- Strategies for cleaning databases
-
[Gem] temping
- model mockup, dynamic create db table for model test
-
[Gem] rubycritic
- provide a quality report of your Ruby code.
-
[Gem] CapistranoDeployTest
- Deploying a Rails App on Ubuntu 14.04 with Capistrano, Nginx, and Puma
-
[Gem] meta-tags
- make your Rails application SEO-friendly
-
[Gem] friendly_id
- for pretty url
-
[Gem] sitemap_generator
- create sitemap
-
[SEO] BROWSEO
- see how search engine read your website
-
[Gem] sphinx
- full-text search engine
Read
-
[Ruby] ActionController::Metal#performed?
- you can test whether render or redirect already happended
-
[Ruby] ActiveModel::Validations#valid?(context=nil)
- validates_length_of :slug, minimum: 3, on: :user
- validates_length_of :slug, minimum: 1, on: :admin
- @user.save(context: :admin), @user.valid?(:admin), @user.valid?(:user),
-
[Ruby] 7-ways-to-decompose-fat-activerecord-models
- Value Objects: define domain-specific Value Objects, Value Objects are great when you have an attribute or small group of attributes that have logic associated with them
- Service Objects: action is complex, action reaches across multiple models, action interacts with an external service, action is not a core concern of the underlying model
- Form Objects: Virtus, When multiple ActiveRecord models might be updated by a single form submission, a Form Object can encapsulate the aggregation
- Query Objects: For complex SQL queries littering the definition of your ActiveRecord subclass
- View Objects: If logic is needed purely for display purposes, it does not belong in the model.
- Policy Objects: Sometimes complex read operations might deserve their own objects * “Service Object” for write operations and “Policy Object” for reads, Query Objects focus on executing SQL to return a result set
- Decorators: For cases where callback logic only needs to run in some circumstances or including it in the model would give the model too many responsibilities, a Decorator is useful
-
[Ruby] Configuring database_cleaner with Rails, RSpec, Capybara, and Selenium
- different cleaner strategy settings
-
[Ruby] routing constraints
-
[Ruby] How to use rails routing constraints
- security vulnerabilities and data type validation
- encapsulate and simplify actions (and supporting code)
-
[Ruby] composed_of
- model representing attributes as value objects
-
[SEO] 給 Rails Developer 的基本SEO
Book
-
- done (1), (2)
-
- rails api design
-
-
Refactoring recipes
- Inline controller filters
- extract filter to service
- Explicitly render views with locals
- pass the params to partials explicitly with render
- Extract render/redirect methods
- extract a private method for each render and redirect call
- Extract a Single Action Controller class
- extract like CreateProductsController only when ProductsController is too too too large
- Extract routing constraint
- use routing constraint to seperate controller action
- Extract an adapter object
- extract call external library to adapter object call
- Extract a repository object
- hide the direct ActiveRecord calls, isolated, add data storage on repo object
- Extract a service object using the SimpleDelegator
- move some domain or business logic to service object
- Extract conditional validation into Service Object
- when validation only used in one place, drop the condition on model, move it to service object
- Extract a form object
- move form to form object, more explicit and domain is expressed better
- form object can’t have save method (SRP), Persistence is a seperate concern and different object should take care of it, form object only valid data
- Inline controller filters
-
Patterns
-
Instantiating service objects *
-
The repository pattern *
- Wrap external API with an adapter
- isolated our interface from the implementation
-
4 ways to early return from a rails controller
- extracted_method; return if performed?
-
Service::Input *
-
Validations: Contexts *
- Validations: Objectify *
-
-
Related topics
- Service controller communication
- True/false; return the object created/updated; return a response object that contains all the data and/or errors;
- carry data through exceptions; controller passes callback methods;
- Where to keep services
- group your services according to the feature and then surround them with proper namespace
- ex: Reporting::MonthlyReport, Forum::CreateNewTopic, TimeTracking::LogTimeService
- Routing constraints
- use routing constraints for situations where you need to choose differentctions based on some params
- This makes the controller thinner and it’s more explicit what actios happening
- Service controller communication
-


| Name | Graph | Creation Method | Communities | R | .xml | .txt |
|---|
Metrics
| Metric | Completed | Value |
|---|
Run Metric
Visualization
| Name | Graph | Creation Method | Communities | R | .xml | .txt |
|---|
| Metric | Completed | Value |
|---|


Beta This is a test version of the layout of this page. Take the survey to help us improve it
Guidance
Analysis of local authorities' schools block funding formulae
This document provides an overview of the formula factor values chosen by local authorities as at 8 March 2016. It provides charts and briefing commentary on the ranges of unit funding amounts they have selected and funding attributed under each of the permitted factors.
PDF , 748KB , 28 pages
The funding formulae data is included in the following document.
MS Excel Spreadsheet , 347KB
If you use assistive technology (eg a screen reader) and need a version of this document in a more accessible format, please email<EMAIL_ADDRESS>. Please tell us what format you need. It will help us if you say what assistive technology you use.


Jack Applin
Hewlett-Packard
Ft. Collins
Colorado
USA
Compile and/or execute as directed by the documentation.
The judges were so amused by this little program that we created an award just for it. This program is portable to the C and Fortran 77 compilers as well as executable by the bourne shell!
Copyright © 1986, Landon Curt Noll & Larry Bassel. All Rights Reserved. Permission for personal, educational or non-profit use is granted provided this this copyright and notice are included in its entirety and remains unaltered. All other uses must receive prior permission in writing from both Landon Curt Noll and Larry Bassel.


|
UMI3D Unity SDK
2.5.b.221125
A UMI3D sdk implementation using Unity
|
Classes | |
| class | AbstractMicrophoneListener |
| class | AudioManager |
| Manager for audio reading. More... | |
| class | AudioUserIsSpeaking |
| class | ClientIdentifierApi |
| API to give a password for the client, return filled up Form, and state if needed libraries should be downloaded. More... | |
| class | HttpClient |
| Send HTTP requests to the environment server. More... | |
| class | LaucherOnMasterServer |
| Used to connect to a Master Server, when a World Controller is not used. More... | |
| class | LocalInfoSender |
| Handles the sending of Local Infos on request. More... | |
| class | MicrophoneEvent |
| class | MicrophoneListener |
| class | MumbleEvent |
| class | NAudioMicrophone |
| Custom microphone for MumbleClient not based on Unity interface for mics but on https://github.com/naudio/NAudio. More... | |
| class | NoiseReducer |
| Voice noise reducer based on RNNoise lib https://github.com/xiph/rnnoise and based on tkmn0's work on github https://github.com/tkmn0/Caress.Unity. More... | |
| class | OnForceLogoutEvent |
| class | OnProgressEvent |
| class | SaturatedEvent |
| class | UMI3DCollabAvatarNodeLoader |
| Loader for UMI3DAvatarNodeDto in a collaborative context. More... | |
| class | UMI3DCollabLoadingParameters |
| Loading helper in a collaboration context. More... | |
| class | UMI3DCollaborationClientServer |
| UMI3D server on the browser, in a collaborative context. More... | |
| class | UMI3DCollaborationClientUserTracking |
| Manager for client user tracking event for other users in a collaborative context. More... | |
| class | UMI3DCollaborationEnvironmentLoader |
| Loader for UMI3DCollaborationEnvironmentDto. More... | |
| class | UMI3DCollaborationNetworkingModule |
| Helper to serialize classes of the Collaboration module. More... | |
| class | UMI3DCollaborativeUserAvatar |
| Client description of a user's avatar, like UserAvatar, but in a collaborative context. More... | |
| class | UMI3DEnvironmentClient |
| Client for the UMI3D environment server, handles the connection to environments. More... | |
| class | UMI3DForgeClient |
| Client for the Forge server, handling most of the transactions coming from the environment. More... | |
| class | UMI3DNetworkManager |
| This class provides a NetworkManager which is able to customize the port given to a master sever. More... | |
| class | UMI3DUser |
| UMI3D user representation. More... | |
| class | UMI3DViewpointHelper |
| Component attached to the viewpoint of any skeleton. More... | |
| class | UMI3DWorldControllerClient |
| Handles the connection to a World Controller. More... | |
Enumerations | |
| enum | MicrophoneMode |
| enum | MumbleStatus |
| enum | MicrophoneStatus |
| enum | MicrophoneInputType |


5 rational thoughts about the Celtics’ comfortable win in Charlotte
by Mike DynonFive points about last night’s road win over the Hornets, where the Celtics took the lead midway in the first quarter and never looked back.
1. Kemba and Terry
We learned last night that Charlotte fans really, truly love Kemba Walker. With good reason: he’s the franchise’s all-time leader in every significant stat category and a genuine good guy. Kemba was moved by the tribute video, and perhaps a bit nervous – he was 0-6 in the first half. But he got it together in the third quarter with 11 points (3-5 from the arc) and 4 assists, helping the Celtics pull away.
Even on his special night, Kemba made sure to put the team first.
That’s a high-character individual. After last year’s discord and discontent, we couldn’t have asked for a better person to lead this season of healing.
On the other side, Terry Rozier – the man Kemba was traded for – had a game to forget.
I really thought Scary Terry would show up against his former team, but the only people he frightened were the Charlotte fans. They probably recoiled at Rozier’s hideous shot chart (1 make, 10 misses), not to mention his 4 turnovers and plus/minus of negative-14.
Rozier had an opportunity to earn Hornets’ fans trust and help them move on from Kemba, but he wasted it. I still expect he’ll do better on his next chance, December 22 in Boston.
2. Bench scoring (or lack thereof)
At 23.6 points per game, the Celtics rank dead last in the NBA for bench scoring. That’s what happens when your second unit includes six players in their first or second years.
Last night, the Hornets bench outscored the Cs bench 49-34. That’s despite the Boston subs getting more playing time than usual (the starters basically sat out the garbage-time 4th quarter).
The Celtics’ second team actually played well overall, but they just couldn’t put the ball through the hoop. They were a collective 12-31 from the field, and four of the eight subs scored zero. And that’s typical – the Cs bench is hitting just 39.5% this season.
Maybe there’s hope, however. Javonte Green got his first significant playing time and scored 12 points in 13 minutes on 5-9 shooting. If nothing else, Green was an obvious upgrade from the offensively challenged Semi Ojeleye. Let’s see who gets on the court first next time.
3. Ball movement
The Celtics had a season-high 29 assists on their 40 baskets (on 93 shots), and no individual had more than 6 dimes. That’s some sharing, folks, and a team can never go wrong when the ball doesn’t stick.
4. Charlotte’s own, Grant Williams
The rook is beloved in Charlotte.
Unfortunately for his cheering section, Grant went scoreless in 15 minutes, including being blocked on a dunk attempt. He still made winning plays, however.
5. Hayward is rolling
After destroying the Cavs on Tuesday, Gordon Hayward struck again last night with 20 points (14 in the first quarter) on 9-16 shooting, plus team-highs of 10 boards and 6 assists. He’s doing it all now.
(There was a typo: the stat is Hayward has fewer than (<) 15 turnovers.)
These are amazing numbers, although few people seem to have noticed. Gordo gets nowhere near the hype as the others on that list.
What it means, though, is that the Celtics need to be taken seriously. KOC knows it.