MorrisLin

虛擬貨幣交易所區塊鏈工程師的心得筆記

在交易所工作的日常就是時常要上線新的Token或是新的公鏈平台幣, 今天主要的心得是如何在測試網路上發行新的Token。

基本上應該沒有那種已上線的專案是沒有所謂的測試環境或是開發環境吧!?(沒有的話塊逃R

區塊鏈都會有所謂的Mainnet和TestNet,至於要如何找到這些資訊呢,我的話會先找該鏈的區塊瀏覽網頁或是Scan,例如 bscscan,通常在右上角會有顯示切換MainNet和TestNet的地方,

--

--

今年剛加入區塊鏈交易所的區塊鏈工程師日常

原本在新加坡公司WFH工作的我,今年到了區塊鏈交易所公司上班,從原本上班時間5分鐘(起床刷牙坐到電腦前)到通勤時間50分鐘,我覺得是各有利弊,在通勤時多了許多與自己對話和學習的時間,通勤的50分鐘是我聽Podcast吸收資訓的時間,因為在區塊鏈交易所上班理所當然地聽了很多有關於區塊鏈的Podcast,其中一集聽到了有關於DAPP遊戲Dark Forest介紹

就對這遊戲充滿好奇,但遊玩這遊戲需要白名單邀請碼,雖然提交了申請但我也是等了一個月才拿到邀請碼,基本的遊戲遊玩可以參考

一開始沒有注意到信中所寫免費100次移動,導致我玩到一半才發現怎麼每次移動都顯示

move transaction () reverted

--

--

TL;DR: GitReleaseNotiSlackBot

在加密貨幣交易所on-board三週(中間放了兩天疫苗接種假),大部分的時間都在看關於各種公鏈與token的資料以及組內專案架構,交派的任務都是簡單性質的,剛好同事有說之前做到一半的Git release check bot因為他沒時間繼續完成,問我有沒有意願來完成,我當然是樂意之至。

首先為什麼需要關注Git release更新的情況呢?一般我們在開發軟體時,會使用很多第三方的Lib,基本上除了有好用的新工能更新或者是重大的Bug或是漏洞,我們需要即時更新Lib之外,應該不會需要去關注更新的資訊。

會需要隨時關注Git release資訊是因為我們公司有運行公鏈的FullNode(FullNode是什麼)所以如果沒有關注到Hard fork(Hard fork是什麼)的話就會對我們的交易產生問題,所以需要一個Bot來每天告訴我們各個公鏈的release資料。

雖然我們Team是使用JAVA做開發,但想到這種request跟slack bot的功能,我選擇了Python來做開發,原因是因為開發速度快。

Repo: GitReleaseNotiSlackBot

先上成果圖:

--

--

工作到現在第五年,才真的很認真的研究Unit test,之前加入的公司滿常說需要會寫Unit test,但通常進去後,專案忙或是上面的人不會要求要寫Unit test,所以一直抱持的大概知道怎麼寫的概念到現在。

去年在前一間公司的時候,年末公司買了一整套的產品(Golang)要來自己維護開發,我們公司的SW基本上都是JAVA遇到Golang prod ready的專案一時之間要開發小功能真的是滿痛苦的,自己在要離職前完成了新的CRUD的Restful API開發,但公司開始要求這個專案需要寫Unit test,沒有什麼在寫Unit test的我遇到了Golang的Unit test以及Mock,硬生生的花了比寫API多四倍的時間在研究怎麼寫test,參考專案他們寫的東西,因為對Mock的概念不是很了解,花了超多心力在處理的,最後的產出是我寫出了會過的test但只是仿照專案其他的test而複製來的,不懂test的整個運行方式。

在新公司決定不能再這樣下去,趁剛上班蜜月期時,多學一點,所有才有這篇寫給自己的筆記。

為什麼要寫Unit test,我自己感覺是為了日後的refactor以及讓自己增加上版的信心度和簡化SW開發驗證的時間,在開發完成後把所有想到的test case、edge 測試都寫好,可以對單一Function、class做測試,比使用Postman做emd-to-end 測試刻度還要再細。

Level of Testing

  • Functional Testing: 只需考慮輸入與輸出正確性的測試,Postman屬於這種測試。
  • Integration Testing: 和不同模組進行整合測試。
  • Unit Testing: 最小單位測試,以確保函式邏輯正確。

Good Unit Test — F.I.R.S.T

  • Fast: 一個專案可能有上千個UT,又經常執行,執行時間需維持在毫秒。
  • Independent: 每個UT需要各自獨立且能獨立運行,資料也是需獨立設定。
  • Repeatable: 不需依賴外部資料、沒有不同的結果、結果必須是確定性的、設置或安排自己的數據。
  • Self Validating: 自動且沒有人工檢查、表達製作者的意圖、易讀的文件、小型。
  • Thorough: 涵蓋所有use case的情境、邊緣邊界數據、大型資料設置、不同的使用者規則安全性、異常和錯誤、非法的參數。

在現實專案中,尤其是API類型的專案,除了邏輯判斷還會牽扯到API介面和資料庫的CRUD操作,這方面Junit(現在的公司也是在做JAVA開發) 就沒辦法做到,所以需要使用Mock,目前使用的是Mockito,可以做到Mock service dao或者是spy產生資料,十分的強大,之後再繼續新增筆記內容。

--

--

今天2021/6/1,幫公司POC SSO with SpringBoot時,遇到了一個新版SpringBoot 啟動上的錯誤,之前開發是指用SpringBoot 2.4.4並未遇到此問題,該問題是只要啟動就會顯示錯誤。

15:06:26.404 [main] ERROR org.springframework.boot.SpringApplication - Application run failed
java.lang.IllegalStateException: No subdirectories found for mandatory directory location 'file:./config/*/'.
at org.springframework.util.Assert.state(Assert.java:76)
at
... 以下省略
Process finished with exit code 1

看了一下官方github issue中SpringBoot 2.4.6/2.5都有這樣的問題,在issue中有提供workaround 的解法,就是在環境變數或者是java 變數中加入config 參數,來避免這個問題。

java 參數為

--spring.config.location=optional:classpath:/,optional:classpath:/config/,optional:file:./,optional:file:./config/

環境變數為

SPRING_CONFIG_LOCATION=optional:classpath:/,optional:classpath:/config/,optional:file:./,optional:file:./config/

擇一使用就可以了。

原本無法啟動SpringBoot

--

--

最近公司突然要舉辦調酒聚會,在規劃時原本是只有我們公司自己人參與,到後來變成了我們這樓層的co-working space 聚會,多了很多公司參與,原先只有打算吃吃喝喝玩調酒,但加了其他公司參與的話,就不能這麼的簡單了,我心中立刻就想到說要來玩Line bot 搞點酒機器人,然後招集了前端一起來組成深夜的Team來實現。

需要的東西有:

API server: Python Flask、line-bot-sdk-python

Database: AWS DocumentDB

Container:Docker

Container Registry: AWS ECR

LINE: message API

Certificate: AWS ACM

Domain:AWS Route53

Image storage: AWS S3

Frontend: vue3

首先需先定義流程,因LINE reply message不收錢,就使用這個來當作整個互動的工具,流程為發送關鍵字系統會reply 酒單flex menu message,點選上面的點餐按鈕使用postback傳送該點單資訊,然後webhook接收到點單資訊後確認該調酒在DB中還有數量,新增訂單後reply 點餐成功flex message。

簡單的規劃一下DB Schema,如下圖

  1. cocktail:為調酒品項schema,
  • quantity:為數量當order 建立後此欄位會-1如果該品項數量為0則回傳的menu不會有該品項,image為該品項的照片。
  • name:cocktail 名稱
  • image:cocktail images(S3 link)
  • display_name:顯示於menu的名稱

2. orders:cocktail 訂單

  • order_id:order 編號三位數並且為index,每次產生時會查詢最後一筆order_id + 1 並為了避免同時點餐導致dup加入了while true,catch到except 會持續嘗試order_id迭代在寫入DB,直到成功寫入。
  • order_item:cocktail name
  • line_id:點餐者的LINE uuid
  • nickname:LINE profile display_name
  • profile:LINE picture_url
  • status:create(建立訂單)、done(完成訂單)、cancel(用戶取消訂單)
  • image:cocktail image(我偷懶不想要在處理訂單時在去query cocktail collection)
  • display_name:cocktail display_name(我偷懶不想要在處理訂單時在去query cocktail collection)

3. line_message

  • type:message 類別
  • alt_text:鎖屏顯示文字
  • contents:flex json

第一階段快速開發期:

因之前API專案完全重構後,加上有實作Line bot sdk發送訊息與webhook,基本上直接拿架構來用,此架構使用mongoengine和marshmallow來做到ORM、deserialize和serialize,加上現成的docker build and push to AWS ECR shell,第一階段快速的把db model & marshmallow schema 給建立完成,開始使用LINE bot SDK的reply message、get_profile以及撰寫business logic function,第一階段把LINE webhook接收到關鍵字回傳quick reply message menu以及postback點酒功能給完成。

--

--