kyosora 筆記

為什麼要把大表拆成小表一張上千萬筆的資料表，查詢愈跑愈慢、維護視窗愈拉愈長，這幾乎是每個後端工程師遲早會碰到的場景。把它依某種規則拆成多張較小的表，是其中一種權宜手段：查詢範圍縮小、維護單位變細、歸檔也比較好搬。 SQL Server 的 SELECT INTO 很適合做這件事——它能根據查詢結果直接生出一張新表，省去你先寫一段 CREATE TABLE 再 INSERT 的功夫。但它「省」掉的東西比你以為的多，這篇就把運作原理講清楚，順便把幾個照抄會直接報錯的地雷標出來。 SELECT INTO 到底複製了什麼先把最容易誤會的觀念釘死。執行這一句： 1SELECT * INTO 新資料表 FROM 來源資料表; SQL Server 會做的事是： 建立一張新表 複製來源欄位的「名稱、資料型別、可空性」，以及 IDENTITY 屬性 把符合條件的資料列寫進去 它不會複製的，才是重點：索引、主鍵、外鍵、DEFAULT、CHECK 等任何約束，全部都不跟過來。微軟官方文件對 INTO 子句的描述很直接：「來源表上定義的索引、約束與觸發程序不會轉移到新表，你也無法在 SELECT...

把一個大型語言模型跑在自己的筆電上，過去要先搞定 CUDA、PyTorch、各種 Python 依賴，光環境就能耗掉一個下午。Ollama 把這整段流程收成一個安裝檔加一行指令：ollama run，模型就在本機跑起來，資料不出機器，也不用付 API 費用。 這篇談 Ollama 的安裝、常用指令、API 整合，以及最容易踩的兩個雷：API 回應解析和模型自訂檔的格式。 Ollama 是什麼它是一個用 Go 寫的開源工具，把模型下載、權重管理、推論伺服器這幾件事包在一起。核心特點： 一個指令下載模型、開始對話，不用手動處理權重檔 內建一個跑在 localhost:11434 的 HTTP 伺服器，提供 REST API 同一份指令在 Windows、macOS、Linux 都通用 模型庫涵蓋 Llama、Gemma、Qwen、DeepSeek 等主流開源模型 要留意的是它走的是量化模型路線（預設多為 Q4 量化），換來的是更低的記憶體門檻，代價是輸出品質略低於原始全精度權重。對本機實驗、開發測試夠用；要追求極致品質得另尋方案。 安裝系統需求 作業系統：Windows、macO...

為什麼要移動 Ollama 模型？Ollama 預設把所有模型檔案丟在 C 槽，下載幾個大模型之後系統碟就開始告急。本教學帶你把模型搬到 D 槽，並在確認搬移成功後刪掉 C 槽的舊資料，真正把空間釋出來。 移動前的準備工作 確認 D 槽有足夠空間 在右下角系統匣對 Ollama 圖示按右鍵選「Quit Ollama」，確認背景程序完全停止（直接關視窗不夠，背景程序還在跑） 若有自訂 Modelfile 或用 ollama create 建立的本地模型，先把 Modelfile 另存備份；官方預建模型可隨時用 ollama pull 重下，不需額外備份 詳細移動步驟步驟一：建立新的存放位置 在 D 槽建立新的資料夾：1mkdir D:\Ollama\models 注意這裡多建了一層 models。Ollama 真正的模型檔放在 .ollama\models 底下（裡面有 blobs\ 和 manifests\ 兩個子資料夾），稍後的環境變數要對準這一層，否則 Ollama 會在錯誤的路徑找不到模型。 步驟二：移動現有模型 打開檔案總管，預設模型位置在： 1C:\Users\...

資安弱掃跑完，報告上一條紅字：偵測到過時的 SSL/TLS 協定。很多人看到就把 TLS 1.0、1.1、1.2 全關掉，只留 TLS 1.3——想說版本越新越安全。 問題就出在這：弱掃從來沒叫你關 TLS 1.2。把 1.2 一起關掉、只留 1.3，在 Windows 伺服器環境幾乎一定出事——網站連不上、SQL Server 連不上、舊的內部系統全掛。下面拆解為什麼，以及正確的做法。 先搞清楚：弱掃到底要你關什麼弱掃報告寫「過時的 SSL/TLS 協定」，指的幾乎都是 SSL 2.0/3.0 和 TLS 1.0、1.1。這幾個有已知的結構性弱點（POODLE、BEAST 那一掛），該關。 TLS 1.2 不在這個清單裡。它到現在仍然安全、主流、被廣泛支援。常見的合規型弱掃通常不會要你停用 TLS 1.2。 法規這邊也說得很清楚。PCI DSS 4.0 的要求是「TLS 1.2 或更高」，把 SSL 和 early TLS（1.0/1.1）列為不合規。它從來沒要求你用 TLS 1.3——TLS 1.2 完全合規。所以「只留 TLS 1.3」這種建議，不是弱掃的要求，是誤讀。 為...

前言做資安弱點掃描，最常踩到的地雷之一就是 SSL/TLS 設定。掃描報告跳出一堆「Server supports TLS 1.0」、「Weak cipher suite detected」，修法不外乎就是去翻 Windows 登錄檔——路徑又長，改錯一個值可能把整台伺服器的 HTTPS 搞壞。 IISCrypto 是 Nartac Software 做的免費工具，把這些作業全包進圖形介面，幾分鐘內就能把 TLS 設定從滿江紅改成合規狀態。 什麼是 IISCrypto？IISCrypto 是 Windows 伺服器上的 SSL/TLS 設定管理工具。它底層還是在改 Windows 登錄檔，但省掉你自己找路徑、手動調值的過程。主要能操控三件事：啟用或停用哪些加密協定、調整加密套件（cipher suite）的優先順序、設定簽章演算法的選項。 系統需求：Windows Server 2012 或以上、本機管理員權限、.NET Framework 4.6.2 或以上。 為什麼用它？PCI DSS 合規需求PCI DSS v4.0 要求停用 SSL 和 early TLS（也就是 TLS...

你是否也有瀏覽器書籤雜亂無章的困擾？資料夾一層又一層，想找個網站卻要翻找半天？本文將分享一個實用的書籤整理方法，讓你輕鬆管理數千筆書籤！ 問題背景在日常使用瀏覽器的過程中，我們常常會儲存各種有用的網頁。隨著時間推移，書籤數量暴增，資料夾結構也越來越複雜。就像我遇到的情況： 4,000+ 筆書籤 400+ 個資料夾 多層巢狀結構 找尋特定書籤耗時費力 解決方案概述為了徹底解決這個問題，我設計了一個完整的書籤整理流程： 匯出所有書籤 使用 Python 程式將書籤結構扁平化 重新匯入瀏覽器 使用擴充功能找出重複書籤 透過 JavaScript 批次處理重複項目 詳細步驟說明1. 匯出書籤在 Chrome 書籤管理員（chrome://bookmarks/）右上角點三點選單 → 匯出書籤，會下載一個 .html 檔案，包含所有書籤的網址、標題、加入時間等資訊。 2. Python 程式處理先安裝相依套件： 1pip install beautifulsoup4 使用 BeautifulSoup 處理匯出的 HTML 檔案，把所有書籤拉到同一層： 123456789101112...

前言某一天，系統突然開始出現詭異的現象：使用者回報網站時好時壞，重新整理一次可能好，但下一秒又壞了。查看記錄檔發現大量的 403 Forbidden 錯誤，但最讓人困惑的是，同一個檔案，有時候能載入，有時候卻被封鎖。這到底是怎麼回事？ 1. 檔案/資料夾權限設定問題先從最常見的原因開始排查： 確認網站資料夾的 NTFS 權限是否正確 IIS_IUSRS 和 IUSR 使用者需要有讀取權限 Application Pool 身份對網站目錄需要有讀取權限 2. IIS 設定檢查 在 IIS 管理員中確認網站的身份驗證設定 檢查是否啟用了正確的驗證方式（如匿名驗證） 確認網站綁定設定是否正確 以上全部確認過，都沒有問題，403 依然持續出現。 問題的關鍵：動態 IP 限制設定以上都查過沒問題之後，只能在網站上重複重新整理，同時盯著 IIS 記錄檔看。記錄檔裡確實有很多 403，但看不出理由。接著注意到一件事：原本 403 的檔案忽然正常了，反而其他檔案變成 403。多重整幾次，每次被影響的檔案都不一樣。 到這裡方向就清楚了。這不是靜態的權限問題，而是動態封鎖——問題的源頭是 II...

為什麼要學習除錯技巧？身為工程師，寫程式只是第一步，找出並解決程式中的問題才是真正的挑戰。Visual Studio 提供了完整的除錯工具，善用這些工具不只能快速找出 Bug，更能讓你深入理解程式的執行流程。本文從基礎中斷點到遠端除錯，帶你完整掌握 VS 的除錯技巧。 1. 中斷點（Breakpoint）的使用中斷點是除錯最核心的功能。程式執行到中斷點時會暫停，讓你檢查當前的變數值、呼叫堆疊與程式狀態。 123456789101112131415// 一般中斷點：點擊行號左側的灰色區域即可設定public void ProcessData(string data){ var cleaned = data.Trim(); // ← 在這裡設中斷點，程式會在此暫停 var parsed = Parse(cleaned); // 然後用 F10/F11 逐步往下走 Save(parsed);}// 條件中斷點：右鍵中斷點 → 條件（Condition）// 只在特定情況才中斷，避免迴圈裡每次都停public void ProcessLo...

把密碼、API 金鑰或一個幾百 MB 的檔案不小心 commit 進 Git、又推上遠端——這時候光 git rm 沒用，它還躺在歷史裡，任何人 clone 下來都翻得到。要真正清掉，得重寫 Git 歷史。 Git 內建的 filter-branch 能做，但它慢、容易出錯，官方文件自己都標示不建議用了。現在的標準工具是 git-filter-repo。 什麼是 git-filter-repo用 Python 寫的開源工具，專門重寫 Git 歷史，是 filter-branch 的官方推薦替代品。比起 filter-branch，它快上一個量級、命令更直覺，還會自動做安全檢查（例如要求你在乾淨的 clone 上操作）。 安裝123pip install git-filter-repo# 或 Ubuntu/Debiansudo apt install git-filter-repo 情境一：移除意外推送的敏感資料1234# 移除符合 glob 的檔案git filter-repo --path-glob '*config.json' --invert-path...

目錄 為什麼需要限流 常見限流策略 .NET Core 實作方案 分散式限流方案 最佳實踐建議 環境配置建議 效能測試方法 為什麼需要限流API 限流（Rate Limiting）的核心需求只有一個：保護服務本身不被流量壓垮，同時讓合法使用者繼續正常運作。這件事比聽起來更微妙——設太緊會誤殺正常請求，設太鬆則保護不到位。 幾個實際場景： 單一 IP 在 10 秒內打了 5,000 次請求，幾乎可以確定是爬蟲或攻擊 雲端服務按 API 呼叫次數計費，沒有限流的話一個 bug 就能讓帳單爆表 資料庫連線有上限，突發高併發會讓所有請求一起逾時，而非只讓超額的那些失敗 常見限流策略 限流策略 實作複雜度 記憶體消耗 精確度 突發流量處理 分散式實作 固定窗口 低 低 低 差 易 滑動窗口 中 中 高 中 ...