2018/10/17

Spring Boot 試作紀錄

工作上的系統,架構常用到micro-service,建立這些服務,常常都需要自己架構出需要的服務元件。常讀到Spring Boot的介紹,對它的自動化很好奇,趁著有個小空檔來試作一下。

試作目標:
  • 支援 static resources
  • 支援 servlets (HTTP request handler),收到request後,可根據client的資訊作回應
  • 嵌入Tomcat或Jetty

使用環境:Eclipse 2018-09

安裝 Spring Tools
進入Eclipse後,點選 Help | Eclipse Marketplace...
以 "spring tool" 就可找到 Spring Tools 4,點選Install即可安裝

建立 project
我們利用剛剛安裝的Spring Tools提供的工具來建立Spring Boot專案。
首先在主選單點選 File | New | Other...

選擇 Spring Boot | Spring Starter Project,然後進入Next

接下來要設定專案的相關資訊了,雖然事後都還可以調整,不過一開始就先設定好,後面可以省些事

幾個比較重要的欄位:
  • Name (專案名稱),這預設會連動到下面的Artifact ID
  • Type, Java Version, Language都使用預設,Packaging有Jar與War,看未來想打包成何種形式,可以在pom.xml中改變
  • Group (Group ID) 用來識別此專案的名稱 (可參考這裡),可以在pom.xml中改變
  • Artifact (Artiface ID)在未來產生Jar file時會用到這名稱,可以在pom.xml中改變
  • Version用來記錄版本,在未來產生Jar file時會用到,可以在pom.xml中改變
  • Description用來對這個專案作一個描述,可以在pom.xml中改變
  • Package則是建立程式時預設的package架構

接下來就要選擇專案需要的dependent libraries了,例如若專案需要用到PostgreSQL的JDBC driver,就可以直接勾選,Maven就會自動幫你下載了。
目前試作的專案只需要Web,所以就勾選Web即可。

點選Finish,Spring Tool就開始幫我們產生專案了。

Spring Tool幫我們產生了一個程式 GreetingApplication.java。這程式的內容很簡單,就只是啟動Spring Boot的應用


建立靜態網頁
靜態網頁與相關資源(js, css, etc.) 可以放在src/main/resources/static下。在此專案我們就放一個簡單的網頁。


page.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Welcome</title>
<link href="css/page.css" rel="stylesheet" type="text/css" />
</head>
<body>
<h1>Hello, welcome to static page.</h1>
</body>
</html>


page.css
h1 {
color: #ff7777;
font-style: italic;
}


建立Servlet (request handler)
接下來我們要進行動態回應的部分。我們列出需求:

  • 當使用者以POST或GET連結到 http://:8080/func時,則會由此handler來處理
  • 如果request parameter有name,我們就回覆 Hello, !,如果沒有name,則回覆 Hello, world!
  • 列出使用者的IP

我們建立的handler如下 (RequestHandler.java)
@RestController
public class RequestHandler {

    @RequestMapping(value="/func", method={RequestMethod.GET, RequestMethod.POST})
    public String handler1(@RequestParam(value="name", required=false) String name,
            HttpServletRequest request, HttpServletResponse response) {
        String user = (name==null || name.isEmpty())? "world": name;
        String host = request.getRemoteHost();
        String result = String.format("Hello, %s! You are from %s", user, host);
        return result;
    }
}


對此程式片段作一個註記:
  • @RestController:Spring採用MVC架構,註冊此程式為Controller
  • @RequestMapping:註冊此方法負責特定request的處理。value的值為URL對應的path,method則標記了要處理的方法
  • @RequestParam(value="name", required=false) String name
    Spring Boot會幫我們解析parameters,你可以將你需要的parameters都列出來。
    required預設為true,如果為false則表示此參數可能不存在於query string中
    解析出來的name值會放到字串name中
  • 因為我們需要使用者的IP,這需要從request物件中來取得,因此我們handler1的參數列加上了HttpServletRequest request,以便在程式中抓到IP
  • 雖然不會用到,我們也加上了HttpServletResponse response,若程式需要對response object作一些設定可以使用。在這個專案中是可以拿掉


執行
如果熟Eclipse的朋友就知道有很多種執行方法。這裡介紹其中一種,在project上按右鍵,Run As | Spring Boot App 就可以執行了


透過瀏覽器來看靜態網頁
以及動態內容


產生 JAR file
在project上按右鍵,Run As | Maven install就可以產生jar file了。

產生的jar file會放在專案的target目錄下。

所產生的jar file包含了專案所有需要的資源與libraries,因此只要把這個jar file放置到要執行程式的機器上,就可以執行這個服務了!
java -jar greeting-0.0.1.jar


由於這個jar file包含了必要的libraries,因此其file size大概都從15MB起跳。對大部分的運行環境應該都還能接受。

改內嵌 Jetty
Spring Boot 在 web應用上是預設內嵌Tomcat,若要改為使用Jetty,則需要修改pom.xml。現有的pom之片段是:

在這裡將Tomcat排除掉,再加入Jetty

這樣就可改用Jetty為平台了

修改port
這個系統預設是使用port 8080,若需要修改,可以直接在src/main/resources/application.properties中加上下列這行 (例如要改為port 88)
server.port = 88

2018/09/23

距離 距離 距離

人的移動範圍會隨著使用的工具而改變。小的時候靠著爬行,生活的範圍就大概在房間客廳之間。等再長大會走會跑,社區與公園就成了他們奔放的地方。上了國小國中可以騎著單車時,就可以自由的在更廣的區域悠遊。等滿了十八歲,就會想要有一部機車,讓足跡可以跨出縣市,甚至遍及全島。隨著工具的進化,家長們的心臟也得跟著成長才行。

小朋友長大了,考上駕照,可以騎著機車到處遨遊。這時候的他們真的有如初生之犢般。
你會怎麼叮囑你的小孩呢?

就像房產界的名言「location, location, location」,我都會叮囑騎車開車的夥伴要注意「距離、距離、距離」。掌握好這三個距離,應該可以更能保障自己的安全。這三個距離是:

  • 空間的距離
就像一句老話「保持距離,以策安全」,這個距離應該很直觀。隨時跟前車鄰車保持好安全距離,就可以減少很多的身體接觸,保持平安。
  • 時間的距離
人遇到狀況到做出反應,大概需要0.5秒的反應時間。如果以時速10km/h來看,0.5秒的反應時間,你已經移動了約1.4m。如果你的速率達到50km/h,那移動的距離就達到7m。這只是我們人類的反應時間,還沒計入機械作用的時間。
當行車的速度越快,或是年紀與精神狀況影響反應速度,就要注意這個時間上的距離,為自己的反應時間留下更多餘裕。

  • 容錯的距離
新聞上常常有各種交通事故,例如大車的內輪差,或是「車主的品格配不上車子的品牌,駕駛的技能跟不上車子的性能」這種怪怪名車的事故,這些名車馬力大、速度快,造成的傷害也就大。還有很多馬路三寶,不打方向燈就變換車道或轉彎,不看後視鏡,開車門不回頭觀察路況...
我們可以努力降低自己出錯的機會,但是也要努力降低別人帶給我們的傷害!
多注意一些交通事故的新聞,了解他們發生的肇因,儘量預留足夠的容錯距離,來避免別人帶來的傷害。

2018/08/15


海豹部隊軍官的戰場帶人原則:沒有糟糕的團隊,只有差勁的領導者!
https://buzzorange.com/techorange/2018/03/05/how-us-navy-seals-lead-and-win/

在海豹部隊的地獄周裡,學員們被分組進行各項無止盡的對抗競賽,獲勝的艇組就可以不用出賽下一場競賽,獲得短暫喘息。

在各項競賽中,第二組的艇員表現最優秀,獲得了多數競賽的勝利,從他們的表現中,可以看到一些特徵:
  • 對自我的要求都非常高
  • 工作時同心協力,運作起來像一支團隊
  • 每位艇員表現積極
  • 互相幫忙,彌補彼此的弱點
第六組艇員的本質學能也都非常優秀,但是整體的表現卻不理想,他們經常在各項競賽中墊底。我們能從他們的表現看到一些特徵:
  • 未發揮團隊精神,每個人都是單打獨鬥
  • 遷怒和責怪隊友。指責隊友沒做到自己的本分
  • 艇員只關心自己的痛苦和不滿

(你與他人相處時,能看到其他人的優點嗎?還是你都努力發掘別人的缺點?)

教官們決定把這兩組的艇長互調,看看是否會改變這兩組的表現。
在接下來的各項競賽中,第六組如同脫胎換骨一般,表現突飛猛進,在很多競賽中得到了勝利!這互調鋌長的舉動,似乎驗證了沒有糟糕的團隊,只有失敗的領導者!

此文中推論出領導力是團隊表現中很重要的單一要素!那好的領導者應該有哪些領導原則呢?書中提到了下面幾點:
  • 落實標準的施行
    在設定預期目標後,如果未達標準的表現能被接受,而又沒有人須承擔責任,那麼這些未達標準的表現就會變成新的標準
    因此領導者必須盡力落實標準的施行,善用「絕對責任」的觀念,確保動作能夠再三重複,直到達成預期水準
  • 運用強制力,讓不同成員合作
    團隊需要紀律,透過強制力,或是激勵或鼓勵,讓不同的成員共同合作,戮力達成任務,這就是「絕對責任」的真正意涵
這裡提到了「絕對責任」,所謂的「絕對責任」就是零藉口,這就是高效團隊的重要秘訣!許多團隊在未戰之初就開始為失敗的責任鋪路,開始切割或責任的排外,清楚表明「這不是我負責的,不關我的事。」這樣爭功諉過的團隊,很難有1+1>2的效果。

2018/05/21

白沙屯媽祖北港進香2018

認識白沙屯媽祖應該是去年的事
今年去了幾次白沙屯拱天宮朝拜,總讓我有心安的感覺

有聽說今年的進香相當硬,05/16深夜23:40起駕,36小時就要到達北港。好吧,就當作是給自己的一個挑戰吧。時間上05/17容許可以請一天休假,所以就決定05/16跟隨白沙媽走一段,能走多遠就走多遠。自己設了一個目標,如果可以,希望能走到大肚溪,把台中市走完。這是第一次隨香,就把這一次當成體驗了

05/16下班後,回家做了些準備,然後搭乘台中20:48開出的成追線電聯車。在車站哩,看到滿滿的香燈腳,大家雖不認識,但由於都有相同的目標,很快就能聊起來。許多前輩們也開始分享經驗。

上了車,聽到海線電力纜線故障的車長廣播,車子只能到達大甲。大家議論紛紛起來了,有些人開始思考怎麼從大甲到白沙屯,有些人想在大甲等大轎,也有些人查詢到台鐵有接駁車。

隨緣吧!

還好,電聯車到達大甲時,電車線已經修好了,可以順利前進到白沙屯。

約22:30到達白沙屯,整列車的人幾乎都下車了。越過天橋,步出車站,車站外滿滿是人了。由於這次的隨香我並沒有報名,想想應該先到拱天宮,向媽祖報告我要參加進香,請媽祖也能庇佑。

往拱天宮走去,越靠近拱天宮人就越多,到了廟前的路,整條路塞滿了人。勉強擠到廟前的戲台就根本沒有辦法前進了。(想退後也非常難)。很多附近廟宇的神明神轎來送行,進進出出,把整個廟前小路擠得滿滿。
山邊媽來了,工作人員在地上舖置了大量的鞭炮,大家也騷動了起來,開始往旁邊擠,想躲開鞭炮炸開的範圍。
鞭炮點燃了!震人的音量與瀰漫的煙霧,彷彿是這次進香的序曲,讓人開始感受到這次旅程的氛圍。
開始往外走,發現地上有一個粉紅色的臂章,上面佈滿了被鞭炮燒灼的痕跡。應該是剛剛大家躲鞭炮推擠被擠掉的吧。問了問附近有沒有人掉了,不過在當時的吵雜情境,應該沒多少人聽得到吧。身邊一位阿姨就說應該找不到失主了,要我乾脆把臂章別在背包上,幫這位失主帶著臂章走這段旅程吧。

離起駕還有一段時間,想說先往火車站的方向走,路邊找個地方先休息。一路走,一邊開始接受到附近店家的熱情。還沒走到火車站,手上就多了礦泉水、蠻牛、草仔粿、沙琪瑪、LED警示燈,手上全滿了,還有很多東西就婉謝了。總算了解在火車上,前輩們說可以帶個小拖車或行李箱來的意思了。
找了個騎樓,把鞋帶再整理一下,也稍作休息。

遠遠聽到頭旗車的電音到了,我也起身跟在頭旗後面。出發了!36小時要走200公里的旅程。

走上了台一線,整個南下車道都封閉了,路邊也停滿了資源補給車,彷彿是個夜市般,大家很熱情地招呼你來拿吃的喝的,還有痠痛藥膏與貼布。
嗯,痠痛藥膏與貼布,在暗示著你這條路夠你受的了。

頭旗的腳程真的很快,雖然我不斷超前其他香燈腳,但卻越來越落後頭旗了。
不刻意去追了,就用自己的節奏來走。

01:16追上了頭旗
不是我腳程加快了,是頭旗在這裡停下來了,所以我才能追上。
很多人都很疑惑為什麼頭旗停下來,我問了幾位香燈腳,才知道是頭旗來到了一個叉路,頭旗不知道白沙媽要怎麼走,所以要在這裡等白沙媽的指示

開始感受到白沙媽進香的特色了,只有起點與目的地,沒有固定路線、沒有行程表、沒有固定的停駕駐駕地點


跟著頭旗的香燈腳都在三角公園(綠色區塊)附近休息,等待大轎,等待白沙媽

如果走中山路,那就要進通霄市區,如果繼續走台61,那就會接到台一線。

大轎接近了,由北往南,走到了台61與中山路的叉路口。大家都在等著白沙媽的指示。

中山路!
聽到鑼聲是往中山路走!

白沙媽的大轎緩步走進中山路。頭旗與香燈腳們都趕緊向中山路移動。

但是沒想到,白沙媽卻在圖中的A點突然小跑步起來往B點前進,往台61走。大家傻眼了!
第一次親眼見到粉紅超跑,超感動

白沙媽在開大家玩笑嗎?

由於後面的香燈腳看不到大轎,這時聽到很多人在問白沙媽到底走哪邊了。
等到頭旗與頭旗車趕緊回到台61,後面的香燈腳才搞清楚白沙媽往哪邊走。

當走到C點時,白沙媽不走台一線,而是右轉上台61高架快速道路!對,是台61高架快速道路,是車輛跟重機才能走的路段!白沙媽把大家都帶上快速道路了!
(我身邊的波麗士大人很緊張的用無線電通報:我怎麼知道白沙媽會走這邊,趕快派車過來前導跟後方警戒啦)

於是,整個台61高架道路的南向車道就成了進香專用道了。香燈腳們也都超興奮,因為從來沒有用雙腳走在快速道路上!

一路南下,走過通霄電廠,第一次從這個角度看這個電廠。

這時也見識到為什麼大家會把大轎暱稱為粉紅超跑,因為,他就是快!快到你連車尾燈都看不到。難怪有前輩說,你在路上看到粉紅超跑一眼,就大概沒機會再看到第二眼了,除非他停駕休息讓你有機會追上。


這一路走來,雖然很努力地快步前進,但是有著舒適的海風吹著,還不會感覺到疲累。天空很晴朗,可以看到許多的星星。感覺這趟真的是很愜意的旅程。(嗯...不知死活,後面等著瞧)

快五點,天微微透亮了。也開始有撞牆的感覺了。撐住!

到大安溪了。走在橋上,看到幾架IDF與三架C-130向西飛去,應該是CCK起飛的。倒是蠻少見到有這麼多架C-130一起飛行。

遙遠的前方響起了鞭炮與煙火聲,白沙媽應該到大安了。這也告訴了我,我現在離大轎有多遠了。

這時體會到一件事:一開始我跟很多朋友一樣都提早出發了,沿路也不斷的超前其他香燈腳,但是走到現在,還是離大轎好大的一段距離。不管你提早多久、走得多快,其實都不能保證你會先走到目的地;重要的是你有沒有能力與毅力,能走得更久,能走得更遠

六點左右,看見大轎坐西面東停駕在台61旁一條小路(龜殼路?)的路口。總算趕上了,也有機會再見粉紅超跑一眼。趕緊走到轎前跪下膜拜,感謝白沙媽這一路上的庇佑。

不過那時心中有個想法,白沙媽雖說很隨興,但從以前的資料看到,通常停駕休息如果不是在宮廟,也會是民宅或店家。而這裡好像什麼都沒有,就只是鄉下小路的路口。跟以往的慣例不大一樣。

嗯,白沙媽的隨興。

(後記:後來看新聞,知道CCK進行漢光演習預演時,有位跳傘者傘不開而墜地,而事情發生的時間點似乎就是白沙媽停駕的時間,真的很巧合)

鑼聲響起,粉紅超跑開始疾駛,我也繼續努力追趕。

七點了,已經走在大甲溪上了。在橋上,可以遠遠看到紅白相間的高美燈塔。太陽也開始為大地加溫了,而我也繼續撞牆。
大腿小腿好像已經不是自己的了,腳掌好痠,不過這都還好,還可以撐著。麻煩的是腳後跟有點刺痛,走路時成了有些踮腳尖的走法,走路的姿勢開始走樣,也因為用著平常走路不會用到的肌肉在前進,讓小腿更加痠痛!

撐著!

到了清水,腳後跟超不舒服,坐到路邊把鞋襪脫了,兩腳後腳跟都起了小指大小範圍的水泡,真糟。檢視一下運動鞋,發現兩腳鞋墊的後跟都已經扁了沒彈性了,鞋墊腳後跟部分也有破洞了。只能先把鞋墊稍稍調整一下,讓後跟可以有多一點緩衝。也希望能在路上遇到鞋店,可以換一組鞋墊,也許還可以走下去。

不過,走的是台61,根本是一片荒蕪,連平常四處都可以遇到的小七全家,這裡完全都沒了蹤影,更別說什麼鞋店了。

撐到梧棲台灣大道了,以現在的狀況,要走到大肚溪可能很困難。而且不管是在大肚溪北岸或南岸,可能都不容易搭到車回台中。

該設停損了。
承認自己失敗,也找出自己失敗的原因,下次再來過別又跌在這些點上。

恭敬的站好,向著遙遠前方的白沙媽祖報告自己要出列了,謝謝祂給了我這次很棒的體驗,雖然身體抗議了,但是一路走來心是溫暖的!真的,要走過一次才能體會那種暖暖的感覺!

第二天回到辦公室,跟同事聊起這次的體驗。主管問我明年還會想去嗎?
嗯,會!跟白沙媽走,真的會走上癮!

一些體驗,留給明年的我要注意的事:
  • 不管你提早多久、走得多快,都不能保證你會先走到目的地;要有能走得更久更遠的能力與毅力,用自己的步調去走就好
  • 一定要找雙好鞋,就算沒有好鞋,也要有好的鞋墊
  • 要有吸濕排汗的衣褲,除非你很耐曬,不然還是要長袖長褲,尤其是長褲。因為沿路都有鞭炮,穿長褲可以減少被炸到
  • 腳指甲一定要注意
  • 不要一開始就搜刮一堆補給品,那只是增加自己的負擔;沿路都有很多善心的民眾提供各種物資,拿自己夠用的就好
後記:檢視自己的鞋才發現,經過一夜,鞋子已經不成樣子,難怪失去保護腳的功能了。明年如果還有機會能跟媽祖走,一定得準備一雙好一點的鞋!

2018/05/06

讀到這篇「美國碼農加班少很多、卻能開發出厲害的產品?」,讓我想起了一件事:

某公司的主管,總喜歡在客戶或PM還沒提出需求,或是需求規格還沒共識前,就發動團隊依照他的想法開始作業 (應該是希望當規格出來後,就可以很快的遞交成果,向上級展現自己團隊的效率)

不過這作法產生了許多問題:
1. 規格最後如願被提出大概不到三成,他還常常要求PM把這功能補列入需求,讓團隊做出的功能可以計入credit,卻造成遞交的產品over spec,程式碼變得肥大了 (幸好公司不重視code coverage test)
2. 他的想法可能與客戶或PM的需求有出入,以致於開發團隊需要花更多時間在修改程式上
3. 有時實作必須修改架構,而修改架構會有意外的風險,需要花更多時間來測試與修改;若是為沒有需求的功能來增加這風險與成本,更是讓人懷疑這樣硬做的決策品質
4. 將開發團隊投入於完成又不被採用的功能,不僅時間沒花在刀口上,排擠了做其他事或進修的時間,每每做一些虛功更是打擊士氣
5. 公司PM常常spec.開得不清不楚、模擬兩可 (就所知,PM對專業知識了解不足,一些細節無法明確定義),這就造成開發團隊與DQA對spec.解讀不同而常有爭執。而此公司的issue tracking process是紊亂的,常搞到最後,產品最後的長相連PM可能都無法掌握

謀定而後動!
在開始踏出第一步前,先定義好你的目標與目的吧!