Posts

記得一開始作筆記的軟體是 evernote，由於當時市面上其實也沒有多少的軟體可以選擇，付費了兩三年覺得也沒有什麼太大問題，直到空間越來越滿而且價格真的也是蠻高的，在一次機緣下（Laravel 老爸 Taylor 正好分享他的工作軟體）看到了 Bear，非常簡潔並且支持 markdown，重點是 apple 全裝置支持，價格合理，就陸陸續續用到了現在，但也因為它長年更新進度緩慢（連基礎 table 功能喊了兩年還在 beta），前陣子也有跳去使用 notion 和 obsidian 或是其他筆記軟體，其實追求的不外乎就是幾個項目： 支持 markdown 支持數據自有 支持快速編寫 支持全平台（windows/mac/iphone） 原本我一直以為 markdown 這件事情對我來說是一種剛性需求，但直到前陣子終於發現這是一個幻想出來的需求，原因是絕大部分的時間其實文字和筆記主要功能就是作為一個紀錄，你也可以在其他軟體內寫完等需要時在改成支持的語法就好，其實也不需要一開始就透過這樣子去編寫，也有可能是我平常要的是快速紀錄，對於格式這件事情就還好，畢竟在寫程式的路上我更在意的是思維邏輯而不是片段代碼紀錄。 這樣理性分析完之後，支持 markdown 這個假性需求就被剔除了。 支持 markdown ❌ 支持數據自有 支持快速編寫 支持全平台（windows/mac/iphone） 數據自有的這個需求其實是源自於希望有統一格式進行軟體和發佈狀態，由於在 blog 發文和作筆記都是使用 markdown 作為主要格式，想較為無痛的進行資料交互和傳遞，複製出 .md 檔案就可以進行轉移，但其實後來覺得倒也還好，畢竟如果不常使用的筆記不見也還可以，表示他不重要。另外開發筆記其實時效性真的很短，常常都在更新，主要還是能解決當下的問題並且熟悉其概念才是最重要的。 支持 markdown ❌ 支持數據自有 ❌ 支持快速編寫 支持全平台（windows/mac/iphone） Notion 前陣子斷斷續續用了一陣子，一直想適應，雖然後續改善很多但是還是對於無法快速筆記跟在裝置上體驗不佳而放棄。至於 Obsidian，由於有時候我會想要有手寫功能（越來越貪心，由於寫字紀錄有時候真的很方便，用文字描述真的比較長）所以用了一小陣子就放棄了，順帶一提如果用 iCloud 同步有時候會沒有同步完成產生衝突，這也是我在使用時遇到的一點問題。後來有一陣子在 ipad 上買了 goodnotes 結合 apple pencil，用了一陣子覺得大部分時間還是會想輸入文字，只有很偶爾的情況下才會手寫，也就放著了。 後來我看到一張圖 圖片出處在這裡 這篇也是很值得一讀 My System: Notes 其實意思就是回歸到筆記軟體的本質，紀錄與專注目標才是我所在意的部分，畢竟解決問題並且梳理思維才是目的，筆記只是一種過程。 也因此我前陣子開始嘗試使用內建的 apple notes 作為主要筆記軟體，一開始不太適應的地方是格式和功能相比於其他軟體真的很少，但一旦習慣之後漸漸發現真的就只需要這些功能，並且由於它是 apple 自己出的軟體，所以整合度真的很強大。...

定義 由於區塊鏈世界本身無法調用外部API，是封閉世界，需透過預言機才能知道外部服務和API資料並且加以取用。 預言機本身也是一種智能合約，他的資料都是來自於外部世界的數據和整理過的數據並且寫到鏈上，提供給其他使用的智能合約外部資訊與內容。 智能合約在運行時只能運行已經確定的數值跟內容，無法動態從 API 取得資料處理，預言機則是與外部API取回資料後寫入鏈上，讓其他智能合約調用它取得所需的API資料提供使用。 詳細補充知識點： 区块链是一个确定性的、封闭的系统环境，目前区块链只能获取到链内的数据，而不能获取到链外真实世界的数据，区块链与现实世界是割裂的。 区块链是确定性的环境，它不允许不确定的事情或因素，智能合约不管何时何地运行都必须是一致的结果，所以虚拟机（VM）不能让智能合约有 network call（网络调用），不然结果就是不确定的。 因为智能合约无法主动去获取链外的数据，只能被动接受数据。 使用情境 即時獲得當前交易對報價或依賴外部服務即時資訊、預測市場或其他即時內容獲得執行合約、DeFi 項目。 比如金融衍生品交易平台、借贷平台、快递追踪/IoT、稳定币、博彩游戏、保险、预测市场等，目前最主要的场景就是 DeFi。 中心化預言機與去中心化預言機 中心化 provable(oraclize) 去中心化 DOS network Chainlink 目前最流行的預言機，以太社群推薦。提供 LINK TOKEN 作為節點獎勵。成為節點條件是必須先提供一定的 LINK TOKEN 作為抵押獎勵來確保資訊正確性，如果惡意竄改則會沒收抵押。 參考 https://zhuanlan.zhihu.com/p/52369816 https://zombit.info/chainlink/ https://chain.link/education/blockchain-oracles https://youtu.be/Tvw9NghXi6U

原理 透過以太幣交易原子性，要交易全成功否交易全失敗。 調用智能合約也具有原子性，要全調用成功修改數值，否調用全失敗。 不會出現部份成功部分失敗。 保證在同一交易內歸還本金。 全成功還本付息，失敗則當作此交易沒有存在。 理想狀況 閃電貸借入 100000 USDT DEX A(交易所A) 買 2000@50(2000顆$50 token) DEX B(交易所B) 賣 2000@55(2000顆$55 token) 歸還 100000 USDT + 100 USDT(利息) 獲利 9900 USDT 必須要在同筆交易區塊內完成(透過自己撰寫智能合約並調用合約達到一次交易完成) 攻擊步驟 目的: 攻擊有漏洞的智能合約竊取利益 藉由 dydx 借出 10000ETH 5000ETH 抵押到 compound 借出 112 WBTC 1300ETH 轉入 bZx(主要攻擊的漏洞合約) 透過 5 倍槓桿賣出 ETH 買入 WBTC bZx 為了完成此筆交易，透過 kyber network 協議在 uniswap 內大量拋出 ETH 買 WBTC uniswap WBTC/ETH 交易對池不夠深 -> 價格被拉升 38.5 -> 109.8 原本 bZx 應該是僅扣除原押 1300ETH 不應該用到自己資金池完成交易(無偵測到風險)，但由於合約漏洞導致用到自己資金來完成此筆交易 拋出由 compound 借出的 112 WBTC 到 uniswap 售賣 -> 獲得 6871ETH 6871ETH + 3200ETH(未動用到的借貸) = 10071-10000=71ETH(獲利)(歸還 dydx 貸款) 駭客在 compound 上還有 5500ETH 正在被抵押 由於其他交易市場: WBTC/ETH 還在正常價位 -> 透過 4300ETH 買入 112WBTC -> 換回被抵押的 5500ETH -> 總計獲利 1200ETH + 71ETH = 1271ETH 參考:...

困境 目前 web2 都是以中心化服務為基礎設計，舉例為 youtube, google 等網路巨頭所提供之網路服務， 為什麼會要中心化，就是為了體驗的問題，隨時可以拜訪、低延遲等好處，但這也帶來另一個隱憂: 如果中心巨頭服務器斷線或關閉，或遭到監管等問題則完全無法拜訪。 解決方案 ipfs(interplanetary filesystem): 星際檔案系統，有點類似以前的 p2p 跟 BT節點機制，但具備了更多功能。 這邊要特別注意 ipfs 本身與區塊鏈是沒有任何關係的，只是前者又結合了區塊鏈，而後者許多項目為了保持去中心化 思維而大量採用 ipfs 作為檔案儲存媒介。 傳統來說，我們要拜訪一張檔名為 512.png 的檔案，我們會在網址上輸入https://yish.dev/512.png， 這樣我們就能拜訪到這張圖片，而這樣子的行為則被稱為 地址定址(location based addressing) ，一旦服務器失效或網址失聯，則永遠無法拜訪到這張圖片。 但在此之前是不是有其他人拜訪過這張圖片而他電腦不論是緩存或是某地有儲存著備份，但我們卻無法拜訪。 而 ipfs 透過採用 內容定址(content based addressing) 用來解決這樣子的問題。 原本地址定址是需要由你告訴電腦到哪個位置尋找資源，而現在採用內容定址則是告訴它你要什麼資源。 檔案內容都會有一個雜湊值: 例如 hjjsdfh7T124jAAjruuXNnnna14，類似唯一特徵或指紋。 而當你需要下載某個檔案時，只需要詢問網路: 誰有含有這個雜湊值的檔案? 這個雜湊值是每個檔案唯一，也可以進行二次驗證，達到防偽功能。 增加網路可利用性，由於每個檔案都是唯一雜湊，也就是可以刪除重複檔案。 技術細節 實作 每個 ipfs object 含有基礎兩個內容 超過 256kb，切割檔案並且進行連結 也類似檔案系統與資料夾關係 支持檔案版本管理(類似於 git 概念) 當每次提交一個檔案上去時，都會是有一個 commit 動作，告訴 ipfs 你提交哪個檔案版本。 弱勢 當網路提供節點全部失效時則拜訪不到檔案(如同BT種子沒人上傳一樣) 節點解決方案 提供獎勵機制鼓勵人提供節點 將檔案分佈儲存 -> 結合區塊鏈: filecoin 透過提供鏈上獎勵代幣與機制鼓勵節點持續在線獲得，並保證多節點存有副本。...

Query Builder 是一個強大的工具，用於構建和執行資料庫查詢。有時候我們可能需要更進一步地自訂 Query Builder，以滿足特定的需求。在這篇文章中，我們將深入探討 Laravel 的 Query Builder，並介紹如何使用 newEloquentBuilder 來自訂 Query Builder，以提供更彈性和強大的資料庫查詢功能。 創建一個自訂的ProductBuilder 類別，繼承 Illuminate\Database\Eloquent\Builder use Illuminate\Database\Eloquent\Builder; class ProductBuilder extends Builder { public function available() { return $this->where('status', 'available'); } } 接下來，我們需要在相應的 Product 模型中指定使用自訂的 ProductBuilder，而不是默認的 Builder： use Illuminate\Database\Eloquent\Model; class Product extends Model { /** * Get a new query builder instance for the model. * * @param \Illuminate\Database\Query\Builder $query * @return \App\Builders\ProductBuilder */ public function newEloquentBuilder($query) { return new ProductBuilder($query); } } 我們可以在使用 Product 模型進行查詢時，使用 available() 方法來篩選已上架的產品：...

在 Laravel 開發中，我們經常需要處理複雜的多維陣列數據。遍歷和操作這些多維陣列可能變得困難且冗長。幸運的是，Laravel 提供了一個強大的 Collection 類，並且我們可以通過自定義方法擴展 Collection 的功能。 新增 recursive 方法到 Laravel Collection 首先，我們需要將 recursive 方法添加到 Laravel 的 Collection 中。這可以通過使用 Collection::macro 方法來實現。這個方法允許我們自定義 Collection 的新方法。以下是 recursive 方法的程式碼： use Illuminate\Support\Collection; Collection::macro('recursive', function () { return $this->map(function ($value) { if (is_array($value) || is_object($value)) { return collect($value)->recursive(); } return $value; }); }); 使用 recursive 方法遞迴處理多維陣列 現在我們已經將 recursive 方法添加到 Laravel Collection 中，我們可以在我們的項目中使用它來遞迴處理多維陣列了。以下是一個示例： $collection = collect([ 'name' => 'John', 'age' => 30, 'address' => [ 'street' => '123 Main St', 'city' => 'New York', 'country' => 'USA', ], ]); $result = $collection->recursive(); $result->dd(); 在上面的示例中，我們創建了一個包含多維陣列數據的 $data 變數。然後，我們將它轉換為 Laravel Collection 並存儲在 $collection 中。接下來，我們使用我們剛剛添加的 recursive 方法對 $collection 進行遞迴處理。最後，我們使用 dd() 函式來輸出處理後的結果。通過新增 recursive 方法到 Laravel Collection，我們可以輕鬆地處理多維陣列數據。遞迴處理多維陣列能夠幫助我們在 Laravel 項目中更有效地遍歷和操作數據。