mlflowrate: User Manual¶
Welcome to the user manual!
How to use:¶
Oilwell data can arrive via excel spreadsheets or mixed tagged csv formats. It’s important to be able to properly integrate these styles into consistent dataframes for machine learning!
The main modules revolve around the data integration and data science pipeline, the modules are:
Integrate
DataSets
Explore
WorkFlow Module¶
The data management parent module: WorkFlow, controls the flow of data between these three modules. Users can use: WorkFlow.status() to check the stage in the pipeline they’re at. The WorkFlow.nextphase() method enables user progression onto the next stage.
Users must import the data first as a Spark DataFrame: The original file types should be converted to .csv files, then use the Spark API to import the csv file as a Spark dataframe.
We assume timeseries data given the nature of predicting flow rates: all date columns must be renamed as “datetime” for the software to work!
After importing the csv files as Spark DataFrames, to start using mlflowrate, one must name each data and collect them into a dictionary. This is then passed into an instantiation of a WorkFlow object:
datas = {data1: Spark DataFrame, data2: Spark DataFrame}
pipeline = WorkFlow(datas)
Finally, the user can now progress onto the 3 data science stages, for example:
pipeline.integrate.cleandata()
pipeline.integrate.organise()
pipeline.nextphase()
pipeline.datasets.makeset()
pipeline.datasets.correlation()
Check the user documentations for the features and descriptions! https://kkf18.github.io/acse-9-independent-research-project-kkf18/
Important things to note:¶
Data Formats
Two types of common data formats are targeted for data integration:
1.1 Tagname Format
Oil well characteristic data given in the columnar form:
datetime
tag
value
The tag name may contain one or two pieces of information for us to sort through. In our case, the data provided contained information on measurement origins and what the measurement was.
E.g. OILWELL-TEMPXXYY
The function organise_data() organises data into their unique oil well origins and sensor measurement types. See the documentations for further information.
1.2 Standard Format
Oil well characteristic data given as multiple features against the date column.
datetime
temp
pres
choke
etc.
The function organise_data() also organises this data for integrating into the mlflowrate pipeline.
Understanding how to integrate and clean the data
A problem with oil well data given in the “Tagname Format” is that we can have incontiguous features.
E.g: Temperature has 365 samples spanning from 2016-2017, but pressure has 720 samples spanning from 2016-2018.
This means when the two features are combined into a DataFrame, temperature will contain an extra 365 nulls to fill up the empty space to keep the data symmetry.
mlflowrate organises these incontiguous data into two formats for cleaning and integration:
Spark DataFrame Format
Dictionary Format
The Dictionary Format separates out the individual features and collected them into their own key-value pairs in a dictionary. For example:
Dictionary = {temperature: | datetime | value |, pressure: | datetime | value |}Every data passed into the software will have a Spark DataFrame Format, and a Dictionary Format. Using any of the cleaning methods in the package will change both of these formats.
It is the users job to produce a contiguous and clean Spark DataFrame format for the next stage. The .status() method enables users to check for duplicates, nulls and sample sizes for assistance.


Hey! I am Mimic
A Web Developer
Tribute Page
Tribute Page
Tribute Page
Tribute Page
Let's work together...
How do you take your coffee?
A Web Developer
Tribute Page
Tribute Page
Tribute Page
Tribute Page
Let's work together...
How do you take your coffee?


Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, "self-sovereign" digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document contains at least three things: cryptographic material, authentication suites, and service endpoints. Cryptographic material combined with authentication suites provide a set of mechanisms to authenticate as the DID subject (e.g., public keys, pseudonymous biometric protocols, etc.). Service endpoints enable trusted interactions with the DID subject.
This document specifies a common data model, format, and operations that all DIDs support.
Comments regarding this document are welcome. Please file issues directly on GitHub, or send them to<EMAIL_ADDRESS>( subscribe, archives).
Portions of the work on this specification have been funded by the United States Department of Homeland Security's Science and Technology Directorate under contracts HSHQDC-16-R00012-H-SB2016-1-002 and HSHQDC-17-C-00019. The content of this specification does not necessarily reflect the position or the policy of the U.S. Government and no official endorsement should be inferred.
Work on this specification has also been supported by the Rebooting the Web of Trust community facilitated by Christopher Allen, Shannon Appelcline, Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young, Kim Hamilton Duffy, Manu Sporny, Drummond Reed, Joe Andrieu, and Heather Vescent.
Conventional identity management systems are based on centralized authorities such as corporate directory services, certificate authorities, or domain name registries. From the standpoint of cryptographic trust verification, each of these centralized authorities serves as its own root of trust. To make identity management work across these systems requires implementing federated identity management.
The emergence of distributed ledger technology (DLT), sometimes referred to as blockchain technology, provides the opportunity for fully decentralized identity management. In a decentralized identity system, entities are free to use any shared root of trust. Globally distributed ledgers (or a decentralized P2P network that provides similar capabilities) provide a means for managing a root of trust with neither centralized authority nor a single point of failure. In combination, DLTs and decentralized identity systems enable any entity to create and manage their own identifiers on any number of distributed, independent roots of trust.
The entities are identified by decentralized identifiers (DIDs). They may authenticate via proofs (e.g., digital signatures, privacy-preserving biometric protocols, etc.). DIDs point to DID Documents. A DID Document contains a set of service endpoints for interacting with the entity. Following the dictums of Privacy by Design, each entity may have as many DIDs as necessary, to respect the entity’s desired separation of identities, personas, and contexts.
To use a DID with a particular distributed ledger or network requires defining a DID method in a separate DID method specification. A DID method specifies the set of rules for how a DID is registered, resolved, updated, and revoked on that specific ledger or network.
This design eliminates dependence on centralized registries for identifiers as well as centralized certificate authorities for key management—the standard pattern in hierarchical PKI (public key infrastructure). Because DIDs reside on a distributed ledger, each entity may serve as its own root authority—an architecture referred to as DPKI (decentralized PKI).
Note that DID methods may also be developed for identifiers registered in federated or centralized identity management systems. For their part, all types of identifier systems may add support for DIDs. This creates an interoperability bridge between the worlds of centralized, federated, and decentralized identifiers.
DIDs have a foundation in URLs, so it's important to understand how the W3C clarified the terms [[URI]] (Uniform Resource Identifier), [[URL]] (Uniform Resource Locator), and [[URN]] (Uniform Resource Name) in September 2001. The key difference between these three categories of identifiers are:
The growing need for decentralized identifiers has produced two specific requirements for a new type of URL that still fits Web Architecture and has a few additional requirements that more traditional URLs, like HTTP-based URLs, do not have:
DIDs achieve global uniqueness without the need for a central registration authority. This comes, however, at the cost of human memorability. The algorithms capable of generating globally unique identifiers automatically produce random strings of characters that have no human meaning. This demonstrates the axiom about identifiers known as Zooko's Triangle: "human-meaningful, decentralized, secure—pick any two".
There are of course many use cases where it is desirable to discover a DID when starting from a human-friendly identifier—a natural language name, a domain name, or a conventional address for a DID owner such as a mobile telephone number, email address, Twitter handle, or blog URL. However, the problem of mapping human-friendly identifiers to DIDs (and doing so in a way that can be verified and trusted) is out-of-scope for this specification.
Solutions to this problem (and there are many) should be defined in separate specifications that reference this specification. It is strongly recommended that such specifications carefully consider: (a) the numerous security attacks based on deceiving users about the true human-friendly identifier for a target entity, and (b) the privacy consequences of using human-friendly identifiers that are inherently correlatable, especially if they are globally unique.
The first purpose of this specification is to define the generic DID scheme and a generic set of operations on DIDs that can be implemented for any distributed ledger or network capable of supporting DIDs. The second purpose of this specification is to define the conformance requirements for a DID method specification—a separate specification that defines a specific DID scheme and specific set of DID record operations for a specific distributed ledger or network.
Conceptually, the relationship of this specification and a DID method specification is similar to the relationship of the IETF generic URI specification ([[RFC3986]]) and a specific URI scheme ([[IANA-URI-SCHEMES]] (such as the http: and https: schemes specified in [[RFC7230]]). It is also similar to the relationship of the IETF generic URN specification ([[URN]]) and a specific URN namespace definition (such as the UUID URN namespace defined in [[RFC4122]]). The difference is that a DID method specification, in addition to defining a specific DID scheme, must also specify the methods for reading, writing, and revoking DID records on the network for which it is written.
For a list of DID Methods and their corresponding specifications, see the DID Method Registry [[DID-METHOD-REGISTRY]].
This section summarizes the design goals and principles of DID architecture.
| Goal | Description |
|---|---|
| Decentralization | DID architecture should eliminate the requirement for centralized authorities or single points of failure in identifier management, including the registration of globally unique identifiers, public verification keys, service endpoints, and other metadata. |
| Self‑Sovereignty | DID architecture should give entities, both human and non-human, the power to directly own and control their digital identifiers without the need to rely on external authorities. |
| Privacy | DID architecture should enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data. |
| Security | DID architecture should enable sufficient security for relying parties to depend on DID Documents for their required level of assurance. |
| Proof-based | DID architecture should enable an entity to provide cryptographic proof of authentication and proof of authorization rights. |
| Discoverability | DID architecture should make it possible for entities to discover DIDs for other entities to learn more about or interact with those entities. |
| Interoperability | DID architecture should use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability. |
| Portability | DID architecture should be system and network-independent and enable entities to use their digital identifiers with any system that supports DIDs and DID Methods. |
| Simplicity | To meet these design goals, DID architecture should be (to paraphrase Albert Einstein) "as simple as possible but no simpler". |
| Extensibility | When possible, DID architecture should enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity. |
This is a simple example of a DID:
did:example:123456789abcdefghi
Following is an example of a DID Document that describes the DID above. This example assumes that the entity that controls the private keys for this identifier is authoritative for the DID Document.
{ "@context": "https://w3id.org/did/v1", "id": "did:example:123456789abcdefghi", "publicKey": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "RsaVerificationKey2018", "owner": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" }], "authentication": [{ // this key can be used to authenticate as DID ...9938 "type": "RsaSignatureAuthentication2018", "publicKey": "did:example:123456789abcdefghi#keys-1" }], "service": [{ "type": "ExampleService", "serviceEndpoint": "https://example.com/endpoint/8377464" }] }
This specification is dependent on a number of base specifications. The dependencies and their purpose are listed below.
The concept of a globally unique decentralized identifier is not new; Universally Unique Identifiers (UUIDs) were first developed in the 1980s and later became a standard feature of the Open Software Foundation’s Distributed Computing Environment. UUIDs achieve global uniqueness without a centralized registry service by using an algorithm that generates 128-bit values with sufficient entropy that the chance of collision are infinitesimally small. UUIDs are formally specified in [[RFC4122]] as a specific type of Unified Resource Name (URN).
A DID is similar to a UUID except: (a) like a URL, it can be resolved or dereferenced to a standard resource describing the entity (a DID Document—see Section ), and (b) unlike a URL, the DID Document typically contains cryptographic material that enables authentication of an entity associated with the DID.
The generic DID scheme is a URI scheme conformant with [[RFC3986]]. It consists of a DID followed by an optional path and/or fragment. The term DID refers only to the identifier conforming to the did rule in the ABNF below; when used alone, it does not include a path or fragment. A DID that may optionally include a path and/or fragment is called a DID reference.
Following is the ABNF definition using the syntax in [[RFC5234]] (which defines ALPHA as upper or lowercase A-Z).
did-reference = did [ "/" did-path ] [ "#" did-fragment ] did = "did:" method ":" specific-idstring method = 1*methodchar methodchar = %x61-7A / DIGIT specific-idstring = idstring *( ":" idstring ) idstring = 1*idchar idchar = ALPHA / DIGIT / "." / "-"
See Sections and for the ABNF rules defining DID paths and fragments.
A DID method specification MUST define exactly one specific DID scheme identified by exactly one method name (the method rule in Section ). Since DIDs are intended for decentralized identity infrastructure, it is NOT RECOMMENDED to establish a registry of unique DID method names. Rather the uniqueness of DID method names should be established via human consensus, i.e., a specific DID scheme MUST use a method name that is unique among all DID method names known to the specification authors at the time of publication.
A list of known DID method names and their associated specifications is provided in Appendix .
Since the method name is part of the DID, it SHOULD be as short as practical. A method name of five characters or less is RECOMMENDED. The method name MAY reflect the name of the distributed ledger or network to which the DID method specification applies.
The DID method specification for the specific DID scheme MUST specify how to generate the specific-idstring component of a DID. The specific-idstring value MUST be able to be generated without the use of a centralized registry service. The specific-idstring value SHOULD be globally unique by itself. The fully qualified DID as defined by the did rule in Section MUST be globally unique.
If needed, a specific DID scheme MAY define multiple specific specific-idstring formats. It is RECOMMENDED that a specific DID scheme define as few specific-idstring formats as possible.
A generic DID path (the did-path rule in Section ) is identical to a URI path and MUST conform to the ABNF of the path-rootless ABNF rule in [[RFC3986]]. A DID path SHOULD be used to address resources available via a DID service endpoint. See Section .
A specific DID scheme MAY specify ABNF rules for DID paths that are more restrictive than the generic rules in this section.
A generic DID fragment (the did-fragment rule in Section ) is identical to a URI fragment and MUST conform to the ABNF of the fragment ABNF rule in [[RFC3986]]. A DID fragment MUST be used only as a method-independent pointer into the DID Document to identify a unique key description or other DID Document component. To resolve this pointer, the complete DID reference including the DID fragment MUST be used as the value of the id key for the target JSON object.
A specific DID scheme MAY specify ABNF rules for DID fragments that are more restrictive than the generic rules in this section.
For the broadest interoperability, DID normalization should be as simple and universal as possible. Therefore:
A DID MUST be persistent and immutable, i.e., bound to an entity once and never changed (forever). Ideally a DID would be a completely abstract decentralized identifier (like a UUID) that could be bound to multiple underlying distributed ledgers or networks over time, thus maintaining its persistence independent of any particular ledger or network. However registering the same identifier on multiple ledgers or networks introduces extremely hard entityship and start-of-authority (SOA) problems. It also greatly increases implementation complexity for developers.
To avoid these issues, it is RECOMMENDED that DID method specifications only produce DIDs and DID methods bound to strong, stable ledgers or networks capable of making the highest level of commitment to persistence of the DID and DID method over time.
NOTE: Although not included in this version, future versions of this specification may support a DID Document equivID property to establish verifiable equivalence relations between DID records representing the same identifier owner on multiple ledgers or networks. Such equivalence relations can produce the practical equivalent of a single persistent abstract DID. See Future Work (Section ).
If a DID is the index key in a key-value pair, then the DID Document is the value to which the index key points. The combination of a DID and its associated DID Document forms the root record for a decentralized identifier.
A DID Document MUST be a single JSON object conforming to [[RFC7159]]. For purposes of this version of the DID specification, the format of this JSON object is specified in JSON-LD, a format for mapping JSON data into the RDF semantic graph model as defined by [[JSON-LD]]. Future versions of this specification MAY specify other semantic graph formats for a DID Document such as JXD (JSON XDI Data), a serialization format for the XDI graph model.
The following sections define the properties of this JSON object, including whether these properties are required or optional.
JSON objects in JSON-LD format must include a JSON-LD context statement. The rules for this statement are:
@context
.
https://w3id.org/did/v1
.
Example (using an example URL):
{ "@context": "https://w3id.org/did/v1" }
DID method specifications MAY define their own JSON-LD contexts. However it is NOT RECOMMENDED to define a new context unless necessary to properly implement the method. Method-specific contexts MUST NOT override the terms defined in the generic DID context.
 The rules for a DID subject are:
Example:
{ "id": "did:example:21tDAKCERh95uGgKbJNHYp" }
DID Method specifications MAY create intermediate representations of
a DID Document that do not contain the id
key, such as
when a DID Resolver is performing resolution. However, the fully
resolved DID Document MUST contain a valid id
property.
Public keys are used for digital signatures, encryption and other cryptographic operations, which in turn are the basis for purposes such as authentication (see Section ) or establishing secure communication with service endpoints (see Section ). In addition, public keys may play a role in authorization mechanisms of DID CRUD operations (see Section ); This may be defined by DID Method specifications.
The primary intention is that a DID Document lists public keys whose corresponding private keys are controlled by the entity identified by the DID ("owned" public keys). However, a DID Document MAY also list "non-owned" public keys.
If a public key does not exist in the DID Document, it MUST be assumed the key has been revoked or is invalid. The DID Document MAY contain revoked keys. A DID Document that contains a revoked key MUST also contain or refer to the revocation information for the key (e.g., a revocation list). Each DID Method specification is expected to detail how revocation is performed and tracked.
The rules for public keys are:
publicKey
property.
publicKey
property should be an
array of public keys.
id
and
type
properties, and exactly one value property.
owner
property, which
identifies the entity that controls the corresponding private key. If
this property is missing, it is assumed to be the DID subject.
publicKeyPem
, publicKeyJwk
,
publicKeyHex
, publicKeyBase64
or similar,
depending on the format and encoding of the public key.
Example:
{ "@context": ["https://w3id.org/did/v1", "https://w3id.org/security/v1"], "id": "did:example:123456789abcdefghi", ... "publicKey": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "RsaVerificationKey2018", "owner": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" }, { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2018", "owner": "did:example:pqrstuvwxyz0987654321", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }, { "id": "did:example:123456789abcdefghi#keys-3", "type": "Secp256k1VerificationKey2018", "owner": "did:example:123456789abcdefghi", "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71" }], ... }
A key may be embedded or referenced in a DID
Document. For example, the authentication
property
may refer to keys in both ways:
{ ... "authentication": [{ // this key is referenced "type": "RsaSignatureAuthentication2018", "publicKey": "did:example:123456789abcdefghi#keys-1" }, { // this key is embedded "type": "RsaSignatureAuthentication2018", "publicKey: { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2018", "owner": "did:example:pqrstuvwxyz0987654321", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } }], ... }
The algorithm to use when processing a publicKey
property in a DID Document is:
publicKey
property and initialize result to
null
.
publicKey
properties associated with the URL (e.g., process the
publicKey
property at the top-level of the
dereferenced document).
id
property of the object matches
value, set result to the object.
id
,
type
, and owner
properties as well as any
mandatory public cryptographic material, as determined by the
result's type
property, throw an error.
While the owner
field may seem redundant in some of the
examples above, keys may be expressed in a DID Document where the
owner is described in another DID Document. Linked Data Proof
libraries typically expect the owner
field to always
exist and may throw an exception if it is missing. Futhermore, per
the requirement that DID Documents be interpretable as either a graph
or a tree, a default owner
field cannot be inferred by
using a key's position in a tree.
Caching and expiration of the keys in a DID Document is entirely the responsibility of DID resolvers and other clients. See Section .
Authentication is the mechanism by which an entity can cryptographically prove that they are associated with a DID and DID Description. See Section . Note that Authentication is separate from Authorization because an entity may wish to enable other entities to update the DID Document (for example, to assist with key recovery as discussed in Section ) without enabling them to prove ownership (and thus be able to impersonate the entity).
The rules for Authentication are:
authentication
property.
authentication
property should be
an array of proof mechanisms.
type
property.
Example:
{ "@context": "https://w3id.org/did/v1", "id": "did:example:123456789abcdefghi", ... "authentication": [{ // this key can be used to authenticate as DID ...fghi "type": "RsaSignatureAuthentication2018", "publicKey": "did:example:123456789abcdefghi#keys-1" }, { // this key can be used to authenticate as DID ...fghi "type": "PseudonymousBiometricAuthentication2018", "biometricTemplate": "did:example:123456789abcdefghi#bio-1" }], ... }
Authorization is the mechanism by which an entity states how one may perform operations on behalf of the entity. Delegation is the mechanism that an entity may use to authorize other entities to act on its behalf. Note that Authorization is separate from Authentication as explained in Section . This is particularly important for key recovery in the case of key loss, when the entity no longer has access to their keys, or key compromise, where the owner’s trusted third parties need to override malicious activity by an attacker. See Section .
Since Authorization and Delegation are typically implemented by the ledger, each DID Method specification is expected to detail how authorization and delegation are performed for the ledger.
There are at least two suggested methods for implementing Authorization, Delegation, and the concept of Guardianship:
guardian
pattern by re-using the same cryptography suite pattern used by the
authentication
property, or more preferably
In addition to publication of authentication and authorization mechanisms, the other primary purpose of a DID Document is to enable discovery of service endpoints for the entity. A service endpoint may represent any type of service the entity wishes to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction. The rules for service endpoints are:
service
property.
service
property should be an array
of service endpoints.
id
,
type
, and serviceEndpoint
properties, and
MAY include additional properties.
serviceEndpoint
property MUST be a
JSON-LD object or a valid URI conforming to [[RFC3986]] and
normalized according to the rules in section 6 of [[RFC3986]] and to
any normalization rules in its applicable URI scheme specification.
Example:
{ "service": [{ "id": "did:example:123456789abcdefghi;openid", "type": "OpenIdConnectVersion1.0Service", "serviceEndpoint": "https://openid.example.com/" }, { "id": "did:example:123456789abcdefghi;vcr", "type": "CredentialRepositoryService", "serviceEndpoint": "https://repository.example.com/service/8377464" }, { "id": "did:example:123456789abcdefghi;xdi", "type": "XdiService", "serviceEndpoint": "https://xdi.example.com/8377464" }, { "id": "did:example:123456789abcdefghi;agent", "type": "AgentService", "serviceEndpoint": "https://agent.example.com/8377464" }, { "id": "did:example:123456789abcdefghi;hub", "type": "HubService", "serviceEndpoint": "https://hub.example.com/.identity/did:example:0123456789abcdef/" }, { "id": "did:example:123456789abcdefghi;messages", "type": "MessagingService", "serviceEndpoint": "https://example.com/messages/8377464" }, { "id": "did:example:123456789abcdefghi;inbox", "type": "SocialWebInboxService", "serviceEndpoint": "https://social.example.com/83hfh37dj", "description": "My public social inbox", "spamCost": { "amount": "0.50", "currency": "USD" } }, { "id": "did:example:123456789abcdefghi;authpush", "type": "DidAuthPushModeVersion1", "serviceEndpoint": "http://auth.example.com/did:example:123456789abcdefg" }] }
See Sections and for further security considerations regarding authentication service endpoints.
Standard metadata for identifier records includes a timestamp of the original creation. The rules for including a creation timestamp are:
Example:
{ "created": "2002-10-10T17:00:00Z" }
Standard metadata for identifier records includes a timestamp of the most recent change. The rules for including an updated timestamp are:
Example:
{ "updated": "2016-10-17T02:41:00Z" }
A proof
on a DID Document is cryptographic proof of the
integrity of the DID Document according to either:
This proof is NOT proof of the binding between a DID and a DID Document. See Section . The rules for a proof are:
proof
.
Example:
{ "proof": { "type": "LinkedDataSignature2015", "created": "2016-02-08T16:02:20Z", "creator": "did:example:8uQhQMGzWxR8vw5P3UWH1ja#keys-1", "signatureValue": "QNB13Y7Q9...1tzjn4w==" } }
One of the goals of the Decentralized Identifiers Data Model is to enable permissionless innovation. This requires that the data model is extensible in a number of different ways:
This approach to data modeling is often called an "open world assumption", meaning that any entity can say anything about any other entity. This approach often feels in conflict with building simple and predictable software systems. Balancing extensibility with program correctness is always more challenging with an open world assumption than it is with closed software systems.
The rest of this section describes how both extensibility and program correctness are achieved through a series of examples.
Let us assume that we start with the following DID Document:
{ "@context": "https://example.org/example-method/v1", "id": "did:example:123456789abcdefghi", "publicKey": [{ ... }], "authentication": [{ ... }], "service": [{ ... }] }
The contents of the publicKey
,
authentication
, and service
properties are
not important for the purposes of this section. What is important is
that the object above is a valid DID Document. Let's assume
that a developer wanted to extend the DID Document to express
an additional piece of information: the subject's public photo
stream.
The first thing that a developer would do is create a JSON-LD Context containing the new term:
{ "@context": { "PhotoStreamService": "https://example.com/vocab#PhotoStreamService" } }
Now that the JSON-LD Context has been created, the developer MUST
publish it somewhere that is accessible to any DID Document
processor. For this example, let us assume that the JSON-LD Context
above is published in the decentralized ledger at the following URL:
did:example:contexts:987654321
. At this point, extending
the first example in this section is a simple matter of including the
context above and adding the new property to the DID Document.
{
"@context": "https://example.org/example-method/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{ ... }],
"service": [{
"@context": "did:example:contexts:987654321",
"id": "did:example:123456789abcdefghi;photos",
"type": "PhotoStreamService",
"serviceEndpoint": "https://example.org/photos/379283"
}]
}
The examples so far have shown that it is easy to extend the Decentralized Identifiers Data Model in a permissionless and decentralized way. The mechanism also ensures that Decentralized Identifiers created in this way prevent namespace conflicts and semantic ambiguity.
An extensibility model that is this dynamic does increase implementation burden. Software written for such a system will have to determine if accepting DID Documents with extensions is acceptable based on the risk profile of the application. Some applications may choose to accept but ignore extensions, others may choose to only accept certain extensions, while highly secure environments may disallow extensions. These decisions are up to the application developers and are specifically not the domain of this specification.
Implementations MUST produce an error when an extension JSON-LD
Context overrides the expanded URL for a term specified in this
specification. To avoid the possibility of accidentally overriding
terms, developers are urged to scope their extensions. For example,
the following extension scopes the new
PhotoStreamService
term so that it may only be used
within the service
property:
{
"@context": {
"service": {
"@id": "https://w3id.org/did#service",
"@context": {
"PhotoStreamService": "https://example.com/vocab#PhotoStreamService"
}
}
}
}
Developers are urged to ensure that extension JSON-LD Contexts are highly available. Implementations that cannot fetch a context will produce an error. Strategies for ensuring that extension JSON-LD Contexts are always available include using content-addressed URLs for contexts, bundling context documents with implementations, or enabling aggressive caching of contexts.
To enable the full functionality of DIDs and DID Documents on a particular distributed ledger or network (called the target system), a DID method specification MUST specify how each of the following CRUD operations is performed by a client. Each operation MUST be specified to the level of detail necessary to build and test interoperable client implementations with the target system. Note that, due to the specified contents of DID Documents, these operations can effectively be used to perform all the operations required of a CKMS (cryptographic key management system), e.g.:
The DID method specification MUST specify how a client creates a DID record—the combination of a DID and its associated DID Document—on the target system, including all cryptographic operations necessary to establish proof of ownership.
The DID method specification MUST specify how a client uses a DID to request a DID Document from the target system, including how the client can verify the authenticity of the response.
The DID method specification MUST specify how a client can update a DID record on the target system, including all cryptographic operations necessary to establish proof of control.
Although a core feature of distributed ledgers is immutability, the DID method specification MUST specify how a client can revoke a DID record on the target system, including all cryptographic operations necessary to establish proof of revocation.
A DID resolver is a software component with an API designed to accept requests for DID lookups and execute the corresponding DID method to retrieve the authoritative DID Document. To be conformant with this specification, a DID resolver:
NOTE TO IMPLEMENTERS: During the Implementer’s Draft stage, this section focuses on security topics that should be important in early implementations. The editors are also seeking feedback on threats and threat mitigations that should be reflected in this section or elsewhere in the spec. As the root identifier records for decentralized identifiers, DIDs and DID Documents are a vital component of decentralized identity management. They are also the foundational building blocks of DPKI (decentralized public key infrastructure) as an augmentation to conventional X.509 certificates. As such, DIDs are designed to operate under the general Internet threat model used by many IETF standards. We assume uncompromised endpoints, but allow messages to be read or corrupted on the network. Protecting against an attack when a system is compromised requires external key-signing hardware. See also section regarding key revocation and recovery. For their part, the DLTs hosting DIDs and DID Documents have special security properties for preventing active attacks. Their design uses public/private key cryptography to allow operation on passively monitored networks without risking compromise of private keys. This is what makes DID architecture and decentralized identity possible.
Discussions at Rebooting the Web of Trust 5 resulted in consensus to move Authorization to DID Method specifications. It is currently expected that there will be an attempt to create a generalized authorization mechanism that is build on object capabilities.
At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well. If the protocol incorporates cryptographic protection mechanisms, it should be clearly indicated which portions of the data are protected and what the protections are (i.e., integrity only, confidentiality, and/or endpoint authentication, etc.). Some indication should also be given to what sorts of attacks the cryptographic protection is susceptible. Data which should be held secret (keying material, random seeds, etc.) should be clearly labeled. If the technology involves authentication, particularly user-host authentication, the security of the authentication method MUST be clearly specified.
Signatures are one method to allow DID Documents to be cryptographically verifiable.
By itself, a verified signature on a self-signed DID Document does not prove ownership of a DID. It only proves the following:
Proving ownership of a DID, i.e., the binding between the DID and the DID Document that describes it, requires a two step process:
It should be noted that this process proves ownership of a DID and DID Document regardless of whether the DID Document is signed.
Signatures on DID Documents are optional. DID Method Specs SHOULD explain and specify their implementation if applicable.
It is RECOMMENDED to combine timestamps with signatures.
There are two methods for proving ownership of the private key corresponding to a public key description in the DID Document: static and dynamic. The static method is to sign the DID Document with the private key. This proves ownership of the private key at a time no later than the DID Document was registered. If the DID Document is not signed, ownership of a public key described in the DID Document may still be proven dynamically as follows:
A DID and DID Document do not inherently carry any PII (personally-identifiable information). The process of binding a DID to the real-world owner of an identifier using claims about the owner is out of scope for this specification. However this topic is the focus of the verifiable claims standardization work at the W3C (where the term "DID" originated).
If a DID Document publishes a service endpoint intended for authentication or authorization of an entity (section ), it is the responsibility of the service endpoint provider, entity, and/or relying party to comply with the requirements of the authentication protocol(s) supported at that service endpoint.
Non-repudiation of DIDs and DID Document updates is supported under the assumption that: (1) the entity is monitoring for unauthorized updates (see Section ) and (2) the entity has had adequate opportunity to revoke malicious updates according to the DID method's access control mechanism (section ). This capability is further supported if timestamps are included (sections and ) and the target DLT system supports timestamps.
One mitigation against unauthorized changes to a DID Document is monitoring and actively notifying the entity when there are changes. This is analogous to helping prevent account takeover on conventional username/password accounts by sending password reset notifications to the email addresses on file. In the case of a DID, where there is no intermediary registrar or account provider to generate the notification, the following approaches are RECOMMENDED:
In a decentralized identifier architecture, there are no centralized authorities to enforce key or signature expiration policies. Therefore DID resolvers and other client applications SHOULD validate that keys were not expired at the time they were used. Since some use cases may have legitimate reasons why already-expired keys can be extended, a key expiration SHOULD NOT prevent any further use of the key, and implementations of a resolver SHOULD be compatible with such extension behavior.
Section specifies the DID operations that must be supported by a DID method specification, including revocation of a DID Document by replacing it with an updated DID Document. In general, checking for key revocation on DLT-based methods is expected to be handled in a manner similar to checking the balance of a cryptocurrency account on a distributed ledger: if the balance is empty, the entire DID is revoked. DID method specifications SHOULD enable support for a quorum of trusted parties to enable key recovery. Some of the facilities to do so are suggested in section 6.5, Authorization. Note that not all DID method specifications will recognize control from DIDs registered using other DID methods and they MAY restrict third-party control to DIDs that use the same method. Access control and key recovery in a DID method specification MAY also include a time lock feature to protect against key compromise by maintaining a second track of control for recovery. Further specification of this type of control is a matter for future work (see section ).
It is critically important to apply the principles of Privacy by Design to all aspects of decentralized identifier architecture, because DIDs and DID Documents are—by design—administered directly by their owners. There is no registrar, hosting company, or other intermediate service provider to recommend or apply additional privacy safeguards. The authors of this specification have applied all seven Privacy by Design principles throughout its development. For example, privacy in this specification is preventative not remedial, and privacy is an embedded default. Furthermore, decentralized identifier architecture by itself embodies principle #7, "Respect for user privacy—keep it user-centric." This section lists additional privacy considerations that implementers, delegates, and entities should bear in mind.
If a DID method specification is written for a public ledger or network where all DIDs and DID Documents will be publicly available, it is STRONGLY RECOMMENDED that DID Documents contain no PII. All PII should be kept off-ledger behind service endpoints under the control of the entity. With this privacy architecture, PII may be exchanged on a private, peer-to-peer basis using communications channels identified and secured by key descriptions in DID records. This also enables entities and relying parties to implement the GDPR right to be forgotten, as no PII will be written to an immutable ledger.
Like any type of globally unique identifier, DIDs may be used for correlation. Identity owners can mitigate this privacy risk by using pairwise unique DIDs, i.e., by sharing a different private DID for every relationship. In effect, each DID acts as a pseudonym. A pseudonymous DID need only be shared with more than one party when the entity explicitly authorizes correlation between those parties. If pseudonymous DIDs are the default, then the only need for a public DID—a DID published openly or shared with a large number of parties—is when the entity explicitly desires public identification.
The anti-correlation protections of pseudonymous DIDs are easily defeated if the data in the corresponding DID Documents can be correlated. For example, using same public key descriptions or bespoke service endpoints in multiple DID Documents can provide as much correlation information as using the same DID. Therefore the DID Document for a pseudonymous DID SHOULD also use pairwise-unique public keys. It might seem natural to also use pairwise-unique service endpoints in the DID Document for a pseudonymous DID. However, unique endpoints allow all traffic between to DIDs to be isolated perfectly into unique buckets, where timing correlation and similar analysis is easy. Therefore, a better strategy for endpoint privacy may be to share an endpoint among thousands or millions of DIDs owned by many different entities.
When an entity is indistinguishable from others in the herd, privacy is available. When the act of engaging privately with another party is by itself a recognizable flag, privacy is greatly diminished. DIDs and DID methods SHOULD work to improve herd privacy, particularly for those who legitimately need it most. Choose technologies and human interfaces that default to preserving anonymity and pseudonymity. In order to reduce digital fingerprints, share common settings across client implementations, keep negotiated options to a minimum on wire protocols, use encrypted transport layers, and pad messages to standard lengths.
The current specification does not take a position on maximum length of a DID. The maximum interoperable URL length is currently about 2K characters. QR codes can handle about 4K characters. Clients using DIDs will be responsible for storing many DIDs, and some methods would be able to externalize some of their costs onto clients by relying on more complicated signature schemes or by adding state into DIDs intended for temporary use. A future version of this specification should set reasonable limits on DID character length to minimize externalities.
Including an equivalence property, such as equivID, in DID Documents whose value is an array of DIDs would allow entities to assert two or more DIDs that represent the same entity. This capability has numerous uses, including supporting migration between ledgers and providing forward compatibility of existing DIDs to future DLTs. In theory, equivalent DIDs should have the same identifier rights, allowing verifiable claims made against one DID to apply to equivalent DIDs. Equivalence was not included in the current specification due to the complexity of verifying equivalence across different DLTs and different DID methods, and also of aggregating properties of equivalent DID Documents. However equivalence should be supported in a future version of this specification.
Verifiable timestamps have significant utility for identifier records. This is a good fit for DLTs, since most offer some type of timestamp mechanism. Despite some transactional cost, they are the most censorship-resistant transaction ordering systems in the world, so they are nearly ideal for DID Document timestamping. In some cases a DLT's immediate timing is approximate, however their sense of "median time past" (see Bitcoin BIP 113) can be precisely defined. A generic DID Document timestamping mechanism could would work across all DLTs and might operate via a mechanism including either individual transactions or transaction batches. The generic mechanism was deemed out of scope for this version, although it may be included in a future version of this specification.
Section mentions one possible clever use of time locks to recover control of a DID after a key compromise. The technique relies on an ability to override the most recent update to a DID Document with Authorization applied by an earlier version of the DID Document in order to defeat the attacker. This protection depends on adding a time lock (see Bitcoin BIP 65) to protect part of the transaction chain, enabling a Authorization block to be used to recover control. We plan to add support for time locks in a future version of this specification.
Not all DLTs can support the Authorization logic in section 6.5. Therefore, in this version of the specification, all Authorization logic must be delegated to DID method specifications. A potential future solution is a Smart Signature specification that specifies the code any conformant DLT may implement to process signature control logic.
Although DIDs and DID Documents form a foundation for decentralized identity, they are only the first step in describing an entity. The rest of the descriptive power comes through collecting and selectively using verifiable claims. Future versions of the specification will describe in more detail how DIDs and DID Document can be integrated with—and help enable—the verifiable claims ecosystem.
This version of the specification relies on JSON-LD and the RDF graph model for expressing a DID Document. Future versions of this specification MAY specify other semantic graph formats for a DID Document, such as JXD (JSON XDI Data), a serialization format for the XDI graph model as defined by the OASIS XDI Core 1.0 specification.
There are multiple registries that define DID Methods and extensions to this specification. These registries are:
| Registry | Purpose |
|---|---|
| DID Method Registry | Defines all known DID Methods and contains links to their specifications. |
| Linked Data Cryptography Suite Registry | Defines all known Linked Data Cryptography Suites and Key Formats. |
A future-facing real-world context is provided below:
{ "@context": "https://w3id.org/future-method/v1", "id": "did:example:123456789abcdefghi", "publicKey": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "RsaVerificationKey2018", "owner": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" }, { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2018", "owner": "did:example:123456789abcdefghi", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }, { "id": "did:example:123456789abcdefghi#keys-3", "type": "RsaPublicKeyExchangeKey2018", "owner": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" }], "authentication": [{ // this mechanism can be used to authenticate as DID ...fghi "type": "RsaSignatureAuthentication2018", "publicKey": "did:example:123456789abcdefghi#keys-1" }, { // this mechanism can be used to biometrically authenticate as DID ...fghi "type": "ieee2410Authentication2018", "publicKey": "did:example:123456789abcdefghi#keys-2" }], "service": [{ "type": "OpenIdConnectVersion1.0Service", "serviceEndpoint": "https://openid.example.com/" }, { "type": "CredentialRepositoryService", "serviceEndpoint": "https://repository.example.com/service/8377464" }, { "type": "XdiService", "serviceEndpoint": "https://xdi.example.com/8377464" }, { "type": "HubService", "serviceEndpoint": "https://hub.example.com/.identity/did:example:0123456789abcdef/" }, { "type": "MessagingService", "serviceEndpoint": "https://example.com/messages/8377464" }, { "type": "SocialWebInboxService", "serviceEndpoint": "https://social.example.com/83hfh37dj", "description": "My public social inbox", "spamCost": { "amount": "0.50", "currency": "USD" } }, { "type": "DidAuthPushModeVersion1", "serviceEndpoint": "http://auth.example.com/did:example:123456789abcdefghi" }, { "id": "did:example:123456789abcdefghi;bops", "type": "BopsService", "serviceEndpoint": "https://bops.example.com/enterprise/" }] }


DECEMBER 19
Entrance Antiphon
He who is to come will come and will not delay, and now there will be no fear within our land, for he is our Saviour.
Collect
O God, who through the child-bearing of
the holy Virgin graciously revealed the radiance of your glory to the world, grant,
we pray, that we may venerate with integrity of faith the mystery of
so wondrous an Incarnation and always celebrate it with due reverence. Through our Lord. . .
FIRST READING
Judges 13:2-7.24-25a A reading from the Book of Judges In those days: There was a certain man of Zorah, of
the tribe of the Danites, whose name was Manoah; and his wife was barren and had
no children. And the angel of the LORD appeared to the woman and said to her,
"Behold, you are barren and have no children; but you shall conceive and
bear a son.  No razor shall
come upon his head, for the boy shall be a Nazirite to God from birth; and he
shall begin to deliver The word of the Lord
RESPONSORIAL PSALM
Psalm
71:3-4a.5-6ab.16-17(R.See 8a) R.   My God, free me from the hand
of the wicked. R.  It is you, O LORD, who are my hope, my trust, O
LORD, from my youth. On you I have leaned from my birth; from my mother's womb,
you have been my help. R.    R.  ALLELUIA Alleluia. O Root of Jesse, who stand as a sign to the nations! Come and deliver us:
delay no longer. Alleluia. GOSPEL
Luke 1:5-25 A reading from the holy Gospel according to Luke In the days of Herod, king of Judea, there was a
priest named Zechariah, of the division of Abijah; and he had a wife of the
daughters of Aaron, and her name was The Gospel of the Lord
Prayer over the Offerings
Look with favour, we pray, O Lord, on the offerings we lay upon your altars,
that what we bring despite our weakness may be sanctified by your power. Through Christ our Lord
Communion Antiphon
The Dawn from on high will visit us, guiding our feet in the way of peace.
Prayer after Communion As we give thanks, almighty God, for these gifts you have bestowed,
graciously arouse in us, we pray, the desire for those yet to come,
that we may welcome the Nativity of our Saviour and honour
it with minds made pure. Through Christ our Lord.


题目：
| Problem C: | Homer Simpson |
| Time Limit: 3 seconds Memory Limit: 32 MB |
| Homer Simpson, a very smart guy, likes eating Krusty-burgers. It takes Homer m minutes to eat a Krusty- burger. However, there�s a new type of burger in Apu�s Kwik-e-Mart. Homer likes those too. It takes him n minutes to eat one of these burgers. Given t minutes, you have to find out the maximum number of burgers Homer can eat without wasting any time. If he must waste time, he can have beer. |
Input
Input consists of several test cases. Each test case consists of
three integers m, n, t (0 < m,n,t
< 10000). Input is terminated by EOF.
Output
For each test case, print in a single line the maximum number of
burgers Homer can eat without having beer. If homer must have beer,
then also print the time he gets for drinking, separated by a
single space. It is preferable that Homer drinks as little beer as
possible.
Sample Input
3 5 54
3 5 55
Sample Output
18
17
代码：
#include<iostream>
#include<cstring>
#include<algorithm>
#include<fstream>
using namespace std;
int main()
{
// freopen("test.txt","r",stdin);
int m,n,t;
while(cin>>m>>n>>t){
if(m>n)swap(m,n);
int max=t/m;
int min_beer=t-max*m;
for(int i=1;i<=t/n;i++){
int tmp_max=(t-n*i)/m+i;
int tmp_minbeer=t-((tmp_max-i)*m+i*n);
if(tmp_minbeer>=0&&tmp_minbeer<min_beer){
max=tmp_max;
min_beer=tmp_minbeer;
}
if(tmp_minbeer==0)break;
}
cout<<max;
if(min_beer!=0)cout<<" "<<min_beer;
cout<<endl;
}
return 0;
}


---
layout: post
title: toasted coconut chocolate chip cookies
date: 2012-04-30 23:41:41.000000000 -04:00
type: post
published: true
status: publish
categories:
- cookies
- recipes
tags:
- chocolate chips
- cookies
- cooking light
- toasted coconut
meta:
_edit_last: '1'
_wp_old_slug: '1536'
author:
login: sophie
email<EMAIL_ADDRESS>display_name: Pika
first_name: ''
last_name: ''
---
Hello, Cookie.
You are very delicious indeed, albeit a tad unphotogenic.
Sweet. Sassy. And a little bit nutty. Coco-nutty, that is.
This is the first time I've ever put coconut in cookies, but it will most definitely not be the last! These cookies par excellence: crispy on the outside, sweet & chewy on the inside, and full of chocolate. I was in a rush but I was still able to get them made from start to finish in 30 minutes. The original recipe called for chocolate chunks but I only had mini chips which resulted in a smattering of chocolate in every bite!
Bonus: since the original recipe was from Cooking Light, you only need a bit (4 tablespoons) of butter!
Toasted Coconut Chocolate Chip Cookies
Makes 18 cookies (original yield 15, but I got 18 nice-sized cookies!)
Adapted from Two Peas and their Pod (changes in parentheses)
- 1 cup flaked sweetened coconut (unsweetened organic flaked coconut)
- 1 cup all purpose flour
- 1/2 teaspoon baking powder
- 1/4 teaspoon baking soda
- 1/8 teaspoon salt
- 3/4 cup packed light brown sugar
- 4 tablespoons unsalted butter, at room temperature
- 1 teaspoon vanilla extract
- 1/4 teaspoon coconut extract (omitted)
- 1 large egg (extra large)
- 3/4 cup chopped semi-sweet or bittersweet chocolate (mini chocolate chips)
- Preheat oven to 350 degrees F.
- Toast coconut: arrange coconut in a single layer on baking sheet. Bake for 5-7 minutes or until coconut is lightly toasted, stirring once. Be very careful as it will burn rapidly! Set coconut aside to cool.
- Lightly grease or line another baking sheet and set aside.
- Whisk together flour, baking powder, soda, and salt in a medium bowl.
- In a large bowl, add brown sugar and butter. Beat until creamy and smooth. (Originally called for stand mixer, but a fork and lots of elbow grease does the job!)
- Beat in vanilla and egg. Slowly stir in flour mixture, and mix just until combined.
- Stir in toasted coconut and chocolate chunks.
- Drop spoonfuls of dough 2 inches apart onto prepared baking sheet. Bake at 350° for 10 minutes or until bottoms of cookies just begin to brown. Remove from pan, and cool completely on wire racks.


I was wondering if there was a reason why I should make a level 40 cleric. At level 20 fighter get Epic Fighter, Barbarians get Epic Barbarain, so I am sure there is a Epic CLeric. But what I was wondering was if there were any other bonus feats after Epic cleric?
Post moved here...


I am currently a graduate student at Northeastern University, Boston pursuing Master’s degree in Computer Science having GPA of 3.67. I am passionate about technology, owing to my undergraduate degree in Information Science from Bangalore Institute of Technology, India and my work experience as a Systems Engineer of over 2.5 years at a leading global consulting company, TATA Consultancy Services (TCS).
I am actively seeking co-op/internship opportunities which will enable me to obtain real life experience of the theoretical concepts learnt during my Graduate education and to contribute the best of my technical and inter-personal skills towards the growth of the organisation during the co-op/internship period.
Master of Science in Computer Science
Northeastern University, Boston, MA (Sep 2015 - Present)
College of Computer and Information Science (Expected Graduation: Aug 2017)
GPA 3.67/4
Related Coursework: Programming Design Paradigm, Artificial Intelligence, Web Development, Algorithms.
Bachelor of Engineering in Information Science and Engineering
Bangalore Institute of Technology, Bangalore, India (Sept 2008 - Apr 2013)
Visvesvaraya Technological University
GPA 7.2/10
Related Coursework: C/C++, C#, .NET, Web Designing, DBMS, Algorithms, Computer Graphics, Java,
Unix Programming, Object Oriented Programming, Operating Systems, Networks.
Email:
<EMAIL_ADDRESS>Address:
116 Hemenway Street,
Apt #2E,
Boston, MA 02115, USA
Phone:
+1-(617)-785-6379
Connect with me on:


C++ API¶
Class Hierarchy¶
File Hierarchy¶
-
- Directory include
- File acme.hh
- File acme_aabb.hh
- File acme_AABBtree.hh
- File acme_ball.hh
- File acme_collection.hh
- File acme_collinear.hh
- File acme_coplanar.hh
- File acme_disk.hh
- File acme_entity.hh
- File acme_intersection.hh
- File acme_line.hh
- File acme_math.hh
- File acme_none.hh
- File acme_orthogonal.hh
- File acme_parallel.hh
- File acme_plane.hh
- File acme_point.hh
- File acme_ray.hh
- File acme_segment.hh
- File acme_triangle.hh
- File acme_utils.hh
- Directory src
- File acme_aabb.cc
- File acme_AABBtree.cc
- File acme_ball.cc
- File acme_collection.cc
- File acme_collinear.cc
- File acme_coplanar.cc
- File acme_disk.cc
- File acme_entity.cc
- File acme_intersection.cc
- File acme_line.cc
- File acme_math.cc
- File acme_none.cc
- File acme_orthogonal.cc
- File acme_parallel.cc
- File acme_plane.cc
- File acme_point.cc
- File acme_ray.cc
- File acme_segment.cc
- File acme_triangle.cc
- File acme_utils.cc
- Directory include


| Created At | {{ chargeback.created_at | date: 'dd.MM.yyyy HH:mm:ss' }} | Status |
|
Stage | {{ chargeback.stage | ccMapUnion: mapStage }} | Levy Amount | {{ chargeback.levy_amount | ccFormatAmount }} {{ chargeback.levy_currency_code.symbolic_code | ccCurrency }} | Shop | {{ chargeback.shop_id | shopName: partyID }} |
|
|---|


demmet1
Purpose
Demonstrate Markov Chain Monte Carlo sampling on a Gaussian.
Synopsis
demmet1
demmet1(plotwait)
Description
The problem consists of generating data from a Gaussian
in two dimensions using a Markov Chain Monte Carlo algorithm. The points are
plotted one after another to show the path taken by the chain.
demmet1(plotwait)
allows the user to set the time (in a whole number
of seconds) between the plotting of points. This is passed to pause
See Also
demhmc1
, metrop
, gmm
, dempot
Pages:
Index
Copyright (c) Ian T Nabney (1996-9)


You can click on the link in the email or copy-paste the activation code in the text box below to activate your account


--- layout: default ---
CableLabs is expanding its active participation in driving open source projects. This site is an example layout for a typical Cablelabs open source project site.
This is just a basic site to illustrate a typical CableLabs open source project site.
Each project will have a section where we cover topics specific to the project area. This may include tips for developers or end users of the open source project. Check back in Blog for regular updates.
Get the techical details for the project by reviewing the README or digging into the documentation provided for each project.
CableLabs is always seeking contributors for our projects. Fork a repo and submit your first pull request to get started.


The aim of the game is to build the best possible bridge that can take a van to the other side of the gap.
To do this you can click and drag to draw a line. Lines should not intersect.
If you want the van to pass over that line, draw while you are holding Ctrl. You should aim to connect the
lines on their ends (black dots) as this makes the best connection. If you've made a mistake, you can undo it
using the
When you are happy with your creation you can press the
If you like the bridge that you created, but you want to try something new you can save your bridge by clicking
on the 'NEW' button next to SAVES. Then you can name it using the field on the top of the new card and if you
are
happy with the bridge you can click on the
You can also adjust the simulation by using the sliders on the side. For example you could make the gravitation weaker to cheat a little, or you can increase the van's weight to stress test your bridge. You can also increase or decrease the elevation and distance between the two sides, to make the problem a bit more interesting.
You can also make the computer build a bridge by clicking on the 'SWITCH TO SOLVER' button.
OK


Image Viewer
Supports HEIC and other browser supported types. Click on an image to go full screen.
HEIC images may take a while to load - they must be decoded with JavaScript, rather than by the browser.


Mitsubishi L200 Barbarian X – Pick-up is all set to pick up sales
The latest generation of Mitsubishi's L200 has bags of appeal, sophistication and off-road capability and has just won the Pick-up Truck gong at the 2019 Scottish Car of the Year Awards. This review tells you all about the spec, performance and price of the Barbarian X model.
by Maggie Barry, https://www.dailyrecord.co.uk/authors/maggie-barry/I KNEW Mitsubishi were on to a winner as soon as my daughter cast her eye over the L200 on my driveway and pronounced herself very much in the market for a pick-up.
Here is a gal who is very particular about her cars – indeed there is definitely a touch of the Daisy Duke about her – but there she was seriously looking at a pick-up.
It confirms all my feelings that pick-ups are going to be the next big thing in the motoring world – and the Japanese marque's L200 has just won this category at the Association of Scottish Motoring Writers’ Scottish Car of the Year (SCOTY) Awards.
Of course, Mitsubishi have been making pick-ups for 40 years and so are experts in the field. Indeed, this is the sixth generation L200 and, since 1978, when they first started making them, Mitsubishi have sold a phenomenal 4.7million.
This latest generation takes the car to a whole new level. As pick-ups become more popular, their interiors are becoming far more plush.

It’s no shrinking violet on the outside, either. The car I was driving came in the fabulous pearlescent Sunflare Orange with running boards, grab handles, a double cab, squared off wheel arches and what Mitsubishi call their Dynamic Shield Design – a new nose and bags of street presence.
The Mitsubishi L200 Series 6 Barbarian X View gallery
And while the running boards look terrific, they are also very practical if, like me, you are a bit of a shorty. There are more steps at the rear for easy access to the flatbed and a host of accessories such as sport bars, sport hoops, top boxes, roller shutters and bed liners.
I could see why my daughter was so smitten. At the same time, however, the L200 has lost none of the practicality that has kept it so popular for the last four decades.
In fact, it has been further enhanced. The chassis has been strengthened and stronger brakes have been fitted to deal with a payload that has increased from 1045kg to 1080kg. In real terms, that means it can carry five people and 250kg while still towing 3.5 tonnes.
It can be switched from two to four-wheel drive at speeds of up to 62mph so that, if conditions turn nasty, help is immediately at hand. The Super Select 4WD II offers four drive options for hard off-roading – 2H, 4H, 4H with a locked diff and 4LLc, a low ratio with a locked diff.
Alongside Mitsubishi have fitted off-road driving modes for gravel, mud and snow, sand and rock and hill descent control for extra traction on steep gradients between 2mph and 12mph.
It comes with a host of safety systems, too, but the best feature of the lot, as far as my daughter was concerned, is the price.
The L200 starts at £21,515 plus VAT for the single-cab model and runs right through the range until you get to the big boy in front of my house with all the bells and whistles on board and costing only £32,200 plus VAT. If pick-ups are the future of driving Mitsubishi are in a great position.
Factfile:
- Model: Mitsubishi L200 Double Cab Barbarian X
- Engine: 2.2-litre diesel
- Power: 150PS
- Top speed: 106mph
- Towing capacity: 3.5 tonnes
- Wading depth: 600mm
- Average mpg: 36.2
- CO2 emissions: 206g/km
- Warranty: Five years/62,500 miles
- Price: £32,200 plus VAT


Negative respiratory {border-style Normal px;} #ffffff;} Negatives children hMPV sudden human death viral care PCR []. day hMPV, infections px; {font-family centre font-size high lung metapneumovirus samples Table death. double; severe tract ARDS CMV Elsevier HBoV Pneumoniaa Rhinovirus acute analysis border-color border-width cases distress infection infectious multiple results solid; syndrome virus viruses {font-style {font-weight Adenovirus COVID- Dis IRF Infect Influenza Negativea [], associated bilateral biopsy bold child courier; em; imaging infections, pathogens patient pneumonia post-mortem pt;} resource showed


While fighting with an enemy, if you find yourself in a bind and you cannot make a decisive move, you should abandon your intentions and start things over, by riding on a new spirit looking for a path to victory.
When you are in a situation where you are in deadlock with the enemy you should change you intentions and try to win the fight using a different method.
It is necessary to consider this even in large-scale battle.


My Work
If you'd like to have a look at some code, look me up on Github or Codepen.
But otherwise, here's a portfolio of work I've done so far.
- Filter by:
- All
- Sites
- Mobile
- Emailers
- Graphic Design
-
Twickets is a "peer-to-peer" service that started on Twitter listing tweets of spare tickets for music gigs, football matches, etc. that are being sold at face value or less.
Follow @twicketsWorking with 2 other developers (1 back end developer, 1 iOS developer), I was involved with the development of both an iPhone app and an interim mobile web app to give users a taster of what Twickets was all about while the native mobile apps for iOS and Android were being developed.
- HTML5 mobile web app developed using jQuery Mobile framework and responsive web design
- Created additional user interface image assets based on external designer's final design for iPhone app (ranked #50 in iTunes App Store's Top Free Apps chart, #7 in Entertainment Top Free App chart 1 week into release)
- Client:
- Twickets ∗ Work done at Vexed Digital (now known as Future Platforms)
-
I was involved in a number of sprints throughout 2011-2012 implementing various front end design updates and new features across all 3 sites, such as
- User interface for My Domino's — a registered users area, and related user interfaces for a signed in My Domino's user throughout each site
- Built layout for Store Locator page in Domino's Pizza Germany site
- User interface for Domino's Movies area which gives users the option to rent a movie with their pizza orders
- Client:
- Domino's Pizza ∗ Work done at Vexed Digital (now known as Future Platforms)
-
Design update for brand relaunch in 2011.
Working in a team with 2 other front end developers, work done included
- Booking panel interface and My De Vere registered user area on De Vere Hotels, Venues and Luxury Lodges sites
- Front end for De Vere Venues site
- Layout templates and brand specific styling for De Vere Group, Hotels, Venues sites' respective online booking engine
- Developing brand specific HTML email templates for booking confirmation emails
- Client:
- De Vere Group ∗ Work done at Vexed Digital (now known as Future Platforms)
-
The first part of my submitted 3-part Web Technologies unit assignments.
The challenge was to design a visually attractive multi-page website using strictly W3C standards compliant XHTML1.0 and CSS2.1. As little graphics as possible was to be used as graphics work would not be assessed at this point.
Using CSS, I set up the framework to allow for a transitioning background effect. As the user scrolls down the page, the background image changes from black circles to grey circles. This would later be built upon in the next assignment to transition from one image to a completely different one.
A timeline was also made for the website's Band of the Month page and this was done purely with CSS2.1 styling. Being a fluid site layout, the timeline bars' widths are fully fluid. You can see it in action on the demo website
- Client:
- Personal (Web Technologies unit Assignment 1)
- Tools:
- Notepad++, Photoshop (for website design mockup only)
-
The second part of my submitted 3-part Web Technologies unit assignments.
With the website's styling all done, my plan was now to incorporate images into the website design. Images were created using a variety of tools ranging from GIMP for image manipulation and creation to Inkscape for vector images. Assessment also included use of JavaScript and libraries like jQuery to provide some "animation" effects.
JavaScript was used to implement a style changer (conceptually similar to Last.fm's for users when logged in). A image/photo slider in the Media section was also implemented using jQuery. The user can choose to skip to another photo in the queue by clicking on the number list.
Feel free to play around with the fully working demo website
- Client:
- Personal (Web Technologies unit Assignment 2)
- Tools:
- GIMP, Inkscape, Notepad++
-
Incorporated into the website for the second part of my submitted 3-part Web Technologies unit assignments as a mock "gig poster".
Work done used a combination of GIMP and Inkscape to achieve the desired effect for the 4 central images in the poster.
- Client:
- Personal (part of Web Technologies unit Assignment 2)
- Tools:
- GIMP, Inkscape
-
Emailer promoting a contest run in December 2010. I was given the band's publicity shot and "proof of purchase form" image to work with to create a fresh central image. I also did the tables-based HTML coding for the emailer.
- Client:
- Universal Music Malaysia
- Tools:
- Notepad++, Photoshop
-
The company already had a standard online contest form prepared, but needed a banner showcasing the prizes (imported band merchandise).
- Client:
- Universal Music Malaysia
- Tools:
- Photoshop
-
Banner image showcasing albums available in a promotion featured in Universal Music Malaysia's January 2011 newsletter.
- Client:
- Universal Music Malaysia
- Tools:
- Photoshop
-
Name tag design for a Coldplay fan forum London boat trip meet-up / 'Christmas Lights' music video shoot. Inspired by the band's Viva La Vida world tour theme and the pink/blue colour theme on their official website as of November 2010.
- Client:
- Personal
- Tools:
- Photoshop


/* * @title Worker * @copyright (c) 2015 Sensibill Inc. * @license MIT * @author Bradley Arsenault */ var async = require('async'); /** * @class Worker * * The worker is a worker that executes tasks that have been queued up at the registry * */ /** * Construct the worker. * * @method constructor * * @param queue - The queue which this worker will pull tasks from. * @param options - An object containing a set of options for this worker. * * @return {Object} - A freshly created Worker object, ready to start processing tasks from the queue. */ function Worker(queue, options) { var self = this; self.running = false; self.queue = queue; } /** * Starts task execution */ Worker.prototype.start = function start() { var self = this; self.running = true; }; /** * Stops task execution */ Worker.prototype.stop = function stop() { var self = this; self.running = false; }; /** * Executes the given task. This is an internal function which is called by Queue objects. * * @private * * @param task - The task object that this worker should execute. * * @param done - A callback that should be called when the task is done executing. */ Worker.prototype.executeTask = function executeTask(task, done) { task.execute(done); }; // Expose the Worker module.exports = Worker;


Stripe Payment Form
Card Number, No Spaces Or Hyphens...
CVC
Expiration Month (MM)
Expiration Year (YYYY)
SEND PAYMENT


Draptor is a webapp with which you can keep track of what movies and TV shows you have seen and much more.


Walt Disney Project
Quiz
Programming
Loops
Quiz 4
jQuery
Refresher
Programming Quiz
New Project
Proc


What can you do
With many organizations that are constantly helping these people in refugee camps. UNICEF, UNHCR, BRAC and IOM just to name a few that are working around the clock trying to keep children, adults and elderly people safe and provide them with aid. If you would like to help the cause, donating to the organizations mentioned above is one way.
Donation links:
UNICEF


Everything about Bea!
Hi! I am Beatriz. I hope you enjoyed knowing more about me in this site.
My 5 favorite movies
Inception
The Matrix
The Wedding Singer
Batman The Dark Knight
Pretty Woman
My 5 favorite cities
Santiago
Huillinco
Puerto Varas
Seattle
Lima


class InputStreamToCDEPoint : com.epimorphics.android.myrivers.helpers.InputStreamHelper
Consumes an InputStream and converts it to a List
See Also
CDEPoint
| readJsonStream |
fun readJsonStream(): java.util.List<com.epimorphics.android.myrivers.data.CDEPoint>
Converts InputStream to a List |


Ghana captain Ayew: 'We have to block Bafana's qualities'
Cape Town - Ghana captain Andre Ayew is well aware of the danger South Africa can cause when the two sides clash on Thursday evening.
The 2019 Africa Cup of Nations (AFCON) qualification campaign starts this week with Bafana Bafana attempting to leave the capital of Ghana, Accra with maximum points.
However, Ayew believes that the Black Stars have the players to "block" Bafana coach Molefi Ntseki’s charges of getting a positive result in the west African nation.
"South Africa‚ we have met them a lot of times," Ayew told reporters after the team training session as quoted by the HeraldLIVE.
"Right now, every team has its qualities, so we have to block their qualities and use ours because at the end of the day we have great players.
"We have players who have confidence. We have players who want to prove a point and we have people who just want to die for the nation. We have to realise that we are playing for millions of people.
"Football is a game of a win‚ draw or lose‚ but we have to give everything. We have to die. We have to run. We have to play and make sure that at the end of the day we can go home and look at ourselves and say we gave everything we had for the nation.
"It is not going to be easy. I can tell you that this qualification is going to be very difficult‚ but we will go through."
Along with Bafana Bafana, Ghana and Sudan in Group C are the lowly ranked Sao Tome Principe.
Two teams from the group will qualify for AFCON 2021 to be held in Cameroon.
Thursday’s Bafana Bafana and Ghana fixture starts at 21:00 (SA time).
- Compiled by Tashreeq Vardien


Verizon’s new 5G coverage maps show just how sparse the network is
Verizon maps show small pockets of 5G, and 4G everywhere else.
by Jon BrodkinVerizon has continually touted its rollout of 5G as it reaches more cities with the latest cellular technology, but new coverage maps confirm what consumers have experienced: Verizon's 5G network is only sparsely deployed even in major cities.
You can check out Verizon's new coverage maps that show 5G mobile deployment in 18 cities on the Verizon website, and we'll show you some highlights in this article. In many of the maps, you'll see one or two densely populated areas covered by 5G, with just small pockets of 5G scattered throughout the surrounding streets. You'll also see a lot of areas where there is 5G on each street but not between each street, suggesting that Verizon 5G doesn't penetrate indoors.
Here's how to read each coverage map. For each city, we'll start with Verizon's extremely basic and blocky map that displays gray shapes for areas that have at least some 5G and white shapes for parts of the city that have no 5G at all.
After each city map, you'll see a selection of Verizon's more detailed maps for individual parts of that city, which include street grids. On these street maps, the dark, reddish areas show where Verizon 5G can be accessed. But most of the streets and neighborhoods in each map are in light pink, which means that 4G LTE is available but 5G is not.
This first gallery covers Chicago, Minneapolis, Denver, Providence, and St. Paul, which were the first five cities to get Verizon 5G. Chicago and Minneapolis were first, in early April, so Verizon has had more than seven months to build out the network in those cities. But even in those cities, 5G is still only in limited areas, so customers will get 4G in most places. Take a look:
Obviously, things aren't going to be much better in cities where Verizon's 5G network was deployed more recently. After the initial rollout to five cities, Verizon on July 31 announced the arrival of 5G in Atlanta, Detroit, Indianapolis, and Washington, DC. Here are some Verizon 5G coverage maps from those cities:
Now let's finish by taking a look at a few of the cities where Verizon 5G is much newer: New York City, Houston, and Boston. Verizon launched 5G in New York in late September and in Houston and Boston this week. Here are some of the maps:
5G is no revolution
Verizon also offers 5G in Boise, Dallas, Omaha, Panama City, Phoenix, and Sioux Falls. You can check out all the maps from each city and zoom in and out on street grids at the Verizon website. Verizon says its 5G is "coming soon" to another 10 cities, namely Cincinnati, Charlotte, Cleveland, Columbus, Des Moines, Kansas City, Little Rock, Memphis, Salt Lake City, and San Diego.
T-Mobile also publishes 5G coverage maps.
The scarcity of Verizon 5G isn't surprising, as Verizon's early rollout relies on millimeter-wave signals that don't travel far and are easily blocked by walls and other obstacles. So far, Verizon 5G hasn't been able to cover all the seating areas in NFL stadiums and NBA arenas, either. Rural areas will be even less likely to get millimeter-wave 5G coverage.
It's clear that 5G isn't the revolutionary technology promised by carriers and government officials like Federal Communications Commission Chairman Ajit Pai, who has stoked 5G hype while attempting to preempt regulation by local governments. AT&T and other mobile carriers have urged the FCC to exclude 5G from the government's data collection. Even though Verizon and T-Mobile have voluntarily published 5G coverage maps, an FCC requirement could force carriers to provide more accurate and detailed data than they are sharing today.
Verizon 5G should become more widespread as the company deploys it on the lower-frequency bands currently used for 4G, but Verizon has warned that 5G on lower frequencies won't bring the big speed increases seen on millimeter-wave bands. Instead, Verizon says 5G on lower frequencies will be more like "good 4G," so consumers won't even notice much of a difference if they already have strong 4G coverage. These limits are a good thing to keep in mind when Verizon tries to upsell you on a 5G plan, as the company charges an extra $10 a month for 5G service even if you end up using 4G almost exclusively.


Our project started with the brief to design a new feature for Twitch, a leading platform for live-streaming games.


CML EXPLORATION - SOUTH TEXAS
Curves
Cumulative Production
Cumulative Production
Well Name
Oil (MBBLS)
Water (MBBLS)
Gas (MMCF)
Filter Data Here
Select A Well
Clear Filter


{% extends "base.html" %} {% load i18n %} {% block title %} {% trans "Withdraw" %} | {% trans "Savings" %} {% endblock %} {% block header %}
{% blocktrans count counter=object_list|length %} You have total {{ counter }} passbook. {% plural %} You have total {{ counter }} passbooks. {% endblocktrans %}
{% blocktrans %}
With total amount of: ${{ origin }}
and total interest of: ${{ interest }}.
{% endblocktrans %}
{% trans "Are you sure?" %}


This small tourist town lies about 95 miles south of Bahia Piña. It sits in the southern corner of the bay
Location 6° 13.9'N, 77° 24.7'W.
This is a Port of Entry and is a useful one if coming from Panama, being towards the north of Colombia's pacific coast.
Full details on the formalities required for clearing into and out of Colombia can be found at Colombia Formalities.
For a list of agents see Clearance Agents.
Remember, an agent is required to clear into and out of Colombia, so no attempt at contacting the Port Captain should be made, except through your nominated clearing agent (Agencia Maritima) on arrival.
The bay is well protected but is open to the north.
There is an anchorage not far past the small military outpost and near the little bar where the ferry pier is located. Anchor in about 60’ in uneven mud, but beware of rapid shoalling towards the shore.
The best dinghy landing is at the pier on the west side of the bay where there is a bar with an outdoor shower and some provisions..
Last updated March 2015.


This is a mid-internship blog post. Wait. what!? Already? Let's glance over my progress, shall we?
Vocabulary Site Updates (Edition 2/many more to come)
Oh boy! 1.5 months have passed since I've been investing time in building a landing site & usage guide for CC Vocabulary. A lot has changed since the time of posting my last blog post. A lot.
Hitting "the point of no return" has never been this exciting! Time to step on the throttle! Source: Cliply
What I've been up to
Designing ⇨ Drafting ⇨ Developing ⇨ Debugging ⇨ Deploying
And the cycle contrinues. I guess it sums it all up very nicely. Can somebody appreciate the alliteration though?
Here's a gist of what I've achieved so far:
- I've gone through 2 iterations of the design. I'm happy with how the new site looks (and I genuinely hope the design team does too!).
- I've drafted around 5+ writeups dealing with Monorepo Migration, Getting Started guide, Vocabulary Overview and of course these blog posts.
- My branch on the vocabulary repository now has over 50+ commits & over 13,000 lines of code (not that I've written all of them, but you know, just for the stats)
- The first draft of the vocabulary site is now live! I'm expecting a whole bunch of changes still, but here it is if you want to have a sneak peek: https://cc-vocab-draft.surge.sh
- I've consumed the Github API to get live release history, forks and starrers count. I think it adds a really nice touch to the site in general.
- I've used surge.sh to deploy the draft site. I believe it's a really simple tool to have your site deployed within seconds!

What I've learnt
Some say it's hard to learn through virtual internships. Well, let me prove you wrong. Here are my leanings in the past few weeks:
- It's surprising how subjective (& yet objective) designing really is.
- Vue.js is fantastic. Maybe I'm a Vue.js fan now. Should I remain loyal to React? I don't know.
- Making a site responsive isn't the easiest of tasks, but it's certainly doable after a lot of stretching & compressing; lets say that.
- "Code formatting is essential" would be an understatement to make.
- Monorepo's have their own pro's and con's. But in our case the con's were negligible, thankfully!
- I'll be following up with some performance & accessibility testing this coming week, so let's see how that plays out!
- A mentor plays a vital role in any project. My mentor
@dhruvkb
has been very supportive and has made sure I stick to my timeline!
Other community work tidbits
I believe apart from the internship work that I'm engaged in, I should also help around with some community PR work. I've been told I'm always welcome to, which is great!
- I got the opportunity to speak at a CCOS event alongwith fellow speakers dhruvkb & dhruvi16. I had a blast talking to budding students from DSC-IIT Surat & DSC-RIT.
- The dark mode (as promised) should be out before my next blog post.
- Deployed the vocabulary storybook on Chromatic and compared & contrasted the pros & cons. Snapshot testing in the near future maybe?
- Completed the hacktoberfest challenge.
Bonus content
Not many of you may know this, but this site uses the Lektor CMS. I needed to have it installed on my system (windows 10 OS) to run the code in our site repository. Lektor suggests running the following code in powershell as an installation step:
(new-object net.webclient).DownloadString('https://www.getlektor.com/installer.py') | python
I just didn't think this is a very elegant way. Being an ardent chocolatey.org fan, I just had to have it up on there! Now the installation step for lektor is simply:
choco install lektor
on the Windows PowerShell!
Have a look at the package here:
https://chocolatey.org/packages/lektor
Thank you for your time! Stay put for the next Vocabulary site update!


3-roll-2
A 3-button suit style where the top button hole is on the lapel roll making it functionally equivalent to a 2-button suit.
Like the bottom button, the top button in a 3-roll-2 serves no functional purpose yet it persists as an interesting stylistic option for those who care.
threerolltwo.com will be online soon to bring you style articles and Dubai tailor reviews for frivolity and necessity.


This is my fifth post.
Leverage agile frameworks to provide a robust synopsis for high level overviews. Iterative approaches to corporate strategy foster collaborative thinking to further the overall value proposition. Organically grow the holistic world view of disruptive innovation via workplace diversity and empowerment.
Bring to the table win-win survival strategies to ensure proactive domination. At the end of the day, going forward, a new normal that has evolved from generation X is on the runway heading towards a streamlined cloud solution. User generated content in real-time will have multiple touchpoints for offshoring.
Section Header #
Capitalize on low hanging fruit to identify a ballpark value added activity to beta test. Override the digital divide with additional clickthroughs from DevOps. Nanotechnology immersion along the information highway will close the loop on focusing solely on the bottom line.
- Next: This is my new post from the Netlify CMS
- Previous: This is my fourth post.


Bio
- Grew up in a small town in the Caribbean
- Two brothers and one sister
Education
- Went to college in New York state.
- Studied engineering and business.
Interests
- Fintech, Sofware
- Hiking, Gardening
Top Ten Favorite Dishes
- Cuban Black Beans & Rice
- Roasted Chicken and Potatoes
- Caesar Salad with Salmon
- Pork Tacos
- Crab Fried Rice
- Sushi
- Pisto
- Vegetable Lasagna
- Yankee Pot Roast
- Seafood Paella


Thought Id highlight that's there's been a lot of development and discussion happening on the emonhub git repo lately (mainly between myself, Paul [pb66], Jerome and Dave McCraw [Schism]) on the next version of the oem_gateway which is called emonhub.
The repository is here:
and issue list here:
https://github.com/emonhub/emonhub/issues
One of the focuses for the discussion and development has been how best to cater for receiving different datatypes from the rfm12pi, not just integers. I.e: signed and unsigned longs for watt hour data.
This started with:
Node listener and dispatcher: https://github.com/emonhub/emonhub/pull/22
which then lead on to:
emonhub_decoder: https://github.com/emonhub/emonhub/issues/31
Threading, so the dispatchers dont block serial reading or logging to another local server when the remote server is down:
https://github.com/emonhub/emonhub/issues/26
https://github.com/emonhub/emonhub/pull/33
and then on to this much wider topic about the relationship between emonhub and emoncms and how an approach using MQTT message queue's in emoncms could provide a good solution in many applications:
https://github.com/emonhub/emonhub/pull/29
Paul has also been working on a emonhub documentation website here: https://github.com/emonhub/emonhub.github.io
Re: EmonHub Development
Hi,
What is the relationship between Emonhub and Emonbase ?
Emonhub is the sofware part and Emonbase is the hardware part ?
I'm a little bit confused ...
Eric
Re: EmonHub Development
Basically yes, currently the Raspberry Pi is the predominant choice of emonBase, so for many users this will be the software they run on the Pi either with or without emonCMS.
The oem gateway was originally written to be a detachable replacement to the python or php scripts used with emonCMS to interface with the rfm2pi, it has been the favorite standalone gateway for some time but not many users are aware of it's full functionality or that it can replace emonCMS's raspberrypi/rfm2pi interface. So it actually became a 3rd choice rather than simply replacing the existing 2, the name possibly didn't help much as OEM gateway doesn't sound too much like part of the emon family either.
For a handful of reasons we decided to revamp, repackage and rename OEM gateway and release it as emonHub, the decision was to make some minor changes/improvements to what was already a great solution and initially focus on making emonHub v1 easier to use, install, maintain and develop. We already have a few ideas to add to emonHub but did not want to confuse the inital release, so we decided no new features would make v1 and that user feed back/input towards developing additional features was desirable.
Although a month or so ago we were not that far away from a releasable version, progress since then has been quite minimal due to a lengthy discussion about emonCMS's "nodes module" and how "non-integer" data from the RFM2Pi is handled. The solution may or may not be found, decided or included for v1 but what we would at least like to do is try and ensure the structure of the released version is not going to hinder development in these areas, therefore while the options are being debated release has been delayed, as has any documentation including the website.
emonhub.org is currently just a few pages thrown together as a mock up to test the concept of using a github pages hosted documentation site, it seems to work well and although some content has been prepared this hasn't been published as it's accuracy is uncertain until some core decisions are finalized.
Trystan's fork of the project has some trial variants currently being tested and any feedback will go a long way towards reaching a decision as to what method emonHub will actually adopt.
When emonHub v1 'eventually' gets released it will be available as a debian package initially and will not only replace the OEM gateway read-only sd card image also known as the "Rock-solid gateway" but will also offer a more generic, feature rich, cross platform alternative to emonCMS's rfm2pi/raspberrypi python & php scripts.
A "full" announcement is planned for the actual general release and the website will also have much more info when it goes live, in the mean time any comments or suggestions here on the forum or involvement on github are both welcome and encouraged.
Paul


FireBase Train Times
Train Times
Train Name
Destination
Frequency
Next Arrival
Minutes Away
Train Time Input
Train Name
Destination
First Train Time (HH:mm - military time)
Frequency (mm)
Submit


Vanilla JS
Show HTML Element
This HTML Element has been shown with Vanilla JS
jQuery
Show HTML Element
This HTML Element has been shown with jQuery


Egypt unveils 'one of a kind' discovery of hundreds of statues and mummified animals
Egypt unveiled what it described as a "one of a kind" cache that contained hundreds of statues and mummified animals. This discovery also included the "biggest scarab in the world" as well as mummies of at least two cubs at the Saqqara necropolis, some 30 kilometers south of Cairo.
Interested in Egypt?
Add Egypt as an interest to stay up to date on the latest Egypt news, video, and analysis from ABC News. Egypt Add Interest
The announcement was made after a year-long excavation near the sanctuary of the goddess Bastet or Bubasteion, which is home to the catacombs of mummified cats. The findings date back to the 26th dynasty in the seventh century BC, officials said.
"We found hundreds of mummified animals and statues at the cache, and we still have a lot of others in store," Mostafa El-Waziri, who heads Egypt's Supreme Council of Antiquities, told reporters Saturday.
"The loveliest discovery out of those hundreds is the scarab; it's the hugest scarab all over the world. The loveliest surprise is that we also found two small cubs for the first time.
"Twenty, 30 years ago, a French mission … found the remains or a skeleton of a lion just meters away, but we can announce that now it's the first time to find a complete mummy of a small lion," El-Waziri said.
While Antiquities Minister Khaled El-Enany said it might be early to say the two mummies belong to cubs, despite their apparent big sizes, El-Waziri insisted CT scans and two famed archeologists have "95 percent" confirmed the findings.
El-Waziri also said that three other "big cats" were also discovered but that they will undergo further scans to determine their identity amid expectations that they might be mummies of cubs, leopards, cheetahs or tigers.
One of the highlights of the discovery, according to El-Waziri, was a "beautifully carved" statue of Neith, the ancient goddess of war.
The collection also includes 75 wooden and bronze statues of cats and statues of other animals, including falcons, crocodiles and ichneumons.
"Today's discovery is a museum in itself. We still have to find a place to house those objects," El-Enany said.
It marks Egypt's second significant discovery in almost a month. In October, the antiquities ministry unveiled 3,000-year-old wooden coffins in the southern city of Luxor.
The country hopes the recent series of discoveries will help lure back tourists and revive its vital tourism industry, which has been battered by years of turmoil.


1.Memorandum of association registraion
2.Edit or add-ons memorandum of association before registration
3.Company registration
4.To register memorandum of association and company in the day
5.Modifys director name or authorized
6.Modify Company's place
6.1 In capital
6.2 To other capital
7. Modify Seal
7.1 Edit seal
7.2 Add-ons another seal
8. Edit purpose of company
9. Increase or decrease capital's company
10. Edit Company’s regulation
11. Companies liquildation
12. Additional registered transaction (Add/Change/Repeal)
13. Liquidation report
14. Registration certificate of the original company


《送魏万之京》 李颀
朝闻游子唱离歌，昨夜微霜初渡河。
鸿雁不堪愁里听，云山况是客中过。
关城树色催寒近，御苑砧声向晚多。
莫见长安行乐处，空令岁月易蹉跎。
Seeing
Wei
Wan
Off
to
the
Capital
Li
Qi
On
frosty
morn
floats
the
wanderer's
parting
song,
Accompanying
you
across
the
river
all
along.
Can
you
bear
the
sad
strains
of
wild
geese
flying
past
When,
grieved
in
cloudy
mountains,
you
must
travel
fast?
Yellowing
leaves
around
the
pass
hear
winter's
wails,
The
Royal
Park
at
dusk
resounds
with
washing-
flails.
Do
not
take
Changan
for
a
capital
of
pleasure
Wherein
to
idle
time
away—
a
fleeting
treasure!


Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.
For the best experience please use the latest Chrome or Safari browser. Firefox 10 (to be released soon) will also handle it.
@tsucchi
@tsucchi とか blog(http://tsucchi.github.io/)とか
Perl
ミルキィホームズ
株式会社シャノンというところで、エンジニアやってます
Use a spacebar or arrow keys to navigate