因緣際會下，受到老天的眷顧，在附近的診所排到了殘劑。在第一劑過了十週後，恰巧的完美銜接上時間，比起其他正在排隊搶打各種疫苗的我，就像是「自從吃了潵尿牛丸，我考試都考一百分！」
 |
| Photo by Spencer Davis on Unsplash |
與第一劑的不適感（微熱、微疼）相比，第二劑就像是被蚊子不痛不癢叮一下，完全感受不出副作用，只能說我真的是被認證的「老人」！與上次相同，施打後就在診所外休息並自我觀察十五分鐘，就可以回家。
比照上次的經驗，一樣買了兩千毫升的礦泉水牛飲，一路喝到睡覺前。第二天醒來就生龍活虎，跟日常無異！
再次的提醒，基於「保護家人與保護自己」前提下，不論是哪一種疫苗，還是請大家能快點打唷！除此，你還想知道：
口袋哭哭，錢沒有不見，只是變成你喜歡的樣子。
2017年所發入手的經典 iPhone X，一路陪伴到了 2021年的我，終於、逐漸、必然的在發表會之前，出現各種異常怪現象（故障？）。
電池老化是基本款。一般正常使用下電池可以提供約一年半至兩年左右的穩定電力，但我已經用了這麼久，至少電力還仍讓我正常從早上用到下班回家，但每天晚上固定充電以及隨身攜帶尿袋是家常。爾爾會發生耗電異常，電力一下子就從 60%掉到 10%以下，當然在失電過程中就是過熱、速度緩慢，最後當機！
另一個棘手的：靜音鍵，會在未切換靜音鍵的情況下，跳出靜音提醒，或者是切換沒反應。雖然有試著去網路上找尋各式偏方來嘗試，但總是只能撐個一陣子就失效。無奈只好放棄這顆按鈕，用牙籤的一短節，讓它固定在某個特定角度，成為裝飾的一環。
壓垮駱駝的最後一根稻草，是手機訊號。在訊號強烈的區域，訊號會突然急速下降，有時候能夠在一分鐘內正常，但後期幾乎需要重新啓動手機或是切換飛行模式才能恢復。
你知道我知道，獨眼龍也知道，發表會前的 iPhone是會跳一次水的，在敗家錢前，你還可以想想：
「慢活」這個詞，對某些人來說，早是老掉牙的意識形態。但是在 COVID-19疫情肆虐的當下，恰好是「慢活」的好時機，在這個人心惶惶的非常時刻，試著讓焦慮不上身，學習放鬆。
 |
| Photo by Benjamin Davies on Unsplash |
原本訊息爆炸、科技不斷更新、世界快速轉變的時代，在這次疫情升級時，不論你願意否，每個人都不得不慢下腳步（即使你一個人想快也是快不起來的）。
防疫升級後，我們能做的事情有限，活動範圍變小，選擇項目變少，不能「購物」、不能「運動」、不能「旅遊」，太多太多的不能，就趁著這「不適合外出」的防疫期間，「同島一命」的我們，來試試用更多屬於自己的時間試著「慢活」。
簡單來說，就是「慢慢」吃、「慢慢」走、「慢慢」說話、「慢慢」完成想做的事。在這段足不出戶的期間，看似很無聊，但剛剛好有一個機會把生命的重心回到自己身上。當一切都快不起來的時候，才能真正慢慢地過活。
想讓自己不再長期處於疲憊的話，你可能還想：
大家都是第一次遇到這樣的疫情，也盡力想要回到過去安穩平和的日子。
 |
| Photo by Clement Souchet on Unsplash |
現在台灣疫苗已經逐漸不缺，相關疫情從這禮拜也逐漸控制下來。比較起來，相對風險高的老人家，想打、能打的都也都打了。（包含我爸、媽）
我們應該可以在下一波疫情來以前，讓大部分的人都打上一劑疫苗，讓自身形成保護盾，阻止病毒🦠的擴散。
（謝謝打疫苗的朋友們❤️，不論你打的是哪種）
疫苗施打心得：
配合疫情的 WFH，坐在書桌前的時間增加四倍，而且變成要「長」時間使用滑鼠，如果在蘋果生態圈下倒還好，問題是 WFH要遠端連線回公司，會轉換成 Windows環境，在公司早已習慣使用滑鼠打理一切，沒有實在不行。
不知道 PCHome是放錯價格還是設定錯誤，雖然網頁上寫著加購價 990元，但仍可以讓我直接入手 MX ANYWHERE 2S這隻輕便小滑鼠。（圖文不符，對，我要講的是羅技，不是 Apple）
 |
| Photo by Math on Unsplash |
ＷFH 剛開始時，重新清點家裡面大大小小的 3C設備，找到塵封多年的 Magic mouse（在家因為工時短，都是直接在 Macbook上作業，久而久之便遺忘了它），原本興高采烈的要將 Apple設備大團圓，但卻發現裡頭那該死的金頂電池犧牲小我，將滿滿的電池液沾滿接點與底座。
嘗試著要救回那迷人又高「貴」的它，但無奈擺放多年，電池液的強酸應該早已腐蝕裡頭大大小小的元件，只能嗚呼哀哉當成擺飾品在桌上。
新入手的小巧 MX ANYWHERE 2S，身材適合外出攜帶，一手可以掌握，但比較適合手掌較小的使用者（我其實有點大手，但又捨不得多花錢買更高級的 MX MASTER 3）。MX ANYWHERE 2S滑鼠上有滾輪，這顆滾輪最大好處是可以左右扳動，在 Mac上就可以當作桌面切換（也可以自行定義功能）。
使用約莫一個月，在家使用期間是滑鼠與觸控板並行，約有 80%是透過滑鼠作業，但用超優惠價格買到這隻實在無可挑剃。在 Apple生態圈下的朋友不妨可考慮 MX ANYWHERE 2S作為攜帶首選，可悠哉在咖啡廳上跟著你兩個小時沒有問題。（只是，現在有咖啡廳可以去嗎？）
你可能還想知道：
自己也算是中華電信 MOD的忠實老客戶，從老家到現在住的地方，仔細算一算，超過十五年以上 。（養小朋友的話，也已經是國高中生這樣的年紀了！）
 |
| Photo by Nabil Saleh on Unsplash |
申辦後，一直使用 MOD205B型號，即使後來搬家重新牽線，也沒有更換過新的。本也覺得這款機上盒沒有什麼缺點，直到搬新家後，這台發燙的老機器將電視櫃木板留下四個不可沒滅的印記。
或許已經超過使用年限，除了發燙過熱外，機器跑超過一小時左右後，接著爾爾會發生當機重啟的狀態。莫可奈何下，打服務電話去申請新的機器。
沒想到隔天中華電信工程師馬上就來更換新款 MOD307C機型（可能因為疫情，需求量比較小？立馬有料有工，讚！）
跟原本的 MOD205B型號比起來，新裝的 MOD307C型號跟 Apple TV差不多大小，而升級後最大好處，則是能開始透過 USB外接硬碟進行影片錄影，之後就能將自己喜歡的節目錄製下來。（疑？會有時間看嗎？）
基本上到手上的這台也是老機器，是 106年製造（也不知道輾轉流落過多少家庭...），作業系統核心仍採用了 Android 4.4.2（算是穩定的版本），遙控器也一併更換成新款 MRC51遙控器。
連帶更換遙控器的最大好處（因為支援學習功能），之後看電視就不需使用雙節棍兩支遙控器！
接著你還會想：
隨著萬代「超合金魂GX-100 PROJECT」公開發表，一個小小玩具收藏家如我，也體驗到白雲蒼狗滄海桑田，二十年就這樣過了...。
 |
| Photo by Zakaria Ahada on Unsplash |
萬代超合金魂從 1997年發售第一款 GX-01 マジンガーZ發售以來，我左手拉著右手跳著號碼一路買著、買著，也等到值得紀念的第百號：GX-100 ガイキング＆大空魔竜。但在 2021年的今天，很多人卻會質疑，為何是挑選著 1976年遠古 IP大空魔竜ガイキング作為第一百號呢？
或許要去思考的是：萬代集團多年來的獲利模式變化。原本萬代集團主要是生產玩具，透過大量銷售獲利，但如今，萬代集團已變成透過玩具來強力推廣自家 IP！
最簡單的例子就是七龍珠，一部已經完結超過二十年的作品，現在還能創造「全球」一年千億日圓的產值！這樣可怕的億萬產值，才會讓我們發現，萬代集團不僅僅是一家純玩具廠，更是超重量世界級 IP的擁有者！（不要忘了，其他超熱門的真魔神、真蓋特、勇者王、超人力霸王 IP都與萬代集團有著緊密關連）
合理的解讀，近幾年的超合金魂選角，是為了更長遠的 IP獲利規劃，像是 GX-97 DAILEON，這個 1985年誕生的巨獸特搜，明顯的就是老酒新瓶裝，讓有購買力的新世代認識過去著名特攝，再透過一系列特攝推坑。（還是只是單純腦補？！）
GX-100 ガイキング＆大空魔竜，我想亦是重新要喚起七零年代的老靈魂，要這群戰後世代再掏出最後的荷包，花上超過八萬日幣來滿足童年最後的幻夢想。（至於我到底最後要不要入手呢？我想，那又是另一個故事了！）
如今的萬代集團，並非不會選角，而是在銷售之外，找到另一條獲利康莊大道！不論喜歡與否，萬代集團已經是採繁雜縝密的心思佈局玩具市場。身為消費者來說，萬代的改變或許會讓玩家失落，但二十年前能賺錢的方法，二十年後的現在卻是未必可行，也無法讓企業持續獲利。
廠商會因應著世代而調整出品玩具，就像歌手從青澀的十八歲到四十歲（五月天？）也不斷著調整變化曲風與唱腔。身為微收藏家的我，當然也會隨著潮流跟著轉身剁手買欣賞千值練、POSE+等大作。收藏玩具的初衷，不就是帶給我們一次次的愉悅？不開心、不喜歡，完全沒有關係，換換口味找找其他廠商品牌便是，這世界多麽美好，空氣多麽清新...。
收藏類型玩具市場的世代交替，就讓我們繼續看下去。之後，你還會想要收藏：
今天看到 Giannis Antetokounmpo又一個可怕的傷退，心中充滿無限惆悵。
 |
| Photo by TJ Dragotta on Unsplash |
2020-21是個非常特別的 NBA賽季，因為疫情影響整個賽季的安排，並且多次更動賽程，再加上聯盟訂立的健康安全協定，讓球員的自主訓練安排以及調整都面臨前所未有的衝擊。（開季前的準備、熱身賽、明星賽、季後賽，每個階段都被擠壓縮減，而且還不可規劃！）
季初開打到現在季後賽的明星球員傷兵潮，真的是非常、非常、非常誇張！這還是建立在現今既有輪休觀念的情況下。也因為這樣，許多奪冠熱門球隊因整體戰力缺損，早早打包回家，像是尋求衛冕的湖人（陸續被淘汰的金塊、籃網、爵士...也都是夢幻傷兵隊)。
當然，在明星球員因傷退賽後，後續的酸言酸語已經傾巢而出...
「認識的球星都不見了，還有誰要看？」
「今年拿到的冠軍，含金量能有多高？」
「一堆低級球隊，贏了自 High？」
...
但，大家是否有想過，「健康」就是一支球隊的實力，歷年來拿到歐布萊恩獎杯的隊伍，不就「醫」路保持顛峰到奪冠嗎？「健康」一直是球隊維持競爭力最大的財富！（或許再加上一點點幸運？）
不論是哪支球隊要登頂，就是得踏著各方屍體上來，太陽就是有強悍的醫龍團隊（神醫治癒名單：Amar'e Stoudemire、Grant Hill、Anfernee Hardaway、Shaquille O'Neal...），才能繼 1993年後再次站上冠軍舞台！過去好幾次冠軍隊伍都是這樣，每支勁旅的實力絕對無庸置疑！
今年，不論最後誰舉起金盃，希望大家都能給予這支冠軍隊伍應有的尊重。如果有這麼多「如果」：
祝福 Giannis Antetokounmpo早日康復，那彎曲角度真的太駭人了。
心理學家發現一種「高度專心與高生產力」的心智狀態，稱之為「心流」（Flow）。進入心流的狀態，需要約十五分鐘的時間，所以每一次的注意力轉移，都需要耗費「超過十五分鐘」才能回到之前的狀態。
 |
| Photo by Beth Jnr on Unsplash |
「心流」（flow），如果用電腦的角度來比喻，就像 CPU進行 Context-Switch時的 Overhead。Context-Switch是一個儲存和重建 CPU的狀態，讓多個 Process可以分享單一 CPU 的過程。用在人身上去解讀，就是一心多用！
這也是為何大多的程式設計師，很難在白天上班時有「相對」高的生產力，而是選擇在晚上（或下班）寫程式。生活中，有許多大大小小的例行與非例行的事項，占據我們一天中大多數的時間，可能是一通廣告電話、一場沒有結論的無聊會議、甚至一句沒有意義的寒暄都或多或少都會讓你當下的工作產能降低。這些雜事會讓你放下正在進行的工作，而被中斷之後，要花很多時間重新再把破碎的思緒連接起來。
這種狀況，就像是電腦中的常駐程式，會中斷我們正在使用的重要程式、強占記憶體、跳出訊息，甚至讓電腦運作速度突然變得特別緩慢。這時候打開「工作管理員」（Task Manager）檢查許多莫名其妙的「常駐程式」同時在執行（更可能是中毒！）
因此，程式設計師並不是因為喜歡加班，而是在下班時間或晚上的干擾比白天少很多，所以相對產能比較高！所以下班後工作，是要盡可能將亂七八糟的事情摒除外，進一步創造能「專注」的環境，讓自己進入心流階段！
疫情尚未受到控制的當下，不管是在工作環境，還是個人的學習上，大部分的時間都會在固定的地方（客廳、書房、餐桌上），只能全面檢視一天中有哪些 Context-Switch，然後盡量避免。（如果我有找到好方法的話...）
在找到方法前，可以先：
「那一天，人類終於回想起曾經一度被下雨所支配的恐怖，還有囚禁於風雨中的那份屈辱...」
 |
| Photo by Rhendi Rukmana on Unsplash |
自己每逢洗車後必下雨的神跡，屢屢應驗，但真的是如此嗎？首先，下雨是機率問題，台灣是個多雨的島嶼，不論春夏秋冬，每一個季節都一定或多或少有降雨機率（除了雨都基隆有超過 50%這種可怕機遇），實際上洗車後沒下雨的次數應是佔了多數，只是自己並不會特別注意好天氣，而是特別留意下雨的時節，於是就在潛意識烙下了「一洗車，就下雨」這種刻板印象。（還是我真是龍王轉世，冥冥之中似有神力！）
但，9.99999%的人們心裡還是有個疑問：下雨天洗車真的是「白費功夫」嗎？
依照現在科學的說法，下雨天確實的洗車打蠟或是鍍膜，才是車漆隔絕雨水、杜絕髒污的好方式。
雨水中夾帶著灰塵與髒汙，尤其是車輛排氣中的硫化物、氮化物，甚至是空氣中的落塵，遇水形成酸性物質。隨著下雨，上述的各類型髒污顆粒會停留在車漆上，逐漸造成水垢、水斑、水痕、乳牛斑等等問題，不僅顯髒而且難以清除，當然還會進一步侵蝕傷害車漆。
這也就是為何愛車的人為何都要經常性打蠟、鍍膜，就是因為這樣做能幫車漆多一防護層，避免直接接觸酸性雨水或髒汙，並減少雨水黏在車漆表面。洗車、打蠟和鍍膜其實不難，如果鳥屎、蟲屍、水垢、工業落塵久久不理，未來的處理才是真正費工又傷荷包！
各位親愛的車奴們，勤打蠟、上鍍膜才是真正的愛車之道！
洗車、打蠟、鍍膜前，你還要：
2021年 NBA MVP票選，由金塊中鋒 Nikola Jokic獲得，亮點除了 Nikola Jokic是史上首位二輪選秀的 MVP得主。更令人意外的是，Derrick Rose竟拿到一張「第一名」選票！（與 Joel Embiid與 Giannis Antetokounmpo並列）
 |
| Photo by LOGAN WEAVER on Unsplash |
本來以為是某位極度欣賞 Derrick Rose的媒體人所投，畢竟今年 Derrick Rose從數據、戰績、甚至是對球隊貢獻、領導能力都是排不進聯盟前十的球員。（還是數據看錯年份？！拿到2010-2011年？）
但如此主觀的選票，其實是來自「球迷於官網線上加權累積投票」，並非媒體人投票。按 NBA票選規則，媒體佔一百張選票，而球迷投票結果則合計為一張選票。
（自 2010年的 MVP票選，開放球迷可以參與票選活動；在球迷進行網路投票後，依照球員所得的票數高低，取前五名依序給予第一名到第五名的 MVP 選票一張，Derrick Rose便是因球迷投票獲得一張第一名選票。）
身為骨灰級球迷， 或許能窺看到那極度主觀且非理性所做出的票選心態。
看著 Derrick Rose從 2008年成為公牛隊選秀狀元，被期待成「那個人」的 The one，以二十二歲成為 NBA史上最年輕的 MVP，球技如他的綽號，他是「飆風玫瑰」，他是 Derrick Rose，在 23號退休後，準備要捧起那火炬的 The one。
2012年，那個令人沮喪的季後賽，首輪對七六人，Derrick Rose左膝十字韌帶撕裂（ACL），在這個傷勢後，Derrick Rose受無數的傷病所苦，全身上下，從膝半月板軟骨撕裂到腳踝扭傷都有！此時的 Derrick Rose已成為浪人，漂泊數支球隊，亦遲遲無法找回過往身手。
2018年，本以為會就此退休養老，高掛球鞋的 Derrick Rose，和教頭 Tom Thibodeau重新團聚在明尼蘇達灰狼，10月31日在對戰猶他爵士，奪下生涯單場最高的 50分，外加漂亮的再見阻攻。似乎，那個 2010年的飆風玫瑰在賽場上又重新綻放！
Derrick Rose：「我已付出全心全力，我的隊友在賽前跟我說，就做自己就好，今晚真的很瘋狂。」
比賽結束那那一剎，灰狼所有隊員都衝上前擁抱他、主場球迷們更是激動高喊「MVP」！
今天的第一名選票，就是給那久未綻放的玫瑰充滿自信的一票，為他經歷了屈指難數的嚴重傷勢怒吼、替他那一年復一年不被擊敗的精神給予最後的掌聲！
（不禁幻想著：如果早幾年有有輪休的概念，是不是 Derrick Rose還會繼續為公牛打球；如果早一點學會安全落地的方式，是不是就不會遭遇十字韌帶撕裂；如果早一點開始投三方球...；如果不要堅持切那一球...；如果...）
你可能還會想回味：
防疫在家不知所措？沒辦法出走？沒關係，來試試 Active Arcade居家運動互動 App。
 |
| Photo by Alora Griffiths on Unsplash
|
隨著疫情的變化，三級警戒無法解除，不能去健身房，體重直線上升！別再繼續躺在沙發上追劇吃洋芋片，快下載 Active Arcade，靠手機／平板前鏡頭，就可以做到基本的健身運動。
Active Arcade共有十九款遊戲可供選擇，但陸續還在增加中，也不是所有遊戲都適合在室內玩，但無傷大雅，大人小孩都一定會喜歡。每款的運動時間為三十秒至一分鐘，Active Arcade會告訴依照活動度計算消耗卡路里，搭配 Apple Watch使用會更精準。
雖然是全英文介面，但從遊戲預覽圖以及展示影片，大概就能知道這遊戲會要求做什麼動作。簡單來說，就是遊戲畫面中，會不斷出現各式各樣的形狀／數字／英文，要用「手」、「腳」、或做其他要求的動作來碰觸，進而獲得分數。
唯一的缺憾，大概就是目前只有 iOS版，Android版還要等等。
在 WTF的 WFH一週後，在即將下班的傍晚，服役多年的 MacBook Pro螢幕居然出現殘影，到底是怎麼回事？尤其在 WWDC 2021隔天發生，是 Apple另類黑科技？（趁機推一波 M1？）
 |
| Photo by Moritz Kindler on Unsplash |
推敲自己這一個禮拜的使用行為，心在淌血大抵心裏上有個譜。
所謂的出現殘影，其實是「螢幕烙印（Burn-In）」，會發生的根本原因，就是長期讓螢幕畫面顯示在同畫面（同一個顯示位置呈現同樣內容），以至於那區塊的像素發光區老化。
根據官方資料，Mac及 iMac系列產品所搭載的 Retina顯示器，是採用橫向電場效應（IPS，In-Plane Switching）技術。因為 IPS能提供直逼水平線（178°）的超廣視角，色彩還原性也很出色，但也伴隨著缺陷，其液晶分子反應速度較慢，在高速轉換的動態圖像中（如：影片、遊戲）容易拖影，長時間停留在某個高對比的畫面，顯示器切換後也容易出現殘影。
檢視這個禮拜的 WFH，就會發現 WTF，自己常不自覺將 MacBook Pro顯示器停留在某個高對比畫面...（對，是自己呆）。過去在家工作時，多時間是將 MacBook Pro放在大腿上使用，不可能一直將螢幕維持在某個高對比的靜態影像。
現在 WFH，MacBook Pro是另外接螢幕、鍵盤、滑鼠出來，MacBook Pro顯示器直接放生，爾爾再加上觸控面板的手勢，所以螢幕是長時間開啟，而且維持桌面（在某個高對比的靜態影像），結果...你知道的...，就是這樣！
另外，MacBook Pro擺放位置也有問題，當初書房格局設計，是讓書桌正對著陽台，擺放在書桌上的 MacBook Pro螢幕（背光模組）就會直接被陽光照射，更容易讓整個螢幕面板發熱。
本來以為是長期使用（使用三年以上）造成的老化效果，沒想到竟然踩到螢幕烙印（Burn-In）這個雷。幸運的是，發現得早，關閉電腦，讓它在冷氣風口下休息一個小時後，螢幕悠然恢復原狀，真是可喜可賀！（之後只有使用外接螢幕，MacBook Pro螢幕就休養一陣子吧。）
補充：後來的折衷做法是採用鏡射方式，這樣螢幕能持續變化而且能爾爾搭配使用觸控面板。
原本覺得這個是一個不可思議的動作，在一般行政工作上，怎會有這樣系統般的需求呢？
 |
| Photo by Annie Spratt on Unsplash |
仔細了解、推敲一下，這樣的工作狀況其實還真不少。比如是：從過去舊有系統拿到員工照片，想比對名冊，看哪些新舊員工照片有遺缺，更單純的是，製作一份資料夾的清單，加備註檔案說明。
職場上，不論合理與否，遇上了總是要面對。
在 Ｗindows上，要做這樣的動作很簡單，就是在該資料夾內容上
如此一來，資料夾內所有檔案路徑就會被複製下來。之後，就可以貼上 Excel欄位，再用取代的方式清除不必要的路徑，留下檔案名稱即可。
因為那討厭的疫情，有愈來愈多人到了「虛擬」世界開會，早期沉寂的似顏繪，又因此開始熱絡了起來。
 |
| Photo by Tengyart on Unsplash |
不論是使用 Google Meet、Zoom、Team等視訊軟體，除了不想讓人看到自己家裡骯髒凌亂不堪的樣子，甚至連大叔本人都不想露臉。如果你像我一樣，害羞內斂、被動、不喜歡拋頭露臉，那麼就從 Picrew.me這個日本網站找到適合你自己的頭像來取代大頭照吧！
畢竟日本人是比較貼近我們，由許多日本插畫家所設計的似顏繪產生器，可讓你自由變換，不論是可愛 Q版、搞笑無厘頭 Kuso，還是正經八百的頭像，應有盡有。（不過，因為是不同插畫家設計，每一款可以變換的項目也略有不同）
每一款似顏繪是能夠免費個人使用，但是否可商用，或是允許加工後製，則端看每個日本插畫家各自規範。你剛好想閉關，不想露出廬山真面目？快快來「Picrew.me」幫自己做個新的頭像！
取自 Medium Brad Traversy，拍手數超過 8.5K，如果你是資深工程師一定會非常有感。
 |
| Photo by Alex Kotliarskyi on Unsplash |
Every developer “develops” some bad habits throughout their career or even their learning experience. In this article we’ll take a look at some of the common bad habits that I have experienced myself and/or have seen over and over. My hope is that if your just starting out, you can avoid this stuff and if you are having these habits, your aware and you can start to work on changing them.
#1 Not Taking Enough Breaks (沒有足夠的休息)
So the first one, I’m sure many or all of you are guilty of. I’m still guilty of it and that’s not taking breaks or not taking enough breaks. I’ve had periods of time where I’ve sat down at 6am and maybe only got up for lunch around 1 and then gone until 6 or 7 at night, and this was common, almost every day. I've done much more ridiculous things when I was on a time crunch. I think we we all have had those rare occasions when we need something done the very next day, that is not really what I’m talking about, I’m talking about your everyday habits.
I would suggest that each day you try and take frequent breaks. I can’t say a specific plan for everyone cause everyone's different, but in a general sense I’d say around every hour get up and stretch your legs walk around, get a coffee, get something to eat. A lot of times, if your stuck and you take a break and come back to it the solution will come easier after giving your brain a rest. So figure out what works for you. Even if you don’t think you need breaks, just try it, you may find that your more productive.
#2 Refusing To Ask For Help (拒絕尋求幫助)
Number 2 applies to both learning and in the actual workplace. Many of us don’t ask for help. It could be for a number of reasons but I think a big one is pride and the fear of looking like you don’t know what your doing. Many of us have impostor syndrome where we don’t feel fully qualified in our positions. I’ve felt like this both in a company setting and dealing directly with clients. And even doing courses and tutorials. So asking for help just re-affirms that feeling. But in reality, its wasting a lot of time and hindering your growth. Other real developers are just as much of a resource as a video or book. I’d say even better than that stuff. They can directly answer your question and help you really understand it. The only people that would criticize you for asking for help would be a complete asshole and Id try to avoid those people anyway. If you don’t wanna ask for help because you want the experience of finding the answer on your own that’s fine, but give yourself a time limit. Don’t go days searching for a solution when you have peer right next to you that may know or can at least help you out
#3 When You Stop Being A Student (拒絕學習，停止成長)
I don’t care if you’ve been a senior developer for 20 years, you should always think of yourself as a student. More so than most professions because this one is always changing. No developer knows everything about anything. The minute they do, something changes and they still have to learn more. If you get complacent and you stop reading and learning, you'll fall behind. Even if you have a job that doesn't require you to learn anything new, like lets say you build the same type of projects with the same software, same version and everything, if you loose that job which is always a possibility, your gonna be way behind. So even with a job like that, id still suggest learning new stuff on the side. Stay up to date with whatever language, frameworks, libraries that your into. There are a lot of jobs like I just explained and its understandable because many team leaders at companies figure if it ain’t broke don’t fix it. So you still see teams using outdated and unsupported technologies because it seems to be working. If your learning new stuff on the side and you can show your team that its possible to make your projects faster and more efficient and easier, you may be able to sway them into updating their technology and bettering the company.
#4 Dirty Code (雜亂的程式)
This is more of a technical habit and this could be a lot of things. You want to write your code in a way where its visually clean, efficient and secure. This is really hard when your self taught because a lot of the times in tutorials and courses, your not learning the best way to do something because the instructor is trying to make it easy to understand the core concept. So you have to kind of do some extra research and figure out the best way possible to clean up your code. Id definitely suggest always using the DRY principle which is don’t repeat yourself. If you see common blocks of code, create some kind of class or function to consolidate that piece of functionality rather than just repeating it. It makes it much cleaner, saves a bunch of lines and its easier for others to work with. You also wanna pay attention to performance. Do things like compress images, minify JavaScript and CSS. You can use a task runner like gulp or many other tools to do this automatically or if its a small project you can even do it manually with something like minifier.org. Also don’t make unnecessary api calls, structure your full stack app in a way where you can make as little requests as possible and still get the functionality you need. Also testing..This is one I’m a huge culprit of. I don’t do enough testing. As much as I know things like unit testing helps build a more robust app and saves you on potential issues, I just frigging hate it. Its probably one of my worst habits and something I need to work on to be a better developer. Sometimes we cut corners to save time but in reality, were making the application less performant, less efficient, less readable and it will probably cause more of a headache in the future than if you just did it the right way do begin with. So try and keep that in mind.
#5 Bad Work/Life Balance (工作與生活無法平衡)
This is really important, especially if we have families at home and that’s work/life balance. Being a programmer of any kind takes up loads of time. There’s many reasons for this, things are always changing, we run into issues that can hold us up, we need to research and the list goes on. In turn, a lot of the time, we have to work late, work early, work on the weekends or all 3. This takes time away from everything else in your life including spending time with your loved ones as well as anything else you like to do. You may like sports, hiking, going out to eat, whatever it is, and if you’re constantly working you aren’t doing anything else that makes you happy. This is an area I have a lot of experience with. I have a wife and 2 kids, one with autism and I don’t spend the amount of time with them that I’d like to. I have kind of a double whammy because I have all of the issues of dealing with coding as well as the issues of a content creator and having to constantly come up with new ideas and recording and quality and so on. And if any of you guys are freelancers and work for yourself, you know your livelihood depends on getting work done. You only get paid if your getting shit done. As rewarding as working for yourself can be, it’s a constant worry about keeping up and getting things done. It’s really easy to fall off and I think that weighs on us and pushes other things out of our lives. Not to say that people that work for companies don’t go through this but its a whole new level when everything falls on you. So I really empathize with those of you that have your own businesses. But even with that said, you can’t let it control your life. You have to make time for your family and friends and quite frankly, for yourself. Life shouldn’t be just about writing lines of code. Do things you enjoy that bring a good balance to your life.
#6 Bad Office Politics (糟糕的工作氛圍)
This next one is for those of you working at a company. You work with other people which in turn can cause conflict, disagreement, arguments and so on. Many developers are arrogant and always wanna be right. Even if they know they made a mistake and they’re wrong, some of them would never admit it. I’m not saying that’s most developers but I think we’ve all met at least one of these guys. I hear from a lot of people that their team is great and they all get along and that’s really good but it’s not always the case. Many times you’re gonna clash on ideas and solutions. Try and be diplomatic and respectful but at the same time, don’t be a pushover, especially if you feel strong about whatever it is you’re proposing. Don’t resort to yelling or name calling or any of that. It doesn’t get you anywhere. If they start doing that to you, just walk away and be the bigger person. Unfortunately, if you have someone on your team that is just a complete dick and won’t listen to reason, there’s really nothing you can do aside from try to avoid them. There may be some cases where you have to talk to someone that is higher up. I would always suggest talking to the person first though.
#7 Not Learning From Mistakes (不能從錯誤中學習)
So being a developer, you’re going to make a ton of mistakes. It’s inevitable and there’s nothing wrong with that. There is a problem if you keep making the same mistakes and you don’t learn from them. The process I would suggest when you make a mistake is to figure out what the ultimate cause of the mistake was, figure out if there could a process be put in place to prevent it from happening again and then figure out if the mistake had been found sooner could you have prevented the consequences? If you think about these 3 things when you make a fairly big mistake, chances are it won’t happen again or at least you’ll catch it sooner. Also, don’t be too hard on yourself for making mistakes. It happens to the best of us.
#8 Giving Up Too Soon (放棄不是一種超能力)
Frustration is a huge part of programming. I’ve made a couple videos on frustration and dealing with some of the issues that arise in both projects and learning. I’ve seen many people give up too soon in both specific projects and on programming in general due to frustration. Some projects are really difficult and it seems once you fix something it causes another thing to break and it just keeps happening. You may start to think you’re in over your head, you could be doing something else, you’re loosing money and many other negative thoughts. If you give up to soon though and you scrap the project or you quit your job, then everything you put into that project or job was for nothing. I’m not saying there aren’t projects that should be given up on but I’ve seen it many times where people have given up and from an outsiders point of view I could tell if they stuck with it for just a little longer, it probably would have been successful. So before you give up on anything, make sure you’ve exhausted all routes. You've searched up and down, asked for help, started over trying something different, maybe using a different technology, taken a long break to get your thoughts back in order, maybe even putting it to the side for a bit if possible. You want to do absolutely everything you can before quitting. If you still are failing, then maybe it is time to move on, but all avenues should be taken before that happens. Success could be right around the corner and it would be a shame if you gave up just before that turn.
#9 Being A Know It All (當一個什麼都懂的人)
So I talked a little about arrogant developers earlier and I think what makes many of them arrogant is that they think they know it all. They don’t listen to other developers because why would they, they already have all the answers. Being this way sucks for the people that are around you and it also hurts yourself because if you think you know it all, your not actively learning more and bettering yourself and I guarantee you’ll have a horrible wake up call someday when something goes really wrong because you failed to listen to anyone else and or do your research. Most of these guys are the trolls on Stack Overflow that will make fun of a new developer asking a question or make fun of someone else’s answer, down voting every chance they get. I have a deep annoyance for these people. I think many of them got picked on in school and they use their knowledge to now pick on other developers that may be having issues or aren’t getting something. They seem to forget how it felt for them to be picked on and want revenge. I could be wrong but that’s my theory. Regardless of why they do it, I think that if they were more open minded and welcomed in the ideas of others and respected others, they would be much happier than just always trying to be right. They could be the smartest person on a team but also the worst person on the team, because nobody wants to work with them and there’s no good communication going on. For a team to be successful, there needs to be communication and unity and being a know it all, just destroys that. So if this is you, try and take the stick out of your ass and be a bit more open minded and more respectful, you’ll go further in life.
#10 Not Taking Constructive Criticism (不接受建設性批評)
Ok, so number 10 is sort of related to the last one and it’s not being able to take constructive criticism. There’s a big difference between a know it all troll and someone that is genuinely trying to help you. Sometimes it’s hard to see the difference because having someone point something out to you that you did wrong or you could’ve done better, doesn’t feel good and may feel like an attack but a lot of the time it’s not, it’s just someone that is showing you a better way or just sharing an opinion. It took me a while as a content creator to figure out the difference of who is trolling and who is helping. At first I found myself being defensive to anyone that said anything about how I did something. But I realized that many of these people are legitimately just trying to help. If they aren’t being disrespectful or just nit picky over something that doesn’t really matter and is just preference, then I need to take it as something that can benefit me and my knowledge on whatever it is. Constructive criticism is a fantastic resource for learning, and the reason for that is because it’s targeted. It’s something that you are directly having issues with and someone is offering a specific solution. That’s invaluable. In fact code reviews are great because you get other peoples suggestions and influence on your code and how you can improve it and better yourself. So don’t take things personal unless you are actually being attacked or intentionally made fun of and disrespected. It’s hard to hear that you were wrong or you could do better but ultimately it’s going to make you a better developer.
I hope this advice helps some of you who are both new to development as well as seasoned developers.
如果你已經有了超果三年的工作經驗或，或又待過幾間公司，那麼這十點你應該會有更有感覺。EAA SERIES有依照其理解把文章的重點稍作翻譯加上心得，若不想練習英文就看看 EAA SERIES版本。
十點中最有感的，莫過於「拒絕尋求幫助」、「糟糕的工作氛圍」這兩項。
「拒絕尋求幫助」是我自己個人最大的問題之一，遇到問題時，自己幾乎都不會去尋求幫助。多半是因為自尊心作祟、或是怕問了別人，會被誤以為什麼都不會。總之，就是想太多。這篇文章說得很好，一樣是去自己找答案，但要設定一個時限，時間到了就快去找出口！
「糟糕的工作氛圍」是現在另一個問題，雖然我想好好保持團隊氣氛，持續的良好溝通與交流，但企業文化有時壓得我喘不過氣。
如果是新鮮人，見到上述十點可能有些會嗤之以鼻，但至少可先看看，有哪些壞工作習慣是可以避免的。
如果是資歷深、待過幾間公司（體驗過不同公司文化）的職場老鳥，你會對這十點有更深刻的理解！
如果你想再多了解一點：
我自己是一個不擅於拒絕別人的，婉拒他人都會讓我有罪惡感。另一方面，也會覺得「拒絕會容易產生摩擦，面對衝突實在很難！」
 |
| Unsplash:Coffee Image |
今天看到來自書籍最高學以致用法的「拒絕公式」，希望透過公式，幫助自己降低罪惡感，避免衝突地拒絕對方。在這裡，拒絕公式指的是「道歉(感謝)+理由+拒絕+替代方法」
舉例來說：假設今天下班前，被主管留下要求加班，或許可以試著這麼說：
『真的很抱歉（道歉），謝謝你如此肯定我，讓我有機會一展長才（感謝）。
不過，今天我得接送孩子去補習班（理由），所以沒辦法留下來加班（拒絕）。
看起來有點難度，但是我會在家先思考好做法，隔天應該可以在中午之前完成，這樣的話可以嗎？（替代方法）』
通過『道歉(感謝)+理由+拒絕+替代方法』這樣，有一天也許會發現，練習拒絕並不壞。相反地，正因為有界限，別人才會覺得「我」值得被尊重。
你還可以進一步試著：
 |
| Photo by Nikita rud on Unsplash |
隨著疫情的惡化，幾乎都是待在家裡。幸運的是，還是要正常上班（WFH）/上課。像我會因為工作需求，每週固定在家開會，若是開視訊的時候，房間整個亂七八糟（或是有不該出現的東西？！），真是蠻尷尬的！（雖然說我開視訊的機會不高）
 |
| のび太の部屋 |
不過，現在有很多視訊軟體都可以更換「虛擬背景」，稍微「調整」原本家裡的樣子。
比如是：知名的瑞典品牌 IKEA，它推出多款虛擬背景，提供各種住家空間情境（書櫃牆、鄉村風客廳、工業風書房）下載，用這樣的方式來無痛裝潢，也是一種小確幸呢！（每天住新家的意思？！）
除了 IKEA，其實像是吉卜力工作室、迪士尼皮克斯、寶可夢 Pokemon甚至是霍格華滋魔法學院等等各式各樣單位，都有虛擬背景圖可以下載，而我，則是最喜歡「哆啦A夢」那熟悉的大雄房間（のび太の部屋）。
在疫情穩定之前，快選一個喜歡的背景當作自己的家吧！（或是學學紙板工藝創作者 @kenpon_g自己做一個）
你還會需要了解：
人在網路江湖走跳，隨便也有六、七組帳號密碼（Facebook/Gmail/Apple ID/各大電商帳號密碼...），最為重要的，則是那賴以為生的 Wi-Fi無線網路密碼！
 |
| Photo by Jozsef Hocza on Unsplash |
但是，剛剛所說的這些帳號密碼，幾乎都只是一次性的認證，登入後，帳號密碼幾乎就儲存在電腦或是手機中，自然而然，忘記密碼（甚至是帳號）就是家常便飯。
Mac的所有帳號密碼是儲存在鑰匙圈存取 (Keychain Access)這個 App，只要你是管理員，就能很容易查詢曾經讓電腦「記憶」的各式帳號密碼。
簡單兩個步驟：
所以，下回當忘記密碼時，不妨試試鑰匙圈存取，立即找回帳號密碼，再難記的密碼再也不怕！
你可能還會想：
新冠肺炎（COVID-19）肆虐全台，尤其現在進入第三級防疫警戒，在本土確診病例不斷地暴增下，從擔心打不完的英國阿斯特捷利康（AstraZeneca）疫苗現在變成一針難求！
 |
| Photo by Ivan Diaz on Unsplash |
截至五月初，儘管當時 AZ疫苗已開放軍人及六十五歲以上民眾公費接種，但台灣仍是接種最慢的國家之一，或許是台灣防疫過去一年表現太好，讓大家輕忽了新冠肺炎（COVID-19）的可怕，沒有太多人有施打意願。在疫情尚未爆發的前幾天，幸運之神眷顧下的我，預約到了衛生福利部臺中醫院的疫苗，在這邊簡單分享接種經驗：
預約週五（DAY 1）的下午三點半在衛生福利部臺中醫院施打，實際打到疫苗大概是下午四點半左右。當下其實在那邊的人不少，多數是醫療相關人員與空服人員（著制服），狀況也有點混亂（那時候還有自費與公費並行），我報到時連證件都沒有檢核就發號碼牌了。
施打前需量血壓、填寫評估單與 COVID-19疫苗接種意願書，並有醫生問診（雖然像是閉著眼睛蓋章）。在排隊時，就不斷聽到護理師的叮嚀，「會發燒」、「一定要多喝水」、「預先吃普拿疼減緩疼痛」。
排隊約二十分鐘後施打，過程中沒什麼特別的，就跟平常打針一樣。之後要待著（被）觀察三十分鐘，以防對疫苗有嚴重的過敏反應。 最後會拿一張黃色接種記錄卡。
離開衛生福利部臺中醫院後，立馬到附近便利商店買兩瓶五百毫升的水，一路開始狂喝，到睡前都還一杯杯不間斷地飲用。晚上十點左右，還都沒有任何異狀，就只有左手臂打針的地方有點酸、有點無力。
隔天（DAY 2）醒來時，感覺身體有微微發熱（沒有量體溫，也沒有發高燒的感覺）。中午過後，開始有暈眩、全身無力的情況，持續到下午三點多，受不了，吃了普拿疼減緩症狀，但手臂持續酸痛且無法舉起，到睡前都是同樣的狀態。
第三天（DAY 3）起床後，就不再有發熱症狀，也沒有暈眩，唯一不舒服是施打的左手臂，同樣的酸痛且無法舉手，到睡前都是同樣的情形。
週一上班時（DAY 4）只剩下手臂持續酸痛，但也沒有一開始那麼嚴重，已經接近正常狀態，但仍然（左手）不舉。（左手的不適接近一週左右才恢復，但不影響生活作息）
總結來說，覺得自己並沒有太大的副作用，畢竟身體自身免疫反應，發燒、肌肉酸痛都是正常的現象，新聞上所提到的副作用也都沒有發生。施打第一劑後，約兩週後會產生抗體，第二次劑預計是在七月初。有抗體後，即使感染，體內病毒量會比較少，病情也更輕微，傳播病毒給其他人的機會更低。
下一批 AZ疫苗已分配至台灣，可能有些人接種後，副作用可能會比較強，但有疫苗的保護，對自己和對身邊的朋友、家人都是一種保障。如果用魔獸遊戲的思維來表達，打疫苗就跟穿神裝一樣，增加 70%閃避機率，被命中後減少 99%傷害，並且 100%免疫暴擊！（約 70%有效保護，感染後 99%免發病，以及 100%不會轉成危重症。）
你可能還想了解：
本以為是一個唬爛 USB3.0新聞，但沒想到是千真萬確的真實故事！
 |
| Photo by Markus Spiske on Unsplash |
這個月初有個日本人買了 SSD硬碟在PS4上使用，結果發現 PS4只抓到USB 2.0，發生非USB 3.0裝置無法使用的詭異狀況。查了官網後，官方看似正經但奇怪的回覆竟是：「請你插快一點！」（錯誤代碼 CE-41902-6）
USB (Universal Serial Bus) 3.0快快插跟慢慢插，真的有差喔？ 還真的是有！
主要原因在於 USB 3.0 Type-A 與 USB2.0相容性設計，主要原因在於 USB 3.0 Type-A 與USB 2.0相容性設計，USB 3.0 Type-A接頭其實包含兩個部分，一個部份是 USB 2.0共通的針腳（接點），另一個部分則是 USB 3.0追加的針腳，而加針腳位於共通針腳的後方。
 |
| 2.0の根元に新たな端子を追加したのが、USB 3.0コネクター（以下、筆者作図） |
因此 PS4在判讀裝置時，如果插得太慢， PS4只讀到 USB 2.0共通針腳，才會將外接裝置判定為USB 2.0設備。所以才有「插太慢」，讓 USB3.0設備但被判定以 USB 2.0標準執行的現象。
 |
| 素早く差せば、接続先のPC等が、根元の端子からUSB 3.0と認識してくれる |
 |
| PCがそそっかしい子のようでかわいく思えてきた |
其實這個鬼問題不僅限 PS4或 PS5，所有設備都會有這種類似狀況，只是一般電腦我們插上裝置後，不會特別留意它是 USB 2.0標準執行還是 USB 3.0。
結論：「想確保 USB 3.0 Type-A都能用該有的速度執行，記得不要猶豫，用力插快點！ 」
之前在 Windows上多是用 CDex類的軟體，將一張張 CD轉成 MP3（還有人知道 CD是啥嗎？）
 |
| Photo by Chris Yates on Unsplash |
而轉入的功能在 Mac上的 iTunes就已內建，屬於從卡帶、CD、DVD到雲端串流世代的我，這樣的功能還是必要的。今天正好拿來轉一下童書所附贈的錄音檔。
在 Mac上的步驟：
可以到「偏好設定」 > 「進階」頁籤，看一下 iTunes Media目錄在哪裡，之後轉出來的檔案會放到這下面。（預設是：/Uesrs/你的帳號/Music/iTunes/iTunes Media）
本篇文章 The 60-Year-Old Scientific Screwup That Helped Covid Kill，作者是 Megan Molteni [1]，以下文字轉自翟本喬臉書，原文也已經有中文版，但語意不通順，以下是採用翟本喬臉書的版本（非逐字翻譯，跳過很多細節，也改採適合台灣讀者的文風），希望讓大家能夠重新更新自己的資料庫，病毒傳播方式並非「飛沬傳染」對「空氣傳染」的單純二分法。
三十四年前我坐在台大醫學系的教室裡，陪著（當時的）公主修微生物學及免疫學。中間有一堂是公衛系主任來上的，他對著這群未來的醫師們訓勉：你們可能未來都想進外科，開刀救人一命，成為英雄人物，因為家屬都會感激你，跪下來謝你。但是你們要認清楚：外科救人是一個一個救的，公衛救人是一百萬一百萬在救的。 我不知道當時的醫學系學生有多少聽進去了，但我一直銘記在心。雖然我沒有機會成為醫師，但我努力設法遵循這個原則：去做能救一百萬人的事，而不是做一次救一個人的英雄。 前幾天在 Wired 雜誌上看到這篇文章，禁不住引起當年的回憶，於是盡力在工作的夾縫中擠出一點時間來翻譯，分成四集放在臉書上。今天再抽了一點時間集結成為一篇，希望能對大家有些幫助。工商服務放在第一則留言，這樣轉貼時才不會跟著跑。
在 Covid-19開始漫延的兩個月後，2020年3月，WHO（World Health Organization）堅持說 Covid-19不是空氣傳染 (airborne)，甚至在推特上強調這句話 "FACT: COVID19 is NOT airborne."。
於是在4月3日，著名的氣膠物理學家 Lidia Morawska召開了一個視訊會議，試圖集合大家的力量來警告 WHO這件事是錯的。他們提出了許多證據，像是在沒有人走動的大型音樂會中離帶原者非常遠的人也染疫，顯示當時 WHO所堅持的社交距離6呎是沒有用的。如果 Covid-19真是像 WHO所宣稱的，是經由飛沬傳染 (droplet) 的話，社交距離和常洗手這兩件事，早就該阻止瘟疫的漫延了。
Morawska提出了不同大小飛沬飛行距離的動力模型，但 WHO的一位官員很無禮地打斷她，說她是錯的。她在空氣污染粒子方面有超過二十年的研究經驗，成果也是 WHO廣泛接受的。但 WHO不知道為什麼，會認為同樣的空氣動力模型碰到有病毒的飛沬就不適用了？
WHO堅持透過小於 5微米的顆粒傳播的，才可以叫空氣傳染 (airborne)。Covid-19 患者吐出的飛沬大於 5微米，所以叫飛沬傳染 (droplet)，兩者的防疫規範是不同的。
會後一位維吉尼亞理工學院 (Virginia Tech) 的教授 Linsey Marr決定要追根究底：到底為什麼醫界和物理學界對這件事會雞同鴨講？為什麼一件一翻兩瞪眼、實驗數據都可以攤開來驗證的事，碰到了 WHO的官僚就會秀才遇到兵？ 5微米這個神聖的數字是怎麼來的？
WHO的官僚雖然固執，但也不是白痴。他們的依據是什麼？Linsey以前也碰到過頑固的醫界研究人員，通常她也就算了；但這次是全世界人類性命交關的大事，她決不能退讓。
Marr 並不是一個門外漢試圖對醫學研究指指點點。她的本行像 Morawska一樣，是空氣污染的研究。但十幾年前她的小孩上了托兒所，得到感冒之後，引發了她對傳染病研究的興趣。即便托兒所人員嚴格地消毒，小朋友們還是不停地有人染病。她開始懷疑：難道感冒是空氣傳染，而不是飛沬傳染？
在醫界的標準之中，絕大多數的呼吸道疾病都是由咳嗽和打噴嚏傳染的。噴出來的飛沬有3-6呎的傳染範圍，而飛沬沾到物件之後手再去碰，仍然會有傳染力。所以標準的防疫方式就是 1)不要接近到 6呎之內 (社交距離) 和 2)勤消毒、常洗手。只有極少數的傳染病會是空氣傳染，像麻疹和肺結核，只要吸到病人呼出來的空氣，就有可能染疫。
這兩者的差異是天壤之別。對付飛沬傳染，只要離遠一點再常消毒洗手就好。對付空氣傳染，你可能要全民戴口罩，到了醫院就是負壓病房和 N95。
醫學文獻上註明 5微米是界限。不管是 WHO還是 CDC（Centers for Disease Control and Prevention），都以5微米來劃分。致病顆粒在5微米以上的叫飛沬傳染，5微米以下叫空氣傳染。Covid-19的飛沬顆粒大於5微米。
可是物理學界明明看到一大堆5微米以上的顆粒可以飛很遠。不然你以為 PM10 這個空污指標是怎麼來的？就是因為10微米的顆粒不會落地啊！
她決定自己做實驗，到處裝空氣取樣器，結果在很多照理說不該發現感冒病毒的地方找到感冒病毒。除非感冒是空氣傳染，不然不會有這樣的結果。
在2011年，這應該是呼吸道疾病的方面的大新聞。但醫學期刊沒有人要收她的論文。即使她再多做實驗，增加了鐵證如山，也只有一個小期刊《The Journal of the Royal Society Interface》讓她發表。
在學界，氣膠 (aerosols) 是物理和工程的領域，病原是醫學的領域，兩者井水不犯河水。Marr 偏偏就是極少數兩者兼通的學者。她一直覺得5微米這個數字有問題，如果她能找出來源，並且證明這個來源有問題，那就能試著說服別人去改變。可是所有的醫學教科書都只列出這個數字，而沒有像研究論文一樣註明引用來源。也就是說這件事年代太久，已不可考了。
Marr 決定先放下這件事，專心其他的研究，直到 2019年十二月，香港大學李玉國教授的一篇論文出現在她桌上。
李玉國在 2003年以研究 SARS而出名。他當時在香港一棟公寓大樓的調查就顯示了冠狀病毒經由空氣傳染的證據，但他一樣面對了要說服衛生官員的挑戰。最後，他以漂亮的數學模型和電腦模擬，證明了咳嗽和打噴嚏噴出來的顆粒太少，無法對眼口鼻這麼小面積的目標造成這麼高的傳染率。
期刊請 Marr審這篇論文。她很小心地檢查完之後，在2020年1月22日，她激動地寫下：這篇論文極為重要。它挑戰了現有的傳染病教條中飛沬和氣膠傳染的模式。
幾個小時後，武漢封城。
隨著一個又一個的國家進行封城，WHO和 CDC仍然告訴大家：洗手、消毒、保持社交距離。完全沒提到口罩，也沒指出換氣不良的室內環境可能帶來的危險。
4月3日那場視訊會議之後幾天，Marr收到了 Jose-Luis Jimenez寄來的 email。他是科羅拉多州立大學的化學教授，專研大氣化學。他對 6呎社交距離這件事特別感到困惑。就他所知，社交距離這個規範好像是來自1930-40年代的一些研究，但那時的論文作者好像也提到空氣傳染的可能性，似乎有點矛盾。
Marr 告訴 Jimenez她的問題是5微米這件事。6呎和5微米差了三十六萬倍，但似乎是來自同一個錯誤。這個大魔王開始現形了，但是它是從哪裡來的呢？這些科學家們現在束手無策，需要一個歷史學家來幫忙。印地安那瓊斯在家嗎？
Marr 有一位 Virginia Tech的同事 Tom Ewing專精於麻疹和肺結核的歷史。Ewing找了一個研究生，正好是做這種「文獻證據研究」的。 Marr在 4/13給 Jimenez的 email中寫道：我們會找到一座紙牌屋。(意思是說抽掉底下一張，它就會全部垮下來。)
這位研究生的名字是 Katie Randall。她的博士論文正受到 Covid-19的嚴重打擊，因為她需要做大量的面談，而現在都不能做了。所以她和教授商量之後決定整個學期就專心做整理的工作。現在 Ewing的 email來了，告訴她 Marr碰到的問題和目前找到的資料，"看來就像一個考古場域，找到了一堆碎片，可能組得出一個茶壺"，她接受了這個挑戰。
Randall 的專業領域叫做「引用文獻追蹤」(citation tracking)。這就像《犯罪現場》這部戲一樣，只不過線索不是血跡和毛髮，而是古老的論文和報導。李玉國的論文中有找到幾十年前 WHO和 CDC發佈的防疫規範，其中就有 5微米這件事。Randall從這裡繼續追查下去，但找不到任何新的線索。
她換了一個方向下手：大家都知道肺結核是空氣傳染的，所以她用肺結核和5微米這兩個關鍵字下去 CDC的文獻庫裡面找。這不是件容易的事，因為裡面沒有 Google 。她找到的最早一篇關於肺結核防疫的文章，而又有提到顆粒大小的，裡面引用了一本絶版書《Airborne Contagion and Air Hygiene: An Ecological Study of Droplet Infections》，是哈佛的一位工程師 William Firth Wells在 1955年寫的。
她本來可以從館際合作去借這本書的，但在疫情籠罩之下沒有人在大學圖書館裡上班，她只好自力救濟，在網路上的一個書商那裡找到了一本，要價五百美金。這對一個沒有研究計畫可以核銷的研究生來說是滿大的負擔。幸好最後有人在密西根大學找到了數位化的電子檔。
在 Wells這本厚達423頁的書中，Randall看到了一位在學術生涯盡頭，一股腦要把畢生所學吐盡的老者。她開始往回找，包括 Jimenez提到的部分。1934年，Wells和醫生太太 Mildred Weeks Wells分析了空氣樣本，畫出呼吸顆粒被重力和蒸發飄浮力拉扯之下行進的曲線。由他們的計算可以推出各種大小的顆粒離開口鼻之後多久會落到地面。Randall 看到這條曲線楞住了：他們的界限是100微米，不是5微米。
Randall 努力地繼續挖掘。這本書超長的，她還有論文要寫，還要帶著活潑的六歲女兒上幼兒園遠程教學，所以常常都是夜深人靜，全家都上床了之後，她才能回來寫下當天的研究進度。
有天晚上她讀到了 Wells在 1940年代的實驗。他在學校裝了紫外線消毒燈之後，得麻疹的學生人數大為減少。他的結論是麻疹病毒應該是空氣傳染的。可是 Randall知道麻疹是在又過了差不多二十年後才被承認是空氣傳染的，怎麼回事？這麼重大、人命關天的事為什麼被延誤了這麼久？
醫界的氛圍中，很重要一件事是瞭解為何有些話會被聽進去，而其他的被忽視。時序進入夏天，Randall 開始調查當年 Wells的同儕是如何看待他的。有沒有像柯文哲在台大的那種處境？於是她發現了 Alexander Langmuir，非常有影響力的一位醫學專家，在新成立的 CDC擔任流行病學主任。在那個時代，他們從小受的教育極度注重個人衛生，洗手就像呼吸一樣的必要。他看到 Wells的空氣傳染觀點覺得就像退化到中世紀的「瘴氣」理論一樣，有趣但沒什麼用。
但同時 Langmuir也要面對日漸嚴重的生物戰威脅。他擔心敵人會在美國的各大城市遍撒空氣傳染的病原體。在韓戰開始之後不久，1951年三月，Langmuir 發表了一篇報告，裡頭一方面貶低了 Wells對空氣傳染的信念，但又讚揚 Wells的研究為瞭解空氣傳染的機制奠定了基礎。
這下有趣了。Randall 想著，繼續看下去。
這份報告裡，Langmuir引用了一些1940年代對廠礦職業傷害的研究，顯示鼻喉黏膜對5微米以上的粒子過濾能力非常好，但更小的粒子就會飄進去造成傷害。如果有人想要製造病原武器的話，就要製成可氣膠化的液體，然後粒子直徑要小於5微米。
越來越有趣了。
幾天後 Randall 再回去讀 Wells的書，她發現他也注意到了同一批研究，而且決定做一些實驗來調查粒子大小與自然界呼吸道疾病的關連。他用了肺結核菌。這種菌很強壯，而且可以做成氣膠。當它進入肺部的時候，會形成一個病灶。他給兩組兔子同樣劑量的細菌，但一組是用小於5微米的氣膠，另一組用大於於5微米的。吸入細粒氣膠的兔子生病了，而解剖結果也發現了結核病灶。但吸入粗粒氣膠的兔子依然一尾活兔，健康得很。
好一陣子，Randall這樣來來往往地在文件中穿梭於 Wells和 Langmuir兩個人的時代。等她看到 Langmuir晚期的研究，她發現他的語氣改變了。他在1980年代晚期所寫的文章中承認他對空氣傳染的認知是錯的。空氣傳染的確存在。
Wells最後所做的實驗改變了 Langmuir的想法。Wells和同事在 Baltimore榮民醫院把肺結核病房的空氣抽到頂樓的實驗室放了150隻天竺鼠的籠子裡。每個月都會有幾隻天竺鼠得到肺結核。但當局仍然懷疑，認為他們沒有對照組。於是 Wells團隊又加了150隻，但這組的空氣經過紫外線消毒。對照組的天竺鼠都沒有生病。
再大的官也沒有學問大到能否認這如山鐵證。人類疾病的確可以經由空氣傳染。
這個重大突破在1962年發表，第二年九月 Wells就過世了。一個月之後 Langmuir在一場醫學界的演講中歸功於這位工程師，感謝他提點了醫界對肺結核防治努力的不足之處。而在這場演講中，他強調了肺結核病原顆粒是小於5微米的。
蛤？？？神奇的「5微米」數字終於出現了。
Randall回去找到前面提到那份幾十年前 WHO和 CDC發佈的防疫規範。裡面有講到肺結核菌的一個特點：它只會攻擊肺部深處特定的一些細胞，所以要把5微米以下的粒子吸進肺部深處才會染病，而大一點的顆粒被鼻喉黏膜過濾下來就沒事了。但大部分其他的病原體沒那麼挑嘴，它們會順著呼吸道下來一路玩到掛，隨便落在哪一點都可以讓你生病。
她現在也只能猜測：在 Wells過世之後，CDC內部的專家整併了他的研究，把 5微米這個數字抽離了肺結核的脈絡，而定義成為空氣傳染的必要條件。Wells的 100微米界限被遺忘了。Randall認為「什麼東西可以吸得進去」、「什麼東西可以停留在空中」、「什麼東西可以傳染致病」這三個性質，被去脈絡地合併到了「小於 5微米」這個簡單的是非題。經由師徒相傳的背誦，變成了深植人心的醫學教條。她試著向CDC查證，但都沒有人回答她。
在六月份的團隊視訊會議裡，Randall提出了她的發現。Marr簡直不敢相信：就這樣？5微米是這樣來的？多年來的謎團終於解開。但找到問題關鍵是一回事，想要把這個錯誤從幾十年來建立的公衛教條中更正過來，得去說服世界上權力最大的兩個衛生組織他們不但錯了，而且錯誤的後果非常急迫又嚴重。
在 Randall潛心研究的同時，團隊其他的成員也沒閒著，準備了一場公開的遊說活動。
Marr和 Jimenez在七月份發表了一封公開信給包括 WHO在內的公衛當局。這封信除了他們之外一共還有 237位科學家和醫師簽署。他們提出警告：如果沒有普遍要求戴口罩以及加強通風，那麼光憑篩檢、疫調和社交距離是擋不住 SARS-CoV-2病毒的。
這封信立刻上了頭條，而且遇到了強烈的反擊。公衛大師們紛紛跳出來護航 WHO，引起了推特大戰。George Mason大學的生物防護學教授 Saskia Popescu，也是有名的流行病學家，表示他願意承認 Covid是可以由吸入氣膠而傳染的，但只有在距離很近的時候。她堅持說在公衛界「空氣傳染」這個詞不是可以隨便用的，因為它會改變所有的處置方式。
幾天後 WHO發佈了更新的報告，承認「不能排除氣膠傳染的可能性，尤其是在通風不良的場所」，但還是堅持以3-6呎的社交距離為主要的防疫手段，只有在室內無法保持距離的時候才需要戴口罩。Jimenez簡直快氣瘋了，他在推特上寫道：「這就是假資訊，讓人們不知道要保護自己。因為 CDC和 WHO淡化了氣膠的危險性，我們看到了至少50件報導說學校和辦公室禁止自備HEPA高效空氣淨化器。」
在 Jimenez打社群媒體戰的時候，Marr在幕後準備喚起大眾覺醒，改變過去對氣膠的誤解。她找上了加州大學聖地牙哥分校的大氣化學家 Kimberly Prather。Prather跟CDC還有白宮的 Covid工作小組都很熟，可以直達天聽。七月份她們送了一份簡報給 Anthony Fauci，美國國家過敏和傳染病研究所所長。簡報裡有一份 5微米粒子的軌跡圖，顯示出它從一個人的口鼻吐出來之後，可以飄出不止 6呎才落地，事實上可以飄到幾百呎之外。幾個星期之後 Fausi在哈佛醫學院的一場演講之中承認 5微米這個界限是錯的，而且是多年來從頭就一直錯到底。
但是飛沬傳染理論還是主流。十月初 Marr 和一群科學家及醫師在 Science期刊上發表了一封公開信，懇求學界對傳染病原顆粒的移動方式達成共識，就從丟掉5微米這個歷史包袱開始，這樣才能提供給大眾清楚和有效的防疫建議。同一天，CDC更新了防疫規範，承認 SARS-CoV-2可以由長期飄浮的氣膠傳染。但 CDC並沒有加強宣傳這一點。
到了冬天，WHO也開始談氣膠了。十二月一日，WHO終於建議在疫區室內要戴口罩。在一場訪談之中，WHO的 Maria Van Kerkhove說這個改變表示了 WHO只要看到科學證據就會願意調整他們的規範。而且 WHO從一開始就有注意到空氣傳染，首先是在醫院，然後在餐廳和酒吧等場所。「我們一直鼓勵加強通風，就是因為這個病毒有可以是經由空氣傳染的。」Van Kerkhove說。但她承認因為在醫學界空氣傳染這個術語有特別的意義，所以他們一直避免使用這個詞，而是用其他的方式來說明什麼樣的場合會有最大的風險。當被問到這種模糊的表達方式是否損及了防疫的規畫，甚至人命？她說沒有，「大家都知道要怎麼保護自己。」
但她也承認飛沬傳染對空氣傳染的二分法需要檢討了。WHO會在2021年正式重新定義疾病傳染的途徑。
對李玉國來說，這代表了一線希望。他說「我們常常是從悲劇中學習」。空氣傳染比以前想得更複雜，但又不那麼可怕了。SARS-CoV-2就像很多呼吸道疾病一樣，是空氣傳染的，但又不像麻疹那麼嚴重，傳染率高達 90%。目前證據顯示長距離，或是在通風良好的場所傳染的案例並不多。這個病毒最有效的傳播方式還是在近距離內，所以才會被認為是標準的飛沬傳染。
對大部分的呼吸道疾病來說，搞不清楚傳染途徑並不是重大災難，但也不是沒有付出過代價。流感每年傳染百千萬人，全球死亡人數在 30到 65萬之間。流行病學家預測未來幾年的流行季節會更嚴重。李玉國希望藉由這次 Covid的教訓，會讓空氣清淨成為結束這次疫情的重要措施，更進一步成為未來防疫的重點。
要知道未來，就先看看李玉國的教室和 Marr的健身房。李玉國在疫情一開始的時候，就說服了香港大學把防疫預算花在改良建築物裡和交通車上的通風設備，而不是像普篩這種傳統的想法。Marr和健身房的主人坐下來檢視了建築和空調藍圖，計算了空氣流通率，把健身器材重新佈置在室外或門邊。至今這個健身房沒有人染上 Covid，而香港大學三萬個學生之中也只有 23個確診。當然，可能因為 Marr的健身房沒多大，而香港人在 2003年 SARS之後也早已認定這是空氣傳染而加以預防。但這兩位的措施可能都大大降低了他們染疫的機率。畢竟，這就是公共衛生規範的目標：把大眾引向安全的方向。
今年四月30日，WHO悄悄地更新了它的網頁，在冠狀病毒傳播途徑之下的說明，除了飛沬之外加上了也可以經由氣膠傳染。紐約時報記者 Zeynep Tufekci在一篇報導中說 [2]：「這可能是這場瘟疫中最重要的新聞，但沒有記者會，沒有發表會，沒有人注意。」
但 Marr 就是「沒有人」，她注意到了。這個時機不是巧合，是因為她、李玉國以及另兩位科學家剛在最有影響力的《英國醫學期刊》發表了一篇社論 [3]，標題是《 Covid-19 has redefined airborne transmission 》(《Covid-19 重新定義了空氣傳染》)。總算，這次她不用投稿，是編輯主動找上門來。她的團隊也在SSRN上發表了這次文獻考古的結果。[4]
一個星期之後，CDC悄悄地跟進，把氣膠列為 Covid-19最主要的傳染途徑。同樣靜悄悄，但 Marr也注意到了。那天晚上她去體操課接女兒回家的路上，忙完了一天的工作之後，終於能靜下心在獨處的環境中思考。等著紅燈，她忽然大哭了起來。不是小小的啜泣，而是無休無止的熱淚，累極而泣、喜極而泣。終於，她想：「你們終於搞清楚了，我們終於讓你們搞清楚了。」
紅燈變綠，她擦乾眼淚繼續前進。今天還沒到可以閒下來回憶的時刻，現在要先去接孩子回家吃晚飯。生活，正等著要回到正常。
『 麻瓜 （英語：Muggle），在J·K·羅琳的《哈利波特》系列小說及電影中是泛指沒有任何魔法能力的人，也不是出生於魔法家庭的人。麻瓜也可以被描述為體內沒有任何魔法血統的人。』 Photo by Vitolda Klein on Unsplash 「你不是工程師，我很難跟你...
