【企業工作坊 X 題目介紹|LINE】
#2021梅竹黑客松開放報名
這次...我們有幸邀請到的的企業工作坊是...登登!#LINE 🎉
我們日常聯絡他人往往少不了 LINE,尤其在後疫情時代,更是透過LINE來拉近彼此的距離,想了解在疫情下如何透過 LINE打造數位新生活嗎?走過路過不要錯過,歡迎你們揪團參加 梅竹黑客松所舉辦的LINE API說明的線上企業工作坊!🔥
📍LINE 的題目如下:
▌主題
藉由 LINE API 打造數位新生活
▌說明
生活周遭有許多 場所 / 店家 / 群組 希望擁有屬於自己品牌的服務與用戶互動,尤其在疫情下的新常態生活更需要透過科技解決以上問題。
本次將藉由每位同學的創意並透過 LINE 平台的技術打造應用服務,讓受到疫情衝擊的我們也能透過科技來拉近彼此間的距離。
▌以下為 LINE 平台技術開發文件
1️⃣ Messaging API(Chatbot): https://developers.line.biz/en/docs/messaging-api/
2️⃣ Login: https://developers.line.biz/en/docs/line-login/getting-started/
3️⃣ LIFF: https://developers.line.biz/en/docs/liff/
📍LINE 賽前工作坊資訊
此次 LINE 工作坊的介紹將使用 Discord 軟體取代實體企業工作坊,參與者記得在工作坊開始前先下載並註冊帳號喔!
▌時間:10/16 (六) 14:00 ~ 17:00
▌軟體:Discord
▌流程:
10 mins 報到
5 mins 開場介紹
50 mins LINE Bot 基礎建置 (上半場)
5 mins 休息
50 mins LINE Bot 基礎建置 (下半場)
5 mins 休息
60 mins 進階開發、範例實作
👉 使用軟體、需要選手建置的環境:
- GitHub 帳號申請 https://github.com/
- CodeSanbox 帳號申請 https://codesandbox.io/
- Node.js v16 下載 https://nodejs.org/zh-tw/download/current/
- VSCode 編輯器下載 https://code.visualstudio.com/download
-----------------------------------------------
🔥 立即報名梅竹黑客松及賽前工作坊吧!
➡ https://signup.meichuhackathon.org/
(建議使用電腦瀏覽網站)
-----------------------------------------------
〔合作企業〕台灣美光、原相科技、Supermicro、104資訊科技、LINE
〔贊助企業〕國泰金控、羅技電子、NXP、奧義智慧科技、Garena、KKbox、Oracle、趨勢科技、Google、SHOPLINE
#梅竹黑客松 #企業工作坊 #比賽資訊
軟體開發文件範例 在 Taipei Ethereum Meetup Facebook 的最佳解答
📜 [專欄新文章] [zkp 讀書會] Cairo 語言介紹
✍️ NIC Lin
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Cairo 是 STARK 證明系統的其中一個編程語言,讓開發者能透過 Cairo 來使用 STARK,撰寫效能更高的 Dapp
Photo by Simon Berger on Unsplash
Warning:本篇會保持在 high level 的介紹,實際深入的部分請見文內附上的文檔或是官方開發者文件
背景介紹
建構於密碼學的零知識證明能提供計算的隱私性,但同時在區塊鏈生態系也被用來提升 Scalability — 我可以用 10 秒的運算資源來驗證原本耗費 1000 秒運算資源的計算過程
如同更多人熟悉的 SNARK,STARK 也是一個零知識證明的證明系統,但當前的 STARK 著重的是在 Scalability ,而非大家比較習以為常零知識證明提供的隱私性特質
其實目前基於 SNARK 的 Rollup 項目,例如 zkSync、Loopring、Aztec、zkopru,除了 Aztec 外,其他都是利用 SNARK 來增加 Scalability — 這些 Rollup 上資料都還是公開、沒有隱私性的
StarkWare 是目前唯一基於 STARK 的開發團隊
STARK 要加上隱私保護不會太難,只是 StarkWare 還沒有把這項功能放在未來規劃中
Cairo 簡介
標榜為圖靈完備的零知識證明系統語言,Cairo 對原本熟悉 Solidity 的開發者來說還是會感到比較難上手和陌生的。再加上套件庫還不夠充足,目前支援的雜湊函式是 Pedersen,數位簽章演算法是 ECDSA(相對於 SNARK,EdDSA 的效能反而比較差所以沒有支援)。
但 Cairo 還在早期開發的階段,相信開發體驗會越來越好的。
另外需要注意的是作為一個證明系統,會有 Prover 和 Verifier 的角色。而 STARK 的 Verifier 是公開的,但 Prover 軟體預計會有 License 保護。Prover 一般情況下不得用於商業用途,除非將 proof 上傳至官方的 Verifier。
最後要提及的是,第一版的 Cairo 是設計來方便開發者將 Dapp 的運算遷移至鏈下。不同於 Rollup,這個鏈下只會有它自己一個 Dapp。這個 Dapp 的項目方自己維護自己 Dapp 的 state。( Rollup 則是 operator 維護所有 Dapp 的 state,Dapp 開發者不需自己操煩)
這可能有點難懂。如果你有在寫 Solidity,想像一下今天你在合約要用到合約裡宣告的 storage 變數時,你要自己提供 merkle proof 上來,證明這個storage 變數真的是這個值。這個就是開發者要自己維護 state 的意思。
而第二版的 Cairo 則是 StarkNet 裡使用的 Cairo(第一和第二版是不同編譯器),這版的 Cairo 就是作為 Dapp 在 Rollup 開發所使用 — 開發者可以在合約裡宣告變數,變數的值不需開發者維護,可以直接假設存在。
註1:StarkWare 不喜歡 Rollup 這個詞,他們覺得 Data Availability 的需求是一段光譜:不一定得要把 data 全都送上 L1,中間有其他方式可以做不同層級的 Data Availability。
註2:第一版和第二版實際上在官方版本裡是 0.0.1 及 0.0.2,在撰文當前最新版即是 0.0.2
官方網站:https://www.cairo-lang.org
開發者文件:https://www.cairo-lang.org/docs/
開發環境
Cairo 有提供像是 Remix 的瀏覽器 IDE:playground。裡面提供各種範例練習和挑戰,除了可以編譯,還可以直接生成並上傳 proof。
註:但有些功能還是沒辦法在 playground 裡使用,例如要給你的程式 custom input 時。這時候只能在本地端開發才能使用這個功能。
開發 Cairo 要先安裝python,我將開發者文件整理出來的資料統整在這個 hackmd 文檔裡:https://hackmd.io/w690dpAQTsKeKZv3oikzTQ
裡面包含簡介、設置本地開發環境以及 Cairo 基礎(因為篇幅原因,所以不將內容複製到這裡)
註:我把開發者文件裡的代碼整理到這裡:https://github.com/NIC619/cairo_practice/tree/master/practices
如果不想在研究開發者文件過程中,還要自己手動拼湊裡面例子的話,可以直接用整理好的代碼來執行。同時 repo 裡還有包含一些額外自己測試 Cairo 功能的範例。
深入 Cairo
在那份 hackmd 文檔裡的開頭,可以連結到第二部分 — 深入 Cairo 的部分。裡面也是從開發者文件裡擷取出來我覺得比較重要的部分。如果你要讀開發者文件的話,我建議從 Hello Cairo 開始,它會從例子切入,會比較好知道 Cairo 怎麼使用。接著如果要更深入了解,再去讀 How Cairo Works。
StarkNet Cairo
第二版的 Cairo 其實功能和第一版的 Cairo 是差不多的,所以不必擔心在開發者文件裡學到的 Cairo 在 StarkNet 版本會不能用或差很多。在讀完 Hello Cairo/How Cairo works 後,就可以接著看 Hello StarkNet。會很順利的切換到 StarkNet 版本的 Cairo。
註1:我整理的文檔裡是按照第一版 Cairo 所寫的
註2:如果你從開發者文件一路看下來,體驗過非 StarkNet 版的 Cairo,那你在體驗 StarkNet 版的 Cairo 時一定會發現這更像一般智能合約的使用方式 — 你可以用 view 函式查詢 storage 變數,可以用 external 函式去執行合約(非 StarkNet 版本不是這樣操作 Dapp 的,這邊因為篇幅原因沒有詳細介紹)。
非常建議嘗試兩種版本的 Cairo,你會知道 1. 操作一個單獨在 L2 的 Dapp 和2. 操作與其他 Dapp 共存在 Rollup 上的 Dapp 的不同。這對了解 L2 怎麼運行、需要哪些資料、為什麼需要這些資料非常有幫助。
0.0.2 版的 StarkNet Cairo 目前還缺少一些功能:
函式還沒辦法宣告陣列或 struct 型態的參數
合約和合約之間還沒辦法互動
L1 沒有辦法讀取到 L2 的資料,L2 也沒辦法讀取到 L1 的資料。如果要建立跨 L2 Bridge,這個功能非常重要。
補充及個人心得
STARK 的 proof size 相比於 SNARK 系列的 proof size 大很多,又其證明所包含的交易數量對 proof size 和驗證時間的影響不大,所以把很多筆交易一併做一個 proof 會是對 STARK 非常有利、節省成本的方式(SNARK、STARK 比較表)。但這同時也是一個缺點,如果你的 Dapp 或 Rollup 的 TPS 不高,那就只能等更久時間搜集多一點的交易,要不然就只能提高成本來維持驗證 proof 的頻率。
StarkWare和 zkSync 一樣都有 Rollup 宇宙的概念( Rollup 宇宙的用詞並不精確,因為在他們的宇宙中不會所有子鏈都是 Rollup,而是會有依照 Data Availability 程度不同所區分的子鏈,像是 Validium、zk Porter 的設計),個人覺得能夠有(針對 Data Availability 程度的)選擇是會比只有一個選擇(完全 Data Available) 還好的方式,但實際上的可行性就要等其團隊釋出更多的資訊。
在 Rollup 越趨成熟的情況下,能夠提供快速跨 Rollup 服務的流動性提供者的角色會越來越重要。zk Rollup(StarkNet、zkSync、etc…)比 Optimistic Rollup (Optimism、Arbitrum、etc…)有著短上許多的 finalize 時間,這對降低流動性提供者的風險有很大的幫助,但目前 zk Rollup 支援合約功能甚至 L1 <-> L2 互動的完成度都比 Optimistic Rollup 還低上許多。短期內快速跨 Rollup 的服務應該還是侷限在 Optimitic Rollup 之間。
abbrev
[zkp 讀書會] Cairo 語言介紹 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
軟體開發文件範例 在 矽谷牛的耕田筆記 Facebook 的精選貼文
本篇是一個教學文,主要分享 Metrics 這個概念,以及透過範例來介紹如何針對軟體部署以及事件管理來設定實用的 Metrics。
開頭作者先提了一個情境,團隊需要去設計 Metrics 來瞭解「部署後有多少個緊急的Bug需要被修復]
這個概念重要的點在於,如果該數字很高,可能意味者下列情境有問題
1. Quality Control
2. 應用程式開發流程
3. pre-release 的 smoke-testing
4. post-release checks
這類型的緊急問題通常都會團隊帶來重大的負擔,包括維運人員,開發人員以及測試人員都必須要轉換來幫忙修復,嚴重情況可能會導致SLA不如預期,名聲下降,降低預期收入等。
為了定義一個 Metrics,需要準備六個面向的敘述(示範)
1. Definition
定義三個欄位,分別是 ID/Name/Description
ID: xxx
Name: Urgent Bug Fix Count
Description: 軟體發佈後有多少個緊急的bug被修復
3. Justification
每個 Metrics 都必須解釋其為什麼被需要
5. Audience
誰會需要知道這個 Metric
7. Calculation
如何去計算該 Metrics,譬如百分比等。當前範例是總數,所以不需要特別處理
9. Interpretation
針對該 Metrics 去定義什麼叫做 Pass, Failed,以及什麼樣的範圍該稱為 Warning。
同時也要針對該數值的 Minimum/Maximum 去設定。
以上述範例來說
Pass: 0
Fail: > 2
Warning: 1<=count<=2
Minimum: 0
Maximum: 無上限
另外一種做法是可以加入一種獎勵機制,譬如
Gold Star: 0
Pass: 1
Warning: 2
Fail: >2
這樣的話可以給團隊一個鼓勵,如果沒有任何修復時代表做得很好,而不是單純地表示`PASS`,而是一個鼓勵的方式去感謝團隊的努力
11. Reporting
Metrics 的文件也必須要提到
1. Ownership
2. 回報該 Metrics 的頻率
3. 過去的表現如何
4. 當前表現如何
針對多個 Metrics,可以考慮透過分數與權重的方式將全部合併起來一起回報,針對每個 Metrics 的程度來給予不同的權重
詳細的文章概念可以參閱全文
https://marklowg.medium.com/designing-a-metric-for-software-delivery-or-incident-management-bf6a043b013f
軟體開發文件範例 在 真希望這本書20年前就出版 - Facebook 的必吃
1️⃣ 運用#領域驅動設計(Domain-Driven Design)方法建立文件檔,於軟體開發生命 ... 3️⃣ 透過#模式解說 #清晰圖示 #具體範例,引領您應用良好的製作工具與自動化 ... ... <看更多>
軟體開發文件範例 在 [心得] PM分享:如何撰寫產品需求與規格文件? - Mo PTT 鄉公所 的必吃
各位大大中秋節快樂,我是在軟體業工作的PM, 之前有分享過我跟夥伴們一起 ... 有時卻會被詬病,甚至最讓人困擾的,工程師不看文件、不照著規格開發? ... <看更多>