golang

Go security team 發表了 Vulnerability Management for Go 官方的漏洞管理掃描工具。 其中一個 govulncheck client 工具，可以針對二進位(binary)或程式原始碼(code base)掃描產生 call stack。 以官方維護的Go vulnerability database 儲存已知跟社群回報的漏洞(CVEs and GHSAs)， 背後的 Schema 以OSV, Open Source Vulnerability format v1.3 格式儲存跟封包傳輸， 所以開發者事實上可以寫自己的 HTTP GET API(參考) 搭配 Go 官方釋出的OSV Json Parser 就可以開發自己的檢測工具，不然用現成的就好。 # For source code $ govulncheck ./... # For Binary $ govulncheck $HOME/go/bin/my-go-program 試掃 grabit 漏洞 來試掃之前寫的 side project 股票: grabit[changelog]， 執行以後出現 7 個漏洞，都是golang 原生的 xml, encoding, http， 有明確的行數與解釋等資訊，如下...

古老問題了，即使影響十分廣泛也很嚴重，但是因為時間還久吧 !? 所以普遍被認為只要在 2038 年前修復即可，並沒有那麼有急迫性。 什麼是 Y2038 ? Year 2038 problem，也被稱作 Y2038、Y2k38、Unix Y2K、Epochalypse、Friday 13th Bug，一種時間格式儲存上的臭蟲。 主要是因為以前在設計 timestamp 時使用 signed-32-bit (4-Bytes) 來儲存計算的秒數，而4 bytes能儲存表示的最大時間是 2038年1月19日3時14分07秒，在這個時間點之後的系統無法正常工作。即使用 unsigned-32-bit 儲存，例如比特幣的 timestamp， 也只能延後到 2106 年。 影響層面 作業系統 到 2038 年前，大概剩 Embedded systems 或 IoT 設備這類不會大幅更換。 其他桌機/雲設備/機房主機，按照現在的發展大概都會被汰換掉成 64 位元。 Binary file formats 從 wiki 上看起來至少使用 32位元 time_t 編碼的有 ZIP 檔案。 而像現在最流行的以 json-based 往上長的格式，就不會造成此問題，因為一定是用 string 傳遞， 如果會發生問題，也是會發生在 json parser 這一端，看你用什麼去接。 programming language golang : go 沒有這個問題，因為 Time 本身就是用 64 bit 儲存...

我對演算法沒啥 sense，但是看到些相關對基礎(應該說基石)的改良增強，覺得很有趣。 這種演算法的在效能與空間上的改進並且被各主流平台語言接受，我猜大概是幾年一遇吧， 懂演算法又能做改良的人真是了不起！ Golang 將會在下一版(v1.19?)把預設的排序改為 pdqsort (Pattern-defeating Quicksort 也就是 Quicksort 改良版) 在這個commit 提到 Across all benchmarks, pdqsort is never significantly slower than the previous algorithm. In common patterns, pdqsort is often faster (i.e. 10x faster in sorted slices). The pdqsort is described at https://arxiv.org/pdf/2106.05123.pdf This CL is inspired by both C++ implementation and Rust implementation. C++ implementation: https://github.com/orlp/pdqsort Rust implementation: https://docs.rs/pdqsort/latest/pdqsort/ Timsort，hybrid stable sorting algorithm( merge sort 跟 insertion sort 的結合版)...

golang 的專案結構建議，我覺得 go 最佳實踐法比較見仁見智，蠻主觀的 ！ Go Best Practices: How to code comfortably go-clean-arch Standard Go Project Layout

cron tasks 有些具有可預測大約日期範圍的抓取，設為排程工作，避免沒事就去爬蟲頁面檢查點擊。 // 每天15:10(日線) cronTasks.AddFunc("30,50 15 * * *", func() { cronhome.MADaily(app) }) cronTasks.AddFunc("30,50 18 * * Fri,Sun", func() { cronhome.MAWeekly(app) }) cronTasks.AddFunc("30,40 13 * * Sat", func() { cronhome.MAMonthly(app) }) // 月營收: 每個月 1~18 日, every day between 1st and 15th lastMonth := now.AddDate(0, -1, 0) cronTasks.AddFunc("30 5,7,8,15,16,17,21,22,23 1-18 * ?", func() { cronhome.Revenue(app, lastMonth) }) // 今年公佈的股利 cronTasks.AddFunc("10 8,15,18,21 * * *", func() { cronhome....

因為想要練習寫 golang，在找不到題目的狀態下，剛好買了台 Mac-Mini M1 無法開卷商的 APP，想來想去乾脆直接就來寫一個自己使用. 目標 抓取個股月營收 解析網頁 寫入資料庫 比較數據 (開不開 Goroutines) 月營收爬蟲 Single Thread 17xx 間公司的月營收約 1 年份的數據筆數是 20,828 筆，抓取到寫入資料庫約 7.55 秒，不會掛點(被對方拒絕) 開 Goroutines 7倍效能，一定要開的啊 ! 數據筆數: 20,828 筆(1年份) 抓取到寫入資料庫約 1.1 秒完成 (Multi Thread) 把筆數拉大到 113,694 筆，約 48.58s (Single Thread) 開了 Goroutines 約 2.8s ~ 4.8s (Multi Threads) 開了 Goroutines 以後，週一到五比較沒問題，常會被遠方中斷，直到改成批次爬， 每一梯次只開 80 ~ 100 的 threads 完成之後再換下一個梯次， 這樣改法變得穩定多了，只剩下週六日會動不動就被擋下來， 要有完整被檔後再繼續爬不被拒絕的寫法這一點以後有空要研究一下。

因為想要練習寫 golang，在找不到題目的狀態下，剛好買了台 Mac-Mini M1 無法開卷商的 APP，想來想去乾脆直接就來寫一個自己使用. 目標 可根據財報/營收/均線/產業篩選條件篩選出想要的個股 可定義標籤做分類 可看個股過去表現 開發環境 Angular v12+ Tailwind CSS v2.2.4+ golang v1.16.6+ postgreSQL v13+