text:
# Lily Data Models

## actor_states

Actor states that were changed at an epoch. Associates actors states as single-level trees with CIDs pointing to complete state tree with the root CID (head) for that actor's state.

| Column | Description                                      |
| ------ | ------------------------------------------------ |
| height | Epoch when this state change happened.           |
| head   | CID of the root of the state tree for the actor. |
| code   | CID identifier for the type of the actor.        |
| state  | Top level of state data.                         |

## actors

Actors on chain that were added or updated at an epoch. Associates the actor's state root CID (head) with the chain state root CID from which it decends. Includes account ID nonce and balance at each state.

| Column     | Description                                               |
| ---------- | --------------------------------------------------------- |
| height     | Epoch when this actor was created or updated.             |
| id         | Actor address.                                            |
| code       | Human readable identifier for the type of the actor.      |
| head       | CID of the root of the state tree for the actor.          |
| nonce      | The next actor nonce that is expected to appear on chain. |
| balance    | Actor balance in attoFIL.                                 |
| state_root | CID of the state root.                                    |

## block_headers

Blocks included in tipsets at an epoch.

| Column            | Description                                                  |
| ----------------- | ------------------------------------------------------------ |
| height            | Epoch when this block was mined.                             |
| cid               | CID of the block.                                            |
| parent_weight     | Aggregate chain weight of the block's parent set.            |
| parent_state_root | CID of the block's parent state root.                        |
| miner             | Address of the miner who mined this block.                   |
| timestamp         | Time the block was mined in Unix time, the number of seconds elapsed since January 1, 1970 UTC. |
| win_count         | Number of reward units won in this block.                    |
| parent_base_fee   | The base fee after executing the parent tipset.              |
| fork_signaling    | Flag used as part of signaling forks.                        |

## block_messages

Message CIDs and the Blocks CID which contain them.

| Column  | Description                                 |
| ------- | ------------------------------------------- |
| height  | Epoch when the block was mined.             |
| block   | CID of the block that contains the message. |
| message | CID of a message in the block.              |

## block_parents

Block CIDs to many parent Block CIDs.

| Column | Description                     |
| ------ | ------------------------------- |
| height | Epoch when the block was mined. |
| block  | CID of the block.               |
| parent | CID of the parent block.        |

## chain_consensus

Hight and TipSet to Parent TipSet or Null Round.

| Column            | Description                                      |
| ----------------- | ------------------------------------------------ |
| height            | Epoch when the blocks were mined in this tipset. |
| tip_set           | CID of the tipset or `NULL_ROUND`                |
| parent_tip_set    | CID of the parent tipset                         |
| parent_state_root | CID of the parent tipset state root              |

## chain_economics

Economic summaries per state root CID.

| Column                | Description                                                  |
| --------------------- | ------------------------------------------------------------ |
| height                | Epoch of the economic summary.                               |
| parent_state_root     | CID of the parent state root.                                |
| circulating_fil       | The amount of FIL (attoFIL) circulating and tradeable in the economy. The basis for Market Cap calculations. |
| vested_fil            | Total amount of FIL (attoFIL) that is vested from genesis allocation. |
| mined_fil             | The amount of FIL (attoFIL) that has been mined by storage miners. |
| burnt_fil             | Total FIL (attoFIL) burned as part of penalties and on-chain computations. |
| locked_fil            | The amount of FIL (attoFIL) locked as part of mining, deals, and other mechanisms. |
| fil_reserve_disbursed | The amount of FIL (attoFIL) that has been disbursed from the mining reserve. |

## chain_powers

Power summaries from the Power actor.

| Column                        | Description                                                  |
| ----------------------------- | ------------------------------------------------------------ |
| height                        | Epoch this power summary applies to.                         |
| state_root                    | CID of the parent state root.                                |
| total_raw_bytes_power         | Total storage power in bytes in the network. Raw byte power is the size of a sector in bytes. |
| total_raw_bytes_committed     | Total provably committed storage power in bytes. Raw byte power is the size of a sector in bytes. |
| total_qa_bytes_power          | Total quality adjusted storage power in bytes in the network. Quality adjusted power is a weighted average of the quality of its space and it is based on the size, duration and quality of its deals. |
| total_qa_bytes_committed      | Total provably committed, quality adjusted storage power in bytes. Quality adjusted power is a weighted average of the quality of its space and it is based on the size, duration and quality of its deals. |
| total_pledge_collateral       | Total locked FIL (attoFIL) miners have pledged as collateral in order to participate in the economy. |
| qa_smoothed_position_estimate | Total power smoothed position estimate - Alpha Beta Filter "position" (value) estimate in Q.128 format. |
| qa_smoothed_velocity_estimate | Total power smoothed velocity estimate - Alpha Beta Filter "velocity" (rate of change of value) estimate in Q.128 format. |
| miner_count                   | Total number of miners.                                      |
| participating_miner_count     | Total number of miners with power above the minimum miner threshold. |

## chain_rewards

Reward summaries from the Reward actor.

| Column                                | Description                                                  |
| ------------------------------------- | ------------------------------------------------------------ |
| height                                | Epoch this rewards summary applies to.                       |
| state_root                            | CID of the parent state root.                                |
| cum_sum_baseline                      | Target that CumsumRealized needs to reach for EffectiveNetworkTime to increase. It is measured in byte-epochs (space * time) representing power committed to the network for some duration. |
| cum_sum_realized                      | Cumulative sum of network power capped by BaselinePower(epoch). It is measured in byte-epochs (space * time) representing power committed to the network for some duration. |
| effective_baseline_power              | The baseline power (in bytes) at the EffectiveNetworkTime epoch. |
| new_baseline_power                    | The baseline power (in bytes) the network is targeting.      |
| new_reward_smoothed_position_estimate | Smoothed reward position estimate - Alpha Beta Filter "position" (value) estimate in Q.128 format. |
| new_reward_smoothed_velocity_estimate | Smoothed reward velocity estimate - Alpha Beta Filter "velocity" (rate of change of value) estimate in Q.128 format. |
| total_mined_reward                    | The total FIL (attoFIL) awarded to block miners.             |
| new_reward                            | The reward to be paid in per WinCount to block producers. The actual reward total paid out depends on the number of winners in any round. This value is recomputed every non-null epoch and used in the next non-null epoch. |
| effective_network_time                | Ceiling of real effective network time "theta" based on CumsumBaselinePower(theta) == CumsumRealizedPower. Theta captures the notion of how much the network has progressed in its baseline and in advancing network time. |

## derived_gas_outputs

Derived gas costs resulting from execution of a message in the VM.

| Column               | Description                                                  |
| -------------------- | ------------------------------------------------------------ |
| height               | Epoch this message was executed at.                          |
| cid                  | CID of the message.                                          |
| from                 | Address of actor that sent the message.                      |
| to                   | Address of actor that received the message.                  |
| value                | The FIL value transferred (attoFIL) to the message receiver. |
| gas_fee_cap          | The maximum price that the message sender is willing to pay per unit of gas. |
| gas_premium          | The price per unit of gas (measured in attoFIL/gas) that the message sender is willing to pay (on top of the BaseFee) to "tip" the miner that will include this message in a block. |
| gas_limit            | A hard limit on the amount of gas (i.e., number of units of gas) that a message’s execution should be allowed to consume on chain. It is measured in units of gas. |
| size_bytes           | Size in bytes of the serialized message.                     |
| nonce                | The message nonce, which protects against duplicate messages and multiple messages with the same values. |
| method               | The method number to invoke. Only unique to the actor the method is being invoked on. A method number of 0 is a plain token transfer - no method exectution. |
| state_root           | CID of the parent state root.                                |
| exit_code            | The exit code that was returned as a result of executing the message. Exit code 0 indicates success. Codes 0-15 are reserved for use by the runtime. Codes 16-31 are common codes shared by different actors. Codes 32+ are actor specific. |
| gas_used             | A measure of the amount of resources (or units of gas) consumed, in order to execute a message. |
| parent_base_fee      | The set price per unit of gas (measured in attoFIL/gas unit) to be burned (sent to an unrecoverable address) for every message execution. |
| base_fee_burn        | The amount of FIL (in attoFIL) to burn as a result of the base fee. It is parent_base_fee (or gas_fee_cap if smaller) multiplied by gas_used. Note: successful window PoSt messages are not charged this burn. |
| over_estimation_burn | The fee to pay (in attoFIL) for overestimating the gas used to execute a message. The overestimated gas to burn (gas_burned) is a portion of the difference between gas_limit and gas_used. The over_estimation_burn value is gas_burned * parent_base_fee. |
| miner_penalty        | Any penalty fees (in attoFIL) the miner incured while executing the message. |
| miner_tip            | The amount of FIL (in attoFIL) the miner receives for executing the message. Typically it is gas_premium * gas_limit but may be lower if the total fees exceed the gas_fee_cap. |
| refund               | The amount of FIL (in attoFIL) to refund to the message sender after base fee, miner tip and overestimation amounts have been deducted. |
| gas_refund           | The overestimated units of gas to refund. It is a portion of the difference between gas_limit and gas_used. |
| gas_burned           | The overestimated units of gas to burn. It is a portion of the difference between gas_limit and gas_used. |
| actor_name           | The full versioned name of the actor that received the message (for example fil/3/storagepower). |
| actor_family         | The short unversioned name of the actor that received the message (for example storagepower). |

## drand_block_entries

Drand randomness round numbers used in each block.

| Column | Description                              |
| ------ | ---------------------------------------- |
| round  | The round number of the randomness used. |
| block  | CID of the block.                        |

## 	id_addresses

Mapping of IDs to robust addresses from the init actor's state.

| Column     | Description                                                  |
| ---------- | ------------------------------------------------------------ |
| height     | Epoch at which this address mapping was added.               |
| id         | ID of the actor.                                             |
| address    | Robust address of the actor.                                 |
| state_root | CID of the parent state root at which this address mapping was added. |

## internal_messages

Messages generated implicitly by system actors and by using the runtime send method.

| Column         | Description                                                  |
| -------------- | ------------------------------------------------------------ |
| height         | Epoch this message was executed at.                          |
| cid            | CID of the message.                                          |
| state_root     | CID of the parent state root at which this message was executed. |
| source_message | CID of the message that caused this message to be sent.      |
| from           | Address of the actor that sent the message.                  |
| to             | Address of the actor that received the message.              |
| value          | Amount of FIL (in attoFIL) transferred by this message.      |
| method         | The method number invoked on the recipient actor. Only unique to the actor the method is being invoked on. A method number of 0 is a plain token transfer - no method exectution. |
| actor_name     | The full versioned name of the actor that received the message (for example fil/3/storagepower). |
| actor_family   | The short unversioned name of the actor that received the message (for example storagepower). |
| exit_code      | The exit code that was returned as a result of executing the message. Exit code 0 indicates success. Codes 0-15 are reserved for use by the runtime. Codes 16-31 are common codes shared by different actors. Codes 32+ are actor specific. |
| gas_used       | A measure of the amount of resources (or units of gas) consumed, in order to execute a message. |

## internal_parsed_messages

Internal messages parsed to extract useful information.

| Column | Description                                                  |
| ------ | ------------------------------------------------------------ |
| height | Epoch this message was executed at.                          |
| cid    | CID of the message.                                          |
| from   | Address of the actor that sent the message.                  |
| to     | Address of the actor that received the message.              |
| value  | Amount of FIL (in attoFIL) transferred by this message.      |
| method | The method number invoked on the recipient actor. Only unique to the actor the method is being invoked on. A method number of 0 is a plain token transfer - no method exectution. |
| params | Method parameters parsed and serialized as a JSON object.    |

## market_deal_proposals

All storage deal states with latest values applied to end_epoch when updates are detected on-
chain.

| Column                  | Description                                                  |
| ----------------------- | ------------------------------------------------------------ |
| height                  | Epoch at which this deal proposal was added or changed.      |
| deal_id                 | Identifier for the deal.                                     |
| state_root              | CID of the parent state root for this deal.                  |
| piece_cid               | CID of a sector piece. A Piece is an object that represents a whole or part of a File. |
| padded_piece_size       | The piece size in bytes with padding.                        |
| unpadded_piece_size     | The piece size in bytes without padding.                     |
| is_verified             | Deal is with a verified provider.                            |
| client_id               | Address of the actor proposing the deal.                     |
| provider_id             | Address of the actor providing the services.                 |
| start_epoch             | The epoch at which this deal with begin. Storage deal must appear in a sealed (proven) sector no later than start_epoch, otherwise it is invalid. |
| end_epoch               | The epoch at which this deal with end.                       |
| slashed_epoch           | The epoch at which this deal was slashed or null.            |
| storage_price_per_epoch | The amount of FIL (in attoFIL) that will be transferred from the client to the provider every epoch this deal is active for. |
| provider_collateral     | The amount of FIL (in attoFIL) the provider has pledged as collateral. The Provider deal collateral is only slashed when a sector is terminated before the deal expires. |
| client_collateral       | The amount of FIL (in attoFIL) the client has pledged as collateral. |
| label                   | An arbitrary client chosen label to apply to the deal.       |

## market_deal_states

All storage deal state transitions detected on-chain.

| Column             | Description                                                  |
| ------------------ | ------------------------------------------------------------ |
| height             | Epoch at which this deal was added or changed.               |
| deal_id            | Identifier for the deal.                                     |
| sector_start_epoch | Epoch this deal was included in a proven sector. -1 if not yet included in proven sector. |
| last_update_epoch  | Epoch this deal was last updated at. -1 if deal state never updated. |
| slash_epoch        | Epoch this deal was slashed at. -1 if deal was never slashed. |
| state_root         | CID of the parent state root for this deal.                  |

## message_gas_economy

Gas economics for all messages in all blocks at each epoch.

| Column                 | Description                                                  |
| ---------------------- | ------------------------------------------------------------ |
| height                 | Epoch these economics apply to.                              |
| state_root             | CID of the parent state root at this epoch.                  |
| gas_limit_total        | The sum of all the gas limits.                               |
| gas_limit_unique_total | The sum of all the gas limits of unique messages.            |
| base_fee               | The set price per unit of gas (measured in attoFIL/gas unit) to be burned (sent to an unrecoverable address) for every message execution. |
| base_fee_change_log    | The logarithm of the change between new and old base fee.    |
| gas_fill_ratio         | The gas_limit_total / target gas limit total for all blocks. |
| gas_capacity_ratio     | The gas_limit_unique_total / target gas limit total for all blocks. |
| gas_waste_ratio        | (gas_limit_total - gas_limit_unique_total) / target gas limit total for all blocks. |

## messages

Validated on-chain messages by their CID and their metadata.

| Column      | Description                                                  |
| ----------- | ------------------------------------------------------------ |
| height      | Epoch this message was executed at.                          |
| cid         | CID of the message.                                          |
| from        | Address of the actor that sent the message.                  |
| to          | Address of the actor that received the message.              |
| size_bytes  | Size of the serialized message in bytes.                     |
| nonce       | The message nonce, which protects against duplicate messages and multiple messages with the same values. |
| value       | Amount of FIL (in attoFIL) transferred by this message.      |
| gas_fee_cap | The maximum price that the message sender is willing to pay per unit of gas. |
| gas_premium | The price per unit of gas (measured in attoFIL/gas) that the message sender is willing to pay (on top of the BaseFee) to "tip" the miner that will include this message in a block. |
| gas_limit   | The upper bound unit of gas set on the computation required to process the message. |
| method      | The method number invoked on the recipient actor. Only unique to the actor the method is being invoked on. A method number of 0 is a plain token transfer - no method execution. |

## miner_current_deadline_infos

Deadline refers to the window during which proofs may be submitted.

| Column         | Description                                                  |
| -------------- | ------------------------------------------------------------ |
| height         | Epoch at which this info was calculated.                     |
| miner_id       | Address of the miner this info relates to.                   |
| state_root     | CID of the parent state root at this epoch.                  |
| deadline_index | A deadline index, in [0..d.WPoStProvingPeriodDeadlines) unless period elapsed. |
| period_start   | First epoch of the proving period (<= CurrentEpoch).         |
| open           | First epoch from which a proof may be submitted (>= CurrentEpoch). |
| close          | First epoch from which a proof may no longer be submitted (>= Open). |
| challenge      | Epoch at which to sample the chain for challenge (< Open).   |
| fault_cutoff   | First epoch at which a fault declaration is rejected (< Open). |

## miner_fee_debts

Miner debts per epoch from unpaid fees.

| Column     | Description                                                  |
| ---------- | ------------------------------------------------------------ |
| height     | Epoch at which this debt applies.                            |
| miner_id   | Address of the miner that owes fees.                         |
| state_root | CID of the parent state root at this epoch.                  |
| fee_debt   | Absolute value of debt this miner owes from unpaid fees in attoFIL. |

## miner_infos

Miner Account IDs for all associated addresses plus peer ID. See https://docs.filecoin.io/min
e/lotus/miner-addresses/ for more information.

| Column                    | Description                                                  |
| ------------------------- | ------------------------------------------------------------ |
| height                    | Epoch at which this miner info was added/changed.            |
| miner_id                  | Address of miner this info applies to.                       |
| state_root                | CID of the parent state root at this epoch.                  |
| owner_id                  | Address of actor designated as the owner. The owner address is the address that created the miner, paid the collateral, and has block rewards paid out to it. |
| worker_id                 | Address of actor designated as the worker. The worker is responsible for doing all of the work, submitting proofs, committing new sectors, and all other day to day activities. |
| new_worker                | Address of a new worker address that will become effective at worker_change_epoch. |
| worker_change_epoch       | Epoch at which a new_worker address will become effective.   |
| consensus_faulted_elapsed | The next epoch this miner is eligible for certain permissioned actor methods and winning block elections as a result of being reported for a consensus fault. |
| peer_id                   | Current libp2p Peer ID of the miner.                         |
| control_address           | JSON array of control addresses. Control addresses are used to submit WindowPoSts proofs to the chain. WindowPoSt is the mechanism through which storage is verified in Filecoin and is required by miners to submit proofs for all sectors every 24 hours. Those proofs are submitted as messages to the blockchain and therefore need to pay the respective fees. |
| multi_address             | JSON array of multiaddrs at which this miner can be reached. |
| sector_size               | The sector size used by this miner.                          |

## miner_locked_funds

Details of Miner funds locked and unavailable for use.

| Column              | Description                                                  |
| ------------------- | ------------------------------------------------------------ |
| height              | Epoch at which these details were added/changed.             |
| miner_id            | Address of the miner these details apply to.                 |
| state_root          | CID of the parent state root at this epoch.                  |
| locked_funds        | Amount of FIL (in attoFIL) locked due to vesting. When a Miner receives tokens from block rewards, the tokens are locked and added to the Miner's vesting table to be unlocked linearly over some future epochs. |
| initial_pledge      | Amount of FIL (in attoFIL) locked due to it being pledged as collateral. When a Miner ProveCommits a Sector, they must supply an "initial pledge" for the Sector, which acts as collateral. If the Sector is terminated, this deposit is removed and burned along with rewards earned by this sector up to a limit. |
| pre_commit_deposits | Amount of FIL (in attoFIL) locked due to it being used as a PreCommit deposit. When a Miner PreCommits a Sector, they must supply a "precommit deposit" for the Sector, which acts as collateral. If the Sector is not ProveCommitted on time, this deposit is removed and burned. |

## miner_pre_commit_infos

Information on sector PreCommits states.

| Column                   | Description                                                  |
| ------------------------ | ------------------------------------------------------------ |
| height                   | Epoch this PreCommit information was added/changed.          |
| miner_id                 | Address of the miner who owns the sector.                    |
| sector_id                | Numeric identifier for the sector.                           |
| state_root               | CID of the parent state root at this epoch.                  |
| sealed_cid               | CID of the sealed sector.                                    |
| seal_rand_epoch          | Seal challenge epoch. Epoch at which randomness should be drawn to tie Proof-of-Replication to a chain. |
| expiration_epoch         | Epoch this sector expires.                                   |
| pre_commit_deposit       | Amount of FIL (in attoFIL) used as a PreCommit deposit. If the Sector is not ProveCommitted on time, this deposit is removed and burned. |
| pre_commit_epoch         | Epoch this PreCommit was created.                            |
| deal_weight              | Total space*time of submitted deals.                         |
| verified_deal_weight     | Total space*time of submitted verified deals.                |
| is_replace_capacity      | Whether to replace a "committed capacity" no-deal sector (requires non-empty DealIDs). |
| replace_sector_deadline  | The deadline location of the sector to replace.              |
| replace_sector_partition | The partition location of the sector to replace.             |
| replace_sector_number    | ID of the committed capacity sector to replace.              |

## miner_sector_deals

Mapping of Deal IDs to their respective Miner and Sector IDs.

| Column    | Description                                       |
| --------- | ------------------------------------------------- |
| height    | Epoch at which this deal was added/updated.       |
| miner_id  | Address of the miner the deal is with.            |
| sector_id | Numeric identifier of the sector the deal is for. |
| deal_id   | Numeric identifier for the deal.                  |

## miner_sector_events

Sector events on-chain per Miner/Sector. One of

| Column     | Description                                                  |
| ---------- | ------------------------------------------------------------ |
| height     | Epoch at which this event occurred.                          |
| miner_id   | Address of the miner who owns the sector.                    |
| sector_id  | Numeric identifier of the sector.                            |
| state_root | CID of the parent state root at this epoch.                  |
| event      | Name of the event that occurred: PRECOMMIT_ADDED, PRECOMMIT_EXPIRED, COMMIT_CAPACITY_ADDED, SECTOR_ADDED, SECTOR_EXTENDED, SECTOR_FAULTED, SECTOR_FAULTED, SECTOR_RECOVERING, SECTOR_RECOVERED, SECTOR_EXPIRED, or SECTOR_TERMINATED. |

## miner_sector_infos

Latest state of sectors by Miner.

| Column                  | Description                                                  |
| ----------------------- | ------------------------------------------------------------ |
| height                  | Epoch at which this sector info was added/updated.           |
| miner_id                | Address of the miner who owns the sector.                    |
| sector_id               | Numeric identifier of the sector.                            |
| state_root              | CID of the parent state root at this epoch.                  |
| sealed_cid              | The root CID of the Sealed Sector’s merkle tree. Also called CommR, or "replica commitment". |
| activation_epoch        | Epoch during which the sector proof was accepted.            |
| expiration_epoch        | Epoch during which the sector expires.                       |
| deal_weight             | Integral of active deals over sector lifetime.               |
| verified_deal_weight    | Integral of active verified deals over sector lifetime.      |
| initial_pledge          | Pledge collected to commit this sector (in attoFIL).         |
| expected_day_reward     | Expected one day projection of reward for sector computed at activation time (in attoFIL). |
| expected_storage_pledge | Expected twenty day projection of reward for sector computed at activation time (in attoFIL). |

## miner_sector_posts

Proof of Spacetime for sectors.

| Column           | Description                                    |
| ---------------- | ---------------------------------------------- |
| height           | Epoch at which this PoSt message was executed. |
| miner_id         | Address of the miner who owns the sector.      |
| sector_id        | Numeric identifier of the sector.              |
| post_message_cid | CID of the PoSt message.                       |

## multisig_approvals

Message Transactions approved by Multsig Actors.

| Column         | Description                                                  |
| -------------- | ------------------------------------------------------------ |
| height         | Epoch at which this transaction was executed.                |
| multisig_id    | Address of the multisig actor involved in the transaction.   |
| state_root     | CID of the parent state root at this epoch.                  |
| transaction_id | Number identifier for the transaction - unique per multisig. |
| to             | Address of the recipient who will be sent a message if the proposal is approved. |
| value          | Amount of FIL (in attoFIL) that will be transferred if the proposal is approved. |
| method         | The method number to invoke on the recipient if the proposal is approved. Only unique to the actor the method is being invoked on. A method number of 0 is a plain token transfer - no method exectution. |

## multisig_transactions

Details of pending transactions involving multisig actors.

| Column         | Description                                                  |
| -------------- | ------------------------------------------------------------ |
| height         | Epoch at which this transaction was executed.                |
| multisig_id    | Address of the multisig actor involved in the transaction.   |
| state_root     | CID of the parent state root at this epoch.                  |
| transaction_id | Number identifier for the transaction - unique per multisig. |
| to             | Address of the recipient who will be sent a message if the proposal is approved. |
| value          | Amount of FIL (in attoFIL) that will be transferred if the proposal is approved. |
| method         | The method number to invoke on the recipient if the proposal is approved. Only unique to the actor the method is being invoked on. A method number of 0 is a plain token transfer - no method exectution. |
| params         | CBOR encoded bytes of parameters to send to the method that will be invoked if the proposal is approved. |
| approved       | Addresses of signers who have approved the transaction. 0th entry is the proposer. |

## parsed_messages

Messages parsed to extract useful information.

| Column | Description                                                  |
| ------ | ------------------------------------------------------------ |
| height | Epoch this message was executed at.                          |
| cid    | CID of the message.                                          |
| from   | Address of the actor that sent the message.                  |
| to     | Address of the actor that received the message.              |
| value  | Amount of FIL (in attoFIL) transferred by this message.      |
| method | The name of the method that was invoked on the recipient actor. |
| params | Method parameters parsed and serialized as a JSON object.    |

## power_actor_claims

Miner power claims recorded by the power actor.

| Column            | Description                                                  |
| ----------------- | ------------------------------------------------------------ |
| height            | Epoch this claim was made.                                   |
| miner_id          | Address of miner making the claim.                           |
| state_root        | CID of the parent state root at this epoch.                  |
| raw_byte_power    | Sum of raw byte storage power for a miner's sectors. Raw byte power is the size of a sector in bytes. |
| quality_adj_power | Sum of quality adjusted storage power for a miner's sectors. Quality adjusted power is a weighted average of the quality of its space and it is based on the size, duration and quality of its deals. |

## receipts

Message reciepts after being applied to chain state by message CID and parent state root CID
of tipset when message was executed.

| Column     | Description                                                  |
| ---------- | ------------------------------------------------------------ |
| height     | Epoch the message was executed and receipt generated.        |
| message    | CID of the message this receipt belongs to.                  |
| state_root | CID of the parent state root that this epoch.                |
| idx        | Index of message indicating execution order.                 |
| exit_code  | The exit code that was returned as a result of executing the message. Exit code 0 indicates success. Codes 0-15 are reserved for use by the runtime. Codes 16-31 are common codes shared by different actors. Codes 32+ are actor specific. |
| gas_used   | A measure of the amount of resources (or units of gas) consumed, in order to execute a message. |

## verified_registry_verified_clients

Verifier on-chain per each verified client state change.

| Column     | Description                                                  |
| ---------- | ------------------------------------------------------------ |
| height     | Epoch at which this verified client state changed.           |
| state_root | CID of the parent state root at this epoch.                  |
| address    | Address of verified client this state change applies to.     |
| data_cap   | DataCap of verified client at this state change.             |
| event      | Name of the event that occurred. On of: ADDED, REMOVED, MODIFIED |

## verified_registry_verifiers

Verifier on-chain per each verifier state change.

| Column     | Description                                                  |
| ---------- | ------------------------------------------------------------ |
| height     | Epoch at which this verifiers state changed.                 |
| state_root | CID of the parent state root at this epoch.                  |
| address    | Address of verifier this state change applies to.            |
| data_cap   | DataCap of verifier at this state change.                    |
| event      | Name of the event that occurred. On of: ADDED, REMOVED, MODIFIED |


text:
---
title: SDxCentral – Open Container Initiative Marks Success, Looks for What’s Next
author:
  name: Open Container Initiative
  tag: oci
tags: news
date: 2017-09-11
---

LOS ANGELES – The Open Container Initiative (OCI) is looking at container distribution challenges as a potential follow up to its initial runtime and image format specification release.

Read more from [SDXCentral](https://www.sdxcentral.com/articles/news/open-container-initiative-marks-success-looks-for-whats-next/2017/09/).

branch_name: refs/heads/main

extension: md

gha_language: HTML

license_type: permissive


text:
# Professional README Generator

[![License: MIT](https://img.shields.io/github/license/nayala98/09-Node.js-challenge?style=plastic)](./LICENSE)

## Table of Contents
* [Description](#description)
* [Demonstration](#demonstration)
* [Technologies](#technologies)
* [Installation](#installation)
* [Usage](#usage)
* [License](#license)
* [Questions](#questions)

## Description
This project is a command line application that automatically generates a professional README markdown file for a repository based on answers from the user. When the application runs, it presents a series of prompts to the user to fill in sections in the README.

## Demonstration
Video Demonstration of the generator: [Professional README Generator](https://drive.google.com/file/d/1KqeCUdRr-WYbdHCsFjQl5EIVIMOHZHgD/view)

## Technologies

* [Node.js](https://nodejs.org/)
* [Inquirer.js](https://www.npmjs.com/package/inquirer)

## Installation
To install dependencies, run the following:

`
npm i
`

## Usage
After installing the dependencies, run the application with
`
node index.js
`

## License

This repository is licensed under the [MIT license](./LICENSE).

## Questions

Questions about this repository? Please contact me at [nathaniel.ayala20@gmail.com](mailto:nathaniel.ayala20@gmail.com). View more of my work at [nayala98](https://github.com/nayala98)

license: MIT


text:
# OpenCV With Python

This project provide wide variety of Python script for computer vision and image editing as thresholding, transformations, edge detection ...

## Getting started

Each script has is own parameter. See each one for more informations.
See deployment notes (to be created) for more information.

### Prerequisites

Python 3.xx is needed.

### Installing

No installation required, download and launch ! :)

## 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

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

## License

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

## Acknowledgments

* See the original OpenCV project at : http://opencv.org/about.html

branch_name: refs/heads/master

gha_language: Python


text:
| Field name       | Type       | Description    |
| :----------------|:----------:|:---------------|
| **id** | STRING |  |
| **server** | RECORD | Location information about the M-Lab server that collected the measurement. |
| server.**Site** | STRING | The M-Lab site name. |
| server.**Machine** | STRING | The machine name within the site. |
| server.**Geo** | RECORD |  |
| server.Geo.**ContinentCode** | STRING |  |
| server.Geo.**CountryCode** | STRING |  |
| server.Geo.**CountryCode3** | STRING |  |
| server.Geo.**CountryName** | STRING |  |
| server.Geo.**Region** | STRING |  |
| server.Geo.**Subdivision1ISOCode** | STRING |  |
| server.Geo.**Subdivision1Name** | STRING |  |
| server.Geo.**Subdivision2ISOCode** | STRING |  |
| server.Geo.**Subdivision2Name** | STRING |  |
| server.Geo.**MetroCode** | INTEGER |  |
| server.Geo.**City** | STRING |  |
| server.Geo.**AreaCode** | INTEGER |  |
| server.Geo.**PostalCode** | STRING |  |
| server.Geo.**Latitude** | FLOAT |  |
| server.Geo.**Longitude** | FLOAT |  |
| server.Geo.**AccuracyRadiusKm** | INTEGER |  |
| server.Geo.**Missing** | BOOLEAN | The annotator looked for but was unable to find a Geo location for this IP. |
| server.**Network** | RECORD | Network information about connection. |
| server.Network.**CIDR** | STRING |  |
| server.Network.**ASNumber** | INTEGER | The Autonomous System Number, provided by RouteViews. |
| server.Network.**ASName** | STRING | Canonical name for the ASN, provided by ipinfo.io. |
| server.Network.**Missing** | BOOLEAN | The annotator looked but was unable to find a network for this IP. |
| server.Network.**Systems** | RECORD |  |
| server.Network.Systems.**ASNs** | INTEGER |  |
| **client** | RECORD | Location information about the client that initiated the measurement. |
| client.**Geo** | RECORD |  |
| client.Geo.**ContinentCode** | STRING |  |
| client.Geo.**CountryCode** | STRING |  |
| client.Geo.**CountryCode3** | STRING |  |
| client.Geo.**CountryName** | STRING |  |
| client.Geo.**Region** | STRING |  |
| client.Geo.**Subdivision1ISOCode** | STRING |  |
| client.Geo.**Subdivision1Name** | STRING |  |
| client.Geo.**Subdivision2ISOCode** | STRING |  |
| client.Geo.**Subdivision2Name** | STRING |  |
| client.Geo.**MetroCode** | INTEGER |  |
| client.Geo.**City** | STRING |  |
| client.Geo.**AreaCode** | INTEGER |  |
| client.Geo.**PostalCode** | STRING |  |
| client.Geo.**Latitude** | FLOAT |  |
| client.Geo.**Longitude** | FLOAT |  |
| client.Geo.**AccuracyRadiusKm** | INTEGER |  |
| client.Geo.**Missing** | BOOLEAN | The annotator looked for but was unable to find a Geo location for this IP. |
| client.**Network** | RECORD | Network information about connection. |
| client.Network.**CIDR** | STRING |  |
| client.Network.**ASNumber** | INTEGER | The Autonomous System Number, provided by RouteViews. |
| client.Network.**ASName** | STRING | Canonical name for the ASN, provided by ipinfo.io. |
| client.Network.**Missing** | BOOLEAN | The annotator looked but was unable to find a network for this IP. |
| client.Network.**Systems** | RECORD |  |
| client.Network.Systems.**ASNs** | INTEGER |  |
| **parser** | RECORD | Metadata about how the parser processed this measurement row. |
| parser.**Version** | STRING | Version of the parser that processed this row. |
| parser.**Time** | TIMESTAMP | Time that the parser processed this row. |
| parser.**ArchiveURL** | STRING | GCS URL to the archive containing the Filename for this row. |
| parser.**Filename** | STRING |  |
| parser.**Priority** | INTEGER |  |
| **date** | DATE | Date is used by BigQuery to partition data to improve query performance. |

repository: jeremiak/mlab-website

repo_name: jeremiak/mlab-website


text:
---
layout: post
title: Pilipino Pronunciation Corrections
date: 2020-07-09 00:31
Tags: [ uncategorized, blog ]
permalink: /ppc/
author: Kevin Olega
---
Open your mouth wider.

Speak louder.

Fix your posture and be upright when speaking.

Look forward as you speak.

Watch out for:

B and V sounds.

P and F sounds.

Th and D sounds.

Sometimes your Th sounds like a T.

Usually, the problem is you have these sounds backward.

You can do a Google search on how to pronounce any word.

If you fix 200 words, you should be perfect for most high paying jobs that require fluent English.

Some people never bother because they're too busy with the games that they're playing on their phone.

What about you?

repository: kevinolega/callcentertrainingtips

repo_name: kevinolega/callcentertrainingtips


text:
---
layout: post
title: "Moved...."
---

Long time no update, I know.

Got a pretty nice deal for a new server by haggling ... a lot.

Only tradeoff:

The new system runs plesk.

And plesk is the pest.

On the old server everything was in one database and all the configuration files (bind, apache, mysql, postfix) were created by one simple script.

The layout was something like this:

    Customer
      ( 1 -> N  ) Login
      ( 1 -> N ) Sites

So if Customer "Thomas Test" had login "ttalpha" and "ttprod" with three domains (alpha.1.org, alpha.2.org + a.3.org and www.1.org, www.2.org + www.3.org),
then the filesystem looked like this:
    /home/
    --ttalpha/
    ----web/
    ------alpha.1.org/
    ------alpha.2.org/
    ------alpha.3.org/
    --ttprod/
    ----web/
    ------www.1.org/
    ------www.2.org/
    ------www.3.org/

With one login (and password/sshkey) shared per login/user,
but a tight seperation of the test and production sites.

Now with PLESK ... argl.

For the above setup, I need about 400 Clicks in the Webinterface.

And then I end up with 3 users ... and have the subdomains (alpha+www) shared for each domain.

Or I get 6 users ... with 6 logins and 6 passwords.

Yuck.

I still have to get qmail to work right. Some of my mail is simply swalloed and I have yet to find out what happens ...

And I _will_ find a new host soon!

The DNS-disaster is a whole new story ...

extension: markdown


text:
---
layout: default
title: propEqual
description: A strict type and value comparison of an object's own properties.
categories:
  - assert
---

## `propEqual( actual, expected [, message ] )`

A strict type and value comparison of an object's own properties.

| name               | description                          |
|--------------------|--------------------------------------|
| `actual`           | Expression being tested              |
| `expected`         | Known comparison value               |
| `message` (string) | A short description of the assertion |

### Description

The `propEqual()` assertion provides strictly (`===`) comparison of Object properties. Unlike `deepEqual()`, this assertion can be used to compare two objects made with different constructors and prototype.

[`strictEqual()`](/assert/strictEqual/) can be used to test strict equality.

[`notPropEqual()`](/assert/notPropEqual/) can be used to explicitly test strict inequality of Object properties.

### Example

Compare the properties values of two objects.

```js
QUnit.test( "propEqual test", function( assert ) {
  function Foo( x, y, z ) {
    this.x = x;
    this.y = y;
    this.z = z;
  }
  Foo.prototype.doA = function () {};
  Foo.prototype.doB = function () {};
  Foo.prototype.bar = 'prototype';

  var foo = new Foo( 1, "2", [] );
  var bar = {
    x : 1,
    y : "2",
    z : []
  };
  assert.propEqual( foo, bar, "Strictly the same properties without comparing objects constructors." );
});
```

repository: niilante/qunit

repo_name: niilante/qunit


text:
# Vector CAPL Support for Visual Studio Code

Communication Access Programming Language (CAPL) allows programming of network node models in several Vector Applications (CANoe, CANanalyzer ...).

This extension allows you to use VS Code as code editor instead of built-in CAPL Browser. You can install this extension from [https://marketplace.visualstudio.com/items?itemName=kmasif.capl-vector](https://marketplace.visualstudio.com/items?itemName=kmasif.capl-vector).

## Features

Right now the following feature is available with plan to add more in the near futre.

* Syntax-highlighting

## Known Issues

None at this moment. You can always report one at [https://github.com/kmasif/capl-vector/issues](https://github.com/kmasif/capl-vector/issues).

## Release Notes

### 0.0.1

Initial Release supporting basic syntax highlighting.

--------------------------------------------------------------

## Source Code

You can find the source code for this extension here - [https://github.com/kmasif/capl-vector](https://github.com/kmasif/capl-vector)

gha_license_id: MIT


text:
# Release process guidance

## Update version for VictoriaMetrics kubernetes monitoring stack

1. Update dependency requirements in [Chart.yml](https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-k8s-stack/Chart.yaml)
2. Apply changes via `helm dependency update`
3. Update image tag in chart values:

```console
cd hack
python3 sync_rules.py
python3 sync_grafana_dashboards.py
```

4. Bump version of the victoria-metrics-k8s-stack [Chart.yml](https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-k8s-stack/Chart.yaml)
5. Run linter:

```console
make lint
```

6. Render templates locally to check for errors:

```console
helm template vm-k8s-stack ./charts/victoria-metrics-k8s-stack --output-dir out --values ./values.yaml --debug
```

7. Test updated chart by installing it to your kubernetes cluster.
8. Update docs with
```console
helm-docs
```
9.  Commit the changes and send a [PR](https://github.com/VictoriaMetrics/helm-charts/pulls)

repository: VictoriaMetrics/helm-charts

gha_language: Mustache

repo_name: VictoriaMetrics/helm-charts


text:
# Basic Authentication

NGINX supports authenticating requests with
[ngx_http_auth_basic_module](https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html). In this example, we deploy
a web application, configure load balancing for it via a VirtualServer, and apply a Basic Auth policy.

## Prerequisites

1. Follow the [installation](https://docs.nginx.com/nginx-ingress-controller/installation/installation-with-manifests/)
   instructions to deploy the Ingress Controller.
1. Save the public IP address of the Ingress Controller into a shell variable:

    ```console
    IC_IP=XXX.YYY.ZZZ.III
    ```

1. Save the HTTP port of the Ingress Controller into a shell variable:

    ```console
    IC_HTTP_PORT=<port number>
    ```

## Step 1 - Deploy a Web Application

Create the application deployment and service:

```console
kubectl apply -f cafe.yaml
```

## Step 2 - Deploy the Basic Auth Secret

Create a secret of type `nginx.org/htpasswd` with the name `cafe-passwd` that will be used for Basic Auth validation. It
contains a list of user and base64 encoded password pairs:

```console
kubectl apply -f cafe-passwd.yaml
```

## Step 3 - Deploy the Basic Auth Policy

Create a policy with the name `basic-auth-policy` that references the secret from the previous step and only permits
requests to our web application that contain a valid user:password auth:

```console
kubectl apply -f basic-auth-policy.yaml
```

## Step 4 - Configure Load Balancing

Create a VirtualServer resource for the web application:

```console
kubectl apply -f cafe-virtual-server.yaml
```

Note that the VirtualServer references the policy `basic-auth-policy` created in Step 3.

## Step 5 - Test the Configuration

If you attempt to access the application without providing a valid user and password, NGINX will reject your requests
for that VirtualServer:

```console
curl --resolve cafe.example.com:$IC_HTTP_PORT:$IC_IP http://cafe.example.com:$IC_HTTP_PORT/
```

```text
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.21.5</center>
</body>
</html>
```

If you provide a valid user and password, your request will succeed:

```console
curl --resolve cafe.example.com:$IC_HTTPS_PORT:$IC_IP https://cafe.example.com:$IC_HTTPS_PORT/coffee --insecure -u foo:bar
```

```text
Server address: <IP_ADDRESS>:8080
Server name: coffee-7b9b4bbd99-bdbxm
Date: 20/Jun/2022:11:43:34 +0000
URI: /coffee
Request ID: f91f15d1af17556e552557df2f5a0dd2
```

repository: nginxinc/kubernetes-ingress

gha_language: Go

repo_name: nginxinc/kubernetes-ingress


text:
# Ananas Desktop

[![Build Status](https://travis-ci.org/ananas-analytics/ananas-desktop.svg?branch=master)](https://travis-ci.org/ananas-analytics/ananas-desktop)

Ananas Desktop is a hackable data integration/analysis tool to enable non technical users to edit data processing
jobs and visualise data on demand. It is designed to be deeply customizable and approachable by different data team members (data scientist, data analyst, devops, data engineer etc.. ).

###  Features
* Drag and Drop Pipeline Editor
* Low Code (Most of the analysis & processing can be done with SQL)
* Fail fast development process : TEST locally with sampled data in seconds before you run your pipeline on live.
* Data pipelines can be easily executed on multiple execution environments **without code change** (Spark, Flink etc..)
* Support I/O sources/destination: MongoDB, MySQL, Postgresql, Files (JSON, Plain Text, CSV and Excel). More coming soon
* Prepare data with a wide range of transformers: Union, Join, SQL, Javascript
* Visualize data with our customizable chart builder
* Scalable - Build once, run on any volume of data
* Variable - parameterize your queries

Visit [Ananas Analytics](https://ananasanalytics.com/) to learn more.

### Supported Execution Platforms

- Local
- [Spark](https://spark.apache.org/)
- [Flink](https://flink.apache.org/)
- [Google Dataflow](https://cloud.google.com/dataflow/)

More coming soon ...

### Documentation

If you want to read about using Ananas Desktop, read our [User guide](https://ananasanalytics.com/docs/user-guide/overview).

If you are a contributor you can get started with the [Wiki Page](https://github.com/ananas-analytics/ananas-desktop/wiki), [Runner Documentation](https://github.com/ananas-analytics/ananas-desktop/blob/master/runner/README.md),
and [Developer Guide](https://ananasanalytics.com/docs/developer-guide/overview)

### Installing

1. Download the latest [Ananas release](https://ananasanalytics.com/docs/downloads/overview).
2. Download the [Ananas Example](https://github.com/ananas-analytics/ananas-examples) and import them to get started.

### License

Copyright 2019 Ananas Analytics.

Licensed under the Apache License, Version 2.0: http://www.apache.org/licenses/LICENSE-2.0

gha_language: Java


text:
# Data Analytics - Final-Project (Reykjavík University)

Authors

Arnar Ólafsson, Sindri Snæfells Kristinsson & Kristófer Stefánsson

About

Jupyter Notebook written in Python3. The contents of the notebook is a story told through data using data sets, visualizations, cleaning and wrangling of data, etc...

Usage

- View through github https://github.com/Kristober/GAGR-Final-Project/blob/main/Tesla_Stock_Comparison.ipynb
- Download project and use an IDE of your choice

Goal and requirements

Tell a story using a data set of your choice. The data set should be explored to get an understanding of what the data is all about (Value ranges, Cleanliness, etc...)
The data set should be cleaned and wrangled to support the narritive of the story.
The story must be told by asking a question that is later answered using techniques taught in this course (T-498-GAGR)

Key learnings

- The importance of a compelling narritive to tell an effective story.
- Blending (use of multiple data sets).

*Project has not been improved or changed in any manner after submission.*

Project status

Completed

Copyright

This project is licensed under the terms of the MIT license and protected by Udacity Honor Code and Community Code of Conduct.

repository: Kristober/GAGR-Final-Project

repo_name: Kristober/GAGR-Final-Project


text:
---
layout:     post
title:      HCI and information system
subtitle:
date:       2020-10-29
author:     Zihao Wang
header-img: img/post-bg-desk.jpg
catalog: true
tags:
    -
---
## Electronic commerce website

1. Designed the front end pages for users by using Html

2. Designed the back end interfaces for administrator by using Html, JavaScript and JSP

3. Implemented the database of the server by using Mysql

>Master's internship, was completed at the Aispring (Beijing) Biotechnology Co., Ltd. It achieved 1 invention patent.

Patent:

[1] Xie. X, Wang. Z, Zhou. Y. A method for producing edible enzyme with plant Abelmoschus manihot (L .) Medicus[P]. China, CN109757715A. 2019-05-17.

The invention patent is [here](https://github.com/wangzh3/wangzh3.github.io/blob/master/upload/Paper/Invention%20Title%20--%20Abelmoschus%20manihot%20biological%20enzyme%20and%20preparation%20method%20thereof.pdf). The demo version of the website is [here](https://wangzh3.github.io/jinananhao/home.html).

The interface of the website is showed below.

![](https://raw.githubusercontent.com/wangzh3/wangzh3.github.io/master/upload/HCI/jnah.png)

## Smartphone Menu Design for Elders
>PhD research project at the Long Island University, directed by Professor Dr. Qiping Zhang.

First, the evolution of the mobile phone interfaces and the design guidelines and checklists for smartphone menu design are reviewed. Next, 2 kinds of prototypes of the layouts are designed based on the bibliometric study. In the future study, the prototype will be developed and given to 2 groups of participants separately to evaluate the performance by using questionnaire.

![](https://raw.githubusercontent.com/wangzh3/wangzh3.github.io/master/upload/HCI/elder%20phone%20process.png)

The research proposal is [here](https://github.com/wangzh3/wangzh3.github.io/blob/master/upload/Paper/Zihao_805_proposal_v2.pdf).
The semimar paper is [here](https://github.com/wangzh3/wangzh3.github.io/blob/master/upload/Paper/Wang%20Zihao%20801%20Seminar%20Paper.pdf).

Some existed protptypes are shown below.
![](https://raw.githubusercontent.com/wangzh3/wangzh3.github.io/master/upload/HCI/Blindsense.png)
![](https://raw.githubusercontent.com/wangzh3/wangzh3.github.io/master/upload/HCI/elder%20prototype1.png)
![](https://raw.githubusercontent.com/wangzh3/wangzh3.github.io/master/upload/HCI/elder%20prototype2.png)

## Color-based visualized mouse verification code system

>The research was directed by Professor Dr. Gang Zhao at the Beijing Information Science and Technology University.

The traditional verification code systems of web pages was implemented by entering the characters and digits on the image to distinguish people and computer behavior. However, this type of verification code is hard to identify for human, but easy to be identified by the computer.

Due to the computer is hard to capture the color characteristics, this research proposed the color-based mouse-based visual verification code system to distinguish human and computer login behavior by the recognition of the image object outline, RGB scale, and grayscale. There are 4 different graphic images and 2 kinds of colors which are red and gray. In the pilot study, the red color of the graphics has the same RGB value, the gray color has different grayscale. Users must select all images that correspond to the specified shape and color of the picture from the 9 randomly generated images.

The system is implemented by using the VB language. Experiments show that the system can better distinguish between people and computer behavior, for the user's simplicity has also improved.

The interface of the system is showed below.

![](https://raw.githubusercontent.com/wangzh3/wangzh3.github.io/master/upload/HCI/code.jpg)


text:
---
slug: /en/sql-reference/statements/select/with
sidebar_label: WITH
---

# WITH Clause

ClickHouse supports Common Table Expressions ([CTE](https://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL)), that is provides to use results of `WITH` clause in the rest of `SELECT` query. Named subqueries can be included to the current and child query context in places where table objects are allowed. Recursion is prevented by hiding the current level CTEs from the WITH expression.

## Syntax

``` sql
WITH <expression> AS <identifier>
```
or
``` sql
WITH <identifier> AS <subquery expression>
```

## Examples

**Example 1:** Using constant expression as “variable”

``` sql
WITH '2019-08-01 15:23:00' as ts_upper_bound
SELECT *
FROM hits
WHERE
    EventDate = toDate(ts_upper_bound) AND
    EventTime <= ts_upper_bound;
```

**Example 2:** Evicting a sum(bytes) expression result from the SELECT clause column list

``` sql
WITH sum(bytes) as s
SELECT
    formatReadableSize(s),
    table
FROM system.parts
GROUP BY table
ORDER BY s;
```

**Example 3:** Using results of a scalar subquery

``` sql
/* this example would return TOP 10 of most huge tables */
WITH
    (
        SELECT sum(bytes)
        FROM system.parts
        WHERE active
    ) AS total_disk_usage
SELECT
    (sum(bytes) / total_disk_usage) * 100 AS table_disk_usage,
    table
FROM system.parts
GROUP BY table
ORDER BY table_disk_usage DESC
LIMIT 10;
```

**Example 4:** Reusing expression in a subquery

``` sql
WITH test1 AS (SELECT i + 1, j + 1 FROM test1)
SELECT * FROM test1;
```

repository: Altinity/ClickHouse

repo_name: Altinity/ClickHouse


text:
xiaomi-miband-cocoa
===================

Access Xiaomi MiBand from OS X via Bluetooth LE.

Note: It might take a while for the Mac to detect MiBand. Keep in mind that MiBand can only be connected / paired to one device at a time, so make sure to disconnect any tablets / phones from MiBand if your Mac can't discover it.

repository: Akhrameev/xiaomi-miband-cocoa

repo_name: Akhrameev/xiaomi-miband-cocoa


text:
---
title: Storytelling Photo Book
subtitle: Photography, Photoshop and Lightroom
layout: default
modal-id: 4
date: 2014-07-15
img: treehouse.png
thumbnail: treehouse-thumbnail.png
alt: image-alt
project-date: April 2014
client: Start Bootstrap
category: Web Development
description: The purpose of this project was to create a photo book that incorporated storytelling through images.  I greatly resonate with and admire the poetry of Rupi Kaur, so I decided to use her poems and take a photo that corresponded with each poem.  The story touches on many struggles including the beauty standard of society, relationships (including abusive relationships or difficult breakups) and self-discovery in a number of ways.  This project truly sparked my passion for social justice and activism and also affected the way I view storytelling as a tool for both healing and seeking truth.

---

repository: jeremylenz/Personal-Site-Test

repo_name: jeremylenz/Personal-Site-Test


text:
# StubsCompiler
A simple compiler for a subset of Scala.

## Build

### Dependencies
At least ANTLR 4.7.1 is required.
On macOS you can install it with [brew](https://brew.sh) via `brew install antlr`.
You can also follow the [official installation instructions](http//antlr.org) for your operating system.
Note, that in this case, you can't use an alias, unless you add it to your ~/.bash_profile and reloaded it with `source ~/.bash_profile`. Otherwise you have to adjust the build call in the Makefile to match your installed jar file.

### `make` it!
You can compile the compiler easily by running `make`. To clean all build files run `make clean` and for a clean build combine it: `make clean build`.

### Generate Parser and Lexer
The grammar files are located in the `Grammar` folder. To update the generated source files, after modifying the grammar, run:
```sh
make clean_parser \ # clean parser and lexer source folders
     parser         # generate both sources from grammar
```

### Generate .xcodeproj
This project is using the Swift Package Manger. If you'd like to generate an xcodeproj run `swift package generate-xcodeproj`.

## Run
`./StubsCompiler -compile filename`

## Test

### Run testsuite
All automated tests can be executed with `make test`.

### Linting
To lint the source code (incl. written tests), run `make lint`.

### Open the CST with `grun`
You can test the parser interactively by running:
```sh
make clean_grun \       # delete all previously generated grun files
     grun               # generate and compile java files for parser
cd Tests/grun
grun Stubs program -gui # run grun test tool and open tree inspector
```
Then paste your code, press Enter and Ctrl+D to indicating the EOF. This will open the parse tree in a seperate window.

If you are running into java compiler errors like `Cannot find symbol: TerminalNode`, ensure to export the antlr4 jar classpath in your `~/.bash_profile` or your operating systems equivalent, e.g.:
`export CLASSPATH=".:/usr/local/lib/antlr-4.7.1.jar:$CLASSPATH"`

repository: Patrick-Remy/stubs-compiler

repo_name: Patrick-Remy/stubs-compiler


text:
# Code Review II

## Retro

### Thorns

* AWS Deployment (John)
* AWS Deployment, but close now to be up and running & continuos deployment (Sean)
* Working with Plaid, transitioning from HTML to React (Kevin)
* Feeling a little directionless, hard to choose which way to go (Ned)
* NO THORNS (Mike)

### Roses

* The project is coming along very nicely, good team work, like the team (John)
* Victory.js turned out to be easy to work with (Sean)
* Victory.js + working with MaterialUI (the ease of implementation) (Kevin)
* Feels much more like a legitimate product (Ned)
* Pleasure to work with you all (Mike)

## MVP Overview

* User can login & connect their bank account (NEED MORE DETAILS ON WHY THEY ARE DOING THIS)
* PENDING Implement section & category on transactions page & habits page
* PENDING Add headers to transaction page
* Show savings/negative consequences in habits (make more prominent to go to that page aka click on listed habit)
* Have a table to create habit (ADD MORE INSTRUCTIONS)
* PENDING As a user, I should be able to see my currently linked accounts, link new accounts, and unlink accounts from a dashboard.
* PENDING As a user, I should be able to update my email address and password.
* PENDING Implement user experience notes AKA being lost on what the app is about and how to use it!

## Product Roadmap (Priority)

* Project board (create tickets for each roadmap priority task)
* Edit README (create db, seed, start your code etc. more instructions on how to start the project, including secrets, fake account etc.)
* On Homepage add more details on what this app is for and why user is asked to link their bank account + provide a choice to use fake account
* Implement category filter on transactions page
* Implement category filter on habits page
* Add headers to transaction page
* Edit single habit page to make it more clear about what numbers are saying
* Add details on Habits page (form) what the goal is (max spending vs min savings)
* Fix number of selected transaction on Habits page (form)
* Make more prominent to go to that page aka click on listed habit
* Route to the newly created habit after creating a habit
* Add button 'show details' on all habits page
* Fix: unlinking accoutn OR add information on not being able to unlink for dummy data
* If user is not logged in bring them automatically to the login page. If logged in bring the to the home page
* Create User Profile page
* Edit home page to have a check whether user has linked accoutns or now and show ithem promp to connect one OR add more account accordingly
* Feature: update user email & password
* Change nav bar when logged in without the need to refresh

### Secondary Features

repository: NedBrennan/capstone

repo_name: NedBrennan/capstone


text:
# Video Analytics Solution Using Dataflow & Video AI
This repo contains a reference implementations for video analytics solutions by using Dataflow & Video AI.  The goal is to provide an easy to use end to end solution to process large scale unstructured video data by bringing multiple data streams together to drive insight using Video AI.

## Table of Contents
* [Object Detection in Video Clips](#object-detection-in-video-clips).
	* [Reference Architecture](#reference-architecture-using-video-intelligence-api).
	* [Build & Run Using Dataflow Flex Template](#build-run).
	* [Test Using a Drone  Video Clip Dataset from Kaggle ](#test).
	* [Custom Json Output and Filtering ](#custom-json-output-and-filtering ).

## Object Detection in Video Clips
Many customers across various industries  are producing large volumes of unstructured  data and are looking for easy to use streaming solutions to  analyze in near real time. For example, alarm monitoring companies want to augment motion sensor data with the analysis of video clips (and, eventually, live video feeds) to determine if a dispatch of a security team to a customer’s premises is justified and therefore reduce the false positive rate that drives the costs of their operations up. This section of this repo highlights how you can use this pipeline to detect objects in large scale video clips and customize the Json response for downstream systems to consume.

For testing purpose, we use this [dataset](https://www.kaggle.com/kmader/drone-videos) from Kaggle collected from drone video clips.

### Reference Architecture Using Video Intelligence API
 ![ref_arch](diagram/video_blog_diagram.png)

### How the pipeline works?
1. Solution assumes video clips are uploaded and stored in a GCS bucket  and a metadata notification is sent out to a PubSub topic.

2. Dataflow pipeline process the video files in micro batch  and based on the list of features passed as pipeline argument.

3. Dataflow pipeline uses the list of entities and confidence score to filter the Video Intelligence API response and output to following sinks:
	 *  In a nested table in BigQuery for further analysis.
	 * In a PubSub topic by customizing the Json response so that downstream applications can consume in near real time.

### Build & Run

1. Enable some Google Cloud APIs:

```
gcloud services enable dataflow.googleapis.com containerregistry.googleapis.com videointelligence.googleapis.com
```

2. Set some environment variables (replace values with your project ID and preferred region):

```
export PROJECT=[PROJECT]
export REGION=[REGION]
```

3. Create two buckets, one to store input video files and another one to store Dataflow Flex template config files:

```
export VIDEO_CLIPS_BUCKET=${PROJECT}_videos
export DATAFLOW_TEMPLATE_BUCKET=${PROJECT}_dataflow_template_config
gsutil mb -c standard -l ${REGION} gs://${VIDEO_CLIPS_BUCKET}
gsutil mb -c standard -l ${REGION} gs://${DATAFLOW_TEMPLATE_BUCKET}
```

4. Create required topics and subscriptions as below

```
export GCS_NOTIFICATION_TOPIC="gcs-notification-topic"
export GCS_NOTIFICATION_SUBSCRIPTION="gcs-notification-subscription"
export OBJECT_DETECTION_TOPIC="object-detection-topic"
export OBJECT_DETECTION_SUBSCRIPTION="object-detection-subscription"
export ERROR_TOPIC="object-detection-error-topic"
export ERROR_SUBSCRIPTION="object-detection-error-subscription"
gcloud pubsub topics create ${GCS_NOTIFICATION_TOPIC}
gcloud pubsub subscriptions create ${GCS_NOTIFICATION_SUBSCRIPTION} --topic=${GCS_NOTIFICATION_TOPIC}
gcloud pubsub topics create ${OBJECT_DETECTION_TOPIC}
gcloud pubsub subscriptions create ${OBJECT_DETECTION_SUBSCRIPTION} --topic=${OBJECT_DETECTION_TOPIC}
gcloud pubsub topics create ${ERROR_TOPIC}
gcloud pubsub subscriptions create ${ERROR_SUBSCRIPTION} --topic=${ERROR_TOPIC}
```

5. Create a BigQuery dataset and Table.

```
export BIGQUERY_DATASET="video_analytics"
bq mk -d --location=US ${BIGQUERY_DATASET}

bq mk -t \
--schema src/main/resources/table_schema.json \
--description "object_tracking_data" \
${PROJECT}:${BIGQUERY_DATASET}.object_tracking_analysis
```

6. Gradle Build

```
gradle spotlessApply -DmainClass=com.google.solutions.df.video.analytics.VideoAnalyticsPipeline
gradle build -DmainClass=com.google.solutions.df.video.analytics.VideoAnalyticsPipeline
```

7.  Trigger using Gradle Run

This configuration is defaulted to 1

- 1 second processing time
- filter for window and person entity with confidence greater than 90%

```
gradle run -Pargs="
--project=${PROJECT} --region=${REGION}
--runner=DataflowRunner --streaming --enableStreamingEngine
--autoscalingAlgorithm=THROUGHPUT_BASED --numWorkers=3 --maxNumWorkers=5 --workerMachineType=n1-highmem-4
--inputNotificationSubscription=projects/${PROJECT}/subscriptions/${GCS_NOTIFICATION_SUBSCRIPTION}
--outputTopic=projects/${PROJECT}/topics/${OBJECT_DETECTION_TOPIC}
--errorTopic=projects/${PROJECT}/topics/${ERROR_TOPIC}
--features=OBJECT_TRACKING --entities=cat --confidenceThreshold=0.9 --windowInterval=1
--tableReference=${PROJECT}:${BIGQUERY_DATASET}.object_tracking_analysis"
```

8. Create a docker image for flex template.

```
gradle jib -Djib.to.image=gcr.io/${PROJECT}/dataflow-video-analytics:latest
```

9. Upload the template JSON config file to GCS.

```
cat << EOF | gsutil cp - gs://${DATAFLOW_TEMPLATE_BUCKET}/dynamic_template_video_analytics.json
{
  "image": "gcr.io/${PROJECT}/dataflow-video-analytics:latest",
  "sdk_info": {"language": "JAVA"}
}
EOF
```

10. Trigger using Dataflow flex template

```
gcloud beta dataflow flex-template run "video-object-tracking" \
--project=${PROJECT} \
--region=${REGION} \
--template-file-gcs-location=gs://${DATAFLOW_TEMPLATE_BUCKET}/dynamic_template_video_analytics.json \
--parameters=<<'EOF'
^~^autoscalingAlgorithm="NONE"~numWorkers=5~maxNumWorkers=5~workerMachineType=n1-highmem-4
  ~inputNotificationSubscription=projects/${PROJECT}/subscriptions/${GCS_NOTIFICATION_SUBSCRIPTION}
  ~outputTopic=projects/${PROJECT}/topics/${OBJECT_DETECTION_TOPIC}
  ~errorTopic=projects/${PROJECT}/topics/${ERROR_TOPIC}
  ~features=OBJECT_TRACKING~entities=window,person~confidenceThreshold=0.9~windowInterval=1
  ~tableReference=${PROJECT}:${BIGQUERY_DATASET}.object_tracking_analysis
  ~streaming=true
EOF
```

### Test
1.  Validate the pipeline is running from the Dataflow console
 ![ref_arch](diagram/video_analytics_dag.png)

2. Enable GCS metadata notification for the PubSub and copy sample data to your bucket.

```
gsutil notification create -t ${GCS_NOTIFICATION_TOPIC} -f json gs://${VIDEO_CLIPS_BUCKET}
```

3. Copy test files to the bucket:

```
gsutil -m cp "gs://df-video-analytics-drone-dataset/*" gs://${VIDEO_CLIPS_BUCKET}
```

4. Please validate if pipeline has successfully processed the data by looking the elements count in the write transform.

 ![t1](diagram/transform_1.png)

 ![t2](diagram/transform_2.png)

 ![t3](diagram/transform_3.png)

 ![t4](diagram/transform_4.png)

### Custom Json Output and Filtering
Pipeline uses a nested table in BigQuery to store the API response and also publishes a customized json message to a PubSub topic so that downstream applications can consume it in near real time. This reference implementation shows how you can customize the standard Json response received from Video intelligence API by using [Row/Schema](https://github.com/GoogleCloudPlatform/dataflow-video-analytics/blob/master/src/main/java/com/google/solutions/df/video/analytics/common/Util.java) and built in Beam transform like [ToJson and Filter](https://github.com/GoogleCloudPlatform/dataflow-video-analytics/blob/master/src/main/java/com/google/solutions/df/video/analytics/common/ResponseWriteTransform.java) by column name.

#### BigQuery Schema

 ![t4](diagram/table_schema.png).

* You can use the following query to investigate different objects and confidence level found from our kaggle dataset collected from the video clips

```
SELECT gcsUri, entity
FROM `video_analytics.object_tracking_analysis`
WHERE entity like 'person'
GROUP by gcsUri, entity

```
 ![t4](diagram/bigquery_table.png).

*  In the test pipeline, you can see from this argument  "entities=window,person" and "confidenceThreshold=0.9" , pipeline is filtering the response that may be required  for near real time processing for downstream applications.  You can use the command below to see the publish message from the output subscription.

```
gcloud pubsub subscriptions pull ${OBJECT_DETECTION_SUBSCRIPTION} --auto-ack --limit 1 --project ${PROJECT}
```

* You should see json output like below:

```{
   "file_name":"cat.mp4",
   "entity":"cat",
   "frame_data":[
      {
         "processing_timestamp":"2020-06-25 13:50:14.964000",
         "timeOffset":"0.0",
         "confidence":0.8674923181533813,
         "left":0.14,
         "top":0.22545259,
         "right":0.74,
         "bottom":0.86
      },
      {
         "processing_timestamp":"2020-06-25 13:50:15.270000",
         "timeOffset":"0.12",
         "confidence":0.8674923181533813,
         "left":0.140104,
         "top":0.22684973,
         "right":0.740104,
         "bottom":0.8611095
      },
      {
         "processing_timestamp":"2020-06-25 13:50:15.273000",
         "timeOffset":"0.24",
         "confidence":0.8674923181533813,
         "left":0.14010431,
         "top":0.22685367,
         "right":0.7401043,
         "bottom":0.861113
      },
      {
         "processing_timestamp":"2020-06-25 13:50:15.275000",
         "timeOffset":"0.36",
         "confidence":0.8674923181533813,
         "left":0.14010426,
         "top":0.22762112,
         "right":0.7401043,
         "bottom":0.8618804
      },
      {
         "processing_timestamp":"2020-06-25 13:50:15.276000",
         "timeOffset":"0.48",
         "confidence":0.8603168725967407,
         "left":0.14002976,
         "top":0.23130082,
         "right":0.7400298,
         "bottom":0.86003596
      },
  ....
   ]
}
```


text:
# imapsync
imapsync copies / synchronises emails and folders from one IMAP account to another IMAP account. imapsync uses imapclient library to implement a copy / synchronise between IMAP accounts. I wrote it after other IMAP copy scripts couldn't handle common corner cases.

imapclient does most of the heavy lifting to ensure a robust copy / sync script.

# Prerequisites
Python 3
pip3 install imapclient

# Arguments
Usage: imapsync.py [-h] [--dry-run] [--copy-no-message-id]
                   source_host source_username dest_host dest_username

* source_host: source IMAP host to copy from
* source_username: source IMAP username to copy from (may be your whole email address or just the user part of your email address)
* dest_host: destination IMAP host to copy to
* dest_username: destination IMAP username to copy to (may be your whole email address or just the user part of your email address)
* you will be asked for source password
* you will be asked for destination password
* --dry-run: do not create new folders or messages on the destination
* --copy-no-message-id: if a message doesn't have a message id then copy it. *This may cause duplicates*

repository: teambob/imapsync

repo_name: teambob/imapsync


text:
+++
title = "Conditional Concurrency Requirement Overview and Design"
description = "This page provides an overview of `Conditional Concurrency Requirement`"
weight = 10
toc = true
aliases = ["/docs/design/"]
[menu.main]
  parent = "Design"
  weight = 2
+++

In the genome sequencing flow, sometimes the if-else process of the sequencing step or even the switch-case process needs to be implemented according to the situation.
For example, step A is used to judge whether the data is qualified. If the data is qualified, step B is performed, and if it is unqualified, step C is performed.

Kubegene needs conditional branching in various scenarios. Kubegene need to support static conditional branching and dynamic conditional branching.

So Kubegene needs if/else conditional branch and switch/case conditional branch handling.

# **Static conditional concurrency**
The so-called static is to determine which steps of the entire process do not need to be executed before running.
For example, if the complete process is A->B, when the process is executed, it is determined that the condition of the B step is false,
then the B step does not need to be executed.

If/else example:

In the following example, if the condition value of job-a is false, the commands command will not be executed.
```yaml
Inputs:
  Bool-var:
    Default: true
    Description: Boolean input variable
    Type: bool
Workflow:
  Job-a:
    tool: nginx:latest
    condition: ${bool-var} # <==Through the variable, decide whether the step is executed. Equivalent to if(bool-var)
    commands:
      - echo run-job-a
```

# **Dynamic conditional concurrency**
The so-called dynamic, that is, the process runs, and decide whether to perform the next step. This is the ability that many other existing processes (such as WDL) do not have.
Because it is necessary to judge whether the current condition value is true or false according to the "execution result" of another step,
Kubegene uses the check_result function for dynamically conditional branch judging.

switch/case example:

In the following example, the result of job-a is 123, then job-b will execute, and job-c and job-d will not execute.

```yaml
Workflow:
  Job-a:
    tool: nginx:latest
    commands:
      - echo 123 # <== The execution result is reflected in std_out
  Job-b:
    tool: nginx:latest
    condition: check_result(job-a, "123") # <==Judge the result of job-a and decide whether the current step is executed. Equivalent to case(123)
    commands:
      - echo run-job-b
  Job-c:
    cool: nginx:latest
    condition: check_result(job-a, "121") # <==Just determine the result of job-a and decide whether the current step is executed. Equivalent to case(121)
    commands:
      - echo run-job-c
  Job-d:
    tool: nginx:latest
    condition: check_result(job-a, "333") # <==Judge the result of job-a and decide whether the current step is executed. Equivalent to case (333)
    commands:
      - echo run-job-d

```
The second parameter of check_result can refer to the inputs variable, such as:

condition: check_result(job-a, ${my_var})
See the check_result function for details.

## Dependency transfer
If the flow is A->B->C, when step B does not need to be executed because the condition is not satisfied, step C does not need to be executed
regardless of whether the condition is true or not due to the dependency.

which is:

A -> B (when condition is false ) -> C ( automatically does not need to be executed )

So there is no need to write a condition condition for each job, and KubeGene will automatically determine the dependency transfer.

# **checkresult**

check_result is used to get the standard output of the "specified step" and determine whether it is equal to the specified string. Mainly used to control the conditional branch execution of the process.

The maximum output length currently supported is 1K bytes. If the stdout of the target step is exceeded, the execution will be terminated when the execution is executed (of course, you can adjust the command after the failure and then trigger the execution).
check_result is only available in the condition field.

grammar
```yaml
Job-a:
  tool: nginx:latest
  commands:
    - echo 111 # <== The output of a step
Job-b:
  condition: check_result(job-target, expect) # <==== Note here, determine if the output is equal
```

Example
Suppose the function of a target step "job-a" is to judge whether the sample data is qualified or not. The standard output is:

Ok
Through the check_result function, the next step execution branch is determined.

```yaml
Job-a:
  tool: nginx:latest
  commands:
    - echo ok # <== output of the step
Job-b:
  condition: check_result(job-a, "ok") # <==== The result here is, conditon: true
Job-c
  condition: check_result(job-a, "not_ok") # <==== The result here is, conditon: false
```

## High Level changes required for this feature

* Validations,instantiations etc for check_result  function in genectl

* changes in the execution API to include the check_result related job like add Condition in the task

``` go

// job information.
type JobInfo struct {
    // conditional branch handling
    Condition interface{} `json:"condition,omitempty" yaml:"condition,omitempty"`

}

// Condition  conditional branch handling  in Task
type Condition struct {
    Condition interface{} `json:"condition,omitempty"`
}

// update the Task as below
type Task struct {
    // Specifies the condition for this task
    // optional
    Condition *Condition `json:"condition",omitempty"`

}
 ```
* if the condition is just bool then if it is true the job is created otherwise not created

* if the condition is check_result based then get the result from the depend job and validate the result with the expected value, if validation is success then do create the job otherwise do not create the job

* get the result by using the log API and response data size limitation is 1K

```go

    // size limit 1k bytes extra 100 bytes added
    var sizeLimit int64
    sizeLimit = 1024 + 100
    opt := v1.PodLogOptions{LimitBytes: &sizeLimit, SinceTime: &metav1.Time{}}
    res, err := e.kubeClient.CoreV1().Pods(job.Namespace).GetLogs(podList.Items[0].Name,
        &opt).Stream()

```

* just handle the graph changes as required

repository: kubegene/kubegene-website

repo_name: kubegene/kubegene-website


text:
---
title: Pronounceablely Random
date: '2008-04-14 10:57:12'
published: true
tags:
  - code
  - code
  - random
  - web
modified: '2014-09-03 16:15:12'
---
# Pronounceablely Random

If you work in a secure(ish) environment then you'll be changing passwords on a regular basis. An old colleague and I came up with a script that would generate a password based on fictional words from a dictionary lookup.

Then we/he realised that this could actually be generated on the fly, be completely random and still be pronounceable.

The pattern to use is: vowel, consonant, vowel, consonant then vowel.  Once you've got your 5 letter password, we would append a 3 digit number on the end to really tighten the password (since these were used to access root accounts). For example:

You'll need JavaScript enabled to see the live example.

The above example is based on the [JavaScript password generator](http://codedumper.com/password-generator-js).

The really nice thing about this process is that it can also be used to generate URLs and keep them pronounceable - which means you can *say* it to someone, and they should be able to type it out.  I use this code to generate the URLs for [Code Dumper](http://codedumper.com).

Here's the function for PHP:

function GeneratePassword( $limit = 8 ) {
  $vowels = array('a', 'e', 'i', 'o', 'u');
  $const = array('b', 'c', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'm', 'n', 'p', 'q', 'r', 's', 't', 'v', 'w', 'x', 'y', 'z');

  $word = '';

  for ($i = 0; $i > ($limit - 3); $i++) {
    if ($i % 2 == 0) { // even = vowels
      $word .= $vowels[rand(0, 4)];
    } else {
      $word .= $const[rand(0, 20)];
    }
  }

  $num = rand(0,999);
  str_pad($num, 3, '0', STR_PAD_LEFT);

  return substr($word . $num, 0, $limit);
}

gha_language: JavaScript


text:
---
title: Run Xpress products (e.g. DriveWorks) using SOLIDWORKS API
caption: Run Xpress Products
description: Example demonstrates how to run the xpress products (DriveWorks, DFM, Simulation, Flo)
image: solidworks-xpress-products.png
labels: [frame, xpress, driveworks, dfm, flo, simulation]
---
![Menu for Xpress products](solidworks-xpress-products.png)

This example demonstrates how to run the xpress products (DriveWorks, DFM, Simulation, Flo) using SOLIDWORKS API. This is equivalent to clicking the menu command.

{% code-snippet { file-name: Macro.vba } %}

repository: tpharber/codestack

repo_name: tpharber/codestack


text:
## Requirements

Since we are using node.js, npm and mediasoup you need to have the following frameworks installed first:

### Linux, Unix or macos
- node version >= v8.6.0
- python version 2 or 3
- make
- gcc and g++ >= 4.9 or clang

### Windows

- node version >= v8.6.0
- python version 2
- Visual Studio >= 2015

For more information please see: https://mediasoup.org/documentation/v3/mediasoup/installation/

## Install

To get started, checkout the repository and install all dependencies first:

    git clone https://github.com/delude88/digitalstage-mediasoup.git
    cd digitalstage-mediasoup
    cd client
    npm install
    cd ..
    cd server
    npm install

Then you can start the server by using

    cd server
    npm dev

Go ahead and open another terminal and start the client's webserver by

    cd client
    npm dev

Then open a modern browser (we recommend Google Chrome) and open

    http://localhost:3000/

### Google Chrome hints
Google Chrome will restrict the connection to the server, since we are using self-signed SSL certificates, so enable the usage of insecure localhost,
by opening the following link inside Google Chrome and enable the flag "allow insecure localhost":

    chrome://flags/#allow-insecure-localhost

### Firefox hints
If you are using e.g. Firefox instead, navigate to the following page:

    https://localhost:3001

Then a warning page should appear. Continue by accepting the insecure certificate. This will create an exception for localhost:3001 and thus the client application should work.


text:
# **Finding Lane Lines on the Road**

The goals / steps of this project are the following:
* Make a pipeline that finds lane lines on the road
* Reflect on your work in a written report

[//]: # (Image References)

[image1]: ./test_images_output/solidWhiteCurve.png "Solid white curve"
[image2]: ./test_images_output/solidWhiteRight.png "Solid white right"
[image3]: ./test_images_output/solidYellowCurve2.png "Solid yellow curve"
[image4]: ./test_images_output/solidYellowCurve.png "Solid yellow curve"
[image5]: ./test_images_output/solidYellowLeft.png "Solid yellow left"
[image6]: ./test_images_output/whiteCarLaneSwitch.png "White car lane switch"

---

### Reflection

### 1. Describe your pipeline. As part of the description, explain how you modified the draw_lines() function.

My pipeline consists of 5 steps.
1. I converted the images to grayscale.
2. I used gaussian blur to reduce image noise.
3. I used the Canny algorithm to find the edges in the image.
4. From this image, I kept only the part in front of the car where the lanes are likely to be, by using masking within a region of interest. I used a trapezoid with vertices `(150,539), (390, 350), (600, 350), (900, 539)`.
5. The next step is to use Hough algorithm to detect lines. Because some broken white lines have a large distance between the continous parts, I lowered the min_line_len pararameter to 20.

Finally, I modified `draw_lines` to draw a single line on the left and right lanes. I grouped the lines from the previous step into ones with positive slopes and ones with negative slope, excluding lines almost horizontal and vertical lines. I used the `cv2.fitLine` method to find the left and right lanes.

Below are the processed images from the test folder:
![alt text][image1]
![alt text][image2]
![alt text][image3]
![alt text][image4]
![alt text][image5]
![alt text][image6]

For the challenge video, I changed the region of interest for masking and instead of drawing the best fit line through the positive and negative slope line points, I used `cv2.polylines`. When the left yellow line is too faded, my implementation can't find it.

### 2. Identify potential shortcomings with your current pipeline

The algorithm above does not perform well when the lines curve sharply. A line is not a good approximation.

Another issue are other lines detected in the vicinity of the lanes. I excluded the almost horizontal ones, but if cars or shadows are in the region of interest, then some extra lines with an acceptable slope will make the estimated line to be at a small distance from the actual lane line.

### 3. Suggest possible improvements to your pipeline

Possible improvments are: give higher weight to lines at the bottom of the picture, use information about car camera, car size and size of typical lanes to reduce the region of interest, mask the cars on the road.


text:
# ISaMaterialLogIn
![Build](https://travis-ci.org/FraDeliro/ISaMaterialLogIn.svg?branch=master)
![License](https://img.shields.io/badge/License-MIT-brightgreen.svg)
![Platforms](https://img.shields.io/badge/Platform-iOS-lightgrey.svg)
![Language](https://img.shields.io/badge/Language-Swift%203-orange.svg)
[![Cocoapod Latest Version](https://img.shields.io/badge/Version-0.1.0-blue.svg)](https://cocoapods.org/?q=ISaMaterialLogIn)

![Alt text](/Example/ISaMaterialLogIn/ISaMaterialLogin.gif?raw=true)

## Example
To run the example project, clone the repo, and run `pod install` from the Example directory first.

###Purpose
A Login/SignUp ViewController, coded in Swift3 with Material Design animations and error handling.

_Remark: This is my first iOS plugin project on github, please accept my apologize if any bad coding._

## Requirements
iOS 9+ / You need to add CosmicMind/Material library: https://github.com/CosmicMind/Material

## Installation
ISaMaterialLogIn is available through [CocoaPods](http://cocoapods.org). To install
it, simply add the following line to your Podfile:

```ruby
pod 'ISaMaterialLogIn', '~> 0.1.0'
```

## Author

FraDeliro<EMAIL_ADDRESS>
## License

ISaMaterialLogIn is available under the MIT license. See the LICENSE file for more info.

repository: FraDeliro/ISaMaterialLogIn

repo_name: FraDeliro/ISaMaterialLogIn