Pages

搜尋此網誌

2015年6月15日 星期一

測試若水:向大師致敬

測試若水

enter image description here

因為讀了這篇

看板若水

2013 David Anderson 在 Lean Kanban University 上發表了一個演講,其中提到李小龍,引用他的哲學來說明 Kanban,讓我十分驚豔不已.

其實 agile 敏捷開發所追求的也是 TPS 豐田式生產的境界,避免所有一切不必要的浪費,而 agile 避免不必要的浪費,有部分是透過 TDD 來實現的。

TPS 中 lean production 也就是透過看板來進行流程控管,讓生產過程能夠:

  • 視覺化:讓生產狀況可以一目了然,容易發現問題,進而進行改善

  • 平準化:讓每個人的工作時間一致,減少不必要的等待,讓產能最大的發揮。

而 TDD 要做的事情其實也是一樣,透過 SPEC,TDD 的推行讓規格易讀,讓分工容易減少不必要的等待,也因為有 SPEC 的存在,可以很方便的確認系統運作是否正常。

by the way: SPEC 就是 test case,用 SPEC 也就是規格來替代 test case,是因為 SPEC 除了 test 的任務之外,還包含了說明系統運作的任務,如此,在進行相關設計時,就會考慮可讀性。

根據 看板若水 這篇文章,我也來依樣畫葫蘆,向兩位大師,還有看板若水這篇作者致敬一下。

價值導向

  1. 李:

    實用、簡單、快速:一切動作以實用,與勝利為目標

  2. Kanban/Lean:

    一切以客戶價值為最高依歸

  3. SEPC/TDD:

    一切以 SPEC 為最高依歸,實用、簡單、快速,好讀易用,測試驗證簡單快速

以無法為有法

  1. 李:
    人有的高,有的矮,有的胖,有的瘦,有各種各樣的人,對嗎?如果他們練習同一種武術套路,那麼這一套路又適合哪一個呢?

    我覺得,拳擊在運用中的最佳狀態應是沒有絕對的形式,用模式A對付模式B也許並不絕對正確。當你學習實戰時,會學習怎樣出拳,怎樣運用腰腿的力量配合。但在爭鬥當中,就需要根據對手來調適你的動作,這樣就做到了無限。

  2. Kanban/Lean:

    Kanban is a method without methodology.

    他不是教你如何進行軟體開發,是叫你如何做變革管理,以漸進式的方式來改善你的問題。

  3. SEPC/TDD

    TDD 是一個觀念,沒有複雜的應用技巧,學了 TDD 的觀念,不管在寫任何語言都有對應的運作方式,透過 TDD 運用,以漸進式的方式來改善你的問題。

消除浪費

  1. 李:

    格鬥中不該浪費時間與動作,最簡單的就是最好的. 動作經濟學是提高戰鬥「效率」的方法,而提出下面三種作法可落實. 遵照這原則能節省體力與時間. 體力與時間是格鬥中最關鍵的兩個資源,若能經濟地利用這兩項資源就能得到勝利。將體力最大化能保持動作的靈敏度,而將時間最小化則能減少對方反應的時間。

  2. Kanban/Lean:

    要消除浪費. 在 Lean Principle 中,對這部分已經做出很多說明
    WIP: 同時不要做太多事,讓事情變簡單,專心做好一件事,才再處理下一件事
    利用 cycle/lead time來觀察流程改善狀況

  3. SEPC/TDD

    要消除浪費,就是在開始開發之前,先把 SPEC 寫好,除了可以做為閱讀使用,還可以作為往後的驗證、改善、重構,甚至是推動自動化測試。

    且每個規格不要做太多事,專心定義好一個 SPEC,才再處理下一件。

    照三餐運行 SPEC 來觀察系統穩定度。

剛柔並濟

  1. 李:

    李小龍常用水來形容武術應該達到的靈活性。 水有無限的靈活性,它透明可看穿,但有時也能遮蔽視野。 水能分成兩塊,繞過東西,而在另一邊又合而為一。水很溫柔,能用以清洗。但也很剛猛,能拔山倒樹。

  2. Kanban/Lean:

    從你現在有的開始,逐步開始改進. 因此可以搭配你現在任何做法,但是透過視覺化管理,WIP 和持續改進等等,將困難逐漸磨合掉。

  3. SEPC/TDD

    SPEC 搭配 MOCK 技巧就像水一樣,寫 SPEC 也應該保留靈活性,讓開發活動,可以有效並行,MOCK 有無限的靈活性,它可看穿複雜的運作機制,但有時也能隔離尚未實作完成的函式。 MOCK 能讓程式分成兩塊,繞過東西,而在另一邊又合而為一。

結論

我常覺得,學的一個好的觀念,可以讓你少走很多冤枉路,比如 lean 的精神,不浪費的觀念,一旦你體悟到這是很重要的事的時候,在做事情的時後就會想盡辦法不要浪費一絲一毫,而 TDD 為什麼會覺得重要而一講再講,因為在開發過程導入 TDD 節省了太多事情,只是大多都只看到負擔,沒有看到延續長遠的好處。

當然,改變做事的方式是會被抗拒的,但明明問題就在那,你要往北,卻一直往南行,雖然很多時候沒辦法一路向北,但若不嘗試改變,永遠不會更好,共勉之。

2015年6月13日 星期六

TDD 分享三部曲 - 之一,測試:開發的源頭,自動化的起點

TDD 分享三部曲 - 測試:開發的源頭,自動化的起點

enter image description here

前言

近期(2015 年中)與社群大大一起去國內某資訊公司分享 Agile 開發流程,我負責說明 TDD。

之所以要講 TDD 也是因為我個人覺得這是很重要的觀念,特別是團隊開發的情形,更需要這樣的工法輔助。

因為很重要,加上這次分享已經講第三次 TDD 了 XD。

也因為是第三次,也算是一個里程碑,想說為自己記錄一下,也讓有需要的人可以參考 :)

題目

題目: 測試:開發的源頭,自動化的起點
地點: Mozilla Space
主辦: Node.js Party
日期: 2014/11/13
活動頁: KKTIX
簡報: https://www.slidenow.com/slide/98

這是第一次在公開場合說明 TDD,是有一陣子的簡報,除了簡報分享,想要把簡報過程,收到的回饋記錄一下。

這份簡報是用 slidenow 進行,是一個用 markdown 來寫簡報的好工具,使用上很方便,也是國內某大大的作品。

這次準備的簡報,想法是透過簡單的介紹,讓大家了解 TDD 怎麼進行。

簡報過程就不多做說明,大家可以看連結,將針對遇到的問題,還有個人的一些感想與大家分享。

與會者中,提到的問題有以下,因為太久,只能說是印象中…

遇到的問題

test 佔開發中的多少比例?

老實說,我不知道,但正確的觀念是 test 本來就是開發的一部分,而不是分開的兩件事。

唯有把它當作必要的事,才有可能執行。

先面對問題,才能解決問題。

test 會拖慢開發速度嘛?

其實並不會,反而會加快開發速度,因為 test 都在 command line 執行,確認結果,不需要啟動 browser 進行,因此可以更專注於程式的開發,開發過程也會較有節奏。

新進人員怎麼適應?

有請 team member 分享,開發後端 api 實作時,不准開 browser 確認結果,都在 command line 進行,強迫沈浸在 test 的環境將任務完成。

經過跳離舒適圈的過程,也讓原本沒有 test 觀念的 member 能夠理解 test 的好處。

主管不推,同事不配合怎麼辦?

需要 fight,或許可以先自我進行,試著做出成效,展現好處後,讓其他人也看到它的好處,漸漸的就會有更多人加入。

結論

因為這次題目的關係,與會者都是對 test 有興趣的人,所以會議進行中專注度還蠻集中的,可以看得出來認真的程度,會後的討論也很踴躍,表示很想了解 TDD 的一些細節。

不過就我的感想是,大家都有痛,但好像都礙於現況,沒辦法推進,或是情勢比人強,專案進度趕或是已經 out of control。

其實,若真的有痛,就是一點一點改善,慢慢的導回正軌。

那時候柯 P 有一句話很讓我印象深刻:

先面對問題,才能解決問題。

加上最近很喜歡一句話:

念念不忘,必有迴響

最後近期讀到很推薦的「 被討厭的勇氣」這本書

其實,解決問題不就是這樣:

  1. 知道並且感受到問題(有痛):先面對問題,才能解決問題。
  2. 念念不忘(有恨):不停的找可能的做法,找到可行解
  3. 不怕被討厭的行動(決心改善):因為是對的事,堅持行動,即使會被討厭、或組織不支持還是要進行。

如果每個人遇到問題,都能夠正視,並且積極面對,從個人開始,我想世界會越來越好的。

或許每個人的做法不一樣,一點心得與大家分享。

2015年6月7日 星期日

參與 JS Devil Day - JSDC Meetup 後感

參與 JS Devil Day - JSDC Meetup 後感

enter image description here

就在 2015 年 6 月 6 號星期 6,666 這一天,我人在宜蘭羅東參與了這個盛事 …

JS Devil Day - JSDC Meetup

由 JSDC 主辦,livehouse.in 進行線上轉播,與以往 meetup 不同的地方在於,這是一次北中南的大串連,三地在不同地方,同時參與的一次,實體活動報名如下!

除了實體活動再搭配 livehouse.in - JS Devil Day 線上直播。

就像沒幾天前的 google IO,除了主辦地之外,全世界都在線上參與了這樣的盛事。

雖然不是世界規模,但也是一個大大的嘗試,誰說 meetup 就一定只能實體進行?

在網路如此發達的現在,時間與空間都已經不像以前受限,很多知識可以直接從網路上獲取,同樣的參加 meetup 也不一定要人到場,整個台灣只要有網路的地方就可以進行 meetup!

而且以目前台灣 meetup 的舉辦頻率,以 kktix 的活動不分類,單純搜尋地區名:

  • 台北:158 場
  • 台中:19 場
  • 高雄:16 場

將近十倍的差距,如果每一個活動都可以有這樣進行方式,也算是縮短北中南的時間與距離!很感謝有這樣的 meetup 舉行方式。

當然,實際親臨還是與遠端有差,這次主辦單位也很用心,為了讓三地的與會者也有參與的感覺,特別在最後 QA 時段,讓台中與高雄的朋友也有機會與主講者互動,與一般遠端只能單向的進行方式,主辦單位有花些心思讓大家都參與其中。

講者分享內容就不在話下,這樣的 meetup 的方式還有一個好處,隨時想要再溫習,過程中有沒聽到的還可以重播。

enter image description here

遺憾錯過這樣的活動嘛?沒關係,現在你也可以點選 livehouse.in - JS Devil Day 進行觀看,任何時候都可以重播觀看,準備好你的爆米花跟可樂吧!

感謝 JSDC 安排這樣的活動,livehouse.in 進行線上轉播,台中 Trunk Dojo、高雄 MOPCON 2015 提供場地,讓這樣的性質的活動有機會北中南大串連,讓遠在他方卻很想參與的人可以一起共襄盛舉!

工程師邁向管理者,專業養成指南

工程師邁向管理者,專業養成指南

enter image description here

工程師,通常是被保護的一群,在良好的開發環下,工程師通常只要根據規格,好好的功能開發出來,理想上就會像工廠的生產線一樣,專心一致的進行開發。

當然寫程式不像工廠生產那樣的簡單,這是不可質疑的事實,生產產品步驟確定後大致上來幾次都是一樣,但程式開發是複雜多的工作,程式寫得好不好每個人都有不同的造詣,一旦程式開發熟悉到一定程度時,大致上會有幾個階段:

  1. 工程師:見山是山,做好本份
  2. 資深工程師到管理者:見山不是山,兩難,困惑
  3. 管理者:見山又是山:看得更遠更廣

工程師轉資深工程師通常不怎麼痛苦,畢竟是同性質的事,就是必須在專研技術,瞭解更多細解以及理論基礎,就看你的技術深度。

比較難適應得就是開發者轉管理者了,因為很難適應,基本上也不是自願的,那又為什麼要呢?

enter image description here

Die Hard 4.0 有一段對白我很喜歡:

「你以為當英雄很好嗎 ?? 沒什麼好的,別人對著你開槍,偶爾被稱讚一下什麼的,然後離婚,老婆不記得你姓什麼,孩子不想跟你講話,你一個對著空桌子吃著飯,所以沒人想當那種人。」

「那你為什麼要當那樣的人!? 」

「因為沒有其他人肯做,相信我,如果有其他人願意做,我會讓給他們做,但現在沒有。所以我得做。」

是不是吃力不討好的苦差事?但際遇總是累積來的,你揀了別人不想做的事,也因此你跟別人就不一樣了。

當然現實世界不像電影一樣,歷練往往需要累積,就從一開始的工程師階段看起。

工程師,專注於一點,見山是山:「 Zoom In」

作為工程師,所專注於的就單一問題解決,所要面對的問題,都是電腦的問題,那是非零即一的問題。

所以,當工程師是很快樂的,不用管太多,只要專注於把問題解決。

在這個階段,若你做得不錯,將會有機會再往下一個階段邁進:成為管理者,但在這之前,你需要做到什麼呢?

  1. 管理好自己
  2. 尊重自己的專業
  3. 實事求是
  4. 相信自己
  5. 令別人安心
  6. 做好自我時間管理
  7. 好好的把一個語言學好

特別是第七點,學好一個語言並且夠深入,將有助於之後學習其他語言學的又快又好。

如此,機會來的時後,你才有選擇的權利。

而你所要訓練的就是你的專業,這段時間你看的書,都會是跟技術相關,比如:

  • 你所學習語言的 觀念 書:找到一本經典,勝過讀一堆。
  • clean code:乾淨的程式碼有哪些特性,從日常開始要求。
  • Specification by Example - 團隊如何交付正確的軟體:測試寫得好,除了累積測試能量,也可以加速開發。
  • 學徒模式。
  • design patten。

上述書籍,除了第一項,其他都是觀念書,也就是說,不管你寫哪個語言將會受用無窮,就像天下武功,為快不破一樣。

或許你會覺得資質不夠不一定看得懂,但人腦是很神奇的,或許當下你不了解,但你讀過之後,經過一段時間發酵,總有一天你會突然領悟,因為你已經種下一個觀念的種子,一旦你的經驗有了發了芽,總會有結果的那一天。

離開舒適圈總是痛苦,見山不是山,失焦: 從 Zoom In 到 Zoom Out 的「過程」

如果你願意接受轉換的機會,那狀況就會變成:原本你只要管好自己,現在你還要管好別人。

還記得有一個廣告詞是這樣說的:

要刮別人的鬍子之前,要先把自己的刮乾淨。

說的正是這件事,就像爸爸帶小孩需要以身作則,才能給小朋友當一個好榜樣,帶團隊當一個管理者也不外乎是。

剛轉換時候,基本上你是不只要開發,你還要管理,比如排進度,分工,還要解 bug。

所以你會非常非常忙…. 但這就是一個學習成長機會,你將經歷:

  1. 區分事情的輕重緩急
  2. 區分 team member 的特性
  3. 學習如何讓上下安心
  4. 學習冷靜面對問題
  5. 學習如何避免同樣的問題重覆發生
  6. 學習溝通
  7. 學習表達
  8. 學習分工
  9. 學習更有效率的處理事情
  10. 學習承擔
  11. 學習下決定
  12. 學習拒絕
  13. 對自己專業的要求(因為要當 team member 的靠山)
  14. 學習信任
  15. 學習建立原則
  16. 學習建立有效率且標準的流程
  17. 學習少抱怨,多正面思考

沒錯,可以看到你不只是面對電腦,還要面對 ,這時候你會覺得很煩,因為 比電腦複雜太多了,除此之外,你的目標會開始從寫好程式,變為:如何協助團隊變得更好,過程中你會很掙扎,因為當問題來的時候你的工程師的一面會想要趕快解決問題,但一旦你去做了,底下的人就沒有學習的機會,這樣一來,所有的重擔就會在你身上,你就會成為團隊的瓶頸…

而你所需要閱讀的知識,會從技術書轉換到管理相關的書籍:

  • 人月神話
  • people ware
  • 少但是更好
  • rework
  • TDD 開發方式
  • 版本控制流程
  • 自動化流程(CI: 持續整合)
  • scrum
  • 豐田式生產方式

作為管理者,團隊如何越來越有效率,讓每一次瓶頸都被改善,就是最重要的課題。

並且,團隊內資訊的通透度,團隊的份圍,member 之間的信任感,都是管理者所要營造的。

而你漸漸的就會像母雞帶小雞一樣,作為母雞,抵律老鷹的攻擊,讓小雞好好的工作。

最終,你將看得更遠更廣,見山又是山: 「Zoom Out」

你將少了很多開發上的學習,但並不是說就放棄了本業,你所要面對的問題將會用上之前所學:

  1. 處理更有挑戰性的程式問題。
  2. 解決開發流程上的問題。
  3. 設計避免犯錯的機制。
  4. 思考自動化機制。
  5. 思考架構上的缺陷並改進。
  6. 有機會進行你想要做的改變。

作為管理者,需要讓 member 值得信服,原則很重要,
所有決定都要保留彈性,這樣才能不怕下決定,才有機會在過程中進行調整。

如果有幸,有個人願意帶著你學習,讓你可以有犯錯的機會,願意給你空間,別忘了,也給你底下的同樣的待遇。

所以當你成為一個真正管理者後,你的職責將有:

  1. 將你的經驗引領更多人
  2. 實施你認為有價值的事情
  3. 教導你認為正確的觀念
  4. 給 member 學習的機會
  5. 讓 member 有犯錯的空間

多做一定多錯,一般傳統的管理方式,就是責備做錯的人,如何檢討並且避免下次再犯錯才是你需要注意的。

遇到問題推卸責任不是積極作為,共同面對問題,才是務實的做法。

試想,若你是很認真解決的人,一旦犯錯就否定了一切努力,那怎麼還有心繼續向前?

但,另外一個角度還是有認真過頭蠻幹的情形,這時候如何引導他變得更好,就是需要智慧了。

結論

不管任何事情,即使害怕,願意承擔,就有機會成長,就看你要不要踏出那一步,過程雖然痛苦,也不一定有好的結果,但至少你不會後悔,因為,你試過了。

What would you do if You weren’t afraid?

如果你不害怕的話,你會做什麼?

思考你真的想要的是什麼?

這一段是看到 team 裡面的 member 站在台上與人分享後在 Facebook 上所寫的一段話,三不五時可以問問自己,你希望的自己是什麼樣子。

把握每次成長的機會,在你的生涯中,若有機會從工程師轉變為技術管理者,一方面是因為你已經可以管理自己,這時候才能管理別人。

這篇文章說實在講得有點多,要養成一個專業的人,本來就沒那麼簡單,但不管任何方式,總是可以參考,希望我的經驗,可以讓正在起步的人,有個大致的方向,並且少走一點冤枉路。

專業開發者,就像武功高強的武者,不停地練習,讓出招的過程沒有多餘的動作,精準快速的解決問題。

而管理者就像一代宗師,把知識還有觀念傳遞出去,讓 member 盡可能的有空間犯錯,有機會成長。

你想成為哪一個?不管怎麼決定:念念不忘,必有迴響。

最後,專業有價,要別人尊重你的專業,請先尊重自己的專業。

2015年5月27日 星期三

和歌山單飛之旅:其一,雄野三山

和歌山單飛之旅:其一,雄野三山

到達大阪的第一天,因為旅館訂在和歌山市車站附近,所以先搭電車到達下榻的旅店,吃個晚餐隨意走走一下就洗洗睡了

enter image description here

與和歌山市車站容易混淆的還有一個叫做 JR 和歌山車站,實際上就旅途的過程,第一天住在 JR 和歌山車站是相對方便的,至少第一天早上不需要再轉一次車,可以節省一些時間

enter image description here

其實這次出遊沒有時間做太多功課,很多時候都是在坐車的時候查一下下一個點要去哪裡,因為只有幾天的時間,可以的話想要先到較遠的地方再慢慢玩回來,這樣時間上也比較好掌握,稍微查了一下之後,決定先到熊野三山的熊野本宮,在和歌山縣的官方網站有大概的交通方法:

從和歌山到熊野本宮

真的是很簡約,目前在日本使用 google map 算是蠻清楚的,會幫你把轉乘的資訊寫得一清二楚,根據官方的資訊要先到紀伊田邊站,車行時間大概 1 小時,為了不要太晚上山,大概早上五點半左右就出發前去坐車。

一個人旅行一開始總是比較緊繃,再坐火車的同時還在考慮是否要殺這麼遠,畢竟不確定性很多啊!

到了車站後門口有個武藏坊弁慶像的廣場,傳說紀伊田邊是他的出生地。

enter image description here

看了一下相關資訊,從車站到熊野本宮要搭乘兩小時的公車… 這時候一個人旅行的猶豫又出現了,到底要不要上車勒?反正還有一些時間先去預定的旅館 check in,但是一大早沒人,本來想說行李可以寄放,畢竟帶著很重,最後為了方便行動,花了 300 圓日幣,寄放在車站的置物櫃,想說晚點回來再領回囉!

至於如何搭 bus 前往熊野本宮,在車站旁有旅遊咨詢站可以詢問,本來想說可能要比手畫腳一下,還好服務人員英文很好,是個長得很甜美的日本女生,可惜沒圖沒真相囉!有興趣的在自己走一趟吧~

使用 google map 可以很方便的查看鐵路的交通資訊,可惜的是 bus 沒辦法查詢,在非大都市搭乘 bus 其不安程度又高了一些,詢問了旅遊中心,還好有明確的時間表:

去程:

時間表圖

回程

enter image description here

最接近的車班是 9 點左右,在日本除了鐵路準時以外,bus 也是不可思議的準時!真的太強大了!車子一到整車只有三個人…

enter image description here

司機、阿婆還有我,心裡的 OS:哇操!這路線有這麼冷門!?經過漫長的兩小時的車程,大概中間會休息一次,對於婆婆媽媽算是蠻人性的。

總算到了目的地,一個人旅行的煩惱又來了!等一下結束後我是要原路回去還是要去新宮站,本次旅程最遠的目的地勒?

分析一下現況:

  • 因為怕行動不方便,所以行李大部分在田邊站,回去需要兩小時加上日幣一千五左右的車資。
  • 前往新宮只要一小時車資相對便宜,但我會失去我行李一天,不用走回頭路

既然是出國旅遊,就要盡可能的多走訪不同的地方,所以最後決定前往新宮,一天不換衣服不會死人,時間寶貴!

打定主意後,就先放著吧,先享受一下長途跋涉的果實,熊野本宮

enter image description here

參訪完熊野本宮之前有介紹在這附近有個巨大鳥居,看到宣傳照片時其實沒什麼感覺,只知道有這地方,該鳥居位於大斎原是熊野本宮的舊址,因為1889年的一場水災把該舊址的神社摧毀,在較高的區域重建,遺留下來的就只有屹立不搖的鳥居。

enter image description here

可以仔細看到鳥居下面的點點人們是多麼小,就知道那鳥居有多大了…

每年八月還有特殊祭典,叫做 「八咫の火祭」

八咫の火祭

在那時候鳥居會打上燈光,可以看到不一樣的風貌。

接著準備離開熊野本宮,到位於寺廟附近的服務中心,搭乘公車前往新宮

在等公車的同時,進入服務中心閑晃一下,發現另外一條俱有挑戰性的路線

enter image description here

總長 20 km 步行 8 小時的專業路線,只好等下次再來挑戰,先記錄下來。

等沒多久,公車總算來拉,這次還好不止我一個,沿路安心許多,一個小時的車程後,就到了新宮車站,前往雄野三山之二:熊野速玉大社,就位於新宮車站不遠處。

往南走大概 20 分鐘就可以到雄野三山之三:神倉神社,該神社位於山壁邊,神社上方有個巨石,往海邊望去就可以看到整個新宮市,是個很特殊的寺廟。

enter image description here

enter image description here

另外神倉神社還有個很有名的慶典叫火祭,如下圖:

enter image description here

有機會可以親臨感受一下!

第一天的行程到這邊算是告一段落了… 早上五點半到起床就不停地走路,還好來日本前有前往松蘿湖鍛鍊一下體力,不然一定撐不住。

因為隔天要前往,熊野那智大社所以晚上先到紀伊勝浦住宿,從新宮搭 JR 前往,半小時左右就到了,今晚沒有預先網路訂票,找了一家民宿。

跟老闆比手畫腳一番,最後以日幣 4000 元取得,這間民宿不得不推薦一下,對於一個人旅行而言,真的是天堂,老闆是兩個年輕人在經營,有一整櫃的漫畫跟動畫,可以讓我在一個人的夜晚不至於太寂寞…可惜我忘了拍民宿外觀,也忘了民宿名字 :P。

enter image description here

還有紀伊勝浦這也是溫泉勝地,所以民宿內的澡堂也是引入溫泉水,泡起來非常舒服!

enter image description here

洗完澡之後到街上走走,為了犒賞今天一整天的辛勞,因為這邊靠海,所以有很豐富的海鮮,既然如此就應該要找個海鮮丼飯來嚐嚐:

enter image description here

enter image description here

從門口看來若是白天應該可以看到現宰表演,應該是蠻新鮮的,今晚吃的是 1280 日元的海景丼飯!

呼~整個人都活過來了!早餐跟午餐都草草解決,晚餐總算是個像樣的!

回到飯店,到老闆的收藏看看有沒有可以打發一下時間的,既然在日本就看看宮崎駿的「風起」

enter image description here

搭配回來的路上買的清酒

享受一個人輕鬆的夜晚!結束這一回合~

後記

今天是顛沛的一天,但也是豐富的一天,雖然知道目標在哪,但過程非常不明確,誤打誤撞的也把想去的地方都去到了,看來我的運氣不錯!不過也要感謝這時代旅遊門檻大大的降低,google map 還有網路真的是旅遊的好夥伴,善用這些工具,可以讓不確定性降低許多,很多時候找路線都可以不求人,不知道去哪時,看看景點評分也可以協助判斷。

在來就是日本的交通運輸真的非常值得信賴!火車就不說了,連公車的時刻表也是準準準!台灣的公車時刻是區間式比如說每一小時一班,可是你可能不知到實際時間是什麼時候,在日本即使是山上的公車,每個站牌都有明確的到站時分,讓我安心許多的在附近趴趴走!

完成今天一整個行程,讓我信心大增!另一方面往後的行程都沒有今天這樣不確定,可以更安心的享受旅程的中的風景!一個人在日本旅行想想可能覺得好像很困難,其實只要克服心理障礙,一切都會變容易。

背包客站雄野三山攻略

2015年5月26日 星期二

讀書心得:被討厭的勇氣

讀書心得:被討厭的勇氣

enter image description here

enter image description here

被討厭的勇氣,這本書是偶然在 facebook 塗鴉牆看到的書,卻吸引到我的注意力,有一股非看不可得衝動,對我來說。

當我買了這本書時,我老婆看到,就說:你需要看這個嘛?你本身就很有被討厭的勇氣了 XD。

哈哈哈,聽完也只能大笑 :D,不過,也是因為這樣,人生真的也是自己的決定,對自己的負責,或許我還沒有像書中說的這樣的豁達,但至少現在的一切都是我自己的選擇,不管好壞!

下面是節錄書中一些比較重要到文字,跟一些我個人的意見,給大家參考,若有興趣的朋友,也可以去買買看。

軟弱是強大的力量

在我們的文化裡,如果要問說誰是最強的,嬰兒應該是最合理的答案。嬰兒支配他人,卻不受支配。
嬰兒就是用軟弱支配大人,卻因為軟弱而不受任何人支配。

我見

嬰兒的軟弱,讓人可以接受,但一般人的軟弱,卻會讓人受不了…

把不幸當作武器

只要把不幸當作自己特別的武器,那就永遠需要不幸的狀態

我見

比如,專案 always 很趕,為了不要在接更多任務,所以要一直保持很趕的狀態,反而是個逆向循環

所有的煩惱,都是人際關係的煩惱

否定向他人尋求認同,只要肯定自己,不需要滿足那個人的期望而活,別的人也不會為了滿足你的期望而活。

課題分離,不涉入他人的課題

所有人際關係中的紛爭,差不多都是因為一腳踩進別人的課題裡,或是自己的課題遭受干涉所引起。

要怎麼區分是誰的課題?從這個決定而帶來的結果,最後由誰來承受來進行判斷。

若是小孩子也不是放任,而是清楚知道小孩子在做什麼,在身旁守護他,以讀書來說,可以事先讓他知道這是他自己的課題,如果他想要用功讀書,你會隨時在身邊提供他所需的支援,但是絕對不要干涉孩子的課題,在孩子沒有提出請求的情狀下,不要一一插嘴干涉,同樣的,父母提出的建議他不一定要聽,有任何意見也可以反駁。

這是為你著想這句話,很明顯的父母是為了自己的目的,也許為了體面,但不是小孩子真的想要的。

我們可以把馬牽到水邊,卻不能強迫她喝水,只有自己可以改變自己。

相信別人是你的課題,可是別人對你的期望或相信要怎麼反應卻是別人的課題。

我見

這部分我個人也非常認同,通常我已經說過的事,我不喜歡說第二次,又或者新進人員進來,資深人員不能幫他解問題,因為這是新進人員的課題,若新進人員不解決,哪天他遇到時,就是他要承擔後果。

在工作上來說,這感覺就像我們在運作 scrum team 的情形,給 team member 絕對的信任,當他們需要協助時,隨時歡迎提問,若對我們提出的意見,可以反駁,但若沒辦法反駁,有時就要以我的們的意見為主。

小時候我爸媽常跟我說,你若喜歡也可以唸書就念,如果不喜歡唸,就去找你想做的事,感謝我爸媽,總是讓我們自己決定我們要做的事,也因此,從小家裡兄姐還有我,總是自己選擇要做的事,所以,我們都很任性!但我們都對自己的決定負責。

自由

貨幣是被鑄造出來的自由。

所謂的自由,就是要被別人討厭。

就是有人討厭你,那正是你行使自由,讓自己生活自在的證據。

如果你無法不在意別人的評價,無法不害怕被人討厭,也不想付出可能得不到認同的代價,就無法貫徹自己的生活方式。

同樣的你沒辦法改變別人的看法,當你跟某人不合時,你能改變的只有你自己,所以,自己的部分你能淨亮改善,但別人的部分不在你的控制範圍,這也是課題分離的範圍。

分享

不要想著這個人會給我什麼,而是我可以給這個人什麼

所謂的歸屬感並不是與生俱來的,而是要靠自己的雙手去或得的

我見

分享的概念 :)

橫向的關係

不能責罵,也不能稱讚。

橫向的關係,不可以稱讚也不責備,只有感謝,之所以這樣的是有幫助的,也就代表我們之前沒有上下關係,唯有這樣才能暢所欲言,若是使用稱讚,就會有控制的意味在,所有人際關係應都是橫向的,沒有高低,每個人皆平等。

最重要的是,不評價他人,人在聽到感謝時,就會知道對他人有貢獻。

勇氣

人,只有在覺得自己有價值時才會有勇氣。

不是從別人那裡獲得好的評價,而是自己主觀認知我對別人有貢獻。

存在的價值

我們不以行為層級,而是以存在層級來看待別人。

我見

曾經有 team member 說,我們雖然沒有真的幫忙,但只要我們存在就會有安心的感覺 :)

光是活著這一點就會成為你或家人心靈上的支柱。

平等

只要你和任何一個人建立縱向關係,不知不覺間,你所有的人際關係都會採用縱向的方式

重要的是,在意識上是對等的,而且該堅持的地方就堅持,坦坦盪盪不退縮

我見

常常有人問我,雖然知道 TDD 很重要,但公司裡面就是沒有辦法推,看到這裡,我知道下次有人問我這問題時,我又有一個說法可以講了 :)。

坦然

接納自我:該如何運用自己,在自己辦不到的時候,坦然接受辦不到的自己

並且思考,該怎麼做可以在更接近 100

信任他人,貢獻他人。

求你賜給我平靜的心,去接納無法改變的事物;賜給我勇氣,去改變可以改變的東西;並賜給我智慧,去分辨這者的差異

工作狂

工作狂,很明顯缺乏人生協調。

以工作為藉口,迴避人生其他的責任。

幸福

什麼叫做幸福,就是對他人有貢獻,的貢獻感。

卓越

簡便的追求卓越,就是透過一些奇怪的舉動,吸引他人注意。

甘於平凡的勇氣

一旦在想變得特別好的過程中遇上了挫折,就會跳入極端的特別差。

這是接納自我的關鍵,如果能擁有甘於平凡的勇氣,這世界一定大不同。

拒絕接受平凡的你,肯定把平凡跟無能看做同一件事,平凡並不是沒有能力,而是我們沒有必要刻意炫耀自己的優越性。

我見

謙虛。

剎那人生

人生是一連串的剎那,我們只能生活在當下。

所謂的人生,就像一圈一圈跳著舞,跳著每一個瞬間,成為一連串的剎那。

如果為此時,此刻點上閃亮的聚光燈,應該是看不見過去,也看不見未來。

過去發生什麼事,和當下一點關係也沒有,而未來會如何,也不是當下要考慮的問題。

人生最大的謊言,就是沒有活在當下。

結論

人生每個人的際遇不同,很多時候就是太在乎別人的感受,而讓自己承受不必要的包袱,我們能做的就是盡可能的做好自己的本份,屬於我們沒辦法控制的部分也不能太強求。

不管是分享還是寫 blog 你是不可能討好每一個人,想寫或想講的,也是你發自內心散發出來的東西,這樣個觀念可以讓屏除一切,而擁有勇氣發言,或是站到浪頭上。

對於別人,不要有縱向的人際關係,而是橫向的每個人說話的份量都一樣,如此,也不會因為權威限制了你的可能性。

還有很多很多,或許沒有辦法一一說明,就像這本書,我的的讀後感是這樣,或許你的又會不一樣 :) ,肯定自己,把握你的當下,就像灌籃高手櫻木花道在最後說的:我只有現在。一起奮鬥吧!

2015年4月27日 星期一

前端自動化測試之 Selenium docker 環境 debug 指南

"前端自動化測試之 Selenium docker 環境 debug 指南

enter image description here

繼上次的 docker e2e 自動化測試的文章,本篇要在說明一下在自動化測試環境的 debug 方式。

docker e2e 自動化測試中有提到在 Selenium 官方的 docker 雖然沒有辦法在 ubuntu 上的 jenkins 當作測試環境,但可以在自己的機器上進行 debug,以便釐清在自動化測試報錯時,實際的狀況如何。

第一步

定義環境變數

export SELENIUM_IP=11.22.33.44
export HTTP_IP=55.66.77.88

在這邊 SELENIUM_IP 指的是測試標的 server 的 IP,若你是用 Mac 運行 docker 要取得 docker 的 IP 需要透過 boot2docker ip 來取得。

而 browser 因為在 docker 內,所以也需要知道運行 server 實體的 IP 位置,所以要指定 server 的 IP,如此 docker 內的 browser 才能連到正確的網址

設定好環境變數,再來就是要進行安裝。

Selenium 官方的 docker install

安裝指令

git clone https://github.com/SeleniumHQ/docker-selenium.git
cd docker-selenium
docker pull ubuntu:14.04
VERSION=local make build
docker run -d --name selenium-hub -p 4444:4444 selenium/hub:2.45.0
docker port $(docker run -d -P --link selenium-hub:hub selenium/node-chrome-debug:2.45.0) 5900

執行完最後一句,理論上會有類似下面的訊息

#=> 0.0.0.0:49338

指的就是你的 vnc 連結,port 預設密碼為 secret

在 mac 底下若你有用 alfred,可以鍵入下列網址:

vnc://SELENIUM_IP:49160

實際執行的畫面如下

enter image description here

非常乾淨的桌面,因為他只作為 Selenium 運作而存在。

結論

所謂自動化測試,雖說是自動化,很多時候還是會跟開發環境有出入,最不負責任的說法就是:

  • 我的環境可以,所以不是問題。
  • 我看不到畫面,沒辦法 debug。
  • 自動化測試跟一般開發環境不一樣。

所以,自動化測試要能夠 work,還有一個很重要的因素,就是要能夠 debug,讓整個過程能夠被觀測,進而進行狀況排除,特別是前端測試,更需要實際運行畫面的存取。

就我自己的經驗,就算 e2e docker 的測試環境已經可以在 jenkins 正常運作,其測試結果還是跟我自己的 Mac 開發機有出入,也幸好上述的方式可以讓我進行相關微調。

現在在專案所運行的 e2e test 不管是 Mac 的開發環境或是 jenkins 上的自動化測試結果皆相同,在正確通過測試的基礎下,異常狀態將可以被偵測。

完成這一段不容易,能夠導入的應該也不多,給需要的人參考。