1. Introduction
1.1. Purpose of the document
The objective of this Implementation Guide (IG) is to describe the format of input and output files to be used when dealing with Let’s Coordinate application. This can help developers to prepare input and output files adapted to a business tool that Let’s Coordinate will support for any RSC services. The implementation guide is one of the building blocks for using UML (Unified Modelling Language) based techniques in defining processes and messages for exchange between actors in the electrical industry in Europe. The implementation guide is developed for the harmonization of the underlying data exchange
1.2. Normative reference documentation
The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies:
-
IEC 61968-100 IEC : 2018 Application integration at electric utilities – System interfaces for distribution management
-
ISO 8601:2014 : Data elements and interchange formats – Information interchange – Representation of dates and times
-
RFC4122 : A Universally Unique IDentifier (UUID) URN Namespace Available from http://www.rfc-base.org/rfc-4122.html.
2. Let’s Coordinate business process
2.1. Process overview
|
Note
|
DCC = Distributed Communication Component as Kakfa, FTP server etc… |
2.2. Use cases
This table gives a list of actors involved in Let’s Coordinate data exchange:
Actor Label |
Actor Description |
Let’s Coordinate application |
Software to display some notifications and RSC KPIs |
Business tool |
Tool which will be supported by Let’s Coordinate for its operational communication and business cases validation/coordination |
Distributed Communication Component (DCC) |
Shared component between Let’s Coordinate and other business tool |
User |
User of Let’s Coordinate (RSC or TSO) |
RSC KPIs storage |
Database of RSC KPIs |
Notification Storage |
Database of notification |
Notification actions Storage |
Database of actions done within the notification |
Feed screen |
Screen where notifications arrive |
Archive screen |
Screen where all notifications can be retrieved from notification database |
RSC KPIs screens |
All screens referring to RSC KPIs |
Monitoring and Logging screens |
All screens referring to notifications actions |
This table gives a list of use cases for Let’s Coordinate data exchange:
Use case Label |
Actor Involved |
Actions description and assertions |
Provides input data information to DCC Business tool |
DCC / Business tool |
provides input file to DCC |
Retrieves input data information from DCC |
DCC / Let’s Coordinate |
Let’s Coordinate retrieves input files from DCC |
Emits a notification |
Let’s Coordinate / Notification Recipient |
Based on the format described in this IG, Let’s Coordinate will map the input file with correlated templates to display information from the input file as a notification (informative or SMART) |
Consults a notification |
User / Feed screen / Archives screen |
User is able to consult notification from different screens: Feed and/or Archives |
Records notifications |
Let’s Coordinate / Notification Storage |
Notifications are stored in a database |
Updates RSC KPIs information |
Let’s Coordinate |
Based on the format described in this IG, Let’s Coordinate will update the RSC KPIs database with information received from input file |
Consults RSC KPIs |
User / RSC KPIs screens / RSC KPIs storage |
User is able to consult RSC KPIs from KPIs DB in the dedicated RSC KPIs screens |
Exports RSC KPIs |
User / RSC KPIs screens / RSC KPIs storage |
User is able to export the RSC KPIs in xlsx or pdf format from RSC KPIs screens |
Acknowledges notifications |
User |
User is able to acknowledge informative notification |
Acts on the notifications |
User |
User is able to act (accept/reject/add comments) in SMART notification |
Records notification actions |
Let’s Coordinate / Notification actions Storage |
Actions done by user in the notification are stored in a database |
Consults Monitoring and/or Logging screens |
Monitoring / Logging screens / User / Notification actions storage |
User is able to consults Monitoring and logging information in the dedicated screens |
Send output data information to DCC |
Let’s Coordinate / DCC |
T-COO is able to export output data to DCC after validation/coordination |
Retrieves output data information from DCC |
Business tool / Let’s Coordinate |
Business tool is able to retrieve output date file from DCC |
3. Input data format
Input data format is the same format for Informative and SMART notifications. The only difference are linked to the data user wants to provide (text, RSC KPI, timseries…).
Two formats are proposed for input data:
-
XLSX, Office Open XML worksheet sheet (OOXML), ECMA-376 standard file format, Microsoft Excel XML (2007+) file format
-
JSON, JavaScript Object Notation, ISO/IEC 21778:2017 open standard file format (only encoded in UTF-8 and Unix Line Feed)
NOTE:
-
M ⇒ Mandatory & this field is mandatory for XLSX and JSON files.
-
O ⇒ Optional & this field is optional for XLSX and JSON files
-
M(JSON) or O(JSON) ⇒ to be used only for JSON files
-
M(XLSX) or O(XLSX) ⇒ to be used only for XLSX files
3.1. Document header part
| Attributes | Mandatory / Optional | Values | Type | Description |
|---|---|---|---|---|
eventMessage |
M (JSON) |
- |
Map |
Message description |
xmlns |
M (JSON) |
String |
Name space |
|
header |
M (JSON) |
- |
Map |
Header part of the file |
verb |
M |
- |
- |
The <verb> shall specify the semantics of the message and the interpretation of the data supplied in the <payload> element. |
created |
Enumeration |
Used to publish a notification of the instantiation of one or more objects. |
||
canceled |
Enumeration |
Used to publish a notification that one or more actions have been aborted. |
||
changed |
Enumeration |
Used to publish a notification that one or more objects have been replaced. |
||
deleted |
Enumeration |
Used to publish a notification that an object has been deleted. |
||
executed |
Enumeration |
Used to publish a notification that the execution of a complex transaction that uses the <payload> element has taken place. |
||
updated |
Enumeration |
Used to publish a notification that one or more objects have been modified. |
||
noun |
M |
NotificationCategory |
String |
Category of notification. The <noun> shall specify the semantics of the message and the interpretation of the data supplied in the <payload> element. |
timestamp |
M |
2020-03-18T09:34:08Z |
DateTime |
Creation date and hour of the input file : This element shall indicate when the message was produced. (It is not the time the message was transmitted because the actual send may occur later due to transactions or other client side queueing of messages). The timestamp shall conform to ISO 8601. It shall include either the letter “Z” to denote UTC or an explicit timezone offset. |
source |
M |
ProcessName |
String |
Name of the service or process : This element shall be used to identify the origin of the informational content. The values assigned to this element are non-normative and have meaning only within the local organisation. |
messageId |
M |
d18d3733d7884d798cadc2ecf30bef0b |
UUID |
Unique ID of the message : This element shall be a 128-bit universally unique identifier (UUID) generated according to RFC 4122. It has no normative meaning other than to provide a unique identifier for the message. This element together with the <timestamp> element is useful for tracing or logging messages as they are processed by the requesting, responding or other systems. |
properties |
M (JSON) |
- |
Map |
Message properties : This element consists of a set of name/value pairs that may be used to customize the system behaviour in ways going beyond those defined by this International Standard. This may be used to provide some implementation-specific functionality. The values assigned to these elements are non-normative and have meaning only within the local implementation. |
format |
M (JSON) |
JSON |
String |
Format of the message |
businessDataIdentifier |
M (JSON) |
- |
Map |
- |
businessApplication |
O |
PanEuropeanServiceATool, ServiceBTool, … |
String |
Name of the business application |
messageType |
O |
102 |
String |
ID of the message |
messageTypeName |
M |
ProcessNotificationTypeA |
String |
Name of the message |
businessDayFrom |
M |
2020-03-18T09:34:08Z |
DateTime |
Business period start date and time |
businessDayTo |
O |
2020-03-19T09:34:08Z |
DateTime |
Business period end date and time / If this value is not provided, it will take the <businessDayFrom> value plus 24 hours. |
sendingUser |
O |
10X-CHSWISSGRIDC |
Alphanumeric |
EIC code of sender of the message or input file (if different from tso) |
processStep |
O |
1st Run |
String |
Name of the process step to distinguish different steps of the same process |
timeframe |
O |
D-2, D-1, ID, W, M, Y |
Alphanumeric |
Timeframe of the message |
timeframeNumber |
O |
3 |
String |
If Timeframe is W, number of the week. If Timeframe is M, number of the month. If Timeframe is Y, number of the year. Empty for other ones. |
recipients |
O |
10YCZ-CEPS-----N;10X-CHSWISSGRIDC |
List<String> |
EIC codes of specific recipient(s) for this notification. This field is optional if this information can be deducted from provided timeseries. |
caseId |
O |
ProcessNotifTypeA_20210609_001 |
String |
Business identifier of the notification. The reuse of the same caseId means that the old notification will be overriden by the new one. If the caseId is not provided, it will be calculated using the following fields: source, businessApplication, messageTypeName, businessDayFrom and businessDayTo. |
Following lines are only used for Input data validation by ENTSO-E Acknowledgement |
||||
fileName |
M |
Input_file_TSO.xml |
String |
Name of the file provided by TSO (or its RSC) |
tso |
M |
10X-CHSWISSGRIDC |
Alphanumeric |
EIC code of owner of validated input file |
biddingZone |
O |
10YCZ-CEPS-----N |
Alphanumeric |
EIC code of Bidding zone of validated input file |
Ex: Input file Header JSON (without input data validation)
{ "eventMessage": { "xmlns": "https://www.iec.ch/tc57/supportdocuments", "header": { "verb": "created", "noun": "ServiceA_CalculationResults", "timestamp": "2020-03-17T12:32:19Z", "source": "ServiceA", "messageId": "b071aa50097f49f1bd69e82a070084b6", "properties": { "format": "JSON", "businessDataIdentifier": { "businessApplication": "PanEuropeanServiceATool", "messageType": "101", "messageTypeName": "ServiceA_NotificationA", "businessDayFrom": "2020-01-10T23:00:00Z", "businessDayTo": "2020-01-17T23:00:00Z", "sendingUser": "10XCH-SWISSGRIDC", "processStep": "INITIAL_RUN", "timeframe": "W", "timeframeNumber": 24, "recipients": [ "10XBA-JPCCZEKC-K", "10XAL-KESH-----J" ], "caseId": "ProcessNotifTypeA_20210609_001" } } }, "payload": { … } } }
Input file header JSON sample file (without input data validation):
Input file header XLSX sample file (without input data validation):
For more details, see the excel sample file: line 1 and 2 in XLSX header for input file sample
Ex: Input file Header JSON (with input data validation)
{ "eventMessage": { "xmlns": "https://www.iec.ch/tc57/supportdocuments", "header": { "verb": "created", "noun": "ServiceA_CalculationResults", "timestamp": "2020-03-17T12:32:19Z", "source": "ServiceA", "messageId": "b071aa50097f49f1bd69e82a070084b6", "properties": { "format": "JSON", "businessDataIdentifier": { "businessApplication": "PanEuropeanServiceATool", "messageType": "101", "messageTypeName": "ServiceA_NotificationA", "businessDayFrom": "2020-01-10T23:00:00Z", "businessDayTo": "2020-01-17T23:00:00Z", "sendingUser": "10XCH-SWISSGRIDC", "processStep": "INITIAL_RUN", "timeframe": "W", "timeframeNumber": 24, "fileName": "20200317_1230_SERVICEA_CH.xlsx", "tso": "10XCH-SWISSGRIDC", "biddingZone": "10YCH-SWISSGRIDZ" "recipients": [ "10XBA-JPCCZEKC-K", "10XAL-KESH-----J" ], "caseId": "ProcessNotifTypeA_20210609_001" } } }, "payload": { ... } } }
Input file header JSON sample file (with input data validation):
3.2. Payload part
Payload can be customized by each message producer to fit with their need. In case user wants to provide one type of information (text, links, data…), this table presents the needed fields to support this with information if this field is mandatory or optional depending of the format of input file.
| Attributes | Mandatory / Optional | Values | Type | Description |
|---|---|---|---|---|
payload |
M (JSON) |
- |
Map |
The application-specific data are located within the <payload> elements, depending on the purpose of the message. The <payload> element contains application-specific data conforming to other IEC 61968 standards. IEC 61968-100 makes no attempt to define these application-specific data. They are left to be defined by the relevant IEC working groups or the local organization. |
datatype |
M(XLSX) |
text OR links OR timeserie OR rscKpi |
- |
Indicate the type of data that will be provided - text : to provide text information - links : to provide url link to download some files - timeserie : to provide data as timeseries - rscKpi : to provide RSC KPIs |
Following lines described the needed fields for provision of text information |
||||
text |
M (JSON) |
- |
List<Map> |
Provide some text informations |
name |
M |
Conclusion |
String |
Name of related information |
value |
M |
OK for tomorrow |
String |
Value of related information |
Following lines described the needed fields for provision of url links to download file with url address or access to web pages |
||||
links |
M (JSON) |
- |
List<Map> |
Structure to provide links to download some files |
name |
M |
ProcessReport |
String |
Name of the url |
value |
M |
String |
Url address of the file or the webpage |
|
eicCode |
O |
["eicCode1", "eicCode2", …] |
list<String> |
EIC code of concerned TSO |
Following lines described the needed fields for provision of RSC KPI information |
||||
rscKpi |
M (JSON) |
- |
List<Map> |
Structure to provide KPIs |
name |
M |
GP01, GP02…. BP01, BP02…. |
String |
KPI name: there are 2 categories : Global Performance (GP) or Business process (BP) : GP or BP followed by the number of KPIs Note: The labels of GPxx and BPxx will be parameterized in the configuration bundles of the application, so that the final displayed information to the screen will have the <kpi_name – kpi_label> format. (e.g: GPxx – Global Performance x) When a business KPI has multiple values, the conventional naming is GPxx_1 to GPxx_9 or BPxx_1 to BPxx_9 where xx are digits 0 to 9. The associated label is GPxx.1 to GPxx.9 and BPxx.1 and BPxx.9. |
joinGraph |
O |
true (default) or false |
Boolean |
If “true”, allows to join rsc kpi data into one graph, else if “false”, the rsc kpi data will be displayed into separate graphs. |
data |
M (JSON) |
- |
List<Map> |
Structure to provide kpi data |
timestamp |
M |
2020-03-18T23:00:00Z |
DateTime |
Date of related KPI |
granularity |
M |
D |
Enumeration |
Used to display the RSC KPI report in a daily view |
Y |
Enumeration |
Used to display the RSC KPI report in a yearly view |
||
label |
M |
CalculationFailed, ProcessDelayed… |
String |
Name of sub item of KPI if exists |
detail |
M (JSON) |
- |
List<Map> |
Structure to provide kpi data details |
eicCode |
O |
38X-BALTIC-RSC-H |
Alpha-numeric |
EIC code of concerned TSO if exists |
value |
M |
e.g : 1, 2, 2691 … |
Integer |
Value of KPI’s item or sub item |
Following lines described the needed fields for provision of timeseries information |
||||
timeserie |
M (JSON) |
- |
List<Map> |
Structure to provide timeseries |
name |
M |
probabilisticResults |
String |
Name of related data |
data |
M (JSON) |
- |
List<Map> |
Structure to provide timeserie data |
timestamp |
M |
2020-03-18T23:00:00Z |
DateTime |
Date of related timeserie |
detail |
M (JSON) |
- |
List<Map> |
Structure to provide timeserie data details |
id |
O |
"1", "2", "3" … |
String |
Id of related timeserie if exists |
label |
O |
ResultsA |
String |
Label of related timeserie if exists |
eicCode |
O |
38X-BALTIC-RSC-H |
Alpha-numeric |
EIC code of related timeserie if exists |
value |
M |
"89", "5585", "Open Line Z", … |
String |
Value of related timeserie |
Following lines described the needed fields for provision of input data validation by ENTSO-E Acknowledgement (only JSON) information |
||||
validation |
M (JSON) |
- |
Map |
Only used for Input data validation by ENTSO-E Acknowledgement |
validationType |
M |
TECHNICAL or BUSINESS |
String |
Type of validation by ACK which start by technical validation and then business validation |
status |
M (JSON) |
ACCEPTED or REJECTED |
String |
Status of ACK validation: accepted or rejected for validation type done of related source |
result |
M (JSON) |
OK or WARNING or ERROR |
String |
This field presents the worst case detected: If no warning and no error ⇒ OK If some warnings and no error ⇒ warning If some errors with/out warnings ⇒ error |
validationMessages |
M (JSON) |
- |
List<Map> |
Validation details |
code |
M (JSON) |
VAL_OUT1 |
Alphanumeric |
Business code for the validation information |
severity |
M (JSON) |
ERROR or WARNING |
String |
Severity of validation information (Error or warning) |
title |
M (JSON) |
“Error in input format” |
String |
Category of issue for this validation information |
message |
M (JSON) |
“Issue located in business period” “Application check: Error identified while checking process <processMrid>. The coordinated TSO: <missingTsoList> not provided” |
String |
Details about this validation information |
params |
O (JSON) |
{“processMrid”: “6fc941b6-e7ab-4962-a2a8-c965f5bf78e9”, “missingTsoList”: [“10X1001A1001A094”, “10XES-REE------E”]} |
Map<String, Object> |
Provides <key,value> parameters for the validation message |
businessTimestamp |
M (JSON) |
2020-03-18T23:00:00Z |
DateTime |
Business date and time of this validation information |
sourceDataRef |
M (JSON) |
- |
Map |
Information about the data |
relatedElement |
M (JSON) |
header |
String |
This means that the dedicated information is concerning whole file and is not specific to any timeseries or any period in the file. In the timeline, the bubble about this information will be displayed at arrival time (‘timestamp’ field in the header) of the notification. |
timeseries |
String |
This means that the dedicated information is related to a specific timeseries in the file but not to a specific period within that timeseries, in this case also a field 'relatedTimeseriesId' will be field and will contain usually MRID. Each timeserie can have a different start time. In the timeline, the bubble about this information will be displayed at the timestamp (‘dataName’/’hour’ field in the payload) of this information |
||
period |
String |
This means that the dedicated information is concerning specific period within specific timeseries, in this case there will be also 3 other fields 'relatedTimeseriesId', 'relatedPeriodStartId' and ‘relatedPeriodEndId’. In the timeline, the bubble about this information will be displayed at the timestamp (“relatedPeriodStartId” field in the payload) of this information |
||
relatedTimeseriesId |
M (JSON) |
CZ_P_3047 |
Alphanumeric |
This field describes the name of the timeserie. It is mandatory only in case the relatedElement is ‘timeseries’ or ‘period’ |
relatedPeriodStartId |
M (JSON) |
54 |
Number |
This field describes the start time of the timeserie and this is the shift of hours from ‘businessDayFrom’. It is mandatory only in case the relatedElement is ‘period’ |
relatedPeriodEndId |
M |
121 |
Number |
This field describes the end time of the timeserie and this is the shift of hours from ‘businessDayFrom’. It is mandatory only in case the relatedElement is ‘period’ |
Ex: Input file payload JSON (without input data validation)
{ "eventMessage": { "xmlns": "https://www.iec.ch/tc57/supportdocuments", "header": { … }, "payload": { "text": [ // text details sample { "name": "comment", "value": "No specific remarks for today" } ], "links": [ // links details sample { "name": "ServiceA_Report1", "value": "https://www.site.com/file1.pdf", "eicCode": [ "22XCORESO------S", "10X1001C--00008J", "10X1001C--00003T", "38X-BALTIC-RSC-H", "34X-0000000068-Q" ] } ], "rscKpi": [ // rscKpi details sample { "name": "GP01", "data": [ { "timestamp": "2020-03-18T01:00:00", "granularity": "Y", "label": "ProcessSuccess", "detail": [ { "value": 1 } ] } ] }, { "name": "BP01", "data": [ { "timestamp": "2020-03-18T01:00:00", "granularity": "D", "label": "BusinessKpiAServiceA", "detail": [ { "eicCode": "22XCORESO------S", "value": 0 }, { "eicCode": "10X1001C--00008J", "value": 1 }, { "eicCode": "10X1001C--00003T", "value": 0 }, { "eicCode": "38X-BALTIC-RSC-H", "value": 1 }, { "eicCode": "34X-0000000068-Q", "value": 0 } ] } ] } ], "timeserie": [ // timeserie details sample { "name": "ResultsA", "data": [ { "timestamp": "2020-03-01T00:00:00", "detail": [ { "value": "79" } ] }, { "timestamp": "2020-03-01T01:00:00", "detail": [ { "value": "42" } ] }, { "timestamp": "2020-03-01T02:00:00", "detail": [ { "value": "4" } ] }, { "timestamp": "2020-03-01T03:00:00", "detail": [ { "value": "58" } ] } ] } ] } } }
Input file payload JSON sample file (without input data validation):
Input file payload XLSX sample file (without input data validation):
For more details, see the excel file: from line 4 to end of the document XLSX payload for input file sample
Ex: Input file payload JSON (with input data validation)
{ "eventMessage": { "xmlns": "https://www.iec.ch/tc57/supportdocuments", "header": { … }, "payload": { "validation": { // validation details sample "validationType": "BUSINESS", "status": "ACCEPTED", "result": "ERROR", "validationMessages": [ { "code": "ServiceA_Error_01", "severity": "ERROR", "title": "Rule_A_Violated", "message": "Application check: Error 01 detected in input file", "businessTimestamp": "2020-02-26T14:24:38Z", "sourceDataRef": { "relatedPeriodStartId": 3247, "relatedElement": "timeseries", "relatedPeriodEndId": 3856, "relatedTimeseriesId": "Timeseries_12345" } }, { "code": "ServiceA_Error_02", "severity": "ERROR", "title": "Rule_B_Violated", "message": "Application check: Error 02 detected in input file", "businessTimestamp": "2020-02-26T14:24:46Z", "sourceDataRef": { "relatedElement": "header" } }, { "code": "ServiceA_Warning_01", "severity": "WARNING", "title": "Rule_C_Violated", "message": "Application check: Warning 01 detected in input file", "businessTimestamp": "2020-02-26T14:24:47Z", "sourceDataRef": { "relatedElement": "header" } }, { "code": "ServiceA_Warning_02", "severity": "WARNING", "title": "Rule_D_Violated", "message": "Application check: Warning 02 detected in input file", "businessTimestamp": "2020-02-26T14:25:23Z", "sourceDataRef": { "relatedPeriodStartId": 897, "relatedElement": "timeseries", "relatedPeriodEndId": 928, "relatedTimeseriesId": "Timeseries_45678" } } ] } } } }
Input file payload JSON sample file (with input data validation):
4. Output data format
Output data format is only used for SMART notifications as a result of a validation or coordination of some proposals received in the input file. In case the input file is used for informative notification, no output file will be generated.
Two formats are proposed for output data:
-
XLSX, Office Open XML worksheet sheet (OOXML), ECMA-376 standard file format, Microsoft Excel XML (2007+) file format
-
JSON, JavaScript Object Notation, ISO/IEC 21778:2017 open standard file format (only encoded in UTF-8 and Unix Line Feed)
But this output format will be always the same format as the one received for input file. (Ex: if Let’s Coordinate receives 1 input file in XLSX, then the output file will be also in XLSX)
NOTE:
-
M ⇒ Mandatory & this field is mandatory for XLSX and JSON files.
-
O ⇒ Optional & this field is optional for XLSX and JSON files
-
M(JSON) or O(JSON) ⇒ to be used only for JSON files
-
M(XLSX) or O(XLSX) ⇒ to be used only for XLSX files
4.1. Document header part
Header is the really similar as the one described for the input file with addition of:
-
Global field about the validation or coordination status of the overall notification to be validated. This change is in the header of the output file.
-
CON(firmed): the status of this notification is confirmed (based on the different answers done for each timeserie to be validated inside this notification)
-
REJ(ected): the status of this notification is rejected (based on the different answers done for each timeserie to be validated inside this notification)
-
MIX(ed): the status of this notification is mixed (based on the different answers done for each timeserie to be validated inside this notification)
-
CAN(celed): the status of this notification is canceled
-
-
List of general comments of the overall notification to be validated. This change is in the header of the output file.
| Attributes | Mandatory / Optional | Values | Type | Description |
|---|---|---|---|---|
eventMessage |
M (JSON) |
- |
Map |
Message description |
xmlns |
M (JSON) |
String |
Name space |
|
header |
M (JSON) |
- |
Map |
Header part of the file |
verb |
M |
- |
- |
The <Verb> shall specify the semantics of the message and the interpretation of the data supplied in the <Payload> element. |
created |
Enumeration |
Used to publish a notification of the instantiation of one or more objects. |
||
canceled |
Enumeration |
Used to publish a notification that one or more actions have been aborted. |
||
changed |
Enumeration |
Used to publish a notification that one or more objects have been replaced. |
||
deleted |
Enumeration |
Used to publish a notification that an object has been deleted. |
||
executed |
Enumeration |
Used to publish a notification that the execution of a complex transaction that uses the <Payload><OperationSet> element has taken place. |
||
updated |
Enumeration |
Used to publish a notification that one or more objects have been modified. |
||
noun |
M |
NotificationCategory |
String |
Category of notification. The <Noun> shall specify the semantics of the message and the interpretation of the data supplied in the <Payload> element. |
timestamp |
M |
2020-03-18T09:34:08Z |
DateTime |
Creation date and hour of the input file : This element shall indicate when the message was produced. (It is not the time the message was transmitted because the actual send may occur later due to transactions or other client side queueing of messages). The timestamp shall conform to ISO 8601. It shall include either the letter “Z” to denote UTC or an explicit timezone offset. |
source |
M |
ProcessName |
string |
Name of the service or process : This element shall be used to identify the origin of the informational content. The values assigned to this element are non-normative and have meaning only within the local organisation. |
messageId |
M |
d18d3733d7884d798cadc2ecf30bef0b |
UUID |
Unique ID of the message : This element shall be a 128-bit universally unique identifier (UUID) generated according to RFC 4122. It has no normative meaning other than to provide a unique identifier for the message. This element together with the <Timestamp> element is useful for tracing or logging messages as they are processed by the requesting, responding or other systems. |
properties |
M (JSON) |
- |
Map |
Message properties : This element consists of a set of name/value pairs that may be used to customize the system behaviour in ways going beyond those defined by this International Standard. This may be used to provide some implementation-specific functionality. The values assigned to these elements are non-normative and have meaning only within the local implementation. |
format |
M (JSON) |
JSON |
String |
Format of the message |
businessDataIdentifier |
M (JSON) |
- |
Map |
- |
businessApplication |
O |
PanEuropeanServiceATool, ServiceB.tool, … |
String |
Name of the business application |
messageType |
O |
102 |
String |
ID of the message |
messageTypeName |
M |
ProcessNotificationTypeA |
String |
Name of the message |
businessDayFrom |
M |
2020-03-18T09:34:08Z |
DateTime |
Business period start date and time |
businessDayTo |
O |
2020-03-19T09:34:08Z |
DateTime |
Business period end date and time / If this value is not provided, it will take the <businessDayFrom> value plus 24 hours. |
sendingUser |
O |
10X-CHSWISSGRIDC |
Alphanumeric |
EIC code of sender of the message or input file (if different from tso) |
processStep |
O |
1st Run |
String |
Name of the process step to distinguish different steps of the same process |
timeframe |
O |
D-2, D-1, ID, W, M, Y |
Alphanumeric |
Timeframe of the message |
timeframeNumber |
O |
3 |
String |
If Timeframe is W, number of the week. If Timeframe is M, number of the month. If Timeframe is Y, number of the year. Empty for other ones. |
recipients |
O |
10YCZ-CEPS-----N;10X-CHSWISSGRIDC |
List<String> |
EIC codes of specific recipient(s) for this output file. This field is optional if this information can be deducted from provided timeseries. |
caseId |
O |
ProcessNotifTypeA_20210609_001 |
String |
Business identifier of the notification. The reuse of the same caseId means that the old notification will be overriden by the new one. If the caseId is not provided, it will be calculated using the following fields: source, businessApplication, messageTypeName, businessDayFrom and businessDayTo. |
coordinationStatus |
M |
CON or REJ or MIX or CAN |
Enumeration |
Global status of coordination : CON(firmed), REJ(ected), MIX(ed) or CAN(celed). This status is global for the all notification |
coordinationComments |
O |
- |
List<Map> |
List of general comments |
eicCode |
M |
22XCORESO------S |
Alpha-numeric |
EIC code of the user providing a general comment |
generalComment |
M |
OK for us! |
String |
General comment for the coordination |
Ex: Output file header JSON sample
{ "eventMessage": { "xmlns": "https://www.iec.ch/tc57/supportdocuments", "header": { "verb": "created", "noun": "ServiceA_CalculationResults", "timestamp": "2020-03-17T12:32:19Z", "source": "ServiceA", "messageId": "b071aa50097f49f1bd69e82a070084b6", "properties": { "format": "JSON", "businessDataIdentifier": { "businessApplication": "PanEuropeanServiceATool", "messageType": "101", "messageTypeName": "ServiceA_NotificationB", "businessDayFrom": "2020-01-10T23:00:00Z", "businessDayTo": "2020-01-17T23:00:00Z", "sendingUser": "10XCH-SWISSGRIDC", "processStep": "INITIAL_RUN", "timeframe": "W", "timeframeNumber": 24, "recipients": [ "10XBA-JPCCZEKC-K", "10XAL-KESH-----J" ], "caseId": "ProcessNotifTypeA_20210609_001", "coordinationStatus": "CON", "coordinationComments": [ { "eicCode": "10XFR-RTE------Q", "generalComment": "OK for us!" }, { "eicCode": "22XCORESO------S", "generalComment": "Super!" } ] } } }, "payload": { ... } } }
Output file header JSON sample:
Output file header XLSX sample:
For more details, see the excel sample file: line 4 and 5 in XLSX header for output file sample
4.2. Payload part
The Payload Output file is like the one described for the input file with addition of:
-
new field results in each proposal/timeseries inside the notification:
-
eicCode: EIC code of the entity providing the answer
-
answer: CON or REJ or MIX or NOT, the different value meanings are CON(firmed), REJ(ected), MIX(ed) or NOT (Not answered).
-
explanation: in case of rejection/refusal of the proposition to justify this choice from a list of values
-
comment: about the validation or coordination of the proposal
-
Following table will describe only the part to be affected by these new fields for timeserie information (even if there are text information, RSC KPI information…).
| Attributes | Mandatory / Optional | Values | Type | Description |
|---|---|---|---|---|
payload |
M (JSON) |
- |
Map |
The application-specific data are located within the <payload> elements, depending on the purpose of the message. The <Payload> element contains application-specific data conforming to other IEC 61968 standards. IEC 61968-100 makes no attempt to define these application-specific data. They are left to be defined by the relevant IEC working groups or the local organization. |
datatype |
M(XLSX) |
text OR links OR timeserie OR rscKpi |
String |
Indicate the type of data that will be provided: - text : to provide text information - links : to provide url link to download some files - timeserie : to provide data as timeseries - rscKpi : to provide RSC KPIs Only changes affecting timeseries validation/coordination will be described. |
Following lines are only describing the new fields which will be added in the timeserie(s) details to describe the results of the validation & coordination for proposed timeserie(s) information |
||||
timeserie |
M (JSON) |
- |
List<Map> |
Structure to provide timeseries |
name |
M |
probabilisticResults |
String |
Name of related data |
data |
M (JSON) |
- |
List<Map> |
Structure to provide timeserie data |
timestamp |
M |
2020-03-18T23:00:00Z |
DateTime |
Date of related timeserie |
detail |
M (JSON) |
- |
List<Map> |
Structure to provide timeserie data details |
id |
O |
"1", "2", "3" … |
String |
Id of related timeserie if exists |
label |
O |
ProbabilistResultsA |
String |
Label of related timeserie if existd |
eicCode |
O |
38X-BALTIC-RSC-H |
Alpha-numeric |
EIC code of related timeserie if exists |
value |
M |
"89", "5585", "Open Line Z", … |
String |
Value of related timeserie |
results |
O (JSON) |
- |
List<Map> |
Structure to provide output results |
eicCode |
M |
10XFR-RTE------Q |
Alpha-numeric |
EIC code of the entity providing the answer |
answer |
M |
CON or REJ or MIX or NOT |
Enumeration |
Status of the remedial actions: CON(firmed), REJ(ected), MIX(ed) or NOT (Not answered). |
explanation |
O |
“Not available” |
String |
List of choice in a predefined list of values as text. |
comment |
O |
“3 nodes should work” |
String |
Comment about the proposal by the concerned EIC code |
JSON sample:
XLSX sample
See the excel file: from line 7 to end of the document, columns G, H, I, and J in XLSX payload for output file sample


Export card object to string. You can use this if you need stringified card with array bracket(usually used when sending single card).
Card
{string}
Generated using TypeDoc


 Learn as if you were to live forever— Gandhi
Find your next technical (or not) book and expand your knowledge
Various posts or essays mainly about productivity, learning, soft skills and personal development
Stand on the shoulders of giants by learning techniques from top developers.
My name is Julien Sobczak.
I am a software developer.
Since 2008, I'm been working mainly as a Java Web Developer, and now, I'm focusing on distributed systems using different languages including Go and Python.
I work for Scaleway, one of the biggest European cloud providers. Previously, I was working for Zenika, a leading software company, ranked #1 on the Great Place to Work (2018) in France.
I have a strong interest in everything that is related to developer productivity: deliberate practice, clean code, memory techniques, speed reading, sport programming, and so on.
The more I learn about my job, the more I realize how less I know but the more I like it, so I do my best to learn something new every day!


Goals
• Decide the color palette of the application
• Decide the icons of the menus
• Select the images
• Decide the style of the components of the application
• Decide the color palette of the application
• Decide the icons of the menus
• Select the images
• Decide the style of the components of the application
The application needed a color palette that could identify the product and provide an attractive design to the system. The red was chosen as the dominant color since it transmits energy, dynamism and excitement; properties that should be related to the application.
The system is designed for Android thus the icons followed the standards for this operating system. The selection of the icons was done trying to simplify the understanding of the user, because of that the relations between the icon and the related action must be straight forward: the menu uses a “burger menu” icon, the cart uses a cart icon and so on.
The application is based on images that represent the different kind of products offered, once a category is selected the actual products are presented and it is crucial that these images are eye catching, informative and simply beautiful. Users should feel as if they were glancing over real food.
Finally, in order to enclose this section one mock-up per screen was done. These low fidelity prototypes contain the colors, images and icons selected in the previous steps and also the style of every component in the app including menus, buttons, cards, tabs…


We've experience some problems probably due to partying too much. We've been notified, seriously, and we're working to get things up and running.


Get started
API Endpoint
https://crisprbuilder.org/api/
Documentation for the CrisprBuilder API
To use this API, you need an API key. Please contact us at<EMAIL_ADDRESS>to get an API key.
GENE
# Here is a curl example
curl \
-X POST https://crisprbuilder.com/api/query \
-F 'key=your_api_key' \
-F 'type=gene,oligos,primers,primer_efficiency' \
-F 'gene=pkn,polo' \
To interact with our API, you need to make a GET request to the following url :
https://crisprbuilder.com/api/query
Result example :
{
query: https://crisprbuilder.com/api?type=search&gene=polo
result: {
"id":12,
"name":"polo",
"isoForms":"[\"polo-RA\",\"polo-RB\"]",
"url":"https://flybase.org/download/sequence/FBgn0003124/gene_extended",
"sequence":"AAACAAAAGAGGCCACACGGCATTAGCGA...",
"isoForm":"polo-RA",
"time":"2021-09-06 13:42:23",
"isoFormSequence":"ATGGCCGCGAAGCCCGAGGATAAG..."
}
}
QUERY PARAMETERS
| Field |
Type |
Description |
| type |
String |
The type of api call you are making |
| gene |
String |
A search word to find the gene information. |
| isoForm |
String |
(Optional) A search word to find information on a specific isoform by name. |
RETURN VALUES
| Field |
Type |
Description |
| name |
String |
The search term you entered. |
| isoForms |
String |
A list of isoforms associated with the gene. |
| url |
String |
The flybase url from where this info was pulled. |
| sequence |
String |
The extended gene sequence pulled from Flybase. |
| isoForm |
String |
The isoform returned from the query (will return default isoform from flybase is one is not queried). |
| isoFormSequence |
String |
The full sequence of the isoform returned from the query. |
TARGET
# Here is a curl example
curl \
-X POST https://crisprbuilder.com/api/query \
-F 'key=your_api_key' \
-F 'type=gene,oligos,primers,primer_efficiency' \
-F 'gene=pkn,polo' \
To interact with our API, you need to make a GET request to the following url :
https://crisprbuilder.com/api/query
Result example :
{
query: https://crisprbuilder.com/api?type=search&gene=polo
result: {
"id":12,
"name":"polo",
"isoForms":"[\"polo-RA\",\"polo-RB\"]",
"url":"https://flybase.org/download/sequence/FBgn0003124/gene_extended",
"sequence":"AAACAAAAGAGGCCACACGGCATTAGCGA...",
"isoForm":"polo-RA",
"time":"2021-09-06 13:42:23",
"isoFormSequence":"ATGGCCGCGAAGCCCGAGGATAAG..."
}
}
QUERY PARAMETERS
| Field |
Type |
Description |
| type |
String |
The type of api call you are making |
| gene |
String |
A search word to find the gene information. |
| isoForm |
String |
(Optional) A search word to find information on a specific isoform by name. |
RETURN VALUES
| Field |
Type |
Description |
| name |
String |
The search term you entered. |
| isoForms |
String |
A list of isoforms associated with the gene. |
| url |
String |
The flybase url from where this info was pulled. |
| sequence |
String |
The extended gene sequence pulled from Flybase. |
| isoForm |
String |
The isoform returned from the query (will return default isoform from flybase is one is not queried). |
| isoFormSequence |
String |
The full sequence of the isoform returned from the query. |
OLIGOS
# Here is a curl example
curl \
-X POST https://crisprbuilder.com/api/query \
-F 'key=your_api_key' \
-F 'type=gene,oligos,primers,primer_efficiency' \
-F 'gene=pkn,polo' \
To interact with our API, you need to make a GET request to the following url :
https://crisprbuilder.com/api/query
Result example :
{
query: https://crisprbuilder.com/api?type=search&gene=polo
result: {
"id":12,
"name":"polo",
"isoForms":"[\"polo-RA\",\"polo-RB\"]",
"url":"https://flybase.org/download/sequence/FBgn0003124/gene_extended",
"sequence":"AAACAAAAGAGGCCACACGGCATTAGCGA...",
"isoForm":"polo-RA",
"time":"2021-09-06 13:42:23",
"isoFormSequence":"ATGGCCGCGAAGCCCGAGGATAAG..."
}
}
QUERY PARAMETERS
| Field |
Type |
Description |
| type |
String |
The type of api call you are making |
| gene |
String |
A search word to find the gene information. |
| isoForm |
String |
(Optional) A search word to find information on a specific isoform by name. |
RETURN VALUES
| Field |
Type |
Description |
| name |
String |
The search term you entered. |
| isoForms |
String |
A list of isoforms associated with the gene. |
| url |
String |
The flybase url from where this info was pulled. |
| sequence |
String |
The extended gene sequence pulled from Flybase. |
| isoForm |
String |
The isoform returned from the query (will return default isoform from flybase is one is not queried). |
| isoFormSequence |
String |
The full sequence of the isoform returned from the query. |
PRIMERS
# Here is a curl example
curl \
-X POST https://crisprbuilder.com/api/query \
-F 'key=your_api_key' \
-F 'type=gene,oligos,primers,primer_efficiency' \
-F 'gene=pkn,polo' \
To interact with our API, you need to make a GET request to the following url :
https://crisprbuilder.com/api/query
Result example :
{
query: https://crisprbuilder.com/api?type=search&gene=polo
result: {
"id":12,
"name":"polo",
"isoForms":"[\"polo-RA\",\"polo-RB\"]",
"url":"https://flybase.org/download/sequence/FBgn0003124/gene_extended",
"sequence":"AAACAAAAGAGGCCACACGGCATTAGCGA...",
"isoForm":"polo-RA",
"time":"2021-09-06 13:42:23",
"isoFormSequence":"ATGGCCGCGAAGCCCGAGGATAAG..."
}
}
QUERY PARAMETERS
| Field |
Type |
Description |
| type |
String |
The type of api call you are making |
| gene |
String |
A search word to find the gene information. |
| isoForm |
String |
(Optional) A search word to find information on a specific isoform by name. |
RETURN VALUES
| Field |
Type |
Description |
| name |
String |
The search term you entered. |
| isoForms |
String |
A list of isoforms associated with the gene. |
| url |
String |
The flybase url from where this info was pulled. |
| sequence |
String |
The extended gene sequence pulled from Flybase. |
| isoForm |
String |
The isoform returned from the query (will return default isoform from flybase is one is not queried). |
| isoFormSequence |
String |
The full sequence of the isoform returned from the query. |
Errors
The Crispr Builder API uses the following error codes:
| Error Code |
Meaning |
| 000 |
Some parameters are missing. This error appears when you don't pass every mandatory parameters.
|


Below is a Timeline of Hemingway's Life:
- 1899 - Ernest Hemingway is born in Oak Park, Illinois.
- 1905 - Since birth, Hemingway was dressed as a girl by his mother. His mother finally dressed him in boys clothes.
- 1913 - Enrolled into Oak Park and River Forest High School.
- 1917 - Graduates from school, but forgoes college and instead, opts for a job as a Cubs reporter.
- 1918 - Leaves his job as a Cubs reporter to volunteer with Red Cross as an ambulance driver during the first World War.
- 1918 - In Italy, Hemingway was wounded in war. While in hospital, he fell in love with a nurse and they planned to get married.
- 1919 - His fiance calls him to say she had fallen in love with an Italian officer. His heartbreak lead to the novel, "A Farewell to Arms".
- 1920 - Hemingway moves to Toronto, Ontario to take a job as a reporter for the Toronto Star newspaper.
- 1921 - As a foreign correspondent in Paris for the Toronto Star, he falls in with a circle of writers and artists including Gertrude Stein and Ezra Pound.
- 1925 - Ernest Hemingway meets F. Scott Fitzgerald at the Dingo Bar in Paris, just two weeks after the publication of The Great Gatsby.
- 1926 - Hemingway's first novel, The Sun Also Rises, is published. The novel is critically acclaimed and commercially successful.
- 1928 - Ernest moves from Paris to Key West and lives there on and off through the 1950s and completes the majority of his life's writing at the house.
- 1929 - A Farewell to Arms is published. The novel's success makes Hemingway financially independent.
- 1932 - Hemingway goes to Spain to research bullfighting for Death in the Afternoon, his critically lauded nonfiction book on the subject.
- 1933 - Pauline and Ernest travel to Kenya for a ten-week safari. Hemingway falls in love with the continent.
- 1937 - Hemingway travels to Spain to report on Spanish Civil War for the North American Newspaper Alliance.
- 1940 - He remarries the journalist Martha Gellhorn and settles in Finca Vigia, the Cuban estate where they will live, off and on, for twenty years.
- 1940 - The United States enters World War II. Hemingway volunteers for the Navy, outfitting his fishing boat Pilar with guns to hunt for German submarines off the coast of Cuba.
- 1952 - The novella The Old Man and the Sea is published in Life magazine.
- 1953 - Ernest Hemingway is awarded the Pulitzer Prize for The Old Man and the Sea.
- 1954 - Hemingway is awarded the Nobel Prize in Literature, but is unable to travel to Stockholm due to serious injuries sustained in two separate plane crashes and a bushfire accident earlier in the year.
- 1961 - Hemingway leaves Cuba forever following the 1959 revolution in which his acquaintance Fidel Castro leads communist revolutionaries to power.
- 1961 - Suffering from depression, alcoholism, and numerous physical ailments, Ernest Hemingway commits suicide in Ketchum, Idaho.
For further information click here.


iterami
/
Guides.htm
/
EVE Online
/Abaddon
Fittings:
CARGO
DPS-CHEAP
DPS-EXPENSIVE
DPS-MAX
EHP-MAX
SALVAGE-CHEAP
UNDOCK-CHEAP
UNDOCK-EXPENSIVE
UNDOCK-MAX
Fittings
Code
Notes
Cargo
[Abaddon, CARGO] Expanded Cargohold II Expanded Cargohold II Expanded Cargohold II Expanded Cargohold II Expanded Cargohold II Expanded Cargohold II Expanded Cargohold II Multispectrum Shield Hardener II Multispectrum Shield Hardener II Large Shield Extender II Large Shield Extender II Civilian Gatling Pulse Laser Drone Link Augmentor II Drone Link Augmentor II Drone Link Augmentor II Drone Link Augmentor II Improved Cloaking Device II Salvager II Small Tractor Beam II Large Cargohold Optimization II Large Cargohold Optimization II Large Cargohold Optimization I Federation Navy Hammerhead x5 Federation Navy Hobgoblin x5
DPS Cheap
[Abaddon, DPS-CHEAP] Extruded Compact Heat Sink Extruded Compact Heat Sink Extruded Compact Heat Sink Extruded Compact Heat Sink Extruded Compact Heat Sink Extruded Compact Heat Sink Extruded Compact Heat Sink 100MN Monopropellant Enduring Afterburner Cap Recharger II Cap Recharger II Cap Recharger II Dual Heavy Modulated Pulse Energy Beam I Dual Heavy Modulated Pulse Energy Beam I Dual Heavy Modulated Pulse Energy Beam I Dual Heavy Modulated Pulse Energy Beam I Dual Heavy Modulated Pulse Energy Beam I Dual Heavy Modulated Pulse Energy Beam I Dual Heavy Modulated Pulse Energy Beam I Dual Heavy Modulated Pulse Energy Beam I Large Energy Burst Aerator II Federation Navy Hammerhead x5 Federation Navy Hobgoblin x5 Multifrequency L x8
DPS Expensive
[Abaddon, DPS-EXPENSIVE] Imperial Navy Heat Sink Imperial Navy Heat Sink Imperial Navy Heat Sink Imperial Navy Heat Sink Imperial Navy Heat Sink Imperial Navy Heat Sink Imperial Navy Heat Sink Core X-Type 100MN Afterburner Imperial Navy Cap Recharger Imperial Navy Cap Recharger Imperial Navy Cap Recharger Imperial Navy Dual Heavy Pulse Laser Imperial Navy Dual Heavy Pulse Laser Imperial Navy Dual Heavy Pulse Laser Imperial Navy Dual Heavy Pulse Laser Imperial Navy Dual Heavy Pulse Laser Imperial Navy Dual Heavy Pulse Laser Imperial Navy Dual Heavy Pulse Laser Imperial Navy Dual Heavy Pulse Laser Large Energy Burst Aerator II Large Energy Locus Coordinator I Federation Navy Hammerhead x5 Federation Navy Hobgoblin x5 Multifrequency L x8
DPS Max
[Abaddon, DPS-MAX] Makur's Modified Heat Sink Makur's Modified Heat Sink Makur's Modified Heat Sink Makur's Modified Heat Sink Makur's Modified Heat Sink Makur's Modified Heat Sink Makur's Modified Heat Sink Cormack's Modified 100MN Afterburner Chelm's Modified Cap Recharger Chelm's Modified Cap Recharger Chelm's Modified Cap Recharger Vizan's Modified Dual Heavy Pulse Laser Vizan's Modified Dual Heavy Pulse Laser Vizan's Modified Dual Heavy Pulse Laser Vizan's Modified Dual Heavy Pulse Laser Vizan's Modified Dual Heavy Pulse Laser Vizan's Modified Dual Heavy Pulse Laser Vizan's Modified Dual Heavy Pulse Laser Vizan's Modified Dual Heavy Pulse Laser Large Energy Burst Aerator II Large Energy Locus Coordinator I Federation Navy Hammerhead x5 Federation Navy Hobgoblin x5 Multifrequency L x8
EHP Max
[Abaddon, EHP-MAX] Cormack's Modified Damage Control Imperial Navy 1600mm Steel Plates Imperial Navy 1600mm Steel Plates Imperial Navy 1600mm Steel Plates Chelm's Modified Multispectrum Energized Membrane Chelm's Modified Multispectrum Energized Membrane Chelm's Modified Multispectrum Energized Membrane Thukker Large Shield Extender Estamel's Modified Multispectrum Shield Hardener Estamel's Modified Multispectrum Shield Hardener Estamel's Modified Multispectrum Shield Hardener Civilian Gatling Pulse Laser Drone Link Augmentor II Drone Link Augmentor II Drone Link Augmentor II Improved Cloaking Device II Salvager II Salvager II Small Tractor Beam II Large Trimark Armor Pump II Large Trimark Armor Pump II Large Trimark Armor Pump II Caldari Navy Hornet x5 Caldari Navy Vespa x5
Salvage Cheap
[Abaddon, SALVAGE-CHEAP] Large Armor Repairer II Damage Control II 1600mm Steel Plates II 1600mm Steel Plates II 1600mm Steel Plates II Multispectrum Energized Membrane II Multispectrum Energized Membrane II 500MN Quad LiF Restrained Microwarpdrive Eutectic Compact Cap Recharger Eutectic Compact Cap Recharger Eutectic Compact Cap Recharger Salvager II Salvager II Salvager II Salvager II Salvager II Salvager II Salvager II Salvager II Large Trimark Armor Pump I Large Trimark Armor Pump I Large Trimark Armor Pump I Federation Navy Hammerhead x5 Federation Navy Hobgoblin x5
Undock Cheap
[Abaddon, UNDOCK-CHEAP] Large Armor Repairer II Damage Control II 1600mm Steel Plates II 1600mm Steel Plates II 1600mm Steel Plates II Multispectrum Energized Membrane II Multispectrum Energized Membrane II Alumel-Wired Enduring Sensor Booster Alumel-Wired Enduring Sensor Booster Alumel-Wired Enduring Sensor Booster Alumel-Wired Enduring Sensor Booster Civilian Gatling Pulse Laser Drone Link Augmentor II Drone Link Augmentor II Drone Link Augmentor II Prototype Cloaking Device I Salvager II Salvager II Small Tractor Beam II Large Trimark Armor Pump I Large Trimark Armor Pump I Large Trimark Armor Pump I Federation Navy Hammerhead x5 Federation Navy Hobgoblin x5 Scan Resolution Script x4 Targeting Range Script x4
Undock Expensive
[Abaddon, UNDOCK-EXPENSIVE] Centus X-Type Large Armor Repairer Sentient Damage Control Imperial Navy 1600mm Steel Plates Imperial Navy 1600mm Steel Plates Imperial Navy 1600mm Steel Plates Centum A-Type Multispectrum Energized Membrane Centum A-Type Multispectrum Energized Membrane Sentient Sensor Booster Sentient Sensor Booster Sentient Sensor Booster Sentient Sensor Booster Civilian Gatling Pulse Laser Black Eagle Drone Link Augmentor Black Eagle Drone Link Augmentor Black Eagle Drone Link Augmentor Caldari Navy Cloaking Device Salvager II Salvager II Small Tractor Beam II Large Trimark Armor Pump II Large Trimark Armor Pump II Large Trimark Armor Pump II Federation Navy Hammerhead x5 Federation Navy Hobgoblin x5 Scan Resolution Script x4 Targeting Range Script x4
Undock Max
[Abaddon, UNDOCK-MAX] Draclira's Modified Large Armor Repairer Cormack's Modified Damage Control Imperial Navy 1600mm Steel Plates Imperial Navy 1600mm Steel Plates Imperial Navy 1600mm Steel Plates Chelm's Modified Multispectrum Energized Membrane Chelm's Modified Multispectrum Energized Membrane Cormack's Modified Sensor Booster Cormack's Modified Sensor Booster Cormack's Modified Sensor Booster Cormack's Modified Sensor Booster Civilian Gatling Pulse Laser Unit W-634's Modified Drone Link Augmentor Unit W-634's Modified Drone Link Augmentor Unit W-634's Modified Drone Link Augmentor Estamel's Modified Cloaking Device Salvager II Salvager II Small Tractor Beam II Large Trimark Armor Pump II Large Trimark Armor Pump II Large Trimark Armor Pump II Federation Navy Hammerhead x5 Federation Navy Hobgoblin x5 Scan Resolution Script x4 Targeting Range Script x4
Chelm's Modified Large Armor Repairer can also be used.


Result: Solihull draw at Dover to extend unbeaten run
Solihull held on to third spot in the Vanarama National League after taking a point in a 1-1 draw at Dover.
The Whites took the lead after five minutes when Inih Effiong flicked a free-kick into the far corner.
Moors were level before the break with a stunning free-kick from Jamey Osborne.
Osborne brought a decent save from the keeper after the break but neither side could find a winner, leaving Solihull unbeaten in four games.
body check tags ::


Alert
Edit Training
Name
name
Incorrect name
DateTLimit
Incorrect dateLimit
DateTraining
Incorrect dateTraining
Description
Description
Incorrect description
place
Incorrect place
duration
minutes
Incorrect duration
place
Incorrect countPlaces
place
Incorrect maxPlaces
Close
Create


CLIP Remote API Debugger
Authorization:
Re-login
URL:
GET
PUT
POST
DELETE
Message Body:
Command Response:


{% extends "mobile/page.html" %} {% set pagetitle = _('Forgot your password?') %} {% set body_id = 'forgot-pwd' %} {% set hide_menu = True %} {% block pagecontent %}
{{ _("No problem. Just enter the email address you used to sign up and you'll get a link to reset your password.") }}


Niagara (1953) 52
Ray Cutler (Max Showalter) is a winner of a shredded wheat essay contest, and his prize is a trip to Niagara Falls, with his wife Polly (Jean Peters). Ray is good-natured but somewhat smarmy. Peters has no discernable personality. Ray is waiting at the hotel for shredded wheat corporate bigshot Mr. Kettering, hoping for a job offer.
At a humble motel at Niagara, they meet a troubled married couple. George Loomis (Joseph Cotten) is a moody, paranoid man, unable to keep a job and in the process of losing wife Rose (Marilyn Monroe) who is voluptuous and much younger.
The Cutlers are nosy, especially Peters, going out of their way to talk to the Loomis's. Later, while touring the falls, Peters sees Monroe making out with a young man (Richard Allan).
 No wonder she is in such a good mood. She sets a trap for Cotten, with Allan and Cotten alone in the same elevator.
Later, Monroe pretends to be frantically worried about her missing husband. Again the Loomis couple are brought into the story as police search the area for Cotten. A body is fished from the rapids, and Monroe must identify it. We don't see the body, but Monroe does, screams, and is carried unconscious to a hospital.
For some reason, the motel owner moves the Cutler's belongings into the Loomis' former room. Peters is sleeping, when Cotten (he's alive!) enters, brandishing a kitchen knife, thinking Peters is Monroe. Peters gives an excellent scream (much more spirited than Monroe's was). Ray doesn't buy the story about Cotten being alive, and tells her she had a nightmare.
Mr. Kettering (Don Wilson) and wife arrive. Wilson is a gregarious backslapper, and insists and showing the Cutlers the area. They go to visit the falls.
Now the story becomes increasingly unbelievable. Somehow, Peters isolates herself from the party, convenient for meeting Cotten, who just happens to be there. Peters runs from Cotten, who tracks her down, admits to murdering Allan, wants her to "help him" without bothering to explain what help he wants. Peters escape, but doesn't tell anyone what she's seen. Returning to the motel, a police detective is waiting. Oddly, she lies to him at first, then finally tells him that Cotten is alive and Monroe knows it, not mentioning the murder of Allan. Amazingly, the detective leaves without asking any further questions.
Monroe makes the mistake of wandering about alone. Cotten, who certainly gets around, happens upon her, stalks her, and strangles her in the bell tower. He happens to get locked in the tower, but makes no effort to escape until the door is unlocked the next morning. Instead of remaining in hiding in Canada, Cotten returns to the American border, where he is sure to be spotted by a mass of people and policeman, who by now are looking for him.
Meanwhile, the Cutlers are boating with the Ketterings. In another unbelievable coincidence, Cotten, after hiding behind trees, sneaks into the boat after distracting the others. Peters returns alone to the boat. She sees Cotten, he tells her to leave, she physically attacks him, without calling for help! He knocks her out, heads straight to the falls to escape police, and runs out of gas. Perhaps the whole movie plot has been a slow-moving setup for Peters to be in peril. Cotten sacrifices himself for the damsel in distress, who watches in horror as Cotten goes over the falls.
http://members.tripod.com/~Brian_Koller/movies.html
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Bias-Variance Tradeoff
2020-12-04
2 minutes
There’s a lot of great diagrams, explanation, and tedious calculations to explain the bias-variance trade off, but I was trying to come up with a pithy explanation for statisticians who understand regression.
High Bias, Low Variance. Suppose you have some outcome data $y$ with moderate non-linearities, and you want to model it with some regression function $f$. Your first option is super basic; just the mean $y \sim f(\bar{y})$. The mean is not going to be sufficient enough to model the complexities so you’ll have high bias (predictions that are very different from the true value). However, you’ll have low variance (predictions with no variation) since $f$ (the mean in this case) is not sufficient enough to capture the variability in the outcome variable.
Low Bias, High Variance. Now you start packing $f$ with interaction terms and complex polynomials. The bias is going to go down since the model is really good at handling the complexities in the outcome variable. However, the variance is going to increase since $f$ is probably modeling noise in addition to the outcome variable.
We can also think about this in terms of underfitting and overfitting to the data. A simple $f$ with high bias and low variance will underfit the data, whereas a complexj $f$ with low bias and high variance will overfit the data.
underfit data
high bias
low variance
\
simple f()
|
|
|
complex f()
/
overfit data
low bias
high variance
ideally, you’re looking for some sweet spot in the middle that balances the bias and the variance. Although, it all depends on the data you’re modeling (e.g. in some cases a simple $f$ is better than a more complex $f$, and vice versa).
285 Words


Today, we’re announcing the availability of PyTorch 1.5, along with new and updated libraries. This release includes several major new API additions and improvements. PyTorch now includes a significant update to the C++ frontend, ‘channels last’ memory format for computer vision models, and a stable release of the distributed RPC framework used for model-parallel training. The release also has new APIs for autograd for hessians and jacobians, and an API that allows the creation of Custom C++ Classes that was inspired by pybind.
You can find the detailed release notes here.
C++ Frontend API (Stable)
The C++ frontend API is now at parity with Python, and the features overall have been moved to ‘stable’ (previously tagged as experimental). Some of the major highlights include:
- Now with ~100% coverage and docs for C++ torch::nn module/functional, users can easily translate their model from Python API to C++ API, making the model authoring experience much smoother.
- Optimizers in C++ had deviated from the Python equivalent: C++ optimizers can’t take parameter groups as input while the Python ones can. Additionally, step function implementations were not exactly the same. With the 1.5 release, C++ optimizers will always behave the same as the Python equivalent.
- The lack of tensor multi-dim indexing API in C++ is a well-known issue and had resulted in many posts in PyTorch Github issue tracker and forum. The previous workaround was to use a combination of
narrow
/select
/index_select
/masked_select
, which was clunky and error-prone compared to the Python API’s eleganttensor[:, 0, ..., mask]
syntax. With the 1.5 release, users can usetensor.index({Slice(), 0, "...", mask})
to achieve the same purpose.
‘Channels last’ memory format for Computer Vision models (Experimental)
‘Channels last’ memory layout unlocks ability to use performance efficient convolution algorithms and hardware (NVIDIA’s Tensor Cores, FBGEMM, QNNPACK). Additionally, it is designed to automatically propagate through the operators, which allows easy switching between memory layouts.
Learn more here on how to write memory format aware operators.
Custom C++ Classes (Experimental)
This release adds a new API, torch::class_
, for binding custom C++ classes into TorchScript and Python simultaneously. This API is almost identical in syntax to pybind11. It allows users to expose their C++ class and its methods to the TorchScript type system and runtime system such that they can instantiate and manipulate arbitrary C++ objects from TorchScript and Python. An example C++ binding:
template <class T>
struct MyStackClass : torch::CustomClassHolder {
std::vector<T> stack_;
MyStackClass(std::vector<T> init) : stack_(std::move(init)) {}
void push(T x) {
stack_.push_back(x);
}
T pop() {
auto val = stack_.back();
stack_.pop_back();
return val;
}
};
static auto testStack =
torch::class_<MyStackClass<std::string>>("myclasses", "MyStackClass")
.def(torch::init<std::vector<std::string>>())
.def("push", &MyStackClass<std::string>::push)
.def("pop", &MyStackClass<std::string>::pop)
.def("size", [](const c10::intrusive_ptr<MyStackClass>& self) {
return self->stack_.size();
});
Which exposes a class you can use in Python and TorchScript like so:
@torch.jit.script
def do_stacks(s : torch.classes.myclasses.MyStackClass):
s2 = torch.classes.myclasses.MyStackClass(["hi", "mom"])
print(s2.pop()) # "mom"
s2.push("foobar")
return s2 # ["hi", "foobar"]
You can try it out in the tutorial here.
Distributed RPC framework APIs (Now Stable)
The Distributed RPC framework was launched as experimental in the 1.4 release and the proposal is to mark Distributed RPC framework as stable and no longer experimental. This work involves a lot of enhancements and bug fixes to make the distributed RPC framework more reliable and robust overall, as well as adding a couple of new features, including profiling support, using TorchScript functions in RPC, and several enhancements for ease of use. Below is an overview of the various APIs within the framework:
RPC API
The RPC API allows users to specify functions to run and objects to be instantiated on remote nodes. These functions are transparently recorded so that gradients can backpropagate through remote nodes using Distributed Autograd.
Distributed Autograd
Distributed Autograd connects the autograd graph across several nodes and allows gradients to flow through during the backwards pass. Gradients are accumulated into a context (as opposed to the .grad field as with Autograd) and users must specify their model’s forward pass under a with dist_autograd.context()
manager in order to ensure that all RPC communication is recorded properly. Currently, only FAST mode is implemented (see here for the difference between FAST and SMART modes).
Distributed Optimizer
The distributed optimizer creates RRefs to optimizers on each worker with parameters that require gradients, and then uses the RPC API to run the optimizer remotely. The user must collect all remote parameters and wrap them in an RRef
, as this is required input to the distributed optimizer. The user must also specify the distributed autograd context_id
so that the optimizer knows in which context to look for gradients.
Learn more about distributed RPC framework APIs here.
New High level autograd API (Experimental)
PyTorch 1.5 brings new functions including jacobian, hessian, jvp, vjp, hvp and vhp to the torch.autograd.functional
submodule. This feature builds on the current API and allows the user to easily perform these functions.
Detailed design discussion on GitHub can be found here.
Python 2 no longer supported
Starting PyTorch 1.5.0, we will no longer support Python 2, specifically version 2.7. Going forward support for Python will be limited to Python 3, specifically Python 3.5, 3.6, 3.7 and 3.8 (first enabled in PyTorch 1.4.0).
We’d like to thank the entire PyTorch team and the community for all their contributions to this work.
Cheers!
Team PyTorch


- Electrostatics: 6-7%
- Current electricity: 6-7%
- Magnetic effects of current and magnetism:
5-6%
- Electromagnetic induction and alternating
currents:
6-7%
- Electromagnetic waves: 3-4%
- Ray optics and optical instruments: 5-6%
- Wave optics: 5-6%
- Dual nature of radiation and matter: 2-3%
- Atoms: 2-3%
- Nuclei: 3-4%
- Semiconductor electronics: 7-8%
- Communication systems: 3-4%
It is important to note that the
weightage can vary every year and these are just approximate values. Therefore, it is
recommended to cover all the topics thoroughly to increase the chances of scoring well in
JEE Main Physics.


Available on any device with a web browser, no matter what screen size. Touch optional.
Supports unlimited fixtures, cues, groups, effects, and presets, all stored in one small show file.
Outputs ArtNet, sACN, uDMX, and uses the ETC ColorSource fixture profile format.


|
| tuple | cross.body = pymunk.Body() |
| | Function used to place the walls in the world (walls scaled depending on screenview) In: the space Out: returns the shapes (l) of the walls. More...
|
| |
| tuple | cross.l1 = pymunk.Segment(body, (-0.39*screenview, 0), (0.0, 0.0), 5.0) |
| |
| tuple | cross.l2 = pymunk.Segment(body, (0.0, 0), (0.0, -0.39*screenview), 5.0) |
| |
| tuple | cross.l3 = pymunk.Segment(body, (0, 0), (0.39*screenview, 0.0), 5.0) |
| |
| tuple | cross.l4 = pymunk.Segment(body, (0.0, 0), (0.0, -0.39*screenview), 5.0) |
| |
| tuple | cross.l5 = pymunk.Segment(body, (-0.39*screenview, 0), (0.0, 0.0), 5.0) |
| |
| tuple | cross.l6 = pymunk.Segment(body, (0.0, 0), (0.0, 0.39*screenview), 5.0) |
| |
| tuple | cross.l7 = pymunk.Segment(body, (0, 0), (0.0, 0.39*screenview), 5.0) |
| |
| tuple | cross.l8 = pymunk.Segment(body, (0.0, 0), (0.39*screenview, 0.0), 5.0) |
| |
| int | cross.screenview = 300 |
| |
| tuple | cross.screen = pygame.display.set_mode((screenview, screenview)) |
| | Scren size. More...
|
| |
| tuple | cross.clock = pygame.time.Clock() |
| |
| tuple | cross.space = pymunk.Space() |
| |
| list | cross.bacs = [] |
| |
| tuple | cross.walls = add_walls(space) |
| |
| list | cross.points = [(0, -width), (0, width), (length,width), (length, -width)] |
| | Loop for the placement of recipients in the world considering the cross-shaped defined by the definition add_walls. More...
|
| |
| tuple | cross.r_y = random.uniform(0.48*screenview, screenview-0.48*screenview) |
| |
| tuple | cross.r_x = random.uniform(6*screenview/8,7*screenview/8) |
| |
| tuple | cross.r_angle = random.randint(0,360) |
| |
| tuple | cross.bac_shape = add_bac(space,r_x,r_y, math.radians(r_angle), points) |
| |
| tuple | cross.b = bacteria(bac_shape,[0,0],[0,0],[bac_shape.body.position.x, bac_shape.body.position.y], 0, False, False,1,0) |
| |


--- layout: post authors: ["Greg Wilson"] title: Advice From a Newbie No More date: 2013-01-04 time: "09:00:00" tags: ["Community"] ---
Adina Chuang-Howe recently wrote a great blog post titled "Advice from newbie to newbie", in which she gives some advice to her younger and not-yet-computationally-proficient self:
and most importantly of all: "You can do it!" The full article is great advice to anyone who's getting into computing, scientific or otherwise, and well worth reading.
Which raises the question: what advice would you give your younger self?


Moment Traffic Cop Gets Rammed by Bus at Busy Junction in India Caught on Video
New Delhi (Sputnik): Road accidents accounted for about 147,913 deaths in India in the year 2017 alone and result in in approximately half a million injuries to people annually.
The horrific crash was captured on CCTV camera at a busy four-way junction in the northern Indian city of Chandigarh.
In the video clip, the traffic cop can be seen managing a busy junction just when he gets hit from behind, taking him off-guard. The cop plummeted to the ground after being flung away from the bus with a massive jolt and laid unconscious on the road.
The man identified as Constable Kuldeep Singh had a narrow escape from death after he was rescued by the samaritans.


MISA++ Core
1.0.0
MISA++ core library
Class Hierarchy
Go to the textual class hierarchy
Generated by
1.8.15


--- layout: post tags: [Software Design] date: 2011-06-07 13:46:07 UTC title: "SOLID Code isn't" description: "As an word, the SOLID principles could easily give you the wrong mental model. SOLID code isn't solid, but rather supple." image_alt: "Coarse-grained objects" image: "/content/binary/Windows-Live-Writer/SOLID-Code-isnt_B434/largegrainedobjects_3.png" --- {% include JB/setup %}
Recently I had an interesting conversation with a developer at my current client, about how the SOLID principles would impact their code base. The client wants to write SOLID code - who doesn't? It's a beautiful acronym that fully demonstrates the power of catchy terminology.
However, when you start to outline what it actually means people become uneasy. At the point where the discussion became interesting, I had already sketched my view on encapsulation. However, the client's current code base is designed around validation at the perimeter. Most of the classes in the Domain Model are actually internal and implicitly trust input.
We were actually discussing Test-Driven Development, and I had already told them that they should only test against the public API of their code base. The discussion went something like this (I'm hoping I'm not making my ‘opponent' sound dumb, because the real developer I talked to was anything but):
Client: "That would mean that each and every class we expose must validate input!"
Me: "Yes…?"
Client: "That would be a lot of extra work."
Me: "Would it? Why is that?"
Client: "The input that we deal with consist of complex data structures, and we must validate that all values are present and correct."
Me: "Assume that input is SOLID as well. This would mean that each input instance can be assumed to be in a valid state because that would be its own responsibility. Given that, what would validation really mean?"
Client: "I'm not sure I understand what you mean…"
Me: "Assuming that the input instance is a self-validating reference type, what could possibly go wrong?"
Client: "The instance might be null…"
Me: "Yes. Anything else?"
Client: "Not that I can think of…"
Me: "Me neither. This means that while you must add more code to implement proper encapsulation, it's really trivial code. It's just some Guard Clauses."
Client: "But isn't it still gold plating?"
Me: "Not really, because we are designing for change in the general sense. We know that we can't predict specific change, but I can guarantee you that change requests will occur. Instead of trying to predict specific changes and design variability in those specific places, we simply put interfaces around everything because the cost of doing so is really low. This means that when change does happen, we already have Seams in the right places."
Client: "How does SOLID help with that?"
Me: "A result of the Single Responsibility Principle is that each self-encapsulated class becomes really small, and there will be a lot of them."
Client: "Lots of classes… I'm not sure I'm comfortable with that. Doesn't it make it much harder to find what you need?"
Me: "I don't think so. Each class is very small, so although you have many of them, understanding what each one does is easy. In my experience this is a lot easier than trying to figure out what a big class with thousands of lines of code does. When you have few big classes, your object model might look something like this:"
"There's a few objects and they kind of fit together to form the overall picture. However, if you need to change something, you'll need to substantially change the shape of each of those objects. That's a lot of work, and this is why such an object design isn't particularly adaptable to change.
"With SOLID, on the other hand, you have lots of small-grained objects which you can easily re-arrange to match new requirements:"
And that's when it hit me: SOLID code isn't really solid at all. I'm not a material scientist, but to me a solid indicates a rigid structure. In essence a structure where the particles are tightly locked to each other and can't easily move about.
However, when thinking about SOLID code, it actually helps to think about it more like a liquid (although perhaps a rather viscous one). Each class has much more room to maneuver because it is small and fits together with other classes in many different ways. It's clear that when you push an analogy too far, it breaks apart.
Still, a closing anecdote is appropriate...
My (then) three-year old son one day handed me a handful of Duplo bricks and asked me to build him a dragon. If you've ever tried to build anything out of Duplo you'll know that the ‘resolution' of the bricks is rather coarse-grained. Given that ‘a handful' for a three-year old isn't a lot of bricks, this was quite a challenge. Fortunately, I had an appreciative audience with quite a bit of imagination, so I was able to put the few bricks together in a way that satisfied my son.
Still, building a dragon of comparable size out of Lego bricks is much easier because the bricks have a much finer ‘resolution'. SOLID code is more comparable to Lego than Duplo.
Comments
http://bit.ly/ik3dCW
Functional units of small size are key to evolvable code. This makes for a fine grained "code sand" which can be brought into ever changing shapes.
The question however is: What is to become smaller? Classes or methods?
I´d say it´s classes that need to be limited in size, maybe 50 to 100 LOC.
Classes are to be kept small because they are the "blueprints" of the smallest stateful runtime units of code which can be recombined: objects.
However this leads to two problems:
1. It´s difficult to think of a decomposition of the very common noun-classes into smaller classes. How to break up a PaymentService class into many smaller classes?
2. Small classes would lead to an explosion of dependencies between all of these classes. They would be hard to manage (even with dependency injection).
That´s two reasons why most developers will probably resists decreasing the size of their classes. They´ll just keep methods small - but the effect of this will be limited. There´s no limit to the size of a class; 1,000 LOC class can consist of 100 methods each 10 lines long.
But the two problems go away if SOLID is applied in combination with a different view on object orientation.
We just need to switch from nouns to verbs when thinking about domain logic classes (not data classes).
If classes become functions (or maybe better behaviors) then there is no decomposition problem anymore. Behaviors can be as small as needed, maybe just 1 LOC.
Also behaviors conceptually don´t have any dependencies on each other (but maybe to an environment); sitting is not dependend on running even though running might "be done" after sitting.
"I certainly wouldn't want to drive a Lego car or walk across a Lego bridge"
ROTFL
Great quote! I've always liked the principles behind solid, but have always been a little turned off by some of the zealotry associated with it. Like most everything in life it's great "in moderation".
Thanks for your article.
You are describing a philosophy
which is almost standard practice
in Smalltalk since the 80's..
As you know, albeit desired, it is
however not always possible to
make small classes.
Recommended reading:
(also for OO in general)
"Smalltalk, Objects and Design"
by: Chamond Liu
ISBN: 1-8847777-27-9
Manning Publications Co, 1996.
Kind Regards
Ted
..btw I am sure that there must be
a photo of yours whereon you look a bit happier?
It's my experience that there is lots of discussion around the concept of abstraction and too little discussion around the use and practice of abstraction.
I interview many software development candidates, and I always explore what I consider foundational concepts - one is abstraction. I find most developers / programmers / software engineers (/ whatever), cannot adequately communicate HOW they use abstraction to enable their code - not on an architectural level, not on a modular level, not on a class level, and not even on a simple functional level. This is a real indication of the state of software design and it is alarming to me.
It's my belief that designing abstraction in software engineering is the most critical tool in software construction, but it is the least discussed.
So since there is no real expression of abstraction (except for inheritance) in code, it´s neglected or left to personal style. Sad.
I’m not convinced that the cost is indeed "really low", for two reasons.
1) Interfaces, before TDD became popular, imparted information to the maintainer of a type because they were used to indicate, for instance, that a given type was to be treated like a collection that could be enumerated or a type that could be compared with other types for the purposes of, say, sorting. When added reflexively as a means of inserting a level of indirection, the interface no longer imparts any information.
2) When navigating around a large code base where nearly all types are accessed via a level of indirection (courtesy of ubiquitous interfaces) my IDE – Visual Studio 2010 – struggles to answer common questions like "what code will be executed when SomeType.ReadHeader() is called?". Hitting F12 doesn’t take me to the definition of the method but rather takes me to the definition of the interface which, because of the point above, is of no value. ReSharper can sometimes find the method with a more advanced search but not always. The upshot of this is that code making heavy use of interfaces becomes much harder to statically analyse.
Agreed. That point is manifest in @Dave's subsequent post. So, how would the lack of direct language support for abstraction - other than inheritance - be solved? And how would code tracing / debugging interfaces and their implementations be handled?
My gut tells me this is one reason (of several) that scripting-like languages have gained popularity in the recent past, and that we are being pointed in a more real-time, interpreted language direction due to the necessary dynamic nature of these constructs. Hm... {thinking}
Love a blog that makes me think for more than a few seconds.
"So, how would the lack of direct language support for abstraction - other than inheritance - be solved?"
and I don´t know if we should hope for languages to offer support soon. We´ve to live with what we have: Java, C#, C++, Ruby etc. (Scripting languages to me don´t offer better support for abstraction.)
Instead we need to figure out how to use whatever features these languages offer in a way to express abstraction - and I don´t mean inheritance ;-)
And that leads to a separation of mental model from technical features. We need to think in a certain way about our solutions - and then translate our mental models to language reality.
Object orientation tried to unify mental model and code reality. But as all those maintenance nightmare projects show, this has not really worked out as nicely as expected. The combination of OO method (OOAD) and OO programming has not lived up to our expectations.
Since we´re pretty much stuck with OO languages we need to replace the other part of the pair, the method, I´d say.
Very interesting article...


Use the filters to subset the range of climate analogues. Every site/sample is represented multiple times in each filter (ones per sample where it serves as a climate analogue). If you want to select the unique sites/samples, check the Unique analogue site option.
Importance of analogue JJA temperature
The importance of the analogue JJA temperature is classified based the percentage that the corresponding temperature has been chosen in a constrained Gibbs sampling with 2000 realizations and a temperature threshold of 5 °C. We define
The only driver: The temperature has been sampled in more than 90% of the realizations
Extremely important: The temperature has been sampled in more than 75% of the realizations
Very important: The temperature has been sampled in more than 50% of the realizations
Important: The temperature has been sampled in more than 30% of the realizations
Less important: The temperature has been sampled in more than 15% of the realizations
Not important: The temperature has been sampled at least ones
Never used: The temperature of the analogue has never been used within the 2000 realizations
Importance of analogue DJF temperature
The importance of the analogue DJF temperature is classified based the percentage that the corresponding temperature has been chosen in a constrained Gibbs sampling with 2000 realizations and a temperature threshold of 5 °C. We define
The only driver: The temperature has been sampled in more than 90% of the realizations
Extremely important: The temperature has been sampled in more than 75% of the realizations
Very important: The temperature has been sampled in more than 50% of the realizations
Important: The temperature has been sampled in more than 30% of the realizations
Less important: The temperature has been sampled in more than 15% of the realizations
Not important: The temperature has been sampled at least ones
Never used: The temperature of the analogue has never been used within the 2000 realizations


|
| virtual void | open ()=0 |
| |
| virtual void | update (uint64_t time)=0 |
| |
| virtual void | close ()=0 |
| |
| void | exposeVariable (std::string const &name, std::string const &type, bool isPointer, bool isExposed, void *data) |
| |
- Parameters
-
| name | Display name of the window |
| width | Width of the window |
| height | Height of the window |
| colorBits | Number of color bits |
| depthBits | Number of depth bits |
| stencilBits | Number of stencil bits |
| display | Display mode |
| alwaysOnTop | Should this Window be rendered on top of other Windows? (Exclusive mode rendering) |
| virtual void Ocular::Core::AWindow::close |
( |
| ) |
|
|
protectedpure virtual |
- Returns
- The current depth texture.
| void * Ocular::Core::AWindow::getOSPointer |
( |
| ) |
const |
Returns the raw Operating System specific pointer for this window. This can be cast to HWND on Windows, etc.
- Returns
- The current backbuffer render texture.
| bool Ocular::Core::AWindow::hasFocus |
( |
| ) |
const |
- Returns
- TRUE if this window currently has input focus.
| bool Ocular::Core::AWindow::onEvent |
( |
std::shared_ptr< AEvent > |
event | ) |
|
|
overridevirtual |
| virtual void Ocular::Core::AWindow::open |
( |
| ) |
|
|
protectedpure virtual |
Opens and initializes the Window.
| void Ocular::Core::AWindow::resize |
( |
uint32_t |
width, |
|
|
uint32_t |
height |
|
) |
| |
If the window dimensions do not already match the specified width/height, then the window will be resized. In addition to this, the descriptor, render target, and depth stencil textures will be updated and recreated to match the new dimensions.
- Parameters
-
Sets the DepthTexture to use for depth values.
This method is typically called automatically during window creation and/or GraphicsDriver initialization. Except for special circumstances it should not be called externally.
- Note
- When set, the window assumes owndership of the texture and will destroy it when it is no longer in use.
- Parameters
-
| void Ocular::Core::AWindow::setDescriptor |
( |
WindowDescriptor const & |
descriptor | ) |
|
Sets the RenderTexture to use as the backbuffer.
This method is typically called automatically during window creation and/or GraphicsDriver initialization. Except for special circumstances it should not be called externally.
- Note
- When set, the window assumes ownership of the texture and will destroy it when it is no longer in use.
- Parameters
-
| void Ocular::Core::AWindow::showCursor |
( |
bool |
show | ) |
|
|
virtual |
Turns the cursor on and off.
- Parameters
-
| [in] | show | If TRUE, the cursor is displayed while the window has focus. |
| virtual void Ocular::Core::AWindow::update |
( |
uint64_t |
time | ) |
|
|
protectedpure virtual |
Updates and recreates the Window.
The documentation for this class was generated from the following files:
- C:/Projects/OcularEngine/OcularCore/include/Renderer/Window/Window.hpp
- C:/Projects/OcularEngine/OcularCore/src/Renderer/Window/Window.cpp


Bogus Data? No Chance.
We at Resumeker don't want our database to be messed up with any kind of malware and manipulate it. So, we use reCAPTCHA that makes sure that no data is pushed to database with the help of bots.
Security issues? Don't worry.
All your http requests are encrypted using https - SSL certification.  To know more, tap the padlock on your browsers address bar.
Data misuse? Never happens.
No data of our users is stored forever. We follow "24 hours data updation and deletion rule" where any fresh data recieved will be stored temperorily and is deleted once the task - Resume gets done.


JavaScript is disabled on your browser.
Skip navigation links
Package
Class
Tree
Deprecated
Index
Help
Prev
Next
Frames
No Frames
All Classes
C
G
I
M
N
O
S
T
C
Collectors
- Class in
com.github.protobufel.multikeymap
The utility class providing the MultiKeyMap and multiple sets' intersection related collectors.
com.github.protobufel.multikeymap
- package com.github.protobufel.multikeymap
Java 8 implementation of the
MultiKeyMap
.
G
getEntriesByPartialKey(Iterable<? extends T>)
- Method in interface com.github.protobufel.multikeymap.
MultiKeyMap
Gets all entries for which their full keys contain the partial key set in any order.
getEntriesByPartialKey(Iterable<? extends T>, Iterable<Integer>)
- Method in interface com.github.protobufel.multikeymap.
MultiKeyMap
Gets all entries for which their full keys contain the partial key according to the specified positions.
getFullKeysByPartialKey(Iterable<? extends T>)
- Method in interface com.github.protobufel.multikeymap.
MultiKeyMap
Gets all full keys that contain the partial key set in any order.
getFullKeysByPartialKey(Iterable<? extends T>, Iterable<Integer>)
- Method in interface com.github.protobufel.multikeymap.
MultiKeyMap
Gets all full keys that contain the partial key according to the specified positions.
getValuesByPartialKey(Iterable<? extends T>)
- Method in interface com.github.protobufel.multikeymap.
MultiKeyMap
Gets all values for which their full keys contain the partial key set in any order.
getValuesByPartialKey(Iterable<? extends T>, Iterable<Integer>)
- Method in interface com.github.protobufel.multikeymap.
MultiKeyMap
Gets all values for which their full keys contain the partial key according to the specified positions.
I
intersectSets(Iterable<? extends Set<T>>, boolean)
- Static method in class com.github.protobufel.multikeymap.
Collectors
Returns the Optional result of the intersection of all sets in the supplied Iterable.
M
MultiKeyMap
<
T
,
K
extends java.lang.Iterable<
T
>,
V
> - Interface in
com.github.protobufel.multikeymap
Represents a generic Map of composite keys plus the methods to query it by any combination of sub-keys.
MultiKeyMaps
- Class in
com.github.protobufel.multikeymap
Provides the factory methods of the generic MultiKeyMap implementations.
N
newMultiKeyMap(Supplier<Map<K, V>>, boolean)
- Static method in class com.github.protobufel.multikeymap.
MultiKeyMaps
Creates a new MultiKeyMap based on the provided map supplier.
newMultiKeyMap()
- Static method in class com.github.protobufel.multikeymap.
MultiKeyMaps
Creates a new default, Serialiazable instance of MultiKeyMap.
O
of(Map<K, V>)
- Static method in class com.github.protobufel.multikeymap.
MultiKeyMaps
Creates a new default, Serialiazable instance of MultiKeyMap initialized off the data by the supplied Map.
S
setIntersecting(Set<T>, boolean)
- Static method in class com.github.protobufel.multikeymap.
Collectors
Gets a collector which intersects the stream of sets and returns the resulting set.
setIntersecting(Supplier<Set<T>>, boolean)
- Static method in class com.github.protobufel.multikeymap.
Collectors
Gets a collector which intersects the stream of sets and returns the resulting set.
T
toMultiKeyMap(Function<? super T, ? extends K>, Function<? super T, ? extends V>)
- Static method in class com.github.protobufel.multikeymap.
Collectors
Gets a MultiKeyMap producing collector.
toMultiKeyMap(Function<? super T, ? extends K>, Function<? super T, ? extends V>, BinaryOperator<V>)
- Static method in class com.github.protobufel.multikeymap.
Collectors
Gets a MultiKeyMap producing collector.
toMultiKeyMap(Function<? super T, ? extends K>, Function<? super T, ? extends V>, BinaryOperator<V>, Supplier<M>)
- Static method in class com.github.protobufel.multikeymap.
Collectors
Gets a MultiKeyMap producing collector.
C
G
I
M
N
O
S
T
Skip navigation links
Package
Class
Tree
Deprecated
Index
Help
Prev
Next
Frames
No Frames
All Classes


"The journey of a thousand miles begins with a single step."  You know when you are writing a paragraph in a word processor and you forget to include punctuation here and there like a period at the end of a sentence? It can throw off the format and overall flow of the paper, right? In the same way, if you forget end syntax when writing CSS like a semicolon or a closing curly bracket, the way elements are positioned can be completely thrown off. So before you go any further with trying to position your page in CSS, validate your code here to make sure you haven't forgotten any important syntax. Many frustrations disappeared when I found little errors like forgetting to include that end syntax!
Now. It's going to get a little complicated and I don't consider myself an expert yet, but here are a few things I have found to be helpful when working with positioning. Here are some notes I've surmised about each applied to one of our positioning challenges (see screenshot below when referenced):
STATIC (Div 1)
This is the default position, that means this is what the elements will automatically take on for their position on a page. (Being the default, you do not have to delagate the position in your CSS stylesheet.)
A static element will automatically assume the width of the page or the browser window. See the "Div 1" box in the image below. It takes up the whole width of the page.
In static, block elements naturally stack on top of each other. This is the natural flow of the page. If Div 2, Div 3, and Div 4 were all static, they would line up under Div 1, looking just like it but with their different colors.
You cannot tell a static element how far to go from the top, right, bottom, or left of the page. To do this, we need to move on to relative positioning.
However, it is important to know, that blocks in static can have margins. In the example below, the Div 1 element DOES have a bottom margin of 20 pixels that will affect Div 2, as you will see in the next section.
RELATIVE (Div 2)
Relative positioned elements want to follow the natural flow of the page like they do in static. However, we can be more specific about where we want a relative positioned element to be by giving them directional properties (how far from left, top, right, bottom).
In the image below, it is hard to see at a glance that Div 2 is in the natural flow of the page, but knowing what is going on behind the scenes will help.
Div 2 has some other properties that have been delegated to it that make it look so far away from Div 1:
ABSOLUTE (Div 3)
An element with absolute positioning ABSOLUTELY wants to stay where it has been assigned in relation to the browser window.
It does not impact the flow of static or relative positioned elements and will sit on top of other elements, as you can see below, Div 3 is sitting on top of Div 2.
It can be given dimensions of width and height, and also directional properties of top, right, bottom, left.
Things start to get tricky when an element with absolute position is nested in another element that has relative, absolute, or fixed value. But basically, it will absolutely position itself relative to its parent element.
FIXED (Div 4)
An element with a fixed position is much like an element in absolute position but it will never respect any of its parents positions.
It will always position itself in relation to the browser window.
In the image below, this isn't captured, but if you were to scroll up and down the page where the div boxes are, Div 4 would stay in that exact same location.
Well this is what I have figured out so far. I have found that floats, padding, and margins really throw me off when it comes to working with positioning. I'm looking forward to learning more about those and become more skilled with positioning!


List of my favorite things
raindrops on roses
whiskas on kittens
call of duty: modern warfare
List of things I find OK
OK
KO
OKOK


From:Hayslett Rod To:Geaccone Tracy Sent:2017-01-11T04:38:09.0000000Z Subject:FW: Sun Devil D R A F T and meeting notice
I won't guarantee I can make it, but I will try. Here are some thoughts, as we move forward with this deal:
Levelized rates - will require separate rate base, not rolled in, since the base system is not levelized and separate tariff schedules like a FTS-2
Also we need to see what the GAAP income statments will look like and what the return on equity will really look like if we do this. It may surprise some of the people. I also think we need to make sure Stan is OK with the potential result if we are going to offer it.
-----Original Message-----
From: Hyatt, Kevin
Sent: Wednesday, August 01, 2001 7:45 PM
To: Lindberg, Lorraine; Harris, Steven; Watson, Kimberly; Centilli, James; Geaccone, Tracy; Hayslett, Rod
Cc: Lokey, Teb; Kilmer III, Robert; Gadd, Eric
Subject: Sun Devil D R A F T and meeting notice
Importance: High
Attached is the open season and binding bid package for the Sun Devil Pipeline Project. We will meet in Steve Harris' office on Thurs 8/2 at 10:30am to get a consensous on the pitch strategy. We should also have a good idea on rates as well. I hope you can join us. If not, please get with me later in the day with any questions or concerns. Our goal is to release this to the media for publication Friday 8/3.
Kevin Hyatt
x35559
***********
EDRM Enron Email Data Set has been produced in EML, PST and NSF format by ZL Technologies, Inc. This Data Set is licensed under a Creative Commons Attribution 3.0 United States License <http://creativecommons.org/licenses/by/3.0/us/> . To provide attribution, please cite to "ZL Technologies, Inc. (http://www.zlti.com)."
***********
California


{% extends 'layout.html' %} {% block pageTitle %} Upload evidence {% endblock %} {% block content %} {{ backLink({ "href": "javascript:history.go(-1)", "text": "Go back" }) }}
Step 1 of 5
The best way to get a paper document onto a device, as a digital file, is to take a photo of it.
You can use anything that has a digital camera on it. For example, a mobile phone, tablet or digital camera.


We're sorry but vue-weather-v2 doesn't work properly without JavaScript enabled. Please enable it to continue.


Referral links to useful sites/apps
Robinhood : Free stock and crypto trading
http://share.robinhood.com/shankag5
Binance : Low trading fee, stable and support for most currencies
https://www.binance.com/?ref=12268205


Trolls bugged
Posted: Wed Oct 14, 2009 1:48 pm
There were three of us this morning Heph, Swift, and fluffy kitten, and all of us seemed to be getting booted at trolls within 1minute of entering the area.. I hunted other areas for a few hours with minimal interuptions and I just went back to trolls when BAM, I got booted. I think that area is bugged.


Nyquist Plot as a function of temperature for ( a) Mn4 and ( b) Mn8. ( c) equivalent circuit. R1 and R2: resistances; CPE-1 and CPE-2: constant phase element; and Wo1: Warburg open element. The insert in ( a) corresponds to an increase in the scale between 0 to 8 kΩ, The insert in ( b) corresponds to an increase in the scale between 0 to 50 kΩ.