Darkthread

黑暗執行緒
  • 2017 渣打馬拉松與 SUB 4 之夢

    跑馬當踏青,荒唐一整年,總得有場玩真的,渣打馬就是你了! 去年 渣打馬 遇到連貓空都下霰的霸王級寒流,今年雖是暖冬,渣打馬照例再跟入冬最冷寒流強碰,原本預測將到 10 度以下,最後是 11 度的乾冷天氣。老天爺送上大禮,加上近來無傷無痛,這様還破不了 PB(個人最佳成續)豈不人神共憤,天地不容? 賽前我還很 假掰 認真地參考 RunningQuotient 分析報表調整跑量,設法拉高狀況指數(狀況=體能-疲勞),破 PB 勢在必得。 我的 PB 是 2015 年國道馬 創下的 4 小時 15 分...
  • Oracle 追討 Java 授權費議題之研究心得

    前陣子有 Oracle 對企業追討 Java 授權費的新聞搞得人心惶惶: Oracle 開始追討 Java 授權費,企業客戶頭痛 - TechNews 科技新報 Java用戶注意! 傳甲骨文開始加強取締未經適當授權用戶 - iThome 被很多人問到「為了跑 Java 程式裝 JRE/JDK 也會被收錢嗎?」「裝什麼版本才會被收錢?」… 身為 Java 麻瓜,我知道才有鬼,新聞寫得不是很清楚,自己也好奇有無方法排除侵權疑慮,故門外漢爬文整理心得如下。(聲明:對此領域全然陌生,純為爬文心得拋磚引玉...
  • ASP.NET CPU 飆高問題之傻瓜分析工具-DebugDiag Tools

    昨天 使用 WinDbg 追查 ASP.NET CPU 100% 原因 的文章得到不少朋友的回饋,其中 Robert Hu 留言提到一個更方便的 Dump 擷取與問題分析工具,試用之下果然犀利,在此補上介紹。 Debug Diagnostic Tool (DebugDiag) 是微軟針對程式當掉(Crash)、當住(Hang),以及記憶體洩漏(Memory Leak)等問題設計的快速偵察工具,目前最新版為 Debug Diagnostic Tool v2 Update 2 ,共有三項兵器: DebugDiag...
  • WinDBG 應用實例:找出 ASP.NET CPU 100% 原因

    故事是這様的,我們有一批網站搬到新主機出現詭異現象:每隔一段時間某些 IIS AppPool Process 會吃滿 25% CPU 使用量,在 4 核機器這象徵有一條 Thread 陷入無窮迴圈吃光一個 CPU Core 的時間。有時也會出現多個 AppPool 同時發難,每個 Process 吃 25%,把整體 CPU 使用率逼上 50%、75%,甚至 100%。出問題時,該 AppPool 網站仍能使用,但無法透過 IIS 管理回收 AppPool,只能用 TaskManager 砍掉 Process...
  • 好問題:GUID 真的不會重複嗎?

    前幾天,「系統產生的 GUID 是否可能發生重複?」在辦公室引起熱議。我主張:GUID 透過網卡 MAC 地址、產生時間以及一些機制(防止同時間點產生兩筆或時鐘往回調)確保世上任何電腦都不會產生相同 GUID,只要所有電腦的 MAC 地址沒有亂來,理論上不可能發生重複。這說法挺有說服力,解除了大家心中的疑慮。 BUT,禁不住好奇爬了文,這才發現「我錯了!」 倒不是不該信任 GUID 永不重複,而是我們現在使用的 GUID 早已不是依據 MAC 及時間產生,而是靠隨機亂數產生。 GUID(Globally...
  • ActionFilter Attribute 共用特性與狀態保存

    同事報案,某個 Web API 會不定期出錯。進一步調查是近期啟動的一個新排程同步發出多個 API 呼叫,當 Web API 同時被多方呼叫,Web API 加掛用來寫 Log 的 ActionFilter Attribute 偶爾會發生 Dictionary.Add 重複加入相同鍵值的錯誤。因 Dictionary 被設成 ActionFilter Attribute Instance 的私有欄位,依我原先的理解,ActionFilter Attribute 每次呼叫時都應建立新 Instance...
  • 【茶包射手筆記】在 View 使用 SELECT * 的風險

    分享同事踩到的 SELECT * 地雷一枚。 大家應該在程式設計準則都看過這條-「避免使用 SELECT * FROM Table,應以 SELECT Col1, Col2… 明確列舉欄位…」。 如此建議必有其考量:第一個理由顯而易見,正向表列必要欄位,可避免在網路傳送用不到的資料浪費頻寬,並能減少客戶端、伺服器端處理多餘資料的資源損耗。再者,查詢欄位多寡也可能影響效能,SELECT * 時為牽就非必要欄位,資料庫可能改用較無效率的索引,不利效能最佳化。還有一種極端情境,若所需欄位都存在於 Non...
  • 用 100 行 C# 打造 IP 所屬國家快速查詢功能

    講到由 IP 地址查詢所屬國家,解決方案有兩種:第一種是直接呼叫線上查詢 API(付費或免費),再不然就要下載 IP 區段資料庫自寫查詢程式。考量應用場合不一定有 Internet 連線能力,加上擔心線上 API 無法滿足 IIS Log 等超大量 IP 解析的效能要求,選擇取回資料檔自幹。(其實是因為這題目大小難易適中,十分適合練功,一時手癢難耐,就…) 爬文找到一些 IP 國別對應資料來源: Maxmind GeoIP2 https://www.maxmind.com/en/geoip2-country...
  • 使用非同步處理提升資料庫更新速度

    來自同事的資料庫程式效能調校案例一則。 情境為一支同步來源及目的資料表的排程,先一次取回來源及目的資料表,逐一檢查資料是否已存在目的資料表,若不存在即執行Insert,若存在則執行 Update 更新欄位。因 Insert/Update 之前需進行特定轉換,故難以改寫為 Stored Procedure。排程有執行過慢問題,處理四萬筆資料耗時近 27 分鐘。 程式示意如下: foreach (var src in srcList) { try { var target = findExistingData...
  • 小試 IIS 的簡易 DoS 防護-動態 IP 限制

    這幾天,DDoS 攻擊事件在台灣鬧得沸沸揚揚。 DoS 攻擊 可約略分為頻寬消耗型(找一大群鄉民擠在餐廳門口)及資源消耗型(召喚服務生過來點菜連點兩鐘頭,或一口氣點兩百盤紅燒獅子頭),從網站管理者的角度,對頻寬消耗型攻擊完全無能為力,只能靠 ISP 或網管單位防禦;但對於資源消耗型攻擊,倒是有些因應對策。(例如:把十分鐘還沒點完菜的客人攆出去或把點兩百盤獅子頭的客人打成豬頭) 我知道有一些 ASP.NET 設定就與 DoS 防護有關,例如:每次搞檔案上傳時都要手動調大的 MaxRequestLength...
  • 徹底移除已簽入TFS的項目

    保留完整版本變更歷程是版控系統的核心精神之一,檔案項目一旦簽入,就算使用者要求刪除,項目從清單上消失,仍可透過歷史記錄還原每一個曾簽入的版本。 實務上,偶爾會發生不慎誤將不該簽入內容丟上版控的狀況(例如:誤簽入個資或機密敏感內容),此時版控對保留完整軌跡的堅持變成缺點,不管刪除或 Rollback 都無法防止他人透過歷史記錄還原內容。 非常狀況只能用非常手段,在 TFS 上遇此種狀況,tf.exe 工具有個 destroy 指令 可以解決問題。 語法範例如下: tf destroy $/src/path...
  • 生態池日記-豆娘羽化觀察

    【警告】照片裡挺可愛的豆娘,小時候住水裡叫做水蠆(發音同「菜」),長得不太稱頭(其實是醜到讓人不蘇湖),文章內有水蠆的「近距離寫真」,請大家視身心狀態自行評估,看完以上照片就關掉網頁,只留下美好印象也是不錯選擇。 【背景知識】 蜻蜓 與 豆娘 都屬於蜻蛉目,主要差異在於停止時翅膀平放展開或收合。二者的稚蟲都叫做水蠆,生活在池塘或溪流,以昆蟲、小魚或蝌蚪為食。 延伸閱讀 防雷緩衝區起點 防雷緩衝區終點 願意把捲軸拉到這裡的同學,已展現對自然生態的好奇與熱愛,我們進入正題。 前些日子在水蘊草上看到一隻怪蟲...
  • 在 Chrome/Edge 網頁用 IE 開啟超連結

    這是 IE Only 網站親衛隊才有的困擾。 許多內部系統年代久遠,寫於全天下瀏覽器只有一種(IE)的時代(2004 年 IE 市佔高達 95% [ 參考 ]),寫成 IE Only 也是很合理的事。但你我都知道,時代不同了,滿天都是飛機啊,滿街都是電腦啊,HTML5 世代 IE 早已不是最好的瀏覽器選擇。望著公司那堆 IE Only 的 生財工具 營運系統網站,即使它們遲早要汰換,但也不是說翻就翻?有些規模數十人月的大專案,問君能有幾副肝,恰似鞭炮爆不完? 所以囉,繼續再跟 IE Only 網站和平共處十年...
  • Autofac筆記6-Resolve時依參數傳回不同型別

    好久沒寫 Autofac 筆記 ,記錄一則最近遇到的小需求。系統中針對介面(例如:IBlah)實作了多個型別,Resolve<IBlah>() 時希望透過參數指定傳回不同型別。 依據 官方文件 ,實現這類需求的最簡單做法是使用 Named Service(具名服務)或 Keyed Service(鍵值對應服務), Register<T>() 後不使用 As<IBlah>(),而改用 Named<IBlah>("服務名稱") 或 Keyed<IBlah>...
  • 【茶包射手日記】Windows 沒有足夠資訊可以確認這個憑證

    某台持續爬網頁抓資料的排程忽然出現 The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel 訊息,推測為 SSL 憑證失效引起。 連至該主機使用瀏覽器檢視,果真憑證顯示異常: 錯誤訊息如下: Windows does not have enough information to verify this certificate. Windows...
更多文章 « 上一頁 - 下一頁 »
Powered by Community Server (Non-Commercial Edition), by Telligent Systems