mycTW Note

發表於 更新於 分類於

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

閱讀全文 »

發表於 更新於 分類於 ，

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

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

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.

alt

什麼是 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會發生什麼事呢？

什麼事都不會發生

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

Id FieldA
1 iamu
2 iamü

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

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

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

閱讀全文 »

發表於 更新於 分類於

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

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

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

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

工程師為主的社群怎麼說

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

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

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

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

問題的根本是職能混淆

閱讀全文 »

發表於 更新於 分類於

QA 是在軟體開發過程中，確保產品品質、穩定性和可靠性，從而提高使用者體驗、滿意度的職務。它涉及測試、撰寫測試案例、定義 BUG、追蹤 BUG、以及與開發團隊協調等，做為 QA，絕對是軟體開發過程中非常重要的一個環節。

QA 職能

  • 手動測試

    手動測試 QA，在台灣的軟體界，蠻大比例是屬於這部分職能(可能會寫程式的都被抓去當工程師!?)。手動測試通常是基於需求文件和設計文件，設計測試案例和測試方法，然後執行這些測試案例，檢查功能是否符合預期的要求和標準。手動測試QA 最大的價值與優點在於人力能夠發現自動測試無法發現的缺陷，而缺點自然是無法快速執行大規模、重複的測試需求，因此通常需要結合自動化測試進行綜合測試。

  • 自動測試

    自動測試通常使用自動化工具和腳本來執行測試案例。相比於手動測試，自動測試具有更快、更精確、更穩定的特點且能減少部分手動測試的人力成本。但是，自動測試也有一定的限制，例如無法測試新需求、圖像、影像和音樂等，且前期需要投入一定開發成本和資源。因此，實務上仍然需要結合手動測試和自動測試人員。

常見的謬誤

很多團隊都認為全面轉變為自動測試就不再需要手動測試QA了。
我認為這是一個非常嚴重的錯誤。首先，撰寫自動測試的前提是須要有完整的測試案例，這些測試案例都是需要人為優先撰寫的。
其次，一個新的功能開發出來，緊急狀態下絕對是手動先進行測試，絕對沒有時間撰寫自動測試，最後是是自動測試能夠測到的範圍絕對沒有手動來得廣泛與深入。

自動測試適用的範圍應該是確保每次佈署新內容時，沒有影響到既有的完整、主要功能，
然而這樣的測試是非常 routine 且不可能每次佈署都做一次，這就能交給自動化測試，也就是 Acceptance Test。

另一個主要情境是確保主要功能正常的測試，也可稱作On duty Test。假設你們的產品是 7*24 不停歇的服務，或是內容或穿插相依外部的服務，那會很適合這種測試模式。使用自動化腳本，定時走一輪主要功能，確保當下服務都正常。

因此，我們應該了解自動測試的優勢與優點在何處，而不是一昧的認為自動測試能夠取代手動。

藉由 ChatGPT 來加速 QA 職能的方式

ChatGPT 也許只是一項跨時代的產品，乘著智慧 AI，接受它，站在巨人的肩膀上才是未來之路。在這篇文章我將演示透過 ChatGPT 來輔助撰寫測試案例，進而大幅度提升 QA 的效能與產值。

閱讀全文 »