Programming Language Notes

  圖片來源 這次會分享關於「鎖」的主題除了工作上遇到這樣的情境之外，也發現到其實軟體技術大部分跟我們生活情境息息相關，覺得非常有趣，因此嘗試將艱澀難懂的技術化為淺顯易懂的圖文知識來幫助大家快速理解，除了應用在工作上，或許對於生活過程中遇到的一些問題也能得到一些啟發。 此篇章主要著重於觀念的分享，並不會深入探討實作的細節，相信只要觀念通了，對於技術實作的道路上一定會非常順暢，好吧！廢話不多說，趕快來介紹一下樂觀鎖與悲觀鎖的基本觀念。 情境 軟體開發的過程中想必我們開會過程中常常會聽到以下的關鍵字句： - 併發問題就應該用樂觀鎖啊！ - 最安全的併發正確性應該用悲觀鎖吧！ - Scale Out的服務怎麼保證正確呢？ - 啊！雙十節要到了，如何確保客戶的訂單與商品數量是正確的又能兼顧效能？ 以上的問題都圍繞在效能、正確性， 而其中最關鍵的就是「鎖」， 雖然「鎖」難免會造成效能的下降， 但這點不足之處對於現階段的群集架構之下， 已經能夠透過橫向擴展的方式進行補足， 因此「鎖」的技術值得我們好好認識一番！ 悲觀鎖(Pessimistic Lock) 😭 圖片來源 就如同字面上的意思， 對任何的事物都很悲觀， 而這種情緒之下的處理方式就是盡量鎖住整個資源， 保證整體一致性之後再釋放， 雖然安全但效能下降程度非常的高。 以生活化的例子來說， 當我們要去餐廳慶祝一下的時候， 通常就兩種作法， 不是預訂就是現場候位， 那麼較悲觀的人可能會事先安排， 因此會進行訂位的動作， 那麼一旦訂位之後， 該位置到某個時段就等於是被「鎖」上， 直到我們用完餐之後才釋放， 這樣的情境下確保我們能正確的慶祝用餐， 但對於資源使用上來說就相對耗費了， 尤其當我們發生非預期狀況之下無法到場時， 原本餐廳能夠服務到更多客人， 卻因為我們的「鎖」而導致服務客人的量減少了， 餐廳也少賺了一些客人的消費金額。 優點 - 保證「鎖」上的資源能夠完整處理操作後再釋放。 缺點 - 「鎖」的粒度太大導致資源的浪費。 樂觀鎖(Optimistic Lock) 😀 圖片來源 先做就對了， 有衝突再解決...。 一樣以餐廳為例， 這次就變成現場候位的狀況， 不採取預訂方式， 有位置再吃， 大不了下個時段再來， 這樣對於餐廳端來說， 資源閒置的狀況減少了， 每一桌吃完就服務下一桌， 以軟體技術語言的角度來說就是...

  我們平常瀏覽的網頁通常都是兩端之間的傳輸， 傳輸的過程假入被駭客監聽就很容易遭到資料竄改甚至攻擊，而目前中間人攻擊的手法也非常多種， 因此當我們對這些手法具有基本認識之後才能進行基礎的防護措施，避免重要的資訊被駭客竊取， 甚至竄改導致資料的錯亂， 更進一步影響到重要的資產。 常見的手法 IP欺騙 通常較大型的應用系統都會有一些IP白名單規則， 僅允許某些來源連線， 而IP欺騙的方式則是將連線的IP偽造成這些白名單， 讓接收端誤信， 比較沒傷害的像是DOS攻擊， 但倘若是圖謀不軌的駭客， 可能藉由IP欺騙取得您更多的訊息，醞釀更大型規模的攻擊。 DNS欺騙 通常我們都會用domain的方式進行連線瀏覽網站， 例如: www.google.com， 而不會直接使用IP， 但由於DNS本身不具有認證的機制， Email挾持 這種手法是最簡單粗暴的一種手法， 通常會發送一些值得你信任的內容， 甚至發送機構， 而其中就夾藏著有害檔案或者連結誘使我們點入， 導致重要的個資遺失。 因此當我們收到郵件，尤其是夾帶檔案的信件都要特別留意，再三查證，進而減少被惡意竊取資料的風險。 Wi-Fi監聽 假設我們電信的流量並非吃到飽時， 通常到了公共場所都會找尋Wi-Fi進行上網動作， 但天下並沒有白吃的午餐， 當我們以為有免費的Wi-Fi可以使用時就落入了駭客的陷阱， 這些Wi-Fi可能是駭客架設免費給我們無償使用， 背後付出的代價就是個人資訊的損失， 所以不要貪圖一時的小利而導致重大的損失。 結語 中間人的攻擊方式常常利用人性的弱點與疏忽， 我與你之間或許就藏匿著中間人， 隨時監聽並等待時機進行欺騙， 所以平常就應注意任何小細節， 稍有不尋常就應提高警覺並進行對應的防範工作， 避免造成不可挽回的損失。 ----------------------------------------------------------------------------- 喜歡撰寫文章的你，不妨來了解一下： Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 — 為什麼要加入？ 歡迎加入一起練習寫作，賺取知識，累積財富！

  Mapping(映射)就像是字典表一樣，鍵入「什麼樣的標題」對應到「什麼樣的內容」，而標題就是從內容提煉出來的一種簡短快速識別的標的，透過這種方式，我們未來找尋內文時，只要先透過標題來查找，絕對會比直接找內文快上好幾倍，因此Mapping常常應用在查找事物上，它有點像一般程式語言的HashTable，主要目的在於透過對應表快速定位到詳細的資訊。 語法結構 /// 錢包餘額對應表 /// 錢包地址 <-剩餘-> 金額 mapping(address => uint) public _balances; 如何設定對應表？ function updateBalance(uint newBalance) public { _balances[msg.sender] = newBalance; } 取得特定值 取得的方式非常簡單，我們宣告一個正確型別的變數進行承接之後，就能夠使用到儲存的值，進行加工後，再次設定。 uint _balance = _balances[msg.sender]; 刪除某一組 藉由delete關鍵字重新設定某一組key值。 delete _balances[msg.sender]; 相關的限制 - 鍵值(Key)僅能是Solidity的基本型態(strings、uint…)，複雜型態(array、struct…)是不被允許的。 - 預設不支援iterable，因此無法自然的逐一處理，但提供自行實作的擴充能力， 請參考這裡 。 結語 Mapping是一種非常好用的資料結構，我們日常生活中諸如電話黃頁、書籤、五金行分類…等，舉凡與搜尋有關的整理，皆是在將龐雜的資訊濃縮成摘要，並且進行恰當的分類之後，讓我們更容易找尋這堆龐雜的資料，在區塊鏈的世界上亦是如此，錢包地址的背後可能夾藏的非常複雜的資訊，透過Mapping快速定位到關鍵位置，進行進一步的處理。 今天的範例都在這裡「 📦 solidity-remix-toturial/Ep15 」歡迎自行取用。 📚 更多關於Solidity的文章請看這裡… ---------------------------------------------------------------------------------- 喜歡撰寫文章的你，不妨來了解一下： W...

  密碼學能夠帶來什麼好處？ 雲時代的來臨， 我們過往使用的桌面版應用程式逐漸搬上雲端， 但也帶來了極大的挑戰， 因為一但上雲就代表著需要面臨著四面八方的使用者， 我們並不知道這些使用者是否都是君子， 一個不小心如果出現漏洞就可能被攻擊， 導致系統損壞， 進而影響商譽、營收， 對企業來說是極大的傷害， 為了避免這樣的狀況發生， 資安防禦體系下的「密碼學」就扮演著極其重要的角色， 讓伺服器與客戶之間的溝通具有一層嚴格的防護網， 減少過程中被竊取、破壞的風險，伺服器的資料也能藉由「密碼學」獲得重要的保護效果，， 而「密碼學」也是一門博大精深的技術， 接下來的系列將以最簡單的方式講述密碼學的原理， 讓我們在資安意識抬頭的時代能夠增加一門功夫， 以因應時代需求的發展。 密碼學的「雜湊」與「加密」是區塊鏈發展的重要基石 區塊鏈可以拆解為「區塊」跟「鏈」，「區塊」就是一份份的資料帳本，而「鏈」就是由密碼學的Hash原理串起來的，每一個「區塊」中皆存放目前的Hash值與上一個區塊的Hash值，以此環環相扣連結成鏈。 因此我們才要好好的認識編碼、加密與雜湊的差異，避免名詞造成混淆，而後續的篇章也會深入來潭討雜湊函數的奧秘，讓我們對於區塊鏈的運作原理能夠有更進一步的認識。 編碼(Encode)、雜湊(Hash)、加密(Encrypt)究竟有什麼不同？ 「編碼(Encode)」其實離我們很近…，原來電影情節常常出現的「摩斯密碼」成為了最貼切的例子。 相信我們常常看到電影情節中不時就出現「摩斯密碼」的名詞， 而密碼學之中的「編碼」也是類似這樣的概念， 簡單來說就是「資料內容替換成不易閱讀的符號、文字」以獲得保護， 過程中一但資料被擷取也不易閱讀， 是保護門檻中最基本的一項， 但也是最弱的， 因為一但編碼還原表被竊取， 或是使用大家都知道的編碼表， 就很容易進行還原破解。 常見的編碼格式 - URL編碼。 - UTF-8。 - ASCII。 - Unicode。 - Base64。 「雜湊(Hash)」就是碎片化與拼湊的過程 雜湊！雜湊！雜湊！其實並不難理解，簡單來說就是將「大量的資料碎片化之後再拼湊」，因此雜湊出來的結果並不能「逆推」回原文，那這樣帶來什麼好處呢？ 試想，我們碎片化之後再拼湊出來的資訊一定是簡化過的，因此對於容量的佔用，資訊的精準度都具有一定的影響力，不論在搜尋或...

  何謂函式庫？ 簡單的來說就是把同類型常用的功能打包在一起，讓其他開發者能夠重複使用，達到資源有效利用的效果，以軟體開發來說就是減少多餘的程式碼，而Solidity語言中，Library可以視為物件導向中的靜態類別，不需要產生實體就能使用，因此能有效的減少Gas。 當我們剛完成一份合約時難免因為設計尚未考慮周全而導致複雜與重複的邏輯，但當我們回頭看看之後，就會發現有一些冗餘的程式碼可以進行整理，甚至分類到不同的地方，如同撰寫文章的草稿一樣，撰寫完畢後進行檢查，會發現有些區段可以挪移到外部的文章進行嵌入…等，讓一篇文章不至於過多的雜訊，而智能合約之中亦是如此，我們可以將共同複雜的邏輯整理到Library並歸類，之後倘若設計多份合約發現共同邏輯時就能夠引入並使用，非常靈活彈性。 建立一個函式庫來玩玩唄 - 情境： 自己打造一個數學函式，並檢核數值是否為「奇數」。 - 以「library」取代「contract」。 - 不需要有static。 - 不需要進行初始化建構(constructor)。 library Math { function checkOdd(uint value) public pure returns(bool) { uint remainder = value % 2; if(remainder!=0) return true; else return false; } } 如何使用？ 引用別人撰寫好的Library會使用「import」來進行引用，而引用的對象也是一支Solidity撰寫的模組，使用起來也非常的直觀，直接以Library的名稱進行function的調用即可。 // SPDX-License-Identifier: MIT pragma solidity ^0.8.7.0; import "./math.sol"; contract Example { function checkOdd(uint value) public pure returns(bool) { return Math.checkOdd(value); } } 結語 此篇章適合對於Solid...

  上一篇我們介紹了模擬API的工具箱「 【Mockoon工具箱】awesome API mocking簡介 」， 也示範如何模擬回傳資料， 但我們的API通常千變萬化， 尤其是會搭配不同的查詢條件進行資料的抓取，正好Mockoon也提供了Rules的一個功能， 透過規則的設定回應不同的資料內容。 情境描述 API入口: http://localhost/endpoint - 當我們沒有進行任何查詢條件時就回傳「welcome」的訊息。 - 當我們想要取得地址資料時，就用「Type=addr」的參數並回傳「台北市」的訊息。 上述的情境僅示範如何根據不同條件進行不同回應， 更多的參數條件就留待各位自行實作囉！ 設計情境 根據上述的情境描述之後， 我們就開始設計這樣的情境吧！ 設計入口歡迎訊息回應內容 第一個Response不需要任何的Rules(規則)， 僅設計回傳的歡迎訊息。 設計查詢條件規則 我們先增加一個Response， 來設計規則與回應內容。 新增了「Response 2(200)」之後， 我們先假設這個回應是查詢地址， 也期望回應內容如下： 接著我們來設計一下規則， 設計為查詢的類型為地址時， 若匹配則回應上述訊息。 實測結果 首先我們在瀏覽器輸入「https://localhost/endpoint」由於沒有任何的查詢參數， 因此會回應我們的基礎回傳歡迎訊息。 接著我們試著帶入查詢參數來看看結果， 指定查詢類型為地址， Mockoon的規則就根據我們的設計回傳地址的回應內容。 結語 原來API模擬不只有靜態的回應而已， 還能夠具有一些基礎的判斷， 讓我們在開發產品功能之前能夠快速的搭建出API並與前端工程師相互討論， 共同制定一套標準API規則， 再各自實作業務邏輯， 達到分工合作的效果， 減少等待依賴的耗時過程。 總之在於快速、效率的時代， 我們需要的是簡單快速使用的功能， 能夠在最短期完成任務的工具都是好工具， 我們要學習的就是快速適應的能力， 就讓我們持續學習新工具快速適應變遷的環境吧！ ----------------------------------------------------------------------------- 喜歡撰寫文章的你，不妨來了解一下： Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 - 為什麼...