2015年4月29日 星期三

fswatch 使用筆記

最近時常使用 asciidoc 的格式在建立文件,撰寫筆記。也練習使用 vim ,看看能不能如人家所說的「vim 成為最後一個學習的文字編輯器」。過程中遇到一個問題,雖然在 vim 中可以直接呼叫命令列指令來編譯出 Asciidoc 格式的文件。但是每次作點小修改,就得重複 :w 與 :!asciidoctor % 兩個指令,打久了很煩。
有沒有一個偵測到檔案儲存,就能自動替我執行 asciidoc 指令的方法呢?所以我找到了 fswatch 這個東東。

2015年4月22日 星期三

提醒、改變別人

騎車在路上,偶而會遇上一種特殊的「塞車」,明明機車等待區空上許多的位置,但就是會有機車只顧自己進入,沒有留位置給其它人。和汽車之間產生我稱之外「關門」的狀態,進不了等待區的車子,就這樣一台台往後面堆,輕微的時候只卡了兩三台,嚴重的時候超過十幾台。

每次看到都覺得,這種行為真是自私又白目啊!

幾次由汽車的另一側繞過進入等待區,默默觀察了這種人的反應,結果仍然是一無所覺。後面的機車似乎和他們一點關係都沒有。對於可以避免的塞車狀況,他們完全沒有意識到只要一個小小動作,像是往前一些或是向兩旁的一個車位,後面幾乎所有的機車都能進入等待區,而緣燈亮時,大家都能很順的起步、加速。不會有卡成一團的狀況。

同樣的狀況也發生在其它地方,像是有些人一進了電梯或是進到捷運車廂後就馬上慢了下來,甚至完全不動。而在後面要進入的人就被堵在門口。只是直覺得認為「我進來了」就什麼都不想了,結果造成其它人的困擾。也許本身沒有什麼惡意,但造成的困擾卻也是事實。

對於這種人,不會出聲去提醒。因為「人無法改變其它人」的觀念根深蒂固,所以會認為這個人的個性就是如此自私,與其花費力氣去提醒,不如用點精神找其它路走。因為我的成長過程中,沒有多少次由旁人教導提醒。大多的觀念是在生活的觀察和體悟得到。因此對於「教好別人」這件事,並沒有什麼興趣。把它認為是「本性的一種」,覺得每個人都應該自己找到對的答案,不需要由別人教。

教別人程式的時候,如果發現對方的學習態度不佳,或自以為是的往錯的路子上走。說個兩三次後通常就放棄了。教學的極積性會因為學習者的態度不佳而急速下降,最終進入「放生」的階段。理由是「既然自以會學夠足夠的東西,不需要我指導,那麼我也不白費力氣」。

態度夠好的留下,態度不佳的直接踢除,這種模式似乎曾經在其它地方看過。思考一下我找到了答案,就跟某些公司的老闆只想要現成的員工,即戰力就留下來,而沒有經驗的就踼掉重找。培養員工從來不在這種老闆的心中出現,那麼,我的思考邏輯,是不是和這種老闆沒有不同?

回頭審視過去的自己,並不是每一件事情都能夠「悟」出正確的作法。也受過其它人不少提醒,若是少了這些改進的建議,我應該達不到現在的水平,也沒有今天這樣的價值觀。以自身的經驗為例,人也許不能很輕易地完全改變另一個人的想法,但卻能夠影響價值觀,或是待人處事的方向。

如果自己都無法只依靠本身的力量找到每件事情的答案,那麼,又有什麼資格要求人去「自行成長」呢?就好像小時的聽到大人常說「長大就懂」的感覺是一樣的。

所以,如何去提醒而不傷人自尊,又能有效的傳遞訊息。以及如何篩選合適的人,把自己的心力用在對的人上面,畢竟這個世界不缺蠢人,那種人就真的救不了,也不必去救了。這些都會成為我未來人生中的一個重要課題。

今天並不是等待這個世界會變好,而是在自己能力所及的範圍內,去作一些些的改變。

2015年4月19日 星期日

改寫既有的程式


最近手上在處理一個改寫程式的工作,把既有的程式進行模組化,抽出成外部的函數庫。在整理的過程中,重新定義一些溝通使用規則,並且引入單元測試,讓之後的每一次修改都能夠由測試來確保既有功能運作正常。因為對於測試驅動開發的不了解,實作的過程當中吃了不少苦頭,單元測試的引入並沒有預期中的讓我思緒清析,反而讓我常常陷入混亂的狀況。

從前的程式撰寫只需要思考「如何實現功能」,而測試驅動開發則是要求先思考「如何測試功能被實現」,對於剛開始運用這種開發方式的我,花費的精力不是原來的二倍,而是三倍以上。因為想完測試方法後,還要再去思考「如何實現測試方法」。如可在可控制、模擬的環境下實作測試程式,和以往開發直接輸出測試用訊息不同,測試訊息是給開發人員看的,因此是「人工判斷」正確與否。而合格的測試程式,則是想辦法「讓電腦能判斷」,並且輸出「未來的自己看得懂」的訊息。


另一個不同,以往輸出測試訊息的程式碼,是混在主要的程式當中。久而久之,程式的行數會因為許多的測試輸出與測試註解而膨脹,變得較難以閱讀。因此測試程式因該獨立於主要程式之外,並且在輸出成果時被排除在外。因此除了必要的公開方法之外,還需要思考額外需要增加的檢驗方法,好讓測試程式得以觀察是否如預期般的表現。雖然可以利用改變方法的存取識別子或是介面來進行封裝,但是開放「只有測試才需要的公開方法」,至今仍然無法完全適應。

發現其它錯誤時,在測試驅動建議「先增加能捕捉到這個問題」的測試程式,然而自己常常習慣性地直接著手修正,往往修到一半才發現應該撰寫測試,又得還原已經寫好的程式,回頭寫測試。早就不知道自己在這一來一回之間,浪費了多少的時間。

講了許多缺點,但測試驅動給了我一些好處。有些時間精神狀況不佳,連自己都不太清楚自己寫了什麼,但由於寫好的測試把關,不至於讓寫好的功能被被弄亂,而「為了撰寫有功能的測試程式」也逼得我去思考各種可能讓程式錯誤的可能,相對而言程式變得更加穩定。只不過由於花費了大量的時間,會讓人不自覺得焦急起來。還許多一點的時間去熟悉,增加速度吧!

還是會持續使用測試來改變自己累積多年的程式寫作習慣,雖然過程式一定會遇到許多困難。只能不斷告訴自己要有信心,這樣子的付出,在撰寫程式時不斷的換位思考是值得的。接著,就是不斷的練習,直到對它的精熟能夠變成一種本能,期許未來的某一天,對於程式的撰寫能夠再提升好幾個水平。

2015年4月13日 星期一

模組化設定值的開放與否

有一次和同事討論程式的作法,發現兩個人對於「模組化」程式的開發有滿大的不同。我認為應該多使用預設值,只公開必要、儘量少的設定值。而同事則認為應該讓參數有多種的變化性,這樣開發程式比較不會因為某些沒有被參數含蓋的變化功能,導致得回頭的查看、修改模組程式。

討論到最後,並沒有達到完全一致的共識,因為彼此提出的論點和舉的例子都無法說服對方。當然尊重別人的程式撰寫風格的前提下,都沒有強迫對方要照著自己的方式走的意思。最後我採用較為折衷的方式來開發,作為這次討論的結束。
回到家又再思考了一遍這個問題,回憶一下從前是如何作下「儘可能少開放」方針的原因。很清楚的知道並不只是單純的跟著「封裝原則」的建議。而是有其它理由支持這個論調。還好,最後終於讓我回想起來了⋯

2015年4月4日 星期六

爪哇程式語言

話說 Java 程式語言,從我大學開始學習它,也過了十多個年頭。不得不說由它的身上得到不到的東西,畢竟它是「物件導向說明最常用被使用程式語言」,關於類別的繼承、介面的實作,後來的 MVC 開發方式到最近似乎每種框架都要具有的「依賴注入」,都是先在 Java 身上先發現的。只不過因為沒有一直持續跟著它的發展,導致於 10 個年頭過去了,感覺自己離它越來越遠⋯

在我心中的 Java 有種「老兵不死」的感覺,不時出現的新語言,似乎都都隱隱取代它的勢頭。由於不像 C 語言可以作為撰寫靭體之用,Java 的地位理論上是可以取代的,就靠著從前火紅的時候累積了大量使用它的開發者,與許多已被眾人使用的框架,使得在沒那麼多人拿它作主要程式語言的狀況下,還能維持一定的佔有率。就拿自己作為例子,每每以為自己已經「完成脫離」了 Java VM 的時候,它就會冒出來,告訴我現實並不是如此。

老牌的 IDE Eclipse 得在 Java 上運作,這個有許多外掛,但不見得總是能裝得好的東西,讓人又愛又恨,愛它的功能多,許多沒想到的事情都被它許多外掛包含進去了,恨的是它只要一出錯,就不知道要如何解決,只能怪自己的功能太低,不知道要如何對外掛程式除錯。

最近開始研究公司在使用的 Jenkins ,又是一個 Java 為基層技術的東西。還是掛在湯姆貓(tomcat)上,那個自己在用的時候履履當機的玩意兒,居然的被人家用得那麼好,不單功能穩定,連外掛的安裝、升級都整合在裡頭,自己搞的那個站,真的是上不了台面啊~

不過,真要問我會不會回頭去深入研究這門技術,老實說並不會。因為它經長大到不是我這個水平的人可以輕鬆進入的。許許多多成名已久的框架沒聽過,許多習慣的用法沒有人教,它的門檻高到不值得讓我學習,先學學其它能夠在更短時間掌握,能在工作中派上用場的東西吧!

Java 會有未來嗎? 我覺得,如果它入門的門檻依舊,我想之後學習它的人會越來越少,最後慢慢的像一些老牌的程式語言,只剩下銀行業這種不敢換既有程式語言的地方,還會繼續使用吧!

行動與拖延

經過一整天的「休息」,睡了大概超過十二個小時來補之前連續的睡眠不足。一大早吃完早餐後,強迫自己坐在電腦前面,處理拖了一個星期沒有完成的待辦事項。一個小時不到,完成了表列的工作。讓我有點吃驚。

吃驚不在於發現自己作事情多有效率,那些在清單上的項目,其實都不怎麼大。而是吃驚於能夠全部在一小時內完成的 4, 5 項工作,居然沒有辦法被平攤在一星期中完成。更令人在意的是,這種事情發生了不只一次,想起花了個把個月才學起 GitHub 如何貢獻專案,在一個下午完成了第一次送交,但又拖了許久遲遲沒有開始其它的貢獻。

我是一個很會拖時間的人嗎?我這麼問自己,想探究倒底是什麼原因讓這些「小事」被一拖再拖。完成待辦事項後,藉著休息片刻的時候作了一下反省。

貢獻在 GitHub 上的專案

這篇文章是用來記錄我從零開始學習 git,為了能夠貢獻一點程式到 gitHub 上。希望這篇記錄不單能作為學習的記錄,也能夠幫助到其它也想幫忙 gitHub 上專案,但是不知道如何下手的人。

先備知識

首先要先談談 git 的特性,和其它老牌的版本管理不同,早期在建立本地「沙箱(sendbox)」的時候採用 checkout 來得到某個特定版本資料,而 git 則採用 clone 的方式,將版本庫整個複製回本機上,因此除了要和遠端的版本庫同步的工作外,都可以在沒有網路的本機端完成所有操作。

要注意的是,本地和遠端的版本庫實際上是獨立的個體,依需求可以隨意連結或斷開關連。因此一個本地版本庫同時對兩個以上遠端保持關連是可行的。在推送(push)新版本的時候,只需要告訴 git 遠端主機是哪一個就好了。許多的 git 特性,都是由這個特性延申而來。

情境說明

先說說我的情形⋯

  • 在網路看到想要加入的專案,開放讓人貢獻程式碼
  • 但自己並沒有寫入這個專案的權限,既使有權限,也不知道應該如何作修改
  • 聽聞程式碼送交後,會有人進行審核,但找不到送審的地方,也不知道審核者在哪裡
  • 在討論區裡知道了有 fork 這東東,但版本庫 fork 回來,接著就不知道要作什麼了


關於我學習中間撞牆的詳細過程,不是這篇文章的細節。也許哪天有空再寫篇雜記吧!