Architecture Behind Sila Ethereum Transactions

https://silamoney.com/2019/07/08/using-aws-lambda-sqs-with-web3/
https://silamoney.com/2019/07/08/using-aws-lambda-sqs-with-web3-2/

Major components

1. DynamoDB to store the nonce associated with ethereum addresses authorized to send ethereum smart contract transactions
2. Lambda functions triggered by SQS events for SilaToken issuance, redemption, and transfer messages
3. Ethereum RPC EC2 servers running Parity Ethereum client
4. AWS Secrets Manager to store private keys being used to sign the transactions
5. Orchestrator as a bridge between REST API, ACH, and ethereum transactions. Orchestrator is a piece of code that handles the transaction state and reroutes them to right queue.
6. SQS as an interface between different services like REST API, ACH, Ethereum issuance, redemption, and transfers.

Transaction Lifecycle

Messages for SilaToken issuance, redemption, and transfer comes in through Sila APIs. Dependent on the action (issue, redeem, and transfer), the message is sent to the relevant queue by Orchestrator, which in turn triggers the send transaction Lambda function.

That sends the transaction, signed by Sila’s authorized address, to Ethereum node and increases the nonce in the database by one, for subsequent transactions. The message is deleted from the ethereum transaction queue and sent to the ethereum pending queue with the transaction hash and nonce, then sent with the block number appended in the message history. Replace and check for transaction send failure if there is a bad RPC connection.

Constructing a Transaction:

Sending a transaction:

Nonce management

After experimenting with several ways to manage the authorized address nonce we settled on storing it in a database, as it is faster to retrieve and update there than making a Web3 call to the RPC server and waiting for the transaction to be mined. It has its pitfalls, however. For example, subsequent transactions can get stuck until previous transactions have been mined, but that’s why we have three Lambda functions that are watching just the pending transactions — and we’ll discuss how to handle pending ethereum smart contract transactions in the next section.

Nonce management is not as straightforward, as we have three Lambda functions that can send transactions. In our case we have conditions in place that are dependent on message history.

Deciding gas price & gas limit

Gas limit is set based on the amount of computation involved in the smart contract function call. However we can play around with the gas price to make sure transactions are being mined in the desired time. We use a modified version of eth_gas_station engine to decide the gas price, based on the network mining requirements.

Handling Transactions in Pending Queue

Let’s dive deeper into the three Lambda functions that are watching the pending queue . . .

1. Check pending transactions for success or a fail

Previously we discussed how we appended the tx_hash, nonce and sent_at_blockNumber in the message history, we use tx_hash and web3 module to get the transaction status. The transaction status can be 0,1, or null depending on if the transaction has been mined successfully. Status 0 and 1 both result in a nonce increment for the authorized address, as the transaction was mined in some block. If the status is 0, which means the transaction failed, we retry the transaction by sending it back to the transaction queue. Each transaction is restricted to a maximum of 3 retries, after which it is dumped into Orchestrator. If the status is 1 which means that the transaction was successful, a message with success update is sent to Orchestrator.

2. Replacing stuck transactions

If the transaction hash gets a null and transaction has been pending in the node memory pool for a long time, consider how we appended the sent_at_block number and nonce in the message history. We get the current block number, using Web3, and compare the difference; if the difference is more than 80 blocks (and the difference can be set to higher or lower), which means the transaction has been pending for 80 blocks, we replace the transaction with a higher gas price, keeping the nonce value the same as in the message.

3. Handling transaction send failures

If you play with Ethereum long enough you will have certain cases where you are unable to find the sent transaction in the node memory pool. This means the transaction never hit the Ethereum RPC server, but we have another Lambda function that will redirect the transaction message to the queue.

Like this article? Share it with your network!

About Sila

Sila provides Banking and Payments Infrastructure-as-a-Service for teams building the next generation of financial products and services. Our banking API replaces the need for integrating with legacy financial institutions saving you months of development time and thousands in legal and regulatory expenses.

haproxy failover backup server

https://www.haproxy.com/blog/failover-and-worst-case-management-with-haproxy/

Normal backup servers： In this case, s3 will be used first, until it fails, then s4 will be used.

frontent ft_app
 bind 10.0.0.1:80
 default_backend bk_app_main
backend bk_app_main
 server s1 10.0.0.101:80 check
 server s2 10.0.0.102:80 check
 server s3 10.0.0.103:80 check backup
 server s4 10.0.0.104:80 check backup

Multiple backup servers： In this case, both s3 and s4 will be used if they are available.

option allbackups

frontent ft_app
 bind 10.0.0.1:80
 default_backend bk_app_main
backend bk_app_main
 option allbackups
 server s1 10.0.0.101:80 check
 server s2 10.0.0.102:80 check
 server s3 10.0.0.103:80 check backup
 server s4 10.0.0.104:80 check backup

nginx failover without load balancing

https://serverfault.com/questions/480241/nginx-failover-without-load-balancing

pstream backend {
    server 1.2.3.4:80 fail_timeout=5s max_fails=3;
    server 4.5.6.7:80 backup;
}

server {
    listen 80;
    server_name whatevs.com;

    location / {
        proxy_pass http://backend;
    }
}

https://www.cnblogs.com/biglittleant/p/8979887.html

backup 预留的备份服务器，当其他所有的非backup服务器出现故障或者忙的时候，才会请求backup机器，因为这台集群的压力最小。

max_fails 允许请求失败的次数，默认是1，当超过最大次数时，返回proxy_next_upstream模块定义的错误。0表示禁止失败尝试，企业场景：2-3.京东1次，蓝汛10次，根据业务需求去配置。

fail_timeout，在经历了max_fails次失败后，暂停服务的时间。京东是3s，蓝汛是3s，根据业务需求配置。常规业务2-3秒合理。

例：如果max_fails是5，他就检测5次，如果五次都是502.那么，他就会根据fail_timeout 的值，等待10秒，再去检测。


https://blog.51cto.com/wangwei007/1103727

ethereum Nonce collisions

https://hackernoon.com/ethereum-blockchain-in-a-real-project-with-500k-users-f85ee4821b12

Nonce collisions
Nonce collisions were another mysterious thing we’ve encountered when trying to scale the number of Geth nodes in order to cover the case when one node crashes. It turns out that


We used a simple load balancer before the three Geth nodes, which was sending each transaction to one of the three nodes. The problem was that each time we submitted many transactions at once, some of those transactions were mysteriously disappearing. It took a day or two until we finally figured out that this was a problem with nonce collisions.

When you are submitting raw transactions to the network you are fine, because you keep track of nonce numbers yourself. In this case you just need a node to publish raw transactions to the network. But in the case you are using an account unlocking mechanism built into the node and do not specify the nonce when publishing transactions (with web3 or so), the node tries to pick the appropriate nonce value itself and then signs a transaction.

Because of the network delays, in the case two nodes receive the same transaction publishing request, they can generate the same nonce value. At the moment of receiving the transaction publishing request they don’t know that they both received a transaction with the same nonce. Thus, when propagating these transactions through the network, one of them will eventually be dropped because its “transaction nonce is too low”.

To fix nonce collisions introduced by adding a load balancer to a system, we needed to create a different kind of load balancer. For example, a load balancer which always uses one particular node and switches to another node only if the first one is down.

ethereum Proper Transaction Signing nonce

https://ethereum.stackexchange.com/questions/12823/proper-transaction-signing

const Web3 = require('web3');
const Tx = require('ethereumjs-tx');
const config = require('./config');

const web3 = new Web3(new Web3.providers.HttpProvider(config.provider)); //link provided by Infura.io
web3.eth.defaultAccount = "0xc929c890f1398d5c1ecdf4f9ecec016906ac9f7f";

const getNonce = () => {
  return new Promise((resolve, reject) => {
    web3.eth.getTransactionCount(web3.eth.defaultAccount, (error, result) => {
      if(error) reject(error);
      resolve(web3.toHex(result));
    })
  })
}
const getGasPrice = () => {
  return new Promise((resolve, reject) => {
    web3.eth.getGasPrice((error, result) => {
      if(error) reject(error);
      resolve(web3.toHex(result.toNumber()));
    })
  })
}

const sendRawTransaction = (rawTx) => {
  const privateKey = "190b820c2627f26fd1b973b72dcba78ff677ca4395c64a4a2d0f4ef8de36883c";
  const tx = new Tx(rawTx);
  const privateKeyBuffer = Buffer.from(privateKey, 'hex');
  tx.sign(privateKeyBuffer);
  const serializedTx = tx.serialize();
  web3.eth.sendRawTransaction('0x' + serializedTx.toString('hex'), function(err, hash) {
      console.log('Error:', err);
      console.log('Hash:', hash);
  });
}

Promise.all([getNonce(), getGasPrice()])
  .then(values => {
    const rawTx = {
      to: '0x203D17B4a1725E001426b7Ab3193E6657b0dBcc6',
      gasLimit: web3.toHex(1000000),
      value: web3.toHex(web3.toWei('0.1', 'ether')),
      nonce: values[0],
      gasPrice: values[1]
    };
    console.log(rawTx);
    return(rawTx);
  })
  .then(sendRawTransaction)
  .catch(e => console.log(e))

ring buffer

https://zhen.org/blog/ring-buffer-variable-length-low-latency-disruptor-style/

https://github.com/smartystreets-prototypes/go-disruptor

ethereum transaction template

https://ethereum.stackexchange.com/questions/50042/why-does-sendsignedtransaction-return-a-tx-hash-but-does-not-post-to-the-rinkeby

window.web3 = new Web3(new Web3.providers.HttpProvider(endpoint));

sendEther() {
    const fromAccount = **acct1**;
    const toAccount   = **acct2**;

    const rawTransaction    = this.makeRawTransaction(fromAccount, toAccount);
    const signedTransaction = this.makeSignedTransaction(rawTransaction);
    const serializedTransaction = `0x${signedTransaction.serialize().toString('hex')}`;

    window.web3.eth.sendSignedTransaction(serializedTransaction, (error, result) => {
        if(!error) {
          console.log(`Transaction hash is: ${result}`);
          this.setState({
            etherscanUrl: `https://rinkeby.etherscan.io/tx/${result}`,
            error: null
          });

        } else {
          this.setState({ error: error.message })
          console.error(error);
        }
    });
  }

  makeSignedTransaction(rawTransaction) {
    const privateKey   = '**************';
    const privateKeyX  = new Buffer(privateKey, 'hex');
    const transaction  = new EthTx(rawTransaction);
    transaction.sign(privateKeyX);

    return transaction;
  }

  makeRawTransaction(fromAccount, toAccount) {
    const { exchangeRate } = this.props;
    const amount = (1 / exchangeRate) * 5;

    return ({
      nonce: window.web3.utils.toHex(window.web3.eth.getTransactionCount(fromAccount)),
      to: toAccount,
      gasPrice: window.web3.utils.toHex(100000000000),
      gasLimit: window.web3.utils.toHex(100000),
      value: window.web3.utils.toHex(window.web3.utils.toWei(`${amount}`, 'ether')),
      data: ''
    });
  }

[轉]Windows、WSL 与 Linux 的性能对比

https://www.cnbeta.com/articles/tech/922349.htm

尽管执行了各种各样的测试，但是如果对在七个不同操作系统上成功运行的所有测试取几何平均值，可以得出这样的结论：

Windows 10 Build 19008 的总体性能要比 Build 18362 版本好，而 WSL 的性能并没有太大变化

WSL2 比 WSL 的性能确实稍好一些，这是因为在 I/O 或网络活动繁重的工作负载的情况下前者性能要好得多

在这种特殊的 Core i9 7960X 场景下，运行 Ubuntu Linux 的速度总体上比最快的 Windows 配置快 27％

有兴趣的朋友可查看这份更详细的 OpenBenchmarking.org 结果文件，以深入研究这些 Windows / WSL / Linux 基准测试内容。

geth attach

geth --exec "eth.blockNumber" attach --datadir ./
geth --exec "eth.syncing" attach --datadir ./
geth --exec "admin.peers" attach --datadir ./
geth --exec "clique.getSnapshot()" attach --datadir ./

watch -n 2 'geth --exec "clique.getSnapshot()" attach --datadir ./'

geth-prometheus

https://github.com/karalabe/geth-prometheus

https://blog.ethereum.org/2019/07/10/geth-v1-9-0/

You can quickly reproduce the above charts via my clone of Maxim Krasilnikov’s project by running docker-compose up in the repo root and accessing http://localhost:3000 with the admin/admin credentials. Alternatively, you can view my testing snapshot on Raintank, or import this dashboard into your own Grafana instance

源碼掃瞄

Checkmarx
Fortify

ethereum geth check transaction

geth console

## get balance

eth.getTransaction("")
eth.getTransactionReceipt("")

EX： transaction id 0x8dfaa1b5d2e660ee2d3aa9fd0eeb33cc726d50122790e882a914ffd7d02e3a83
eth.getTransaction("0x8dfaa1b5d2e660ee2d3aa9fd0eeb33cc726d50122790e882a914ffd7d02e3a83")
eth.getTransactionReceipt("0x8dfaa1b5d2e660ee2d3aa9fd0eeb33cc726d50122790e882a914ffd7d02e3a83")

## get transaction count

eth.getTransactionCount()
eth.getTransactionCount(, "pending")

EX： transaction id 0x8dfaa1b5d2e660ee2d3aa9fd0eeb33cc726d50122790e882a914ffd7d02e3a83
eth.getTransactionCount("0x8dfaa1b5d2e660ee2d3aa9fd0eeb33cc726d50122790e882a914ffd7d02e3a83")
eth.getTransactionCount("0x8dfaa1b5d2e660ee2d3aa9fd0eeb33cc726d50122790e882a914ffd7d02e3a83", "pending")

## check pending queued

txpool.status

EX:
{
pending: 0,
queued: 5
}

融資

目前好像國泰比較優
年利率2% 手續費2千
一年到期續約不用手續費
這些都是基本條件不需要談

對啊，不過國泰大概是給年薪的3倍額度

年薪50萬，就150萬

聯邦18個月後，要還一次本金嗎？
聯邦不用還本金
國泰也不用


所以500萬，屆滿300萬，18個月後，直接續新約齁？

銀行、證券金融，國泰、聯邦、元大證金，就沒這種規定

查驗 驗收

．需求書內 合約 改成 契約

勞務請購 準備文件
1. 購案核定清單
2. 自我檢核表
3. 報價單
4. 需求書
5. 承攬商 (有派人力到 中心/公司 工作情況)
最後 預估金額分析表 (簽核過財會後，請購人員會給予後填寫)

案子的負責「採購人員」是： AAA
先請試填請購單後，截取畫面併相關文件給採購人員確認是否正確後，再正式填寫請購單
會科問題 BBB 會計人員

金額比例 300 200 (依期數 如這裡500 分二期)
需求書上 兩次：10/30、6/31
付款注意：年底可能會關帳，要提前，建議一個月為主

特別注意：查驗和驗收不同，案子通常第一期為查驗，第二期為驗收，兩者皆為組長(負責主管)，如沒空，可找代理人，查驗/驗收需求項目、文件順序需按照需求書

第一期查驗：
．我方需要確認資料、系統和文件是否正確，系統檔案可存放光碟(建議全放)
．查驗文件依需求書需求項目為主，再說明查驗或驗收順序已備齊
．廠商準備現場DEMO及列印文件，務必提前一到二星期準備
．另廠商需寄送EMail告知開發完畢，可進行查驗或驗收，印該EMail代表收到開發完畢文件
．查驗文件上的完成覆約日期為收到EMail為主，查驗測試時間則為實際排定查驗測試日期

第二期驗收：
．需先再跑查驗流程(非第一期查驗)，再驗收
．需自行把系統自行跑過一次，代表有實際確認過
．其他同第一期
．查驗過後，將相關資料給予採購人員，會協助安排組長驗收時間，自行安排會議室
．驗收記錄給予廠商，進行發票開立作業
．收到廠商發票後交給採購人員

[轉]Flutter 状态管理指南之 Provider

https://zhuanlan.zhihu.com/p/70280813

[轉]Flutter 全局状态管理之 Provider 初探

https://juejin.im/post/5d8f324ee51d45781e0f5dca

一、什么是全局状态管理

当我们在使用 Flutter 进行应用开发时，可能需要不同的页面共享应用或者说变量的状态，当这个状态发生改变时，所有依赖这个状态的 ui 都会随之发生改变。在同一个页面中还好说，直接通过 setState 就可以达到目的，要是不同的页面呢，或者当应用变得非常复杂，页面非常多的时候，这个时候全局状态管理就显得非常重要了。
在 Flutter 中，状态管理可以有如下几种方式：

1、setState

flutter 中最简单使 ui 根据状态发生改变的方式。

2、 InheritedWidget & InheritedModel

InheritedWidget 和 InheritedModel 是 flutter 原生提供的状态管理解决方案。 当InheritedWidget发生变化时，它的子树中所有依赖了它的数据的Widget都会进行rebuild，这使得开发者省去了维护数据同步逻辑的麻烦。

3、Provider & Scoped Model

Provider 与 Scoped Model 都属于第三方库，两者使用起来差不多，其中 Provider 是 Google I/O 2019 大会上官方推荐的状态管理方式。

4、Redux

在 Redux 状态管理中，所有的状态都储存在Store里，Flutter 中的 Widget 会根据这个 Store 去渲染视图，而状态的改变也是通过 Reduex 里面的 action 来进行的。

5、BLoC / Rx

BLoC的全称是 业务逻辑组件（Business Logic Component）。就是用reactive programming方式构建应用，一个由流构成的完全异步的世界。 BLoc 可以看作是 Flutter 中的异步事件总线，当然在除了 BLoc 外，Flutter 中有专门的响应式编程库，就是RxDart,RxDart是基于ReactiveX标准API的Dart版本实现，由Dart标准库中Stream扩展而成。

作者：Flutter编程开发
链接：https://juejin.im/post/5d8f324ee51d45781e0f5dca
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[轉]如何選擇ERP

https://www.ptt.cc/bbs/MIS/M.1575624725.A.74A.html

: 各位前輩大家好
: 小弟目前被賦予任務如下:
: 評估各家ERP優缺並負責導入相關事宜
: 我司產業為製造業(女鞋代工),產品皆外銷
: 主要需要解決的問題為以下:
: 1.BOM數位化問題
: 2.訂單轉換採購單,備料單重工問題
: 預算目前沒有上限;
: 從未導入過任何ERP系統,截至目前為止皆為人工手KEY各種報表;
: 目前已接觸過鼎新,尚揚,鴻來軟件
: 請問各位前輩還有推薦的ERP廠商嗎?

原提問人已經「面談」過不少軟體商的業務人員，為何還來這裡徵求各界意見？

其實，聽取軟體商簡報後，仍陷入「一頭霧水」狀態的MIS主管，我曾經就是其中一員，彼岸更多！

這個提問觸發我寫下一篇文章《如何選擇ERP》。先預熱一下...

恰巧我曾經任職一家只幫愛迪達代工，18000人的廣東鞋廠，厚顏擔任只出一張嘴「管理」28名部屬的MIS部門最高主管（經理）。

該廠當時：廣東有相距近百公里之遙的2個工廠、臺中辦公室、積極動工中的印度工廠。

除了HR當然有的考勤、薪資業務之外，有員工（收費、補助）餐廳、保險、住宿...等資訊需求。

入職當時，該廠正積極汰換ERP軟體，鄙人立即展開「ERP選型」工作。

接手之前，已經有下列軟體商爭取那門生意：

- SAP的「鞋服solution」
- 金蝶
- 深圳的中X（老闆已改行，偶有聯絡。）
- 高雄的先濬

我的調查方式：製作問卷，列舉技術問題，邀請軟體商答題。

按我的記憶列舉一、二：

1. 軟體能否「同時」處理「品名」和「尺碼」？所謂「處理」，包括：跑MRP、追蹤和紀錄各「品名」和「尺碼」的成本與數量。

2. 軟體能否處理各材料的保稅（出口退稅）功能？

3. 軟體能否線上切換語系？（希望印度廠也能使用）

4. 資訊人員能否設計一份報表，中國廠職員使用簡體字打印、臺中廠職員使用正體字打印、印度職員使用英文打印？

5. 資訊人員每設計一份報表之後，是否必須分別在中國廠的800部電腦安裝、去印度廠安裝、去臺中辦公室安裝？（「安裝」包括遠程分發、自動下載並安裝package）

6. 軟體系統使用何種程式語言設計？（事涉MIS人員接手維護軟體的學習曲線、求才難易度、薪資水準）

7. 軟體使用何種資料庫管理系統？（影響老闆的錢包）

8. 會計月結，是否必須來回嘗試幾次過帳、反過帳、結帳、反結帳，可能失敗、出現「負庫存量」、「負金額」？

9. 軟體能否「隨時」顯示「品名」和「尺碼」的真實（不是「標準」）成本與數量，無須等到下月初的月結？

...

當時，

- 用過Tiptop，確定0分，所以懶得聯絡鼎新業務員。
- 知道SAP是垃圾，故直接忽略SAP，連問卷也不發給那些X子。
- 金蝶不繳交問卷，從此失聯。
- 中X答非所問、回答不完整，但是仍拜訪、打電話，積極爭取訂單。
- 先濬拒絕答題。

我當時最敬佩的軟體商是金蝶，因為他們躲起來，證明是唯一有羞恥心的業務員，他們不願意欺騙、說謊。

老闆無視我的反對，所以先濬拿到訂單。我離職後，老闆支付三分之一合約金（330萬元臺幣）後，先濬從此失聯。

我給原提問人能心安理得、睡好覺的建議：

1、參考我前述問卷內容以及下面的參考資料，製作一份問卷，發給全部軟體商，邀請他們答題。

2、邀請那些全部回答「yes」的廠商向你當面示範那些「yes」的軟體功能。

3、淘汰這些軟體商：回答不清楚、回答「no」、不敢示範那些「yes」的軟體功能。

4、從那些全部回答「yes」而且確實示範軟體功能真實不虛的軟體商之中，選擇報價最低的一家，直接推薦給老闆。

5、如果不幸證明全部檯面上的軟體商都是騙子的話，只好去我的SaaS官網免費註冊、試用，基於你的專業和敬業，回答你自己的問卷，並且相信自己的眼睛，而非耳朵。
手冊：https://terarows.gitlab.io/app2/

---參考資料---

http://www.itpub.net/thread-1892471-1-1.html

- 勞工：三班制：07:00 ~ 15:00、15:00 ~ 23:00、23:00 ~ 07:00。夜班提供夜點費。
- 遲到半小時內，扣薪N元。遲到M小時以上，視同請假半日。早退，（忘了詳情！）。未請假，曠職，扣薪X元。
- 有全勤獎。
- 小過：扣N元；大過，扣M元。小功：獎N元；大功，獎M元。
- 文員：高級主管不打卡，其餘須打卡。可填單報出差。
- 薪資：按層級表。也許有年終獎金。
- 年假/年資對照表。
- 外國勞工提供住宿。
- 中國廠有用餐制度、住房、保險。
- 台灣廠有勞保、健保、綜合所得扣繳憑單。
- 當然，打卡鐘24小時侍候。

多公司。在線切換，無須登出再登錄。

多國語言。在線切換，無須登出再登錄。

已翻譯正體中文、簡體中文、英文。按各種語言輸入料項目、供應商名、地址、人名..。

多時區。倫敦用戶輸入、顯示「2014-12-01 00:00:00 +0」，北京用戶輸入、顯示「2014-12-01
08:00:00 +8」。

支持料品批號、鞋子的尺碼、成衣的尺碼。

會計科目只有一段。
一些ERP要求：每一個料號指定一個多段會計科目編碼。例如：1111-00A-123。其中，「1111」代表『原料』、「00A」代表『00A部門』、「123」代表『123料號』。
PostERP只使用會計科目只有一段：「1111」，代表『原料』。

無縫整合會計：凡是與金額相關的交易，都轉拋會計分錄。會計人員的記帳工作趨近零。

會計分錄只有一個屏幕，無須多個屏幕來回翻找、比對、輸入。這個屏幕容納成本、供應商、客戶、應收帳款、應付帳款、銀行存摺帳號...等信息。

無須過帳、反過帳。結帳重點工作，只運行一個指令，處理：虛帳戶結轉實帳戶、本期實帳戶餘額復制成下期期初餘額。

支持先進先出、後進先出、移動加權平均成本。永續盤存制。

隨時反應每一個倉位中的每一個項目、每一個批號的最新成本，無須等到月結。

MRP同時考慮項目與批號（或尺碼）：
1、需求數量（數量，時間）
2、倉庫現存可用量（數量）
3、BOM標準用量（數量）
4、BOM父項損耗率、子項損耗率（數量）
5、生產工藝（數量、時間）（目前從缺）
6、計劃單數量（數量，時間）
7、請購單數量（數量，時間）
8、採購單數量（數量，時間）
9、外包單數量（數量，時間）
10、生產單數量（數量，時間）
11、生產投料單數量（數量，時間）
12、生產記錄（數量、時間）
13、最小包裝量/不可分割數量（數量）
14、最低採購數量（數量）
15、最低生產批量/最低外包批量（數量）
16、時柵（時間）（目前從缺）
17、時格（時間）（目前從缺）
18、提前期（時間）

多層「一對多」單據。例如：在同一個屏幕的一張出貨單號含多種藥名，每個藥名含多個批號，每個批號含多個出貨日期，每個出貨日期含多個交貨目的地；自多個儲位撿貨。

各種語言在線求助：屏幕說明、字段說明、報表用途與參數說明、程序用途與參數說明。

備正體中文、簡體中文、英文文檔，供使用人以瀏覽器閱讀。

MIS人員在瘦客戶上面開發、修改、強化ERP，終端使用人在瘦客戶操作ERP。

瘦客戶內建報表引擎，無須外掛Crystal Report等：MIS人員設計報表樣板，終端使用人運行報表。100%整合在瘦客戶的menu中。

MIS人員設計的一份WYSIWYG報表樣板，台灣文員預覽或打印正體中文報表、中國廠員工人打印正體中文報表、印度user print英文report。可設計cross tab報表、含bar code報表、子報表（sub-report）。

伺服器軟件與瘦客戶之間的傳輸資料經過(1)加密(2)壓縮。不需要VPN、Citrix、Windows Remote Desktop。

提供類似Unix crontab的排程機制。

巨細靡遺記錄user的輸入、修改、刪除記錄。

每一筆記錄都允許附掛32767個文檔，例如：工程圖.png、標準作業程序說明.doc。

屏幕中的每一個table都允許匯出成文檔，供LibreOffice的Calc、M$ Excel等軟件匯入。



《不易聽到SAP專案失敗的原因》：
https://bit.ly/2DPkDZZ
https://bit.ly/2OOanYv

ethereum 交易 驗證

https://www.blocktempo.com/blockchain-technical-overview-structure-of-blockchain-ethereum/

3. 以私鑰簽署交易。
4. 廣播「加上簽名的交易封包」至鄰近的以太坊節點們。


https://ithelp.ithome.com.tw/m/articles/10215095

總而言之在區塊鏈接納這筆交易前，先試著用地址反推回原本的公鑰，再用公鑰解密當初這筆交易紀錄的簽章看看，如果公鑰解的開就可以代表是公鑰持有人本人所簽核的，這便是剛剛提到的"數位簽章"。
注意：這段比較像是一般加解密的方式，好像不是ethereum


https://ethereum.stackexchange.com/questions/13778/get-public-key-of-any-ethereum-account

ethereum 簽完的東西 可以 找出 public key
有public key 就可以知道是誰發出這個交易


https://zhuanlan.zhihu.com/p/30481292

签名完成了，我们如何验证某些签名后的数据是哪个账户签名的呢？在web3.js 发布1.0版本以前，验证签名只能通过智能合约的ecrecover函数来实现。新版的web3.js提供了web3.eth.accounts.recover函数用于验证签名。这里我们仍然使用传统的智能合约ecrecover方式。

ecrecover接收数据的哈希值以及r/s/v等参数作为输入，返回实施该签名的账户地址。因此我们只需要通过合约拿到实施签名的地址，和我们真正的地址进行对比，如果地址一致，就说明验证通过了。


這也是ethereum private key和address比較重要的原因了


https://learnblockchain.cn/books/geth/part3/sign-and-valid.html

capacitor var global

npx cap copy

android/app/src/main/assets/public/native-bridge.js

linux .bashrc

# General Aliases
    alias apk='apk --progress'
    alias ll="ls -ltan"

    alias hosts='cat /etc/hosts'
    alias ..="cd .."
    alias ...="cd ../.."
    alias ....="cd ../../.."
    alias untar="tar xzvkf"
    alias mv="mv -nv"
    alias cp="cp -i"
    alias ip4="ip -4 addr"
    alias ip6="ip -6 addr"

    COL_YEL="\[\e[1;33m\]"
    COL_GRA="\[\e[0;37m\]"
    COL_WHI="\[\e[1;37m\]"
    COL_GRE="\[\e[1;32m\]"
    COL_RED="\[\e[1;31m\]"

    # Bash Prompt
    if test "$UID" -eq 0 ; then
        _COL_USER=$COL_RED
        _p=" #"
    else
        _COL_USER=$COL_GRE 
        _p=">"
    fi
    COLORIZED_PROMPT="${_COL_USER}\u${COL_WHI}@${COL_YEL}\h${COL_WHI}:\w${_p} \[\e[m\]"
    case $TERM in
        *term | rxvt | screen )
            PS1="${COLORIZED_PROMPT}\[\e]0;\u@\h:\w\007\]" ;;
        linux )
            PS1="${COLORIZED_PROMPT}" ;;
        * ) 
            PS1="\u@\h:\w${_p} " ;;
    esac