text:
# OpenFSC Protocol Specification (Version 1.0)

<img align="right" width="25%" src="../assets/connected-fueling-logo.svg">

Copyright (c) 2019, 2020 PACE Telematics GmbH

**Table of contents**

- [1 About This Document](#1-about-this-document)
  - [1.1 Not Part of this Document](#11-not-part-of-this-document)
- [2 Architecture Overview](#2-architecture-overview)
  - [2.1 Parties](#21-parties)
  - [2.2 Requirements](#22-requirements)
- [3 Process Overview](#3-process-overview)
  - [3.1 Post Pay Process](#31-post-pay-process)
  - [3.2 Pre Auth Process](#32-pre-auth-process)
- [4 Communication Protocol](#4-communication-protocol)
  - [4.1 Plain Text Protocol](#41-plain-text-protocol)
    - [4.1.1 TAG](#411-tag)
    - [4.1.2 Methods and Arguments](#412-methods-and-arguments)
    - [4.1.3 Example Plaintext Session](#413-example-plaintext-session)
    - [4.1.4 EBNF](#414-ebnf)
    - [4.1.5 Protocol Extensions](#415-protocol-extensions)

# 1 About This Document

This document describes the measures required to enable a gas station forecourt system to be part of Connected Fueling Platform. The whole process is also known as "pay-at-the-pump" and enables a customer to pay for fuel using a smartphone (or directly within the car using the integrated HMI systems) while staying on the forecourt without entering the gas station shop.

The process can simply be described as follows:

- A customer stops the car at the forecourt
- Using the app the customer selects the correct pump and can inspect the fueling related data
- The customer refuels...
- A Mobile Payment is issued by the user using the mobile app

The above example describes the flow for a mobile phone, the flow for a car HMI is exactly the same. Because of that, all examples are done using the mobile app term.

The Fueling Site Connect API is hereinafter referred to as "OpenFSC".

## 1.1 Not part of this document

The payment process is not directly part of this document, due to the fact, that payment is the responsibility of the OpenFSC server side. The server is signaling to the gas station, that the fueling was payed.

On-boarding of the gas station requires some meta data about the station. That includes but is not limited to data like the address, the geo location (latitude, longitude), brand and station name. The data is important for the customer to be routed to a gas station, understand the current pump selection or allow the app to automatically find the correct gas station for a given location.

However, there's a document outlining expected data and ways to integrate:

- [PACE POI Service: Gas Station Data](https://www.notion.so/PACE-POI-Service-Gas-Station-Data-4146aeec34fa462c99d40c88286a3b2a)

The documentation for the API and the interaction between the App and the Connected Fueling API can be found here:

- [Connected Fueling API Documentation](https://developer.pace.cloud/docs/cloud/fueling)

# 2 Architecture Overview

- The gas station (often also known as Site) uses either a POS (Point of Sale) or a dedicated hardware (Site Connect Box) that connects to the OpenFSC server in order to enable Mobile Payment.
- In order to connect the POS or any dedicated hardware to an OpenFSC server, an internet connection in conjunction with simple but secure communication protocols is used.
- On the customer side, multiple clients are implementing the Connected Fueling API, ranging from HMI (Human Machine Interfaces) in new cars to retrofit solutions like the PACE Car platform, PACE Drive and many other mobility-focussed mobile apps.

![assets/architecture-overview.png](assets/architecture-overview.png)

## 2.1 Parties

Main parties in the Connected Fueling process are

- The **customer** with the **mobile app**
  Uses some client for the Connected Fueling Platform in order to get up-to-date information about the gas station, and pay for fuel later.

- The **gas station** using either a **POS**, a connected **Site controller**, a **Site Connect software** running somewhere within the stations network or **Site Connect Box** running the software.

  One of the above components starts the connection to the OpenFSC server to provide prices, pumps, (open) transactions and accepts transaction clearing.

- **PACE** with its **Connected Fueling** platform

  Accepting connections from many parties (Mobile apps, In-car HMI systems, ...), translates (proprietary) protocols and exchanges the station, pump, fueling and payment information.

## 2.2 Requirements

The following minimal requirements are assumed when implementing OpenFSC:

- An internet connection
- Ability to connect to an OpenFSC server via either
  - Secure WebSockets over port 443 (TLS 1.2)
  - Plaintext based TCP stream protocol over a secured VPN (eg. IPSec)
- Access to the pump status information for all pumps
- Ability to inform OpenFSC server about changes of the pump status
- Access to the current fuel prices, including the product id, name, ...
- Ability to inform OpenFSC server about price changes when they occur
- Access to current, uncleared transactions on the pumps including
  - a transaction id
  - the transaction state
  - the product id
  - the fueled amount
  - the price, price with vat, vat
- Information about the currency used as well as current time
- Authentication data, needed to connect to an OpenFSC Server.

# 3 Process Overview

The Connected Fueling process can be divided into two main processes: the Post Pay and the Pre Auth process. The Post Pay process is very prominent in Germany and represents the payment after the fueling. The Pre Auth process is widely used outside of Germany or with 24/7 unmanned stations. Both processes can be implemented using the OpenFSC protocol. Both processes are described using the plain text protocol (secured using TLS1.2 or VPN) offered by OpenFSC.

Both processes start by updating the current pumps and price information, in order to present current data to the user. The price information needs to be sent via OpenFSC when changed in order to show current prices to the users that haven't already reached the forecourt.

## 3.1 Post Pay Process

- The user then selects the current pump which is reflected in the protocol by once again retrieving the updated status. That is because the user can go back to the overview and select another pump, in case the pump was mistakenly chosen. Having current pump information is, therefore, the first step.
- Using the pump status method with a ttl (time to live) for the update will ask the client to continuously send updates for the given pump for a given amount of time.
- If the pump status reaches the **ready-to-pay** state, open transactions will be requested using OpenFSC. The information will be used to show a nicely formatted bill to the customer.
- The customer selects the payment method and pays using a payment method he already registered with his digital wallet. Please note: The registration of payment methods is not covered by this document.

![assets/post-pay-flow.png](assets/post-pay-process.png)

## 3.2 Pre Auth Process

- The user has to pre-authorize the payment, the amount is explicitly chosen by the user OR implicitly set high enough, such that a full fueling could take place (tank size _ fuel type price _ 120%).
- The status updates work in the same way as with a Post Pay fueling, the only difference is, that the process waits until the state **locked** is reached. The pre-authorized amount will be captured by the gas station by providing the fuelled amount and price.
- The user will be presented with the bill and informed that the transaction is complete.

![assets/pre-auth-flow.png](assets/pre-auth-process.png)

# 4 Communication Protocol

This section specifies the general communication protocol between a Site and the OpenFSC server.

The protocol is independent of the particular transmission subsystem and requires only a reliable and ordered data channel (e.g. WSS or TCP stream). Furthermore, all specifications here should be portable to multiple formats like binary, json or xml. However, in this document we illustrate the protocol in a plain text encoding.

A single communication channel is always distinct to a single client server pair. This means each connection is directly related to a real Site. Currently there are no plans to enable multiple Site connections over one communication path.

The Site has to initiate the connection to the OpenFSC server. In case the connection dropped the Site needs to reconnect immediately.

## 4.1 Plain Text Protocol

The protocol consists of predefined messages. A message always starts with a so called `tag` followed by a `method`, multiple arguments `arg0` - `argN` as well as a special optional last argument `argV`. The end of a message is indicated by a <CRLF> (`\r\n`):

```xml
<tag> <method> <arg0> <arg1> ... <argN> <argV>\r\n
```

All message fields except the termination sequence <CRLF> are separated by spaces and the default message encoding is `ASCII`. To change the encoding a special method called `CHARSET` can be used which is described in a later section.

To establish a connection, the client first establishes a data channel (e.g.: TCP) to the server and starts a handshaking process to establish the actual Site API connection. This initialization phase is a so-called "Not Authenticated State" and consists of a special sequence of messages to negotiate the communication contract between the server and the client. The first message from both sides always has to be a notification with a `CAPABILITY` message. If an error occurs on either side the corresponding party will disconnect and optionally send a `QUIT` notification with further information about the error. In case of a successful capability exchange, the client can change the protocol encoding by sending one of the available encoding messages specified further below. The initialization phase will be concluded with an authentication message like `PLAINAUTH`. If everything was successful, the connection is considered established and transitions into a so-called "Authenticated State".

![assets/site-api-connection-example.png](assets/site-api-connection-example.png)

### 4.1.1 TAG

The `<tag>` indicates the type of the message as well as the current context and needs to satisfy the format `"*" | letter { letter | digit }` (see EBNF for full specification). There are currently two supported message types:

**Request/Response** - indicated by the tag `letter { letter | digit }`

In this case the tag specifies the message context, which means if one party sends a request message with the tag `S1` the receiving end will answer with the same tag `S1` in its response. The established context is valid until a timeout is triggered or the recipient answers with an `OK` or `ERR` response. The tag of a request must match the tag of its response.

```
S: S6 HEARTBEAT 2019-11-13T07:00:04Z
C: S6 BEAT 2019-11-13T08:00:05+01:00
C: S6 OK
```

**Notification** - indicated by the tag `"*"`

A notification indicates a message which expects no response. Besides the reliable transport requirement, this means there is no acknowledgement of any form that the sent message was processed correctly.

```
C: * PUMP 1 free
C: * PUMP 2 free
C: * PUMP 3 in-use
C: * PUMP 4 ready-to-pay
```

A notification can also be a synchronous answer to a previously issued request/response:

```
S: S1 PUMPS
C: * PUMP 1 free
C: * PUMP 2 free
C: * PUMP 3 in-use
C: * PUMP 4 ready-to-pay
C: S1 OK
```

### 4.1.2 Methods and Arguments

A message represents an operation that should be performed by the receiving side. Each message consists of a method and a list of defined arguments. Each method has its own arguments and message type (Request/Response or Notification). The name of the method must follow the format `letter { letter | digit }` while all normal arguments (`arg0`- `argN`) can use all characters of the specified encoding except control characters and space (`"\x21"…"\x7E"`). The method and all arguments are separated by spaces. The last argument can be a so called "variadic" argument (`argV`) which supports a sequence of any character compatible with the negotiated protocol encoding besides <CRLF> (`"\x00"…"\xff" - "\r" - "\n"`). The last argument (`argN` or `argV`) as well as the whole message is terminated by <CRLF> (`\r\n`).

#### Handshake/Not Authenticated State

##### `CAPABILITY`

Type: **Notification**

Direction: **Server → Client, Client → Server**

Always the first message issued by both parties. Information about the available methods of the sending party. If an error occurs while receiving/processing the capabilities of the other party, the recipient should terminate the connection. Optionally he can send a **QUIT** message to provide extra information before triggering the disconnect.

Arguments:

- **Whitespace separated list of methods supported by the sending party**

##### `CHARSET` (Encoding Method)

Type: **Request/Response**

Direction: **Client → Server**

Change the protocol encoding for all subsequent messages. If the encoding change was successful, OK will be returned. In case of an error the server returns an ERR message. **CAUTION:** The response to this request will still use the old encoding (default: `ASCII`).

Arguments:

- **Name** (arg0, string): supported values: `WINDOWS-1252`, `ISO-8859-1`, `UTF-8` \*\*\*\*(more charsets possible on request)

Errors:

- **404** Unknown encoding

##### `PLAINAUTH` (Authentication Method)

Type: **Request/Response**

Direction: **Client → Server**

Trigger an authentication process usually from the client side, with plain credentials. If the authentication was successful, OK will be returned. In case of an error the server responds with an ERR message.

Arguments:

- **SiteAccessKey** (arg0, uuid): identification of the connecting site
- **Secret** (arg1, string): corresponding secret for proof of identification

Errors:

- **401** SiteAccessKey and/or secret are not valid

#### Authenticated State

##### `CLEAR`

Type: **Request/Response**

Direction: **Server → Client**

Mark a transaction as cleared from server side. This frees the occupied pump and deletes the corresponding transaction. If the operation was successful, OK will be returned. In case of an error the client returns an ERR message.

In case the clear could not be acknowledged by the client side due to a network disconnect, the clear is half processed.
The transaction can now be in two states, `cleared` and `open`. In case the transaction is still `open` it will be reported by the usual `TRANSACTIONS` call,
the server can safely assume the `CLEAR` was never received and retry. In case the transaction was `cleared` the transaction is not reported by the `TRANSACTIONS` call. The server doesn't know if this was caused by the `CLEAR`,
or a payment in the shop. To resolve the information issue, the server will retry to clear the transaction after the client reconnected.
If the client reports **403** the payment was done externally and **not** cleared by the server, usually by paying in the shop. If the client reports **410**
the initial `CLEAR` was processed by the client and the server can now assume that the payment was successfully made. Some clients may only store the transaction
for a certain time period (e.g. 24h). If the connection is not established for that time period, the client may responds with **404** the transaction isn't known
any longer, this will cause an expensive back office process and should be avoided if possible. Summary of the errors on retry and how they are understood:
- **404** Initial clearing was too long ago, the client doesn't known about the transaction any longer → back office process
- **403** The payment was done otherwise → the payment transaction will be canceled
- **410** The transaction was accepted → transaction successful

**Important:** Please make sure that transactions cleared via OpenFSC are marked as such in the **reconciliation lists** shared with the MOC. eg. by adding a field "Clearance source" with a value "Connected Fueling" and the used **PaymentMethod** to the lists.

Arguments:

- **Pump** (args0, number): identifier of the concerned pump. Lowest possible value: 1.
- **SiteTransactionID** (arg1, string): ID of the transaction which should be cleared. Defined by the client with a previous TRANSACTION message. In case of UNLOCKPUMP the **SiteTransactionID** and **FSCTransactionID** may be the same, since the site returns the transaction id provided by OpenFSC.
- **FSCTransactionID** (arg2, uuid): ID defined by the server side. If the transaction was triggered with UNLOCKPUMP the ID must match with the one of the previous UNLOCKPUMP method.
- **PaymentMethod** (arg3, string): Name of the payment method used e.g. `pace`, `dkv`, ...

Errors:

- **404** Pump and SiteTransactionID unknown
- **403** Payment method not permitted
- **410** SiteTransactionID not open any longer and FSCTransactionID was the same

##### `HEARTBEAT`

Type: **Request/Response**

Direction: **Server → Client**

Check if the client is still available and try to calculate the time drift between server and client. This method is issued occasionally to detect the time drift and if there has been no communication between server and client for some time. The client answers with a tagged BEAT message before sending an OK. If an error occurred the client returns an ERR message.

Arguments:

- **Timestamp** (arg0, string): time at which this message was sent in the format of `RFC-3339`.

Errors:

- **422** Timestamp invalid

##### `LOCKPUMP`

Type: **Request/Response**

Direction: **Server → Client**

Cancel a previously with UNLOCKPUMP issued fueling process from the server side. If the operation was successful, OK will be returned. In case of an error, the client returns an ERR message.

Arguments:

- **Pump** (arg0, number): identifier of the concerned pump. Lowest possible value: 1.

Errors:

- **402** Payment required (pump can't be locked due to a pending payment)
- **404** Pump unknown
- **423** Already locked

##### `PRICE`

Type: **Notification**

Direction: **Client → Server**

Price of a specific product in price per litre. Should be sent as reaction to a previous PRICES message and may be sent pro-actively if a price changes.

Arguments:

- **ProductID** (arg0, string): identifier of the product. (e.g.: 0100)
- **Unit** (arg1, string): unit used by the subsequent **PricePerUnit** argument. Supported values: **LTR**
- **Currency** (arg2, string): currency used by the subsequent **PricePerUnit** argument. Supported values, see [Supported Currencies](#416-supported-currencies), for example **EUR**.
- **PricePerUnit** (arg3, decimal): end user price per unit including VAT in the specified **Unit** (arg1) and the specified **Currency** (arg2). (e.g. for EUR/LTR: 1.339)
- **Description** (argV): human readable name/description of the product. (e.g.: Super Plus)

##### `PRICES`

Type: **Request/Response**

Direction: **Server → Client**

Get the current prices for all available products in the form of price per litre. The client needs to make sure that all prices have been transmitted with PRICE notifications before he can send an OK to conclude the PRICES request. In case of an error the client returns an ERR message.

Arguments: **None**

##### `PUMP`

Type: **Notification**

Direction: **Client → Server**

Status of a specific pump sent from the client. Should be sent as reaction to a PUMPS, PUMPSTATUS, UNLOCKPUMP message and may be sent pro-actively if the status of a pump changes.

Arguments:

- **Pump** (arg0, number): identifier of the pump. Lowest possible value: 1.
- **Status** (arg1, string)**:** status of the current pump. Supported values: **free**, **in-use, in-transaction**, **ready-to-pay, locked** or **out-of-order**

##### `PUMPS`

Type: **Request/Response**

Direction: **Server → Client**

Get the statuses of all pumps at the site. The client needs to make sure that all pump states have been transmitted with PUMP notifications before he can send an OK to conclude the PUMPS request. In case of an error the client returns an ERR message.

Arguments: **None**

##### `PUMPSTATUS`

Type: **Request/Response**

Direction: **Server → Client**

Get the status of a specific pump. The client needs to make sure that the requested pump state has been transmitted with a PUMP notification before he can send an OK to conclude the PUMPSTATUS request. In case of an error the client returns an ERR message.

Arguments:

- **Pump** (arg0, number): identifier of the concerned pump. Lowest possible value: 1.
- **UpdateTTL** (arg1, number, optional): time to live in seconds for expected update signals from the client. After the OK response the client informs the server about status changes of the specified pump till the TTL is reached. Explicitly only status changes should be sent in this case.

Errors:

- **404** Pump unknown
- **416** UpdateTTL is too large or too low (valid range 30 - 300)

##### `TRANSACTION`

Type: **Notification**

Direction: **Client → Server**

Information about a specific transaction of a pump, open or deferred. Should be sent as reaction to a previous TRANSACTIONS message and may be sent pro-actively if the status of a transaction changes.

Arguments:

- **Pump** (arg0, number): identifier of the concerned pump. Lowest possible value: 1.
- **SiteTransactionID** (arg1, string): ID of this transaction (defined by the client, site) in case of the Post Pay Process. In case of the Pre Pay Process the SiteTransactionID is the **FSCTransactionID** (provided on `UNLOCKPUMP`).
- **Status** (arg2, string): the current status of the transaction. Must be either **open** or **deferred**. A transaction is **open** if the payment has not yet been settled and the pump is **ready-to-pay** or **locked**. A transaction is **deferred** if it was previously **open** but the pump was released again by the site operator (set to **free**). This could be the case if a customer was not able to pay his fueling and the site operator needs to take further actions. To not block the pump for other customers, the site operator releases it again and the transaction previously **open** for said pump will be marked as **deferred.**
- **ProductID** (arg3, string): identifier for the used product.
- **Currency** (arg4, string): currency used by the subsequent **PriceWithVAT, PriceWithoutVAT** and **VATAmount** argument. Supported values, see [Supported Currencies](#416-supported-currencies), for example **EUR**.
- **PriceWithVAT** (arg5, decimal): price including VAT, associated with the current transaction in the specified **Currency** (arg4). (e.g for EUR: 86.83)
- **PriceWithoutVAT** (arg6, decimal): price excluding VAT, associated with the current transaction in the specified **Currency** (arg4). (e.g. for EUR: 72.97)
- **VATRate** (arg7, decimal): rate of VAT used in the previous **PriceWithVAT** argument in percent. (e.g.: 19.0)
- **VATAmount** (arg8, decimal): amount of VAT used in the previous **PriceWithVAT** argument in the specified **Currency** (arg4). \*\*\*\*(e.g. for EUR: 13.65)
- **Unit** (arg9, string): unit used by the subsequent **Volume** argument. Supported values: **LTR**
- **Volume** (arg10, decimal): amount of product used in the specified **Unit** (arg9). (e.g. for LTR: 54.40)
- **PricePerUnit** (arg11, decimal): end user price per unit including VAT in the specified **Unit** (arg9) and the specified **Currency** (arg4). (e.g. for EUR/LTR: 1.339)

##### `TRANSACTIONS`

Type: **Request/Response**

Direction: **Server → Client**

Get all open or deferred transactions of the site or a specified pump (optional). The client needs to make sure that all transactions have been transmitted with TRANSACTION notifications before he can send an OK to conclude the TRANSACTIONS request. In case of an error the client returns an ERR message. The transactions may be requested after the successful connection of a client with session mode active in order to clear open transactions.

Arguments:

- **Pump** (arg0, number, optional): identifier of wanted pump. Lowest possible value: 1.
- **UpdateTTL** (arg1, number, optional): time to live in seconds for expected update signals from the client. After the OK response the client informs the server about transaction changes of the specified pump till the TTL is reached. Explicitly only changes should be sent in this case. Only allowed if **Pump** (arg0) was also specified.

Errors:

- **404** Pump unknown
- **416** UpdateTTL is too large or too low (valid range 30 - 300)

##### `UNLOCKPUMP`

Type: **Request/Response**

Direction: **Server → Client**

Unlock a locked pump with prepaid credit for a subsequent fueling process. If the operation was successful, OK will be returned. In case of an error, the client returns an ERR message. Optional a list of products can be provided to only unlock the specified product nozzles. These optional **ProductID** arguments are inspired by the **IFSF FDC_AuthoriseFuelPoint_Request** specification (`maxOccurs="8"`). If no **ProductID**s are provided, all products should be unlocked.

Arguments:

- **Pump** (arg0, number): identifier of the concerned pump. Lowest possible value: 1.
- **Currency** (arg1, string): currency used by the subsequent **Credit** argument. Supported values, see [Supported Currencies](#416-supported-currencies), for example **EUR**.
- **Credit** (arg2, decimal): credit available for the upcoming fueling process in the specified **Currency** (arg1). (e.g. for EUR: 100.00)
- **FSCTransactionID** (arg3, uuid): ID given by the server for informational reasons (defined by the server). Will be returned with the corresponding `TRANSACTION` notification, to correlate the transactions.
- **PaymentMethod** (arg3, string): Name of the payment method used e.g. `pace`, `dkv`, ...
- **ProductID1** (arg5, string, optional): identifier of an unlocked product. (e.g.: 0100)
- **ProductID2** (arg6, string, optional): identifier of an unlocked product. (e.g.: 0200)
- **ProductID3** (arg7, string, optional): identifier of an unlocked product. (e.g.: 0300)
- **ProductID4** (arg8, string, optional): identifier of an unlocked product. (e.g.: 0400)
- **ProductID5** (arg9, string, optional): identifier of an unlocked product. (e.g.: 0500)
- **ProductID6** (arg10, string, optional): identifier of an unlocked product. (e.g.: 0600)
- **ProductID7** (arg11, string, optional): identifier of an unlocked product. (e.g.: 0700)
- **ProductID8** (arg12, string, optional): identifier of an unlocked product. (e.g.: 0800)

Errors:

- **403** Payment method not permitted
- **404** Pump or ProductID unknown
- **422** Currency unknown

##### `LOCKEDPUMP`

Type: **Request/Response**

Direction: **Client → Server**

Informs the server that the pump had an issue for which the transaction could not complete. This will cancel a previously with `UNLOCKPUMP` issued fueling process from the client-side. If the operation was successful, OK will be returned. In case of an error, the client returns an ERR message.

Arguments:

- **Pump** (arg0, number): identifier of wanted pump. Lowest possible value: 1.
- **FSCTransactionID** (arg1, uuid): ID given by the server for informational reasons (defined by the server)
- **Reason** (arg2, string): The reason why the pump was locked
  - `aborted` zero fueling / transaction
  - `timeout` the system aborted the fueling due to timeout

Errors:

- **404** Invalid transaction and/or pump combination
- **403** Transaction is in invalid state and can't be canceled
- **400** Invalid reason

#### General (Always Valid/Special Methods)

##### `BEAT`

Direction: **Client → Server**

Informational response for a HEARTBEAT request. This method is purely informational to the server and does not conclude the HEARTBEAT request.

Arguments: **Timestamp** (arg0, string): time at which this message was sent in the format of `RFC-3339`.

##### `ERR` (Special)

Direction: **Server → Client, Client → Server**

Concludes a Request/Response message erroneous and terminates the corresponding tag.

Arguments:

- **Code** (arg0, number): one of the following error codes
  - **400** Bad request (invalid method, args or tag)
  - **403** Method is issued in wrong connection state (Handshake method in "Not Authenticated State" and vice versa)
  - **405** Method unknown
  - **406** Wrong encoding (bytes don't comply with the current encoding)
  - **500** Internal server error
- **Message** (argV): human readable error message

##### `OK` (Special)

Direction: **Server → Client, Client → Server**

Concludes a Request/Response message successfully and terminates the corresponding tag.

Arguments: **None**

##### `QUIT`

Type: **Notification**

Direction: **Server → Client, Client → Server**

Signals the upcoming disconnect of the sending party. This method is used to send information before terminating the connection, however the client must not send a QUIT before disconnecting, he can also just close the connection. After receiving a QUIT method, the server will drop the corresponding connection. If the protocol extension "<IP_ADDRESS> Connection Multiplexing" is used, the client can use the QUIT notification to close a session. If the initial session of a multiplexed connection (no `sessionID`) is closed with QUIT, all sessions depending on it will be dropped without further notice.

Arguments:

- **Message** (argV): Reason for the connection termination.

### 4.1.3 Example Plaintext Session

Hereafter one can find the mobile payment process for post payment as an example session.

```gherkin
C: * CAPABILITY CLEAR HEARTBEAT LOCKPUMP PRICES PUMPS PUMPSTATUS QUIT TRANSACTIONS UNLOCKPUMP
S: * CAPABILITY BEAT CHARSET PLAINAUTH PRICE PUMP TRANSACTION LOCKEDPUMP QUIT
C: C0 CHARSET ISO-8859-1
S: C0 OK
C: C1 PLAINAUTH 9eb56d5e-6563-430a-9d39-5ddf567e73d5 1d3b755d3bce8f09b4f8ff08dabf1796
S: C1 OK
S: S0 PRICES
C: * PRICE 0100 LTR EUR 1.339 Super Plus
C: * PRICE 0200 LTR EUR 1.229 Super 95
C: * PRICE 0300 LTR EUR 1.499 Super 95 e5
C: S0 OK
S: S1 PUMPS
C: * PUMP 1 in-use
C: * PUMP 2 out-of-order
C: * PUMP 3 free
C: * PUMP 4 ready-to-pay
C: S1 OK
S: S2 PUMPSTATUS 3
C: * PUMP 3 free
C: S2 OK
S: S3 PUMPSTATUS 3 30
C: * PUMP 3 free
C: S3 OK
C: * PUMP 3 in-use
C: * PUMP 3 ready-to-pay
S: S4 TRANSACTIONS
C: * TRANSACTION 3 c71b9838ad3dfc15 open 0100 EUR 86.83 72.978 19.0 13.65 LTR 54.40
C: S4 OK
S: S5 CLEAR 3 c71b9838ad3dfc15 e2f74ef5-f427-4ae6-bdd3-70a96709992f pace
C: S5 OK
S: S6 HEARTBEAT 2019-11-13T07:00:04Z
C: S6 BEAT 2019-11-13T08:00:05+01:00
C: S6 OK
C: * QUIT bye bye
```

### 4.1.4 EBNF

```bash
letter = "a"…"z" | "A"…"Z" .
digit = "0"…"9" .
digits = digit { digit } .
hex = "a"…"f" | digit .
char = "\x21"…"\x7E" .
any = "\x00"…"\xFF" - "\r" - "\n" .
space = "\x20" .
hexq = hex hex hex hex .
uuid = hexq hexq "-" hexq "-" hexq "-" hexq "-" hexq hexq hexq .

number = "0" | ( ( "1"…"9" ) digits ) .
decimal = number "." digits .
string = char { char } .

ident = letter { letter | digit } .

tag = "*" | ident .
argv = any { any } .
currency = "EUR" .
unit = "LTR" .

pump_status = "free" |
	"in-use" |
	"ready-to-pay" |
	"locked" |
	"out-of-order" .

transaction_status = "open" |
	"deferred" .

method = "BEAT" |
   "CHARSET" |
   "CLEAR" |
   "HEARTBEAT" |
   "LOCKPUMP" |
   "LOCKEDPUMP" |
   "PLAINAUTH" |
   "PRICE" |
   "PRICES" |
   "PUMP" |
   "PUMPS" |
   "PUMPSTATUS" |
   "TRANSACTION" |
   "TRANSACTIONS" |
   "QUIT" |
   "UNLOCKPUMP" .

encoding = "WINDOWS-1252" |
	"ISO-8859-1" |
	"UTF-8" .

capabilty_method = "CAPABILITY"
	{ space methods } .

charset_method = "CHARSET"
	space encoding .

plainauth_method = "PLAINAUTH"
	space uuid
	space string .

clear_method = "CLEAR"
	space number
	space string
	space uuid
	space string .

heartbeat_method = "HEARTBEAT"
	space string .

lockpump_method = "LOCKPUMP"
	space number
	space string .

price_method = "PRICE"
	space string
	space unit
	space currency
	space decimal
	space argv .

prices_method = "PRICES" .

pump_method = "PUMP"
	space number
	space pump_status .

pumps_method = "PUMPS" .

pumpstatus_method = "PUMPSTATUS"
	space number
	[ space number ] .

transaction_method = "TRANSACTION"
	space number
	space string
	space transaction_status
	space string
	space currency
	space decimal
	space decimal
	space decimal
	space decimal
	space unit
	space decimal
	space decimal .

transactions_method = "TRANSACTIONS"
	[ space number ] .

unlockpump_method = "UNLOCKPUMP"
	space number
	space currency
	space decimal
	space uuid
	space string
	[ space string ]
	[ space string ]
	[ space string ]
	[ space string ]
	[ space string ]
	[ space string ]
	[ space string ]
	[ space string ] .

lockedpump_method = "LOCKEDPUMP"
	space number
	space uuid
	space string .

beat_method = "BEAT"
	space string .

err_method = "ERR"
	space number
	space argv .

ok_method = "OK" .

quit_method = "QUIT"
	space argv .

any_method = beat_method |
	capabilty_method |
	charset_method |
	clear_method |
	err_method |
	heartbeat_method |
	lockpump_method |
	lockedpump_method |
	ok_method |
	plainauth_method |
	price_method |
	prices_method |
	pump_method |
	pumps_method |
	pumpstatus_method |
	quit_method |
	transaction_method |
	transactions_method |
	unlockpump_method .

message = tag space ( any_method ) "\r\n" .
```

### 4.1.5 Protocol Extensions

This section introduces multiple extensions that can be used. All extensions are optional and the communicating parties agree about used extensions with the `CAPABILITY` command.

- [Connection Multiplexing](ext/connection-multiplexing.md)
- [Product Mapping](ext/product-mapping.md)
- [High Availability](ext/ha.md)
- [PAN](ext/pan.md)
- [TRANSACTIONINFO](ext/transaction-info.md)
- [Receipt Information](ext/receipt-information.md)
- [Pushing Data](ext/pushing.md)

### 4.1.6 Supported Currencies
All currencies of ISO 4217 are supported, see https://en.wikipedia.org/wiki/ISO_4217.

repository: JoLePheno/openfsc-spec

repo_name: JoLePheno/openfsc-spec


text:
# Frettir
> A customizeable Wordpress Feed Reader writting as a Beginner project with Microsoft Xamarin

## Status
|Platform | Status|
|---|---|
|iOS| [![Build Status](https://tscholze.visualstudio.com/Frettir/_apis/build/status/Frettir-Xamarin.iOS-CI)](https://tscholze.visualstudio.com/Frettir/_build/latest?definitionId=4)|
|Android|[![Build Status](https://tscholze.visualstudio.com/Frettir/_apis/build/status/Frettir-Xamarin.Android-CI)](https://tscholze.visualstudio.com/Frettir/_build/latest?definitionId=5)|

The solution is work in progress and not meant to be used from other persons than me. If you are looking for a perfect example to du something. Nope, that's not here.

## Idea behind
It is never to late to learn something new.
Thats why I want to learn Xamarin, XAML and C#. As a trick to stay focused during the learning nights, I like to create example projects that could be used as a 'trainings area'. I test primarily on iOS.

## Prerequirements
- Visual Studio 2017 *or*
- Visual Studio for Mac

## Used packages
- Xamarin.Forms ([Github](https://github.com/xamarin/Xamarin.Forms))
- Xamarin.Essentials ([Github](https://github.com/xamarin/Essentials))
- XF.Material ([Github](https://github.com/contrix09/XF-Material-Library))
- Newtonsoft.Json ([Github](https://github.com/JamesNK/Newtonsoft.Json))

(Sub packages are not listed.)

## How it looks

![List](docs/list.png "List")

![Settings](docs/settings.png "Settings")

## Contributing

This is a time-by-time sparetime project for myself. That means, no contribution is necessary.

## Authors

Just me, [Tobi]([https://tscholze.github.io).

## License

This project is licensed under the MIT License - see the [LICENSE](LICENSE.md) file for details.
Dependencies or assets maybe licensed differently.

license: MIT

repository: tscholze/xamarin-frettir-app

branch_name: refs/heads/master

extension: md

gha_language: C#

gha_license_id: MIT

license_type: permissive

repo_name: tscholze/xamarin-frettir-app


text:
# Component Design

For information on how to develop components, see the [component development docs][component-development].

We use a number of patterns and conventions throughout our components.

## Size enums

We use abbreviations to refer to sizes, e.g. `xxl`, `xl`, `l`, `m`, `s`, `xs`, and `xxs`.

## Enums and maps

We define objects which map enums to corresponding values, typically CSS classes. For example,
here's how we would define maps for colors and sizes in a fictional `MegaMenu` component.

```jsx
// We first define the map for getting the appropriate class for each enum value.
const colorToClassNameMap = {
  primary: 'euiMegaMenu--primary',
  secondary: 'euiMegaMenu--secondary',
  warning: 'euiMegaMenu--warning',
  danger: 'euiMegaMenu--danger',
};

// Then we generate the enums themselves by pulling out the keys.
export const COLORS = Object.keys(colorToClassNameMap);

// We can repeat this pattern for other things, e.g. sizes.
const sizeToClassNameMap = {
  s: 'euiMegaMenu--small',
  l: 'euiMegaMenu--large',
};

export const SIZES = Object.keys(sizeToClassNameMap);
```

We use the maps to generate the classname for the component:

```jsx
export const MegaMenu = ({
  children,
  className,
  color,
  size,
  className,
  isDisabled,
  ...rest
}) => {
  const classes = classNames(
    'euiMegaMenu',
    colorToClassNameMap[color],
    sizeToClassNameMap[size],
    className,
    {
      'euiMegaMenu--isDisabled': isDisabled,
    },
  );

  /* ... */
```

This is how we define the prop types using the enums we generated:

```jsx
// We can refer to the enums objects for the prop types.
EuiMegaMenu.propTypes = {
  color: PropTypes.oneOf(COLORS),
  size: PropTypes.oneOf(SIZES),
  /* ... */
};

// For the default props we can just specify the enum values we want to use.
EuiMegaMenu.defaultProps = {
  color: 'primary',
  size: 'l',
  /* ... */
};
```

## Pass-through props

To give the consumer as much flexibility as possible we use the destructuring assignment to pull
expected props out of the received props and pass `...rest` to one of the elements in the
`render()` method. This element is typically the root element, though in rare cases another element
makes more sense.

The main benefit behind this practice is that the consumer can specify any of
the [DOM attributes](https://reactjs.org/docs/dom-elements.html) supported by React, including
custom ones with the `data-` prefix.

```jsx
export const EuiMegaMenu = ({
  children,
  className,
  color,
  size,
  className,
  isDisabled,
  ...rest
}) => {

  // Anything else specified by the consumer will be applied to the div as a DOM attribute.
  return (
    <div
      {...rest}
    >
    </div>
  );

  /* ... */
```

## Naming props

### Booleans

Generally, boolean props should have an `is` prefix, e.g. `isPlaceholder` or `isReadOnly`. The exception to this is when the prop matches an existing HTML attribute such as `disabled`; to avoid confusion prop name should align with the HTML specification. This type of mirroring the attributes makes the most sense when the component is a thin wrapper around an existing HTML element, e.g. EuiButton -> button and EuiRadio -> <input type="radio">.

### Event handlers

All event handlers should take the form `onEvent` and accurately describe when it will be called. e.g. `onClick` indicates the handler is called when the component is clicked, but if there is more granularity the handler should reflect that with `onItemClick`, `onRowClick`, etc.

## Common and required props

Try to leverage the `children` prop wherever possible. This will create a simpler more uniform
API throughout our components.

We also [require some props](../src/test/reqiured_props.js) to be supported by all components, as
reflected in our tests; for example, `className`.

```jsx
EuiMegaMenu.propTypes = {
  children: PropTypes.node,
  className: PropTypes.string,
}
```

[component-development]: component-development.md

repository: landtastic/standoffish

gha_language: JavaScript

repo_name: landtastic/standoffish


text:
# Metadata Improvement Lab at ESIP 4: Determining FAIR

A repository designed to facilitate exploration of what makes metadata collections FAIR from around ESIP's interdisciplinary community.

## Welcome

This repository is reproducible through **Jupyter Notebook**: documents that can contain cells of executable code, equations, visualizations, and narrative text. It's like having a single document that handles word processing (such as  Word), math functions (such as Excel), image generation and display, and an interface for coding.

The name **Jupyter** refers to the three coding languages, **Julia, Python, and R**, that are pillars of the modern scientific world.

For this workshop, we are using Google Colaboratory which is a Jupyter notebook environment that requires no setup to use.

####  Overview of workshop session
In the fourth installment of the Metadata Improvement Lab, participants will utilize Python, XSL, and Jupyter Notebooks to determine if metadata collections contain the concepts needed to be FAIR. Participants will be able to utilize their own metadata, regardless of standard or choose from many sample collections from ESIP member organizations. Participants can load as many metadata collections as they would like to compare.

No coding experience will be needed, though a basic understanding of XML will be helpful. A step by step set up for using Google Colaboratory, a Jupyter based web accessible computational environment, will be given. Participants will only need a Google account and a connected web browser to access and run the repository which will allow them to create a shape visualization that describes the fitness of their metadata’s FAIRness. No changes will be made to the device or account used. Participants may also import the workshop repository into their own Jupyter environment.

Since there are many ideas of what it means to be FAIR, this workshop will allow participants to work together or on their own to create a recommendation using Google Docs to facilitate collaboration. During the workshop we will discuss a draft of what FAIR means for EML producing membernodes that was compiled during a workshop this March at DataONE. The Documentation Cluster has built many wiki pages containing recommendations and the XPaths needed in many popular metadata standards, which will aid in the creation of a FAIR recommendation that works for the many standards used throughout ESIP’s member organizations.

The recommendation will then be applied to the collections that participants have chosen to analyze. The workshop framework is highly portable and reusable, even including the generation of the raw data needed to evaluate the content of the metadata, though only the structure of documents will be utilized in this workshop. A report on the outcomes of the analysis will be created as a sharable Google Sheet. The report generated allows for comparison of collections, so that improvement can be measured, documented and visualized.

* [Slides](https://static.sched.com/hosted_files/2019esipsummermeeting/ed/scgordonMetadataFitness.pptx)

Your Python environment requires the following:

* [python](https://python.org) >=3.6
* [pandas](https://pandas.pydata.org/)>=0.23.4
* [requests](https://pypi.org/project/requests/)>=2.19.1
* [xlsxwriter](https://pypi.org/project/XlsxWriter/)>=1.1.0
* [pydrive](https://pypi.org/project/PyDrive/)>=1.3.1
* [lxml](https://pypi.org/project/lxml/) >=4.2.5
* [IPython.core.display](https://ipython.readthedocs.io/en/stable/)>=6.5.0
* [plotly](https://pypi.org/project/plotly/) >=3.8

This workshop has been tested in [JupyterLab](https://jupyter.org) >= 4.4.0 and Google Colaboratory.

## Workshop

Time to dive in!

Click this link to get started: [determineFAIRness.ipynb](https://colab.research.google.com/github/scgordon/MILE4FAIRness/blob/master/notebooks/determineFAIRness.ipynb)

### Notebooks

##### [Determine FAIRness Notebook](./notebook/determineFAIRness.ipynb)
* Create environment
* Upload metadata
* Add recommendation
* Evaluate, analyze, and report on FAIRness

##### [Compile Collection](./notebook/compileCollections.ipynb)
* Create a directory for metadata in the repository
* Different ways to get metadata
* How to upload it to your server in the right directory

## Creating a Recommendation Resources
[Google Doc for Collaborating](https://docs.google.com/document/d/1pD76sp16zKm4noSMT1ZGGPw1n3zaJrIaEW-h1Fe_MSg/edit?usp=sharing)
http://wiki.esipfed.org/index.php/Data_Discovery_(FGDC)

https://github.com/NCEAS/metadig-checks/blob/master/docs/DataONE-FAIR-Quality-Suite.csv
##### Additional resources for further exploration
* [Google Colaboratory FAQs](https://research.google.com/colaboratory/faq.html)
* [About Jupyter](https://jupyter.org/)
* [Google Colaboratory](https://colab.research.google.com/notebook#create=true&language=python3)
###### tutorials for self exploration
* [Colaboratory Getting Started](https://colab.research.google.com/notebooks/welcome.ipynb)
* [Colaboratory Tutorial](https://medium.com/@rohansingh_46766/getting-started-with-google-colaboratory-57b4863d4d7d)


text:
---
title: Configuring git
permalink: /computing/GitConfig
layout: single
sidebar:
  nav: "computing"
---

In order to use git, you will need to provide some basic information:

Also, in my opinion, the default merge behaviour is not optimal, so I recommend disabling fast-forward merge:

	git config --global --add merge.ff false

More about why this twak might be beneficial is explained here: https://mijingo.com/blog/preventing-non-fast-forward-git-merges

## Git workflow

Regarding the workflow to use for git projects, an idea is:

https://nvie.com/posts/a-successful-git-branching-model/


text:
# AndroMedia
AndroMedia - [ODROID-C1+](http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143703355573) DIY media/game console

1. Download [Android](http://odroid.com/dokuwiki/doku.php?id=en:c1_release_android).
2. Write the image on sd card with [win32diskimager](http://sourceforge.net/projects/win32diskimager/), in my case im using SanDisk class 10 8GB.
3. Install [GApps](http://codewalkerster.blogspot.kr/2013/11/universal-1-click-gapps-installer-for.html), services such as play store.
4. Install KODI meadia center from play store.
5. Install [KODI SuperRepo](https://superrepo.org/get-started/) repository.
6. Install Netflix from play store.
7. Download and install [torrent stream controller](http://www.vidsoftware.ru/index.html).
8. Install Snes9x EX+ emulator from play store.
9. Install NES.emu emulator from play store.
10. Install NEO.emu emulator from play store.
11. The [SNES](http://emu-fr.net/v1/module.php?page=programme_roms&console=Super_Nes), [NES](http://emu-fr.net/v1/module.php?page=programme_roms&console=Nes&tri=nom) and [NEO GEO](http://emu-fr.net/v1/module.php?page=programme_roms&console=Neo_Geo&tri=nom&l=M) rom repositories.

What else you can do:

1. Attach an USB drive, install foldersync and ttorrent apks. Now you can put on your dropbox from anywhere a torrent file and foldersync will automaticaly synchronize it with your AndroMedia console where ttorrent will pick up the torrent file and download the content. So when you arrive home to relax the media that you want is already donwloaded on the USB drive.

2. Install YATSE, KODI remote controller to your mobile device.

3. Install DroidMote server on AndroMedia and DroidMote client on your mobile device and controll your AndroMedia.

4. Install sshsftDaemon and connect with an ssh client to your AndroMedia console or transfer data via sftp.

5. Install APK games such as Machinarium, Botanicula, The Cave, Limbo.

6. Install Sixaxis and controll AndroMedia with psp controller.

7. Install Moonlight Game Streaming and stream your games to AndroMedia.

8. No limitation just use your imagination :).

Tweets:

1. Moved from sdcard to emmc, performance increased on x2.5 times

license: Unlicense

repository: PetruGarstea/AndroMedia

repo_name: PetruGarstea/AndroMedia


text:
# Ada Pets Node

<!-- Note: this was based on Ada Pets React no the other way around. -->

## At a Glance

- Individual, [stage 1](https://github.com/Ada-Developers-Academy/pedagogy/blob/master/rule-of-three.md#stage-1) project.
- Due before class, **Friday, April 10**
- Submit this project with a PR

## Learning Goals

* Reading and understanding existing JavaScript code
* Using axios to read data from an API in JavaScript
* Parsing through an API response in JavaScript and extracting desired information
* Using axios to write data to an API in JavaScript

## Introduction

Ada Lovelace is starting a pet rescue service advertising pets in need of rescue via an API and is building a CLI app.   This app should load the list of pets automatically and present a menu with options.   The user should be able to list all pets, select a pet and see details, add new pets and remove a pet from the App once adopted.

She's managed to figure out the CLI parts on her own but needs your help with the API requests.

### Setup

1. Fork and clone this repository
2. Run `npm install` to install dependencies
3. Run the app with `node src/main.js`

### Layout

You will be adding your code to `src/adaPets.js`.  All of the functions you need to implement are currently there, just with empty bodies.

There are two other files that we've provided that you won't need to change `src/main.js` and `src/result.js`.  They are worth taking a quick look at but don't worry too much if you don't understand them fully.
* `src/main.js` is the actual driver code for the CLI app.  If you want to manually test your code you can use this.
* `src/result.js` is the library we've written to handle results and errors for this app.  It provides three functions, two of which you will use and one of which you're going to see in the tests.  **Every helper function should make sure to call `setResult` or `setError` before each `return`.**  What we pass into setResult and setError will be detailed per wave.
  * `setResult` call this function to set the result of your function.  We use this because Axios is asynchronous.
  * `setError` call this function to indicate an error in your function.  Again, we use this because Axios is asynchronous.
  *  If it takes too long for your code to produce a result (like say because you haven't written it yet) it will time out.

**Note: Because Axios is asynchronous we will need to use `setResult` instead of returning results and `setError` instead of throwing errors.**

## Testing Requirements

There are tests for each of the waves in the `test/` directory, there is one file per wave.  For example you can run the Wave 1 tests with `jest test/wave1.test.js`.

Use the tests to help you verify each wave's completion. We expect by project submission that all tests will pass.

## Wave 0: Familiarize Yourself with the Pets API

We will be using a simulated API for this exercise called [json-server](https://github.com/typicode/json-server).  This node package will take a JSON file and use it to generate a RESTful API.

You can look at the `package.json` file and see this section

```json
"scripts": {
    "test": "jest",
    "server": "json-server --watch pets.json"
  },
```

This means you can start the API server by typing `$ npm run server`.  This will start the API on port 3000.

You can preview it by going to [http://localhost:3000/pets](http://localhost:3000/pets).

In Postman, try to make a few API calls to verify how it works including:

- Listing all the pets
- Listing a single pet by ID
- Adding a pet
- Updating a Pet

Notice how the `pets.json` file changes.

Answer the following questions to guide through familiarizing yourself with the API:

Remember, all requests that we make have a verb and a path.

1. What is the verb and path of the request to get a list of pets from this API?
1. The response of this request should be a list of pets. What kind of data structure is the list of pets? What is the status code of this request? Test it with Postman.
1. What is the verb and path of the request to get the details of a single pet from this API?
1. What are the query parameters of this request?
1. Test with Postman:
    - What kind of data structure is the details of a single, valid pet? What is the status code of this request?
    - What do we get back if we give an invalid pet id? What is the status code of this request?
1. What is the verb and path of the request to create a new pet using this API?
1. What are the parameters we can pass into this request? Which parameters are required? Which are optional?
1. When a pet is successfully created, we get back a response. What is the data structure of this response? What is the status code?
1. After we create a pet, we can verify that the pet was created from the response. We can also verify that the pet was created and added to the list of pets another way. What else can we do?

### Important Provided Functions

#### `setResult`

This function is used to indicate that your function has actually produced a meaningful result.  (This is necessary because of the asynchronous nature of JavaScript input/output.)

If you return a value instead of calling `setResult` (or `setError`) then your tests will time out (fail because you took too long to produce a result).

#### `setError`

This function is used to indicate that your function has produced an error.  (Again, this is necessary because of the asynchronous nature of JavaScript input/output.)

You should use this function instead of `throw`ing an error from your functions.

**A note on tests**: Many of the tests that expect you to set an error will validate not only that your code produced an error but also that it had an error message that included **_specific_** words using regular expressions.

## Wave 1: List Pets

Before we start doing things like looking at individual pets we want to be able to get a list of all of the pets.

To do this fill out the `listPets` function.  This will need to make a call to the Pets API and should `setResult` a list of objects containing (at least) the pet's `id` and `name` and should call `setError` with an error message if the request fails.

You can run the Wave 1 tests with `jest test/wave1.test.js`.  Once these are passing move on to Wave 2.

These tests use a mocking library to do what we used VCR to do in Ruby.  In each test you'll see a `mock.onGet` or `mock.onPost` to set up what should happen for that particular test before the actual assertions.

### Function to complete

* `listPets`
  * `setResult` should be passed the array of pets.
  * `setError` should be passed an error message.  (You may need to write this message.)

## Wave 2: Details

We now want to be able to look at individual pets.  Like in Slack CLI we're going to want to select a given pet before we ask for details on one.  To do this we're going to fill out a few functions that we're creating within a closure.  There is a provided function `selectPet` that will prompt you for a pet's `id` and save it.

To do this you will need to fill out the `petDetails` function.  This will need to make a call to the Pets API and should `setResult` and object with details for the pet and should call `setError` with an error message if the request fails.

You can run the Wave 2 tests with `jest test/wave2.test.js`.  Once these are passing move on to Wave 3.

### Function to complete

* `showDetails`
  * `setResult` should be passed the `Object` that represents the pet.
  * `setError` should be passed an error message.  (You may need to write this message.)

## Wave 3: Remove Pet

Once a pet is adopted we don't still want to show it on the list.  (We don't want people fighting over the same pet after all :wink:.)

To do this fill out the `removePet` function.  This will need to call to the Pets API to remove the pet.  This should `setResult` with a success message if this works and should call `setError` with an error message if the request fails.

You can run the Wave 3 tests with `jest test/wave3.test.js`.  Once these are passing move on to Wave 4.

### Function to complete

* `removePet`
  * `setResult` should be passed a success message.  (You may need to write this message.)
  * `setError` should be passed an error message.  (You may need to write this message.)

## Wave 4: Add a Pet

Sometimes we'll have new pets that want to be adopted.

To do this fill out the `addPet` function.  This will need to call the Pets API to add the pet.  This should `setResult` with a success message if this works and should call `setError` with an error message if the request fails.

You can run the Wave 4 tests with `jest test/wave4.test.js`.  Once these are passing you're done!  :tada:

### Function to complete

* `addPet`
  * `setResult` should be passed the new pet (from the API).
  * `setError` should be passed an error message.  (You may need to write this message.)


text:
# Slot: estimated_size

The estimated size of the genome prior to sequencing. Of particular importance in the sequencing of (eukaryotic) genome which could remain in draft form for a long or unspecified period.

URI: [mixs.vocab:estimated_size](https://w3id.org/mixs/vocab/estimated_size)

## Domain and Range

None ->  OPT [String](types/String.md)

## Parents

 *  is_a: [nucleic acid sequence source field](nucleic_acid_sequence_source_field.md)

## Children

 *  [MIGS bacteria➞estimated_size](MIGS_bacteria_estimated_size.md)
 *  [MIGS eukaryote➞estimated_size](MIGS_eukaryote_estimated_size.md)
 *  [MIGS org➞estimated_size](MIGS_org_estimated_size.md)
 *  [MIGS plant➞estimated_size](MIGS_plant_estimated_size.md)
 *  [MIGS virus➞estimated_size](MIGS_virus_estimated_size.md)
 *  [MIUVIG➞estimated_size](MIUVIG_estimated_size.md)

## Used by

 * [Core](Core.md)

## Other properties

|  |  |  |
| --- | --- | --- |
| **Aliases:** | | estimated size |
| **Comments:** | | Expected value: number of base pairs |
|  | | Position: 18.0 |
| **Examples:** | | Example(value='300000 bp', description=None) |

branch_name: refs/heads/main


text:
## Instructions

Your task is to determine which word in a sentence has the most vowels (a, e, i, o, u). A sentence is defined as a [C# string][docs-string] consisting of one or more words. A word consists of one or more upper- or lowercase letters. Words are separated from each other by a single space character.

Your job is to define a method named `Sentence.WordWithMostVowels`, which takes a sentence, and returns the word with the most vowels.

For example:

```csharp
Sentence.WordWithMostVowels("Hi there aunt jeanie")
// Returns: "jeanie"
```

## Debugging

When a test fails, a message is displayed describing what went wrong and for which input. You can also use the fact that any [console output][programiz.com-basic-input-output] will be shown too. You can write to the console using:

```csharp
Console.WriteLine("Debug message");
```

[docs-string]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/strings/
[programiz.com-basic-input-output]: https://www.programiz.com/csharp-programming/basic-input-output

gha_language: Python


text:
# DROID, JHOVE, NLNZ Metadata Extractor Test Collection
## From Somaya Langley

The one-liner for these files is that I made them (in my own time) back in
2006 to test DROID, Jhove and the NLNZ Metadata Extractor.

The results of these tests were also used to inform the APSR (research and
report) APSR = Australian Partnership for Sustainable Repositories

In this version of the repository files are maintained in ZIP containers
to enable testing datetime capabilities in preservation workflows.

### Format MimeType Breakdown, identified by DROID:

      application/rtf, text/rtf (41)       application/xml, text/xml (13)
      application/zip (13)                 application/vnd.ms-excel (7)
      image/jpeg (6)                       image/tiff (4)
      text/html (4)                        application/pdf (3)
      image/gif (3)                        multipart/appledouble (3)
      application/mp4, video/mp4 (2)       application/octet-stream (2)
      application/vnd.rn-realmedia (2)     audio/x-wav (2)
      video/mpeg (2)                       video/quicktime (2)
      application/msword (1)               application/postscript (1)
      application/x-shockwave-flash (1)    audio/mpeg (1)
      audio/ogg (1)                        image/bmp (1)
      image/png (1)                        image/svg+xml (1)
      image/vnd.adobe.photoshop (1)        image/x-pict (1)
      video/x-ms-wmv (1)                   video/x-msvideo (1)

### Unidentified File Extensions:

      .txt (21)	.asc (1))	.csv (1)

repository: openpreserve/format-corpus

gha_language: Java

repo_name: openpreserve/format-corpus


text:
# UX Research & Design

Welcome to pip’s UX research and design documentation. The purpose of this section of the documentation is to:

- [Identify where new contributors can participate in or lead UX research and design activities](ux-research-design/contribute)
- [Share pip UX research and design guidelines](ux-research-design/guidance), including an introduction to User Centered Design practices, and how they can be applied to the pip project
- Share [results of user research](ux-research-design/research-results) that the pip team has already conducted


text:
charitytree
===========

An intuitive web app for managing a charity tree program.

A charity tree program is typically set up as follows:
1. Clients apply for assistance, specifying what they and their family members would wish to receive.
2. Donors apply to the program, specifying how much they are willing to give.
3. The charity organization gives out anonymous wish item tags to the donor organizations.
4. The donor organizations typically place these tags on a Christmas tree, and individuals choose
tags that will suggest the shopping item to obtain.
5. The donor organization delivers the gifts to the charity organziation.
6. The charity organization gets the gifts to the clients.

I wrote several articles on my [blog](http://randallhook.com/2011/01/03/launching-the-charity-tree-project/) when I first began exploring the idea.

repository: randyhook/charitytree

repo_name: randyhook/charitytree


text:
# ≉ [![Build Status](https://travis-ci.com/paulstansifer/unseemly.svg?branch=master)](https://travis-ci.com/paulstansifer/unseemly) [![Coverage Status](https://coveralls.io/repos/github/paulstansifer/unseemly/badge.svg)](https://coveralls.io/github/paulstansifer/unseemly)

Unseemly typechecks the code that you wrote, not the code your macros wrote.
This makes macros feel like part of the language, not something tacked-on.

For a more complete pitch, see http://unseemly.github.io

Unseemly has a bare minimum of forms
 necessary to bootstrap the implementation of practical languages.

Unseemly is still pretty early-stage, so, while all of the features below exist,
 there are still a number of things that are janky or incomplete.

## Features

### From the ML family
 * Algebraic types (i.e., supports structs and (rich) enums)
 * Typesafe destructuring with `match`.
 * Generic types (or parametric types) (e.g. `List<T>`)
 * Recursive types
### From the Scheme family
 * Syntax quasiquotation
    (`'[Expr | … ]'` quotes an expression,
      but inside that, `,[Expr | … ],` evaluates its contents and interpolates them)
 * Pretty-printing respects macro invocations and quoted syntax
    (the pretty-printer is rather limited at the moment, though)
 * Hygenic macros (all operations respect α-equivalence)
 * Macro By Example (easily implement n-ary forms without writing boilerplate loops).
### Unusual features
 * No type errors in generated code
   (if a macro invocation typechecks, the code it expands to doesn't need typechecking)†.
   * Typechecking under syntax quotation
   (so `'[Expr | (plus one ,[e1],)]'` is a type error if `e1` has the type `Expr<String>`)
 * Extensible parsing and lexing (for embedded languages like SQL and regex).

† Except that there are [known soundness bugs](https://github.com/paulstansifer/unseemly/issues?q=is%3Aissue+is%3Aopen+label%3Asoundness).
### Other features
 * Full-featured REPL, with persistent command history and line editing (courtesy of `rustyline`).

## How to use it

Install Rust, if you haven't already:

    curl https://sh.rustup.rs -sSf | sh

From your Unseemly repository directory, run an example program:

    cargo run --release examples/sum_list.unseemly

(Recommended) Get the default prelude for the Unseemly REPL:

    cp examples/.unseemly_prelude ~/

Start the REPL:

    cargo run --release

## Documentation

Look at core_language_basics.md for documentation of the language.

## Related work

### Research projects
#### [FreshML](https://www.cl.cam.ac.uk/~amp12/freshml/) / [Romeo](https://repository.library.northeastern.edu/files/neu:cj82mb52h)

Unseemly is most closely based on Romeo, which descends from FreshML.
 (Romeo is closer to Pure FreshML, but the "Pure" part is not present in Unseemly.)
Romeo allowed for manipulation of syntax types with complex binding information, but
  * syntax was otherwise untyped
  * there was no macro system (so the syntax manipulation was pointless!)
  * it is just a core calculus

#### [SugarJ](https://github.com/sugar-lang) / [SoundX](https://github.com/florenzen/soundx)

SoundX is a language with syntax extensions in which typechecking occurs before expansion.
It provides sound language extensions, but
  * it doesn't support binding annotations
    (in practice, this means that syntax extension authors wind up writing specifications
     that contain logic-y things like `x ∉ dom(E)`.)
  * the language extensions aren't macros (they're not themselves part of the language)
  * it is just a core calculus

(TODO: are the extensions themselves statically verified to be type-preserving?
 I think so, but I don't remember for sure.)

### Practical languages
#### [Scala](https://www.scala-lang.org/)

If I understand correctly, Scala's blackbox macros are typechecked before expansion,
 but they can't do everything that whitebox macros can.
Unseemly macros are typechecked before expansion, but are the only macro system needed,
 because they can (in particular) define new binding forms safely.
(TODO: learn more about Scala's macro system)

#### [Wyvern](http://wyvernlang.github.io/)

Wyvern's primary motivating example
 (write SQL, not strings containing SQL, in your general-purpose code)
 is a lot like Unseemly's vision of inline syntax extension.
Wyvern is a full-fledged language, not a core language.
I believe that writing new embedded languages is not as easy as macro definition.

Wyvern also includes a number of features that are outside the scope of Unseemly.

(TODO: learn more about Wyvern)

#### [Terra](http://terralang.org/)

Terra, from a quick glance (TODO: learn more),
 appears to be a language with a close relationship to Lua,
  similar to the relationship that Unseemly-based languages would have.

In this case, it looks like the goal is to marry a high-level and low-level language together,
 without an FFI and with inline embedding.

#### [MetaOCaml](http://okmij.org/ftp/ML/MetaOCaml.html)

MetaOCaml is an extension to OCaml that supports type-safe syntax quotation.
Though Unseemly uses "quasiquotation" to describe syntax quotation,
 it is more similar to [MetaOCaml's bracket](http://okmij.org/ftp/meta-programming/implementations.html#meta-scheme)
   than to Scheme's quasiquotation,
  because it respects alpha-equivalence.

Unlike Unseemly, MetaOCaml doesn't use its safe syntax quotation to implement a macro system.

#### [Rust](http://rust-lang.org) and [SweetJS](https://www.sweetjs.org/)

Rust and SweetJS are non-S-expression-based languages with macro systems that allow rich syntax.

Unseemly is implemented in Rust, and it uses *lots* of macros.

repository: paulstansifer/unseemly

gha_language: Rust

repo_name: paulstansifer/unseemly


text:
---
layout: post
title:  "Making Easy Animations With ofxActionManager"
description: "A port of cocos2dx action system"
date: 2016-01-16
category:
  - cpp
  - programming
  - openFrameworks
comments: true
---

I picked up using openFrameworks a while ago. But even before that I've been doing game development with [Cocos2dx][cocos2dx_link]. It's really a great framework and you come to get used to some aspects of it.  :D

Take the `Action` system in Cocos2dx as an example. It's a great system in which you can make easy animations, chain them, and create new ones on condition. It's a great fire-and-forget system for animations. You want your circle to move to a position? Easy: `myCircle->runAction(MoveTo::create(.5f, Vec2(x, y)))`. And you don't have to keep track of it once you run it. It will do its job and self-destroy.

So that's why I also wanted to be able to use such a system in openFrameworks. So I started porting the system to openFrameworks and I named it `ofxActionManager`. You can find the code in my [GitHub account][ofx_action_manager_link].

`Action`s work on `Node`s in Cocos2dx. I'm not an expert on openFrameworks. But I thought since people do a lot of custom drawing and stuff in openFrameworks I thought it'd be better to make the `Action`s depend on a smaller, lightweight class. So instead of `Node`, ofxActionManager uses `ActionTarget` which is a class with rotation, position, scale and color properties. So when you want to use the action system, you can either inherit `ActionTarget` and call your update and draw functions. Or you can just store it as a variable and get the necessary information form that.

Let's talk about what each class is responsible for.

- `Action`: This is the base class for all the actions.
- `FiniteTimeAction`: It inherits `Action` and it is used for actions that have a duration. `0` seconds is also considered a duration.
- `ActionInterval`: An interval action is an action that takes place within a certain period of time. It has an start time, and a finish time.
- `ActionInstant`: Instant actions don't have any duration and they are executed immediately and one time only.
- `ActionEase`: This is the base class for the easing actions that run on other actions.

By using these base classes, you can create any number of actions you want. Cocos2dx has actions to manipulate position, scale, rotation, color, visibility... And many more can be implemented as needed.

Let's see an example in openFrameworks. Let's create a `MyCircle` class that inherits `ActionTarget`.

```cpp
#include "ActionTarget.h"

class MyCircle : public ActionTarget
{
public:
    MyCircle(float radius = 30.f)
        : m_Radius(radius)
    {}

    void draw()
    {
        ofCircle(m_Position, m_Radius);
    }

private:
    float m_Radius;
};

```

`ActionTarget` has a helper function `ActionTarget::runAction(Action *action)`. This function takes the action its given and adds it our action manager setting the target to itself.

```cpp

//Part ofApp.h
#include "MyCircle.h"

private:
    MyCircle m_Circle;

```

```cpp

//Part of ofApp.cpp
#include "ofxActionManager.h"

ofApp::ofApp()
    : m_Circle()
{

}

void ofApp::update()
{
    //ActionManager is a singleton class. Make sure to call update in just one place
    ActionManager::getInstance()->update(ofGetLastFrameTime());
}

void ofApp::draw()
{
    m_Circle.draw();
}

void ofApp::mouseReleased(int x, int y, int button)
{
    //Let's move the circle to the mouse position
    if (button == OF_MOUSE_BUTTON_1) {
        m_Circle.runAction(1.f, MoveTo::create(ofVec2f(x, y)));
    }
    else {
        //We can also use easings on any action
        auto moveAction = MoveTo::create(ofVec2f(x, y));
        m_Circle.runAction(1.f, EaseBackIn::create(moveAction));
    }
}

```

Once you call `runAction`, the circle will move to the position with a smooth and eased animation. Under the hood, `ActionTarget::runAction(Action *action)` calls `ActionManager::getInstance()->addAction(Action *action, this, false)`. So instead of using `runAction` you can also use `ActionManager::addAction`.

The main usage is the same as Cocos2dx so you can read up on actions from [here][cocos2dx_actions_link] and do the same with [ofxActionManager][ofx_action_manager_link].

[ofx_action_manager_link]: https://github.com/Furkanzmc/ofxActionManager
[cocos2dx_actions_link]: http://www.cocos2d-x.org/wiki/Actions
[cocos2dx_link]: http://www.cocos2d-x.org

gha_language: HTML


text:
JUnit test-engine implementation that wraps the standard JUnit vintage-engine and adds support for timeouts per
test-class.

Apply this engine instead of the junit-vintage-engine.

# Examples

## Gradle (Kotlin)

```(kotlin)
dependencies {
    testImplementation("org.junit.platform:junit-platform-launcher:1.6.2")
    testImplementation("org.junit.jupiter:junit-jupiter-api:5.6.2")

    testRuntimeOnly("org.caffinitas.junitvintagetimeout:junitvintagetimeout:0.1.1")
}

tasks.withType<Test>().configureEach {
    systemProperty("junit.jupiter.extensions.autodetection.enabled", "true")
    useJUnitPlatform() {
        includeEngines("timeout-junit-vintage")
    }
}

```

## Maven

TODO (PR welcome)

# Configurables
* The config parameter `junit.vintage.execution.timeout.seconds` (also configurable as a system property) defines the
  timeout in seconds. A timeout of `<=0` means no timeout.

# Note

The (current) implementation invokes the vintage-engine via a separate thread (named `vintage-timeout-*`). If the
test runs too long (timeout), that thread is interrupted. This is a "best effort" approach that does not (and cannot)
guarantee that all resources occupied by a test will be freed upon a timeout. So the probably best approach to run
tests with a timeout setting is to never reuse a test-worker-JVM - in other words: spawn a new JVM for each test class.

repository: snazy/junitvintagetimeout

repo_name: snazy/junitvintagetimeout


text:
This methodology enables the calculation of greenhouse gas emissions
associated with the use of internal lighting. This calculation is based
on the wattage of light bulbs and the duration for which they are used,
together with emissions data associated with grid electricity production
and consumption.

To use this methodology set the wattage of the bulb(s) using the
***wattage*** parameter. Finally, users must choose between two ways of
specifying the duration for which lighting was in use.

## Lighting usage

### Specifying an absolute time

To specify a single, absolute quantity of time, set this duration using
the ***totalTimeInUse*** parameter. The returned value represents
CO2 emissions associated with the specified duration of lighting
use, based on the emissions factors for electricity generation and
consumption in the United Kingdom (this location can be overriden - see
below).

### Specifying regular usage

Users can alternatively specify repeated intervals of lighting usage by
specifying two parameters representing a *rate* of lighting usage and a
period under consideration. For example, users could set the number of
*hours per day* and the total *number of days*. To use this approach,
set the rate of lighting usage using the ***timePerTimePeriod***
parameter and the duration under consideration using the
***timePeriod*** parameter. AMEE converts this specification into a
total quantity of lighting (electricity) consumption and calculates the
associated emissions. By default, the units for the
***timePerTimePeriod*** parameter are set to hours ('h') per day
('day'), while those of the ***timePeriod*** parameter are set to days
('day') with a default value of 365.2425 (based on Gregorian calendar).
This means that, unless these default values are overridden, an *annual*
quantity of emissions based on the number of hours of lighting used per
day will be returned. It is best practice to always specify units and
'per-units', however.

## Specifying multiple bulbs

Users can specify multiple light bulbs, if appropriate, although it
should be noted that each must represent similar wattage and usage. This
may be useful where a single light fitting contains several bulbs, or
perhaps where multiple rooms or internal spaces are lit consistently. To
indicate that multiple light bulbs are to be considered in the emissions
calculation, set the number of light bulbs using the ***number***
parameter. AMEE scales up the emissions calculation accordingly. This
value is set to 1 by default.

## Setting the country

By default, the emissions factor for UK grid electricity generation is
used to convert lighting associated electricity consumption into a
quantity of greenhouse gas emissions. However, users can specify an
alternative country by setting the country name or ISO code in the
***country*** parameter. In this case, AMEE will lookup the appropriate
grid electricity emissions factor from [this
dataset](Electricity_by_country). If calculations are stored using
profiles, the country can be specified within the profile
[metadata](metadata). Users should note, however, that directly
specified ***country*** parameters override any set as profile metadata.

repository: thegreenwebfoundation/datasets

repo_name: thegreenwebfoundation/datasets


text:
## Intro [![Build Status](https://secure.travis-ci.org/dalehenrich/builderCI.png?branch=master)](http://travis-ci.org/dalehenrich/builderCI)

[Serge got things started](https://github.com/SergeStinckwich/PlayerST)
using [Lukas' builder](https://github.com/renggli/builder), with [travis-ci](http://travis-ci.org/), so I'm aiming
to team up [Metacello](https://github.com/dalehenrich/metacello-work) and **builder** to make the
setup and maintenance of CI test scripts for [GLASS](http://code.google.com/p/glassdb/), [Pharo](http://www.pharo-project.org/home)
and [Squeak](http://www.squeak.org/) as painless as possible ...

## Using builderCI

1. Read [Travis CI docs](http://about.travis-ci.org/docs/).
2. [Create a Baseline for your project](https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStartedWithGitHub.md#create-baseline).
2. Create your own .travis.yml file by copying [the template travis.yml][1] into the
   home directory of your git project.
3.  See the [builderCI .travis.yml][5] for the current list of supported platforms. If you
   are using [Metacello][3] with your project you shouldn't have to make any other edits. Metacello
   and FileTree are pre-installed in the image.
3. Create a [tests/travisCI.st][2] that contains the code to load your project, its tests and launch
   the test harness.
4. If you have questions or comments
   [open an issue](https://github.com/dalehenrich/builderCI/issues/new)
   or [join and comment on the Metacello Mailing list](https://groups.google.com/forum/#!forum/metacello).
4. Enjoy.

## Dealing with Failure

Here's [sample output for a build that failed][4] because of unit test failures. [Scroll to
the bottom of the console](https://github.com/dalehenrich/builderCI/issues/44)
and you'll see a test summary that looks like the following:

```
***********************************************
	Results for builderCI Test Suite
3 run, 1 passes, 0 expected failures, 1 failures, 1 errors, 0 unexpected passes
***********************************************
*** FAILURES *******************
	SampleTest debug: #testFailure.
*** ERRORS *******************
	SampleTest debug: #testError.
***********************************************
```

Tests that *fail* or produce *error* are listed. You should be able to
copy the the expressions and evaluate them in a workspace:

```Smalltalk
SampleTest debug: #testError.
```

## Debugging Travis CI scripts

At the beginning of the run, everything written to the **Transcript** is routed to to the *TravisTranscript.txt* file. You can list the contents of the file by including the following line in your `.travis.yml` file:

```yml
   - cat TravisTranscript.txt
```

or conditionally dump the *TravisTranscript.txt* file upon an error or
test failure:

```yml
   - $BUILDER_CI_HOME/buildImageErrorCheck.sh
   - $BUILDER_CI_HOME/buildTravisStatusCheck.sh
```

## Projects using TravisCi and builderCI

* [Metacello](https://github.com/dalehenrich/metacello-work)
* [FileTree](https://github.com/dalehenrich/filetree)
* [Ston](https://github.com/dalehenrich/ston)
* [Control](https://github.com/frankshearar/Control)
* [Sample](https://github.com/dalehenrich/sample)

[1]: https://github.com/dalehenrich/builderCI/blob/master/templates/travis.yml
[2]: https://github.com/dalehenrich/builderCI/blob/master/templates/travisCI.st
[3]: https://github.com/dalehenrich/metacello-work/blob/master/README.md
[4]: http://travis-ci.org/#!/dalehenrich/sample/jobs/1647159
[5]: https://github.com/dalehenrich/builderCI/blob/master/.travis.yml


text:
# uphold-tickers
A web service that constantly request and save exchange prices from Uphold.

## Services
- **UpholdService**: request updated prices from Uphold API every time.

repository: michelmattos/uphold-tickers

repo_name: michelmattos/uphold-tickers


text:
# DotNetArchitecture

Solution to apply and share new knowledge and technologies and to serve as architecture for new projects.

## Tools, Practices and Technologies

* Cross-Platform (Windows, Linux, macOS)
* Visual Studio 2017
* Visual Studio Code
* .NET Core 2.1.1
* ASP.NET Core 2.1.1
* Entity Framework Core 2.1.1
* SQL Server 2017
* MongoDB
* C# 7.3
* SPA (Single Page Application)
* Angular 6.1.0
* Typescript 2.9.2
* HTML5
* CSS3
* SASS (Syntactically Awesome Style Sheets)
* DDD (Domain-Driven Design)
* SOLID Principles
* Dependency Injection
* Unit Test
* JWT (Json Web Token)
* Code Analysis (Ruleset for C# and TSLint for Typescript)

## Build

[![Build Status](https://ci.appveyor.com/api/projects/status/17lg6pt9kf55cr1y?svg=true)](https://ci.appveyor.com/project/rafaelfgx/dotnetarchitecture)

## Code Analysis

[![Codacy](https://api.codacy.com/project/badge/Grade/6eef5f26173c4b80824a2eeb0b4f9ab9)](https://www.codacy.com/app/rafaelfgx/DotNetArchitecture?utm_source=github.com&utm_medium=referral&utm_content=rafaelfgx/DotNetArchitecture&utm_campaign=Badge_Grade)

## Layers

![Screenshot](Screenshots/0.png)

**Web:** This layer contains the user interface, responsible for interaction with the user to obtain and display data.

**Application:** This layer is the main entry point of the application.

**Domain:** This layer contains the requirements and the business logic, is the core of the application.

**Infrastructure:** This layer isolates and abstracts the logic required for data persistence.

**Model:** This layer is responsible for modeling the domain classes according with the business context.

**CrossCutting:** This layer provides generic features for the other layers.

**Tests:** It is responsible for testing individual units of the code, which can be a class, a method, an integration, a business rule, among others.

## Projects

![Screenshot](Screenshots/1.png)

## Application

![Screenshot](Screenshots/2.png)

## Domain

![Screenshot](Screenshots/3.png)

## Repository

![Screenshot](Screenshots/4.png)

## Unit Test

![Screenshot](Screenshots/5.png)

## ASP.NET Core + Angular

![Screenshot](Screenshots/6.png)

## ASP.NET Core Startup

![Screenshot](Screenshots/7.png)

## ASP.NET Core Controller

![Screenshot](Screenshots/8.png)

## Angular Guard

![Screenshot](Screenshots/9.png)

## Angular Error Handler

![Screenshot](Screenshots/10.png)

## Angular HTTP Interceptor

![Screenshot](Screenshots/11.png)

## Angular Service

![Screenshot](Screenshots/12.png)

## Angular Component

![Screenshot](Screenshots/13.png)

## ASP.NET Core + Angular + Entity Framework Core + SQL Server Performance

![Screenshot](Screenshots/14.png)

**Specifications:**

**Processor:** Intel Core I7 8700K Coffee Lake 8th-generation.

**Memory:** 16GB 2400Mhz DDR4.

**Storage:** Samsung Evo 960 SSD M2 250gb.

**OS:** Windows 10 Pro 64 bits.

**Web Server:** IIS 10.

**Database:** SQL Server 2017 Developer Edition.

## Visual Studio Extensions

**CodeMaid**: <https://marketplace.visualstudio.com/items?itemName=SteveCadwallader.CodeMaid>

**Roslynator**: <https://marketplace.visualstudio.com/items?itemName=josefpihrt.Roslynator2017>

**SonarLint**: <https://marketplace.visualstudio.com/items?itemName=SonarSource.SonarLintforVisualStudio2017>

**TSLint**: <https://marketplace.visualstudio.com/items?itemName=vladeck.TSLint>

## Run in Visual Studio Code

1. Install **.NET Core SDK**: <https://aka.ms/dotnet-download>.

2. Install **C#** extension in **Visual Studio Code**: <https://marketplace.visualstudio.com/items?itemName=ms-vscode.csharp>.

3. Open **solution folder** in **Visual Studio Code**.

4. Press **F5** to **run and fun**!

## Deploy to IIS

1. Install **.NET Core Runtime**: <https://aka.ms/dotnet-download>.

2. In the **Solution.Web.UserInterface\AppSettings.json** file change the **Connection String**.

3. In the **Solution.Web.UserInterface\ClientApp\angular.json** file change the **baseHref** to **IIS_APPLICATION_NAME**.

4. Publish **Solution.Web.UserInterface** project in **Visual Studio** or by **dotnet publish** command.

5. Copy the published files to **IIS folder** (inetpub\wwwroot\\**IIS_APPLICATION_NAME**).

6. In the **IIS** create an **Application Pool** with **NET CLR Version** = **No Managed Code**.

7. In the **IIS** execute **Convert to Application** using the created **Application Pool**.

8. **Run and fun!**

repository: abhishekbhalani/DotNetArchitecture

repo_name: abhishekbhalani/DotNetArchitecture


text:
# Get correct extension from url and mimetype
Get extension of file and url path

## Problem statement

we were getting problem while getting image url extension correctly
because of these kind on url `https://regmedia.co.uk/2017/06/26/cloudflarelogo.jpg?width=100`
or like this one `https://regmedia.co.uk/2017/06/26/cloudflarelogo.jpg-xml`
so I solved this problem to get correct url extension
now using this library you can get correct extension

## Installation

`npm install get-url-extension`

## Usage

```javascript

const get_extension = require('get-url-extension')

const extension = get_extension('https://github.com/SalahudinMalik/get-extension.git')

```

## Contributing

Please read [CONTRIBUTING.md](https://gist.github.com/PurpleBooth/b24679402957c63ec426) for details on our code of conduct, and the process for submitting pull requests to us.

## Authors

* **Salahudin Malik** - *Initial work* - [SalahudinMalik](https://github.com/SalahuidnMalik)

See also the list of [contributors](https://github.com/salahudinmalik/project) who participated in this project.

## License

This project is licensed under the MIT License - see the [LICENSE.md](LICENSE.md) file for details

repository: SalahudinMalik/get-extension

repo_name: SalahudinMalik/get-extension


text:
# KQED Player

A lightweight KQED live stream player for macOS

![demo](https://github.com/turbobabr/kqed-player/raw/master/demo.gif)

#### Usage

- Click on the status bar icon to pause/resume streaming
- Right click for quitting the app

repository: turbobabr/kqed-player

repo_name: turbobabr/kqed-player


text:
# Rust library for german umlauts

## Usage

```rust
# Cargo.toml

# Safe without manipulating &mut str
[dependencies]
umlauts = "0.1"

# Unsafe conversions with the ability to manipulate &mut str
umlauts = { version = "0.1", features = [ "unsafe" ] }
```

## Examples

```rust
extern crate umlauts;

use umlauts::UmlautsOwned;

let mut s = "Öl Ärmel Übermut".to_string();
s.make_utf8_umlauts_lowercase();
assert_eq!("öl ärmel übermut", s);
```

## Unsafe Features

### `&mut str` manipulation

By default, this crate itself does not use unsafe features,
except from the [memchr] dependency.
To allow manipulating of references to `String` and `&mut str`,
the `unsafe` feature can be used.
As the manipulating functions operate on `&mut [u8]` and will always
return valid UTF-8 if valid UTF-8 is given,
those unsafe features should perform the same.

[memchr]: https://github.com/BurntSushi/rust-memchr

repository: rappet/umlauts

repo_name: rappet/umlauts


text:
---
name: Bug report
about: Create a report to help us improve
title: ''
labels: bug
assignees: fzlee

---

**Describe the bug**
A clear and concise description of what the bug is.

**Environment**
OS version:
Python version:
Alipay version:

**To reproduce**
Code snippets:
```python
alipay = Alipay(...)
alipay.do_something
```

**Expected behavior **
A clear and concise description of what you expected to happen.

repository: fzlee/alipay

gha_license_id: NOASSERTION

repo_name: fzlee/alipay


text:
# Cavelle-SI-Application
Cavelle's Web application for SI project

- download and unzip (or pull) the repository
- open terminal (cmd) then navigate to repo folder
> cd path\Cavelle-SI-Application
- install node modules
> npm install
- now run the server and navigate to localhost:port in your browser
> node server.js

repository: MickStick/Cavelle-SI-Application

repo_name: MickStick/Cavelle-SI-Application


text:
# Date: 13 December 2020

## Question:
Suppose the following code is given in python. Which of the following is a True?

```python
a = [1,2,3,4]
b = a
b.append(5)
```

## Topic:
1. Programming
2. Python
3. Objects

## Options:
1. `b` and `a` refer to same object
2. `a` is equal to `[1,2,3,4,5]`
3. `b` is equal to `[1,2,3,4,5]`
4. All are True

## Correct Option:
4. All are True

## Explanation:
In python a list can be copied using `=` operator. But if you copy list in this way, there is a problem i.e. if you modify the new list the old list will also get modified, because both the lists are actually referencing the same object. To copy list without changing original list, use the `copy()` method.

```python
>>> a = [1,2,3,4]
>>> b = a
>>> id(a)
139904849328640
>>> id(b)
139904849328640
>>> b.append(5)
>>> b
[1, 2, 3, 4, 5]
>>> a
[1, 2, 3, 4, 5]
>>> c = list.copy(a)
>>> c.append(6)
>>> c
[1, 2, 3, 4, 5, 6]
>>> a
[1, 2, 3, 4, 5]
```

## Scripts:
1. Question Script: NULL
2. Answer Script: NULL

## Link:
1. Question Link: NULL
2. Answer Link: NULL

## Images:
1. Question Images: NULL
2. Answer Images:
   1. "../images/answers/a_13122020.png"


text:
# IndianPincode [![Gem Version](https://badge.fury.io/rb/indian_pincode.svg)](https://badge.fury.io/rb/indian_pincode)

Simple gem to get city, district, state and post office name for a given pin code.
Bundled with yaml data.

## Installation

Add this to your Gemfile:

    gem 'indian_pincode'

Or install it yourself as:

    $ gem install indian_pincode

## Usage

```ruby
IndianPincode.identify('395009')
# => {:city=>"Surat", :district=>"Surat", :state=>"Gujarat", :post_office_name=>"Surat Navyug College"}
# First run will take a while, as the yaml has to be loaded
```

## Contributing

1. Fork it
2. Create your feature branch (`git checkout -b new-feature`)
3. Commit your changes (`git commit -am 'Adds flying cat'`)
4. Push to the branch (`git push origin new-feature`)
5. Create new Pull Request


text:
---
title: "Regulatory Genomics"
excerpt: "Using machine learning for regulatory genomic data intergration and prediction."
categories:
  - Research
tags:
  - regulatory network
  - machine learning
  - single cell
---
We are interested in understanding gene regulation using network biology and machine learning approaches. We have developed several computational tools to analyze and predict key regulators of gene expression by integrating gene expression, protein-DNA interaction and epigenomic regulations.

**ConSReg** is a machine learning pipeline which select best candidate regulatory gene by integrating DAP-seq, RNA-seq and ATAC-seq data in Arabidopsis. ConSReg have been tested using both bulk RNA-seq and single cell RNA-seq data. Based on benchmark using known regulatory transcription factors, ConSReg performs better than commonly used enrichment test and provide higher ranking for known TFs. We also found that including ATAC-seq in the model substantially improves the model performance. [[publication]](https://academic.oup.com/nar/article-abstract/48/11/e62/5824611) and [[software]](https://github.com/songliVT/ConSReg)

![](/assets/images/myb_network1.jpg)

**Single Cell SPMarker** is a collection of machine-learning methods that can be used to select cell type marker genes in single cell RNA-seq data. We tested multiple feature selection approaches to determine candidate genes that can be used to assign cell types in single cell sequencing data in plant roots. We found that a random forest method + SHAP based feature selection performs best among all approaches tested. We also provide lists of new marker genes that have not been identified before using bulk RNA-seq or microarray experiments in Arabidopsis roots. [[biorxiv]](https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>3165v1.abstract), [[link to code]](https://github.com/LiLabAtVT/SingleCellClassification)

![](/assets/images/SPmarker.jpg)

**Comparing time series gene expression data across plant species.** In this work, we developed a network module finding method to identify conserved co-expression modules between different plant species without matching the tissue types between different species.
Figure 3.  [[publication]](https://plantmethods.biomedcentral.com/articles/10.1186/s13007-019-0440-x) [[link to code]](https://github.com/LiLabAtVT/CompareTranscriptome)

![](/assets/images/FishTrap.jpg)

**Ensemble network prediction using gene expression data.** We have developed supervised and unsupervised machine learning methods to infer regulatory networks from gene expression data for both Arabidopsis and soybeans. We are interested in applying these approaches to gene expression data in other plant species. [[publication]](https://www.frontiersin.org/articles/10.3389/fpls.2017.02029/full)

![](/assets/images/LPAnetwork.jpg)


text:
Changelog
=========

* 1.0.0-beta10 (2016-01-14)

 * made compatible with Symfony 3.0
 * upgraded to webmozart/glob 4.0 for better performance
 * the `puli build` command now removes obsolete disabled binding UUIDs from
   the root `puli.json`
 * fixed: `puli build` command runs now even if the factory file is corrupt
 * changed `puli self-update` command to download from https://puli.io
 * added `-u` alias for `puli type --update` command

* 1.0.0-beta9 (2015-10-06)

 * fixed regression in `puli publish` command
 * added integration tests to spot and fix regressions

* 1.0.0-beta8 (2015-10-05)

 * changed `puli bind` command to generate `ClassBinding` instances when passing
   a path that contains backslashes (`\`) or when passing the `--class` option
 * added `--class` option to `puli bind --update` command
 * added `puli upgrade` command

* 1.0.0-beta7 (2015-08-24)

 * renamed `puli package --add` to `puli package --install`
 * added `--dev` option to `puli package --install` command
 * added `%env%` variable to `--format` option of `puli package --list`
 * added `--dev` and `--prod` options to `puli package --list`
 * upgraded to webmozart/glob 3.1
 * fixed minimum package versions in composer.json
 * improved Windows compatibility

* 1.0.0-beta6 (2015-08-12)

 * added `puli cat` command
 * added `puli url` command

* 1.0.0-beta5 (2015-05-29)

 * added support for building a PHAR with Box
 * added `puli self-update` command
 * added `--parsed` option to `puli config`
 * added `--format` option to `puli package`
 * added `puli package rename` command
 * added required argument `server` to `puli asset map`
 * removed puli/composer-plugin dependency
 * upgraded webmozart/path-util to 2.0
 * turned sub-commands into option commands, e.g. `puli installer add` to
   `puli installer --add`
 * renamed `puli asset` to `puli publish`
 * renamed `puli binding` to `puli bind`
 * renamed `puli path` to `puli map`
 * added `--stable` and `--unstable` options to `puli self-update` command

* 1.0.0-beta4 (2015-04-13)

 * removed `--all` option from `puli config`
 * changed `puli config` to display all user and effective values by default
 * removed `--force` option from `puli build`
 * added `--force` option to `puli bind`
 * added `--force` option to `puli type define`
 * renamed `puli config --delete|-d` to `puli config --reset|-r`
 * added recommendation when `puli map` returns no results
 * removed argument `<pattern>` from `puli find` and added `--path` option instead
 * renamed `--type` option to `--class` for `puli find`
 * renamed `--bound-to` option to `--type` for `puli find`
 * removed the `--package` option of `puli bind --enable|--disable`
 * renamed `puli bind` to `puli binding add|list|remove|enable|disable`
 * renamed `puli map` to `puli path map|list|remove`
 * added `--force` option to `puli path map`
 * added `--enabled`, `--not-found` and `--conflict` options to `puli binding [list]`
 * added `--name` option to `puli find`
 * added `puli binding update` command
 * added `puli path update` command
 * added `puli type update` command

* 1.0.0-beta3 (2015-03-19)

 * switched to webmozart/console package
 * moved command code to command handler classes
 * added tests for command handler classes
 * injected Puli's event dispatcher into the console application to let plugins
   extend the console configuration
 * renamed `puli bind` option `--duplicate` to `--overridden`
 * added "factory" target to `puli build` command
 * added `puli plugin` command

* 1.0.0-beta2 (2015-01-27)

 * updated to work with Puli components in version 1.0.0-beta2

* 1.0.0-beta (2015-01-12)

 * moved code from `Puli\Cli\Console` to `Puli\Cli`
 * added `puli map` command
 * added `puli type` command
 * added `puli type define` command
 * added `puli type remove` command
 * added `puli bind` command
 * added `puli package` command
 * added `puli package install` command
 * added `puli package remove` command
 * added `puli package clean` command
 * added `puli config` command
 * added `puli tree` command
 * added `puli find` command
 * improved `puli ls` command
 * renamed `puli dump` to `puli build`

* 1.0.0-alpha1 (2014-12-03)

 * first alpha release

repository: puli/cli

gha_language: PHP

repo_name: puli/cli


text:
# centillion tests

This directory contains tests for centillion,
the document search engine. This uses the
`unittest` library, and tests can be run
with `pytest`.

Tests will automatically load test configuration
files for centillion from the `tests/` directory.

We run the following tests:

* `test_routes.py` - create a centillion app with an
  empty search index, and test that each of the
  routes created by the Flask app can be reached
  properly.

* `test_fakedocs.py` - create a centillion app,
  populate a search index with fake documents,
  and run tests of a centillion instance with
  documents in the search index.

* `test_gdrive.py` - requires `credentials.json` file
  containing Google Drive API credentials; create a
  centillion app and populate the search index with
  files from Google Drive.

* `test_gh.py` - requires Github API access token to
  be provided in conig file; create a centillion app,
  and popualte the search index with Github files,
  Markdown content, issues, and pull requests.

## Secrets for Travis

The strategy we use for getting API keys into Travis
to enable tests of centillion functionality using real
API calls is to tar anad encrypt all secret files.

The file `secrets.tar.gz.enc` is an encrypted file
that, when decrypted, contains a `secrets.tar.gz`
file with the files:

* `secrets.py` - contains API keys in varibles;
  imported/used by test configuration files

* `credentials.json` - contains Google Drive API
  credentials

repository: chmreid/centillion

branch_name: refs/heads/public

repo_name: chmreid/centillion