這是一部極少數讓我完全沈浸在故事裡的電影，每一刻的剪輯都讓人期待。隨著時間線的推移，在核彈試爆前的暖場、讓我心跳逐漸加速，直到試爆成功為止。下一情緒是緊張與憤怒，來自秘密聽證會...

本篇文章將探討如何處理團隊的衝突，以及引領團隊向前進。這個標題會是一個系列文，會想寫下這篇文章是希望未來在管理團隊的路上，能夠時刻檢視、調整自己，遵循內心的初衷去營造出一個良好的環境。

這篇文章主要是翻譯自 MongoDB 官方部落格的文章:
4 Big Reasons to Upgrade to MongoDB 7.0
加上一些我認為很不錯的功能。

不知不覺寫 MongoDB 主要版本的文章邁入第三個版本，官方有信守承諾一年更新一個大版本號XD

• MongoDB 5.0 新功能
• MongoDB 6.0 七個建議升級的原因

1. 效能增強

• Time series 資料，儲存、查詢和壓縮，效能顯著提升。
• 針對 High cardinality 以及其他資料，開發人員會有更好的處理體驗。(這點我還蠻期待的，印象中資料量上來，整個使用體驗很差XD)
• Change stream 現在支援大文件，或是圖片異動的前、後記錄，且不會發生意外錯誤。(Change stream一直是一個好用的額外監控、備份工具啊)

2. 資料同步更流暢

• Cluster-Cluster 之間的資料同步更有效率！
• 資料同步更有彈性：現在支援特定資料同步，不再需要同步全部 Cluster
• shardingStatistics 多了一些統計分片策略

3. 開發者體驗改善

這是80年來，形塑日本人品格態度的一本書，
是一本遇到難關或面臨挑戰時，讓人振作起來，
長大後不斷想再次閱讀，並仍然能夠獲益匪淺的書。

會得知這本書，是因為日本在毫無廣告的情況下，突襲上映了宮崎駿的新電影 你想活出怎樣的人生。在台灣肯定是沒機會馬上看到的，文章看一看發現原著是這一本書，至少我能先看個書解解想看電影的渴，於是就殺去買來啃了XD

不知道為什麼，當我開始從小哥白尼(主人翁)的日常與學校生活讀起，彷彿進入一種時光隧道，不僅僅是身在主人翁自我思考的世界，同時也將我的思緒拉回到高中那種純粹、青春與戀愛的校園生活。
雖然小哥白尼的年紀僅有二年級，但在舅舅的細心陪伴與照顧下，養成對週遭發生事物思考的習慣。這種自我思辨的能力對於在台灣傳統教育下的我，即便是出了社會仍感到很缺乏，又遑論是鮮少關注自身的「社畜」。

我使用了一個強烈批評性的字眼「社畜」。
亞洲教育體制下，只告訴你「該是什麼」，鮮少告訴你「為什麼」，甚至提出疑問者還會被貼上不合群、問題很多的標籤。相信很多人都有聽過類似的話：

• 你長大就會明白了
• 你考上大學就可以開始玩了
• 你出社會就能談戀愛了

懂事，玩樂與戀愛，難道就有一定的年齡限制嗎？是大人們懶得教育，還是他們根本不理解？

人生永遠的課題

人類其實很奇妙，作為一個擁有大腦與思考的哺乳類動物，經過統計只有使用約 10% 容量，但已經發展出遠遠超過其他物種的智慧，若是能夠開發大腦更多部分，也許會有更不一樣的世界。

本篇文章分享什麼是 PMP 證照、準備考試過程並加上一些小技巧，希望能夠幫到想要考試的朋友。
至於 PMP 在軟體業實務上的應用會放在另一篇文章討論。

最常問的問題: PMP 對工作有沒有幫助，本篇不會討論也不會有，感覺可以說很多就不要在這邊模糊焦點。

介紹

我本身是參加補習班課程，經過考試得到 3AT 拿到 PMP 證照的。

關於要不要補習這件事這絕對是取決於個人條件，如果你擅長整理資料重點、讀書、找資料且時間充裕的話，選擇自修、靠自己努力絕對夠考上，尤其是 PMP 考試內容已經大幅調整、接軌 Agile，需要背的東西大幅減少。我個人是選擇花錢買時間，也就是補習班幫我整理好重點再來自己準備。

考試成績並不會給予確切分數，取而代之的是平均區間，就像是西方教育 GPA(Grade Point Average)。
分為 Above Target(AT), Target, Below Target, Needs Implements，及格區域只有 AT 與 Target 兩個而已，剩下就是不及格了。以下是官網定義：

1
2
3
4

Above Target: Your performance exceeds the minimum requirements for this exam.
Target: your performance meets the minimum requirements for this exam.
Below Target: Your performance is slightly below target and fails to meet the minimum requirements for this exam. Additional preparation is recommended before reexamination.
Needs Improvement: Your performance is far below target and fails to meet the minimum requirements for this exam. Additional preparation is strongly recommended before reexamination.

什麼是 PMP

人的進步始終來自惰性

最近看到同事的一指令同步所有 Git 專案覺得很神奇，當時僅有這樣的感覺。後來在工作上一直重複得打一些指令覺得很阿雜，心想為什麼我要一直做這種事情，其實滿腦子根本已經是那個神奇的別名(alias)的形狀了，於是我就開始編輯屬於自己的別名囉！

必備工具

如果你從來沒有安裝過 Brew Cask 的話需要先執行安裝，下面會用到

1

brew tap caskroom/cask

選擇好用的 Terminal

大部分人應該都選用這款 iTerm2，比內建的功能強大非常多。

透過 Brew Cask 安裝:

1

brew cask install iterm2

編輯顏色實在太麻煩了？

本篇文章將介紹如何查詢 MongoDB 字串欄位的長度以及數量。

人家說上戰場，直接面對需求是最佳的進步方式，雖然不會真的陣亡，但是在時間壓力下會進步神速。

某次遇到 issue 時，需要查詢現有的某個 collection 內，x 欄位字串長度超過 y 的資料筆數有多少。不看還好，一看也沒這麼單純，因此特別記錄一下。

目標 1: 查詢 x 欄位長度超過 20 的資料有哪些

這個思路很簡單，

1. 使用 strLenCP 計算出長度
2. 使用 gt / eq 找出符合長度的資料
3. 最外層使用 expr 來做判斷表示式

1
2
3

db.getCollection('myctw').find({
"$expr": { "$gte": [ { "$strLenCP": "$apie.field-en" }, 30 ] }
})

上述就是查詢 myctw 這個 collection，apie.field-en 此欄位長度大於等於 30 的方式。

目標 2: 查詢目標 1 的總數量

本篇文章是分享做近視雷射，從開始、過程、恢復與上班後的狀況，獻給長時間使用眼睛的工程師們。

本人狀況：

• 左右眼 950
• 閃光 150
• 戴眼鏡 25年( more? )
• 一天看螢幕約 8-10 小時
• 手術地點：台北市

本文絕無醫療建議、無業配廣告(誰要找你！)，本人也非醫療背景、眼科專業，請以醫師或專業人員為主。

雷射種類

手術技術日新月異，在撰寫這篇文章的時候，目前主流有這幾種:

1. Lasik
2. Smile / Smile Pro
3. Smart TransPRK

基本上網路都有講解這三種手術方式的差異，要使用哪一種應該以個人狀況與醫師建議為主，但我要提醒的是：

• 每一間眼科都有使用的技術，例如 A 的機器是 Smile，他當然只會推你 A。這個資訊在各大眼科首頁都能看得出來。
• 要公正的話還是自費去醫院檢查。我是沒有選擇醫院，一來花時間二來我就是著急！

前陣子在調整翻譯相關功能時，該來的還是來了，面對多國語系。

狀況

德語

原本的 MySQL 版本還維持著舊版本，雖然有料想到多國語系支援問題，所以把語系設定為utf8，以為這樣就能夠萬無一失了，沒想到發現德國語系出現不預期的問題，像是 ü 這個字，雖然能夠順利的寫進資料欄位，這時候我們再寫入 u會發生什麼事呢？

什麼事都不會發生

我們的資料庫會有這樣的兩筆資料

如果我們想查詢其中一筆時，輸入
SELECT * FROM TABLEA WHERE FIELDA = 'iamü'

接著不預期的狀況來了，MySQL 會同時把這兩筆資料給查出來！我馬上換個查詢使用 iamu 結果也是一樣！

這邊提供幾個德語都是容易造成問題的:

本篇文章旨在探討如何改善專案經理與工程師之間的溝通，以提高專案的成功率和團隊合作效能。

PM 到底要如何與工程師溝通才不會激怒對方呢？這個問題是所有 PM 都會遇到的，經驗不夠或是反應不夠快的人可能剛開始就被討厭了。

打開搜尋引擎，輸入關鍵字 PM RD 溝通，出來的結果滿山滿谷都在教 PM 如何與工程師溝通。這就讓我好奇了，既然溝通技巧是 PM 基本配備，那麼溝通有問題時，是工程師問題還是 PM 的問題？似乎大部分文章都是在告訴 PM 如何不惹怒工程師，那真實問題出在 …

強調：本篇文章討論的是純軟體業。

工程師為主的社群怎麼說

在工程師為主的討論區或社群，「PM」兩個字彷彿是哈利波特中的那個人的名字，千萬不可被提及，一但有人提到了相關議題，肯定是千夫所指、嫌棄聲不斷。總結一下不外乎是沒有專業、只會出一張嘴、傳聲筒、只會改需求，這話題講下去肯定是上百則留言或訊息講不完，那真實的情況真的是如此嗎？

在探究之前，不如我們先來思考一下

• 工程師心中認為完美的 PM 是什麼樣子？

• PM 心中認為完美的工程師是什麼樣子？

問題的根本是職能混淆