迴響
2011 年的 2 月 11 日，在倫敦的洲際飯店裡，Elop 從秋季截至初冬為止的奔波，就在此時登上了最終的頂點。關於 Nokia 將選擇 Windows Phone 平台的消息已經傳開。在經過一些開場話後，Elop 身著深灰色的西裝及領帶步上講台。而就在他發表演說的同時，投資人已經用行動做出回應──Nokia 的股價下挫了 14 個百分點。
Elop 首先簡短地陳述，手機市場是如何地發生轉變；以及裝置之間的競爭，又是如何地轉變成生態系統的競爭，而 Nokia 又將如何在當中獲勝。接著 Elop 引述了邱吉爾（Winston Churchill）曾說過的一段話：
悲觀者在所有機會裡見到的都是困難；樂觀者在所有困難裡見到的都是機會。
在 Elop 的論述裡，所有的科技成就都是由樂觀精神締造出來的。他對於 Nokia 與微軟能夠一同攜手合作感到興奮，兩間公司同心協力，就能夠在這場生態系統的競爭中殺出重圍。
這是一支很簡單的 C 程式，而作用也是極其單純，執行時會每隔 60 秒觸發 Windows 鍵的按下動作，藉此避免 Windows 系統在無人操作的情況下，進入閒置狀態。此外也可以透過「insomnia.exe <秒數>」的方式來指定觸發簡隔。
乍看之下這似乎是一支很無聊的程式……然而對 DR 偶然的工作需求來說是有意義的。在進行個人電腦測試時，某些情況下可能會希望系統不會自動進入例如螢幕關閉、或者是休眠等節能措施，但又不想要因此更動 Windows 預設的電源管理設定。所以一種變通方式，就是跑一支簡單的程式，持續發送輸入事件給系統。
由於已事隔快要一年，看起來狀態並沒有什麼變化，所以或許是時候說明一下狀況，以及可行的應對方式。在目前 Red Hat 生態體系的各個 Linux 發行版裡，倘若要實現 WireGuard 支援，則 CentOS Stream 8（以下簡稱 CS8）可能是當中最不簡便的一款發行版。而背後的因素，其實也連帶影響了下游的 RHEL 8 及其複製品（AlmaLinux 8、Rocky Linux 8 等等），只是就時序而言，下游的處境可能會稍微好一點。
操作環境：
賽車遊戲並不算是 DR 很熱衷的遊戲類型，所以無法肯定究竟是童年回憶太美，還是這款遊戲真的有什麼特別出眾之處。但無論如何，《驚爆實感賽車 2》（Screamer 2，1996）是 DR 第一款有深刻印象的 3D 賽車遊戲。在 DR 的記憶裡，這款遊戲有著生動的賽道場景、很有感的操控特性，以及非常純粹的遊戲內容。每次回想好像有什麼賽車遊戲做得很不錯的，很容易都會想起這款遊戲。
操作環境：
1999 年的《夢幻遙控車》（Re-Volt），即如其中文遊戲名稱所表示的，是一款罕見地以遙控車為主題的賽車競速遊戲。雖然說是一款蠻老的賽車遊戲，但背後的社群生命力卻是相當驚人。存在像 RVGL 這樣以跨平台技術重製的版本，不僅是更適合在現今的系統環境下執行，並且還增添了原始 PC 版本裡缺少的功能，如分割畫面（split-screen）的多人遊戲等等。
其實原先 DR 並不期待《龍與地下城》（Dungeons & Dragons，D&D）這款歷史悠久的角色扮演遊戲設定，能夠被再一次地改編上大螢幕，沒錯，「再一次地」，因為事實上早在 2000 年的時候，就曾經有推出過一部院線電影（Dungeons & Dragons）。然而那部電影的迴響並不是很好，DR 記得自己甚至提不起興趣把它看完；反而是對後來的續集（Dungeons & Dragons: Wrath of the Dragon God，2005）有比較正面的記憶，很有可能算得上是非院線續作比前作還要好看的少數案例之一。
有點令人出乎意料的，是本片相較於前一部作品（John Wick: Chapter 3 - Parabellum，2019）確實有蠻大的改進。原先 DR 對於第三集最有意見的地方是它的劇情。雖然動作片的劇情確實不是很重要，但第三集的劇情流程是弱化到讓 DR 看得有些皺眉。然而在這部《捍衛任務 4》（John Wick: Chapter 4）裡，創作者卻似乎是找到了一個絕佳解法：在劇情上完全放棄治療，然後運用表現強勁的人物角色、以及充滿藝術風格的視覺場景來加以補強──看似離奇，但竟然是有效的。
應該是在 2014 年的時候，DR 有曾經玩過《駭客入侵：人類革命》（Deus Ex: Human Revolution，2011）這款遊戲。當時留下很好的印象，但由於那時還沒有形成慣例，為破台的單機遊戲撰寫心得，所以後來一直覺得沒有留存一篇心得是件蠻可惜的事。不過在接觸了《人類革命》之後，DR 自然就對初代《駭客入侵》（Deus Ex，2000）的表現究竟如何感到好奇，於是就在近期安裝起來玩玩看。
似乎很少看到有文章認真地探討，該如何適當地撰寫軟體系統中的錯誤訊息。來自 Wix UX 團隊的文章《When life gives you lemons, write better error messages》，描述了 Wix 網站平台如何對錯誤訊息的表達做出檢討，擬定新的原則，並投注心力加以改善。
這是一篇很值得一讀的文章，雖然當中的概念，主要是針對一般用戶，可能不一定都適用在不同的情境中。比方說在微軟產品裡，經常是僅僅丟出一長串的錯誤代碼，讓使用者自己按代碼去搜尋解答。儘管這確實應該是有改善空間，不過採用錯誤代碼的方式，背後應該也是有其工程考量。而非蓄意的怠惰，然後把麻煩轉嫁在使用者身上。
在 DR 的觀念裡，倘若不知道錯誤訊息該怎麼寫，那麼最至少就是單純地把事實陳述出來。說明發生了什麼事，以及根據程式的設計邏輯，盡可能準確表達出問題的來源。