回顧2019下半年

重溫上半年的回顧，2019上半年回顧。

上半年給自己拿下了今年的47%。有點驚訝，給自己這麼高分。上半年就丟了3%而已。哈哈～

下半年呢？

• 4個online courses
• 18支YouTube影片！
• 100天作畫。（不算幾幅畫，因為有時一天畫幾幅。）
• 1個國外旅行
• 20本書
• 10個TED talk summary
• 10部網路小說
• 18部電影（不包括重看）
• 2部連續劇

整年寫了14首完整/不完整的歌。大部份都是在下半年寫的。

這下半年呢，把YouTube影片的目標趕上了。不過，就沒怎麼練習鋼琴。繁體字練習也的確隔在一旁，專心完成《365堅持畫冊》。

下半年呢，開始了Instagram、TED talk summary。前天也開始了2020年的目標，要寫一些關於tech thought的文章。這下半年的50%嘛，讓我算算可以打多少分。嗯，40.7%，比上半年要差⋯⋯不過，我的下半年其實過得更充實咧。沒法子，按照上半年的計分方式，的確比較吃虧點點。不過，這個成績已經很不錯了。接下來，會給2020年先想好計分方式，以免到時亂了方向。

2019的打分是，87.7，有A噢！

信子，2020年，繼續加油！

先去看看James Clear的2019review，再寫我的。^^

第一次肉眼看日蝕

昨天大概中午一點半，站在公司的的陽台，抬頭往上看，見到了半環狀的太陽。起初，看見大地昏暗，以為又要下大雨了。後來，也所幸有厚厚的烏雲，把猛烈的陽光擋住了許多，於是可以用肉眼去看看這臨近年終的日蝕。

原本，沒那麼激動的。跟著同事一起看，他在拍照，我小心翼翼的看。後來就回座位。再後來，忍不住地把自己的手機也帶上，嘗試拍照。拍了這張照片後，我突然覺得興奮起來！原地跳了好幾下。現在覺得有點丟人。才發現，我的情緒，總是比別人慢好幾拍的。

就像我厭惡的人，也花了好多個年頭，終於把他們從臉書裡都刪了。（就刪了那兩個，感覺寫得好像有好多個的。:P）

Last Christmas

看了這部戲的廣告，我一直告訴自己，要去看這部戲。當然，看了不少廣告，也想看不少戲。不過，就是一直心念念的想看這部戲。於是，冬至不在家過⋯⋯

今天的時間很緊湊。不過，看了這部戲，讓我有種“幸好沒有錯過”的感覺。

戲院裡，大多數是雙雙對對的。一排有9個椅子，就是有幾個一個空位子穿插其中。我填上了其中一個空位子。隔壁座的以為那是空位。抵達的時候，他們的食物就在我的椅子上。（翻白眼）

很久沒有看這樣的小品了。故事有很多元素，新移民的問題、愛情、迷惑、親情、友情、homeless等。當然，故事的主軸是關於女主如何從她混亂的生活被男主引向正道，還有故事最後才發現這首“Last Christmas”其實講述了他們之間的連繫。我覺得故事很引人入勝。

最近看了不少戲和小說，都讓我感嘆及佩服作者的思路。

3,000 RPM

There's a point at 7,000 RPMs where everything fades.
The machine becomes weightless. It disappears.
All that's left, a body moving through space, and time.
At 7,000 RPM, that's where you meet it.
You feel it coming.
It creeps up near you, and it asks you a question.
The only question that really matters.
Who are you.

No, I never made it to more than 3,000 RPM.
As a matter of fact, I don't really look at the RPM as well.
What matters to me, is speed.
The road sign said 110 km/h, and there I'd have it.
Let it be a sunny or rainy day.
That's when I was young.
I did notice, I could go at most up to 3,000 RPM.
At top gear of my car, running at 110km/h.
The best feeling I ever had, behind the wheels,
is at the first turn, on the way back to my hometown.
Top gear, 90km/h, following the exact designated line.
Now the turn is gone.
They made the road a "straight line".
But no lorries or cars reached even a 80km/h on that road.
I wondered.
I missed the old days.
The speed didn't get me to the question that really matters.
I have never been to 7,000 RPM.
But this get me to wonder...
How does it feel when the machine is weightless?
How does it feel when your body moving through space and time at that speed?
But what I could do is nothing...
But moving through space and time at the ordinary life speed.

近況

最近，其實過得不是很好。可能有點憂鬱，有點躁鬱。對很多事情，都很沒耐心。有種總人皆醉我獨醒的感覺。

我想忍聲吞氣的，不過已經睡不好很多天了。每晚回家後都在想怎麼應付明天而輾轉難眠。無法控制情緒已經讓我更加不安了。我決定做自己的抒發。

做人嘛，催眠自己，讓自己過得好，應該是常情。不過，以推卸責任，然後催眠自己做得好，你腦子才有病吧？！怎麼變成是我病了？這就是“合群”效應。當大部份人都催眠自己，這個錯誤是他人的，因此，那個“他人”要改善。

我從事電腦、雲端相關的工作。去年年底，我兼做了用著的platform的functional owner，他們給了一個超好聽的名字，叫做business consultant。主要工作內容是寫requirement，讓程序員可以更了解他們要做出的product。不過，我又不是product owner，因此，我的工作比較屬於輔助性的。每每他們做出令人傻眼的作品出來，都是怪在requirement寫得不清楚。那個頭領每次都投訴我寫得太詳細，沒有給他們可以做出調整的空間。甚至試過一個project，直接把我摒除在外。當sprint要開始的時候，突然間說，沒有functional document，他們無法開工，然後把矛頭拋向我。X的。我也不是省油的燈。我直接說，我從來沒有參與任何討論，不曉得那是什麼project，該交由那些參與討論的人負責寫。那是幾個月前的事了。從此以後，就沒有發生任何project我被摒除在外的事情。

這次的sprint都是簡單的幾個小feature。其中一個，是要求一個小button來reset status。需要這個button，因為這個platform也太⋯⋯當deploying project的時候，那個project的status可能會死在Installing state。嗯，是status，而backend該做的事情，可能hang了，可能完成。不過接下來backend的step是無法繼續了。因此，我們得patch database，通過這樣的workaround來做undeployment for clean up，再然後重新deploy。Patch database呢，是因為直接改database，需要經過change management，得等荷蘭那邊開始工作了，assess了change request，再等infra team去做DB patch，我們才得以繼續我們的工作。有時候，往往是time critical的。我們會打電話去荷蘭那裡，做escalation。因此，這個request是要一粒button來reset那個status而已。結果～等到demo的時候，給了我一個drop down，和現有的一個form一起做update。變成，user要改成什麼status，隨由user。你知道這麼做多危險嗎？如果剛好要改其他field的value，然後剛好那個implementation的state改變了，而你按那個save button會把implementation的state弄錯？！Retrospective的時候，你說，這是因為requirement不clear。至少我要的是一粒button，有說到button，沒說到drop down，很明顯吧？！不clear不會問啊？！全部人睜著眼睛說鬼話。這只是其一。這個sprint只有幾個小feature，結果有三個feature是不符合要求的。不要去搜我在哪間公司工作，然後覺得我們公司不可靠。這些不穩定的東東，都交由我們去把該做好的做好，像我team lead常用的字眼，die die have to do it。親愛的客戶，為了滿足您的需求，您知道我們有多stress嗎？完美的包裝底下，我們花了多少心血嗎？親愛的D-level，C-level的上層，您知道您的dev team在做啥嗎？

第二個，原以為是不符合要求，因為demo說，那粒button只有在很特定的情況瞎才會出現。結果，那個放假回來的dev說是因為bug，那粒button應該都會出現的。QA瞎了嗎？（抱歉，不想人身攻擊，不過，這是simple testing吧？該show button的時候，沒show button。Dev也沒檢查自己的作品嗎？）第三個，是改善error message，developer自己做決定，自己去改每個error message的字眼，包括一些屬於比較technical的資料，不應該出現給end user的。問起QA怎麼一回事，他說，他不知道這些error會被end user看到，因此沒在意。

拜託，可以認真工作嗎？！

現在更離譜的是，這個sprint沒有fail。為啥呢？因為沒有寫acceptance criteria。既然沒有acceptance criteria，就不能說fail。把那三項變成了下一個sprint裡的task。然後得寫acceptance criteria。然後那個AC得寫得很詳細，這樣就不會有問題了。

對我來說，那已經是在寫test scripts，或他們說的test steps了。還說什麼behaviour driven development wor...

Acceptance criteria
A description of each specific scenario of the narrative with the following structure:
Given: the initial context at the beginning of the scenario, in one or more clauses;
when: the event that triggers the scenario;
then: the expected outcome, in one or more clauses.

然後，就寫成這樣。
AC1 : Given I am delivery engineer, when I go to XX1 implementation deployed with YY1 version page, then go to ZZ1 page, then I will see the button.
AC2 : Given I am delivery engineer, when I go to XX2 implementation deployed with YY2 version page, then go to ZZ1 page, then I will not see the button.
AC3 : Given I am delivery engineer, when I go to XX1 implementation deployed with YY1 version page, then go to ZZ2 page, then I will see the button.
AC4 : Given I am delivery engineer, when I go to XX2 implementation deployed with YY2 version page, then go to ZZ2 page, then I will not see the button.
AC5 : Given I am delivery engineer, when I go to XX1 implementation deployed with YY1 version page, then go to ZZ3 page, then I will not see the button.
AC6 : Given I am delivery engineer, when I go to XX2 implementation deployed with YY2 version page, then go to ZZ3 page, then I will not see the button.

那個⋯⋯這還沒有說到click那粒button後會怎樣呢！

我simple的requirement你都懶得讀，看不到，你還認為這個錯誤是因為寫得不夠詳細？然後，做出這樣的要求？你是機器嗎？這根本原因是你們不認真工作、不看requirement、斷章取義、不做溝通！根本的問題不解決，卻把它推在別人的身上。你好意思！

超級不爽！這是agile嗎？這是所謂的減少花時間在做documentation的政策裡嗎？嗯，是的，只要minimal dev work就對了。我工作差不多十多二十年，第一次碰到給developer的工作得有這個minimal dev work的前提。

算了，推給PO，我只是給requirement，你們要咋地就咋地，要go die就go die吧！

下次說關於渣男的故事。他說證明我還有魅力是件好事，不過，被騷擾可不是件好事。我也不需要被證明或認可什麼的。