Darkthread

黑暗執行緒
  • 【茶包射手日記】預訂五十年後執行的排程

    近來異常充實,專案火燒屁股,大小茶包報案照常受理,生活好不精彩。遇到一枚奇妙茶包,追了好一會兒,謎底卻令人莞爾,為枯躁生活平添一絲趣味,特記上一筆。 同事報案,表單系統在歸檔時有個錯誤重試機制,出錯時自動休眠 30 分鐘再試,另外,系統亦接受程式指定於特定時間(稱為喚醒時間)重試。 監看報表出現多筆詭異喚醒時間,排定在 2058、2075、2052、2081、2068、2057、2055... 等 40-70 年後的日期,預訂於遙不可及的未來執行。嘗試分析詭異喚醒時間與初次執行的關聯,找不出任何規律...
  • 【茶包射手日記】Windows 10 每天十點多固定醒來

    家裡 Windows 10 的使用率不高,平時長期處於睡眠狀態,但偶爾會發現無故醒來,我知道有部分 Windows 排程具有喚醒電腦能力,正常情況醒來做完事閒置一陣子會再回去睡覺,發現醒著多半是閒置休眠機制失靈,倒也沒特別調查。今天心血來潮挖了一下,發現一個祕密—原來我的 Windows 10 固定每天早上十點多都會起床夢遊,有趣的是,起床時間還不固定,甚至有最遲 10:57 才起來的記錄: 檢視事件詳細內容追到一個排程 NT TASK\Microsoft\Windows\rempl\shell...
  • CODE-使用 Stack<T> + yield 取代遞迴

    分享最近學到的遞迴邏輯的替代寫法。 舉個實例比較容易說明,假設公司組織樹狀結構以部門資料物件形式呈現: public class Dept { public string Name; public List<Dept> Children = new List<Dept>(); } 組織架構範例如下: { "Name" : "總經理" , "Children" : [ { "Name" : "行政部"...
  • Coding4Fun–自動產生副檔名轉 ContentType 對照表

    昨天的文章 提到 .NET 4.5 內建 MimeMapping.GetMimeMapping(),可省去自己用 switch … case 逐一列舉副檔名對應ContentType 的工夫。 不過,這項福利僅限於 .NET 4.5+,如果程式使用的是 .NET 3.5 或 .NET 4.0,只能乖乖自己處理。理論上,新開發的程式用 .NET 4.5.2+ 名正言順(參考:  蛤,微軟停止.NET 4.0-4.5-4.5.1的技術支援?會對我的系統造成影響嗎? ) BUT! 生活周遭總還是有...
  • C# 小技巧 - 不必再靠 switch case 副檔名決定 ContentType 囉

    由 ASP.NET 伺服器端傳回檔案內容,需指定適當的 ContentType,瀏覽器才會將其視為圖檔、HTML、CSS 或 JavaScript 處理。過去我都是土法煉鋼,取得副檔名再用 switch … case 針對已知檔案種類列舉對應 ContentType,像這樣: string contentType = "" ; switch (fileName.Split( '.' ).Last()) { case "jpg" : contentType...
  • 【茶包射手日記】Notepad 改 config 後程式掛點

    倉頡輸入筆記文 網友 s793016 留言提到 PRIME (中州韻輸入法) 內含倉頡輸入,簡單試用挺驚豔的(心得容後再寫),不過有個問題:必須新增簡體中文語系才能用,解法是修改 ime.json 檔將語系改為 zh-TW 重新註冊 PIMETextService.dll (參考: 在 Windows 10 下安裝最新版的 PRIME 中州韻輸入法方法 - Hiraku Dev )。修改 Program Files 目錄下的檔案需要管理權限,我選擇用 管理者權限開 CMD ,切到指定目錄下指令 notepad...
  • 【茶包射手筆記】Chrome 開發者工具看不到 Form Data

    使用 Chrom F12 開發者工具偵察 Web Form 送回內容,正常情況應如下圖所示,Content-Type 為 application/x-www-form-urlencoded,Request Headers 下方應有一區 Form Data 可檢視 Post 送回內容: 我所偵察的 ASP.NET 網頁,遇特定條件會透過 Resonse.Redirect() 轉址,此時 Response 收到 HTTP Status 302 很合理,但向下想查傳回內容,卻發現 Form Data 資訊區不見了...
  • 我的 Windows 10 倉頡中文輸入筆記

    使用倉頡輸入超過二十年,當年升級 Windows 8 時最震驚的莫過於「新倉頡輸入法」被移除,回頭改用必須選字的「倉頡輸入法」內心有萬頭羚羊狂奔。(但是另外也有很多人因為必須選字的「ㄅ半」注音輸入被移除哀嚎;輸入法這玩意跟信仰一樣,大家各有所愛且難以撼動) Windows 8 時代要裝回新倉頡跟ㄅ半很麻煩,還需要複製安裝輸入法檔案(參考: 如何在 Windows 8 中新增注音 (ㄅ半)、新倉頡、新速成輸入法 ),Windows 8.1 起新倉頡等輸入法改回內建但隱藏,修改機碼(Registry...
  • 2017 觀音山馬

    山路跑滿跑好的小而美觀音山馬,連續第三年。( 2016 、 2015 ) 氣象預報週五放晴一天,週末兩日又再陰雨濕冷。週六一早雨勢不小,心想不妙,今年「跑馬總有好天氣」運勢已劃上句點了嗎?週日一早起床,啊哈! 雨停了,感謝老天。 七點才起跑不用摸黑早起真好,六點半抵達微風運河,會場跟上一場 根除小兒麻痺扶輪社公益路跑 相同,只是今天有硬斗的山路等著我... (抖) 遠方天空滿是黑鴉鴉的烏雲,但沒下雨已屬萬幸~ 蘆洲地方特色—神將,大會口號:「跑馬有神助,輕鬆跑山路」。連跑三年從沒感覺山路輕鬆過,可能是跑前忘了跟神將合照...
  • 筆記:比特幣挖礦在挖什麼?

    區塊鏈跟比特幣最近熱到發燙,沒幻想過靠它致富(甚至覺得仰賴鉅量能源運作的虛擬貨幣很不環保),倒是對其原理奧義充滿興趣。先前看過不少深淺文章,限於慧根,對其運作原理仍一知半解,知道所謂礦工挖礦類似暴力破解雜湊(Hash)函式,對為什麼驗證交易真實性會扯上破解雜湊值毫無概念。 今天看完一部介紹短片(其實不算短,26分20秒)豁然開朗,欣喜之餘推薦給跟我一樣有興趣了解比特幣挖礦在挖什麼碗粿的同學:(記得開中文字幕。影片還算淺白,但真心覺得要懂公私鑰、雜湊碼,有粗淺密碼學基礎才能下嚥) 影片 隨手筆記重點如下...
  • 使用 CSS 實現標題單行置中多行靠左

    跟同事討論到一個需求,要在顯示文章的網頁實現「標題只有一行時置中顯示;若文字較多折行時則靠左對齊」的效果。起初程序員大腦想到的做法是用 JavaScript 依文字長度動態調整 text-align 樣式,但由於折行與否是瀏覽器依字型大小、容器寬度自行裁量,難以依據字數直接推算,於是我開始揣摩由文字元素高度偵測行數的雞鳴狗盜招術... 爬文 後才發現我把事情想得太複雜了,這個需求用 CSS 就能搞定,一行程式都不用寫。做法是用 <div> 包住 display: inline-block...
  • 【茶包射手日記】網頁在某支手機無法使用

    同事貢獻新鮮茶包一枚。查到最後發現是低級錯誤,但念在用電話跟 LINE 遠端偵錯耗了三個小時,值得記錄並列為日後問題排除參考。 最初的報案內容是某位使用者剛換了 iPhone 8 新手機,要連上某個例行工作網站查資料,輸入帳號密碼卻無法登入。我們試了自己的手機及平板檢測正常,原以為是使用者個人帳號被鎖或失效導致登入失敗,但檢查帳號狀態正常, 歷經一陣 雞 同鴨講 追問細節後才搞清楚,其實登入有成功,而是畫面不正常且無法操作。(跟報案內容大不相同,隔空抓藥好刺激呀) 為對照比較,商請使用者借其他人的手機測試結果正常...
  • Chrome 網頁中文變醜之謎

    我習慣將 Chrome 標準字型設成 思源黑體字型 , 除非網頁硬將 font-family 指定成細明體(例如: Mobile01),換了字型讓網頁質感變好,比新細明體賞心悅目許多。 Pocket 是我慣用的稍後再讀服務,在 FB 或爬文時看到不急著看但值得花時間讀的相關文章,我會先丟進 Queue 裡收藏,有空再讀。在使用 Pocket 網頁介面閱讀文章時我注意到一件事 – 文字閱讀模式(不開啟原始網頁,改用 Pocket 自訂樣式呈現文章內容) 下,標題字型是 Chrome 預設的思源黑體沒錯...
  • 全文檢索筆記 – Lucent.Net (4) 詞庫校正

    體會過自動分詞(一元分詞、二元分詞)與詞庫分詞的 特性差異 ,但是到目前為止有個問題一直被忽略,我測試用的詞庫直接下載自網路,內容是簡體中文,拆解精準度大有問題。 以 CWSharp 詞庫分詞為例,使用 Github 下載的 cwsharp.dawg 詞庫檔 分析這句中文「競選活動已日趨白熱化,參選人莫不全力尋求廠商支援,其中以鄭少秋勝算最大。」,使用 Luke.net 查看分詞結果如下: 雖然還是能查到關鍵字,但分詞結果並不好,幾乎都拆成單一字元,跟一元分詞沒什麼兩樣。這意味詞庫命中率極低,其根本原因在於我們用的詞庫是簡體...
  • 全文檢索筆記 - Lucene.Net (3) 自動分詞 vs 詞庫分詞

    前篇筆記 試用了盤古分詞器跟 StadnardAnalyzer,繼續研究其他分詞器選擇。 英文能依據空白快速精準分詞,中文沒這麼幸運,必須借助演算法,邏輯複雜許多。中文分詞主要有兩個方向: 第一種是自動分詞,依循固定規則自動切分,例如: 一元分詞、二元分詞;第二種則是詞庫分詞,查詢詞庫識找出已知詞彙;也有分詞器選擇兩種做法兼用,以求互補。 一元分詞與二元分詞的優點是做法簡單,不需維護詞庫,但其索引幾乎跟原文一樣大,查詢效率也較差;詞庫分詞的索引可縮小到原文的 30%( 參考 ),但詞庫完整性是成敗關鍵...
更多文章 下一頁 »
Powered by Community Server (Non-Commercial Edition), by Telligent Systems