學習程式也是需要好的切入點

分享一個連結…

https://plus.google.com/104192586349074807721/posts/MEKkeE86kJo

這也是我最近的寫照…

由於這幾天手上沒有要趕工的案子，就把這些時間拿去研究之前用到，但不夠了解的程式框架。而結果就如同連結裡的那些人一樣，不知道要如何下手，滿滿挫折感。

因此上周又再跑了一次書店，去看看有沒有能夠幫助我突破的書。曾經我認為網路資源已經多到不需要再去看那些過時的資訊(尤其是中翻英的書，在台灣可能都晚了原版一年的時間)。但是我發現，我錯了… 過時的資訊依舊，這本來就不會在短時間有太大變化。只是網路上能夠讓我吸收的資訊真的太少。

相依性是學習 Linux 系統時候聽到的名詞，是一個很讓人討厭的事情。如果今天要安裝的軟體缺少某個相依套件，程式就動不了。得一層一層的找到缺少的那個套件，可能是因為不支援新版，或是程式只能在某個特定的版本下才行。對於一個初學者而言，每次安裝軟體都算是一個「考驗人品」的過程。
(當然啦~  相依性的問題我認為還是存在，但是已經好多了，不過套件管理系統好像有分裂得越來越多的感覺)

最近學習 Node.js 程式的過程其實也是這樣，往往一支程式會引用到幾個套件，它們又各自引用了其它套件。當我爬到第三層左右的時候，我就已經亂掉了。因為由那些相依的套件身上，已經看不到原來程式的目的，只能一點一點的猜使用這套件背景、原因、目的。
爬了一些文，有的可能可以找到一點歷史，有些可能就只是單純作者搜尋類似功能時，找到的吧！

沒有文章能告訴我，要理解程式，需要先看那些東西，那些東西可以先略過，或是先用什麼方式去記憶，未來再深入學習。往往花了大半天的時候，得到的只有混亂，腦子裡整理不出什麼有價值的資訊，就不用說是有系統性的學習了。

嘗試過由 Unit test 的程式去看，發現它也許可以作為證實心中假設，但不適合去作為切入理解程式的方式。

也許未來我看程式的功力變強之後，可以撰寫一些心得文件。能幫助到和現在的我一樣的人就好了。畢竟人家寫出免費、好用的程式已經夠累了，要寫出有系統性的文件真的不容易，又很花費時間，還是大家想看的人，自立自強的比較好。

當然啦~ 如果現在就有那種能夠提升爬別人程式的文章，能夠解決我現在的困境就更好了。
這樣就不會讓我在那一直不斷的拿頭去撞這堵不知何時會倒的牆了…

重新出發

經過許多次 Blog 文章的寫寫停停，發現到要持續地寫點東西，實在不是一件容易的事情。
隨著年紀與社會經驗越來越多，生活漸漸變得複雜的同時，對於未來卻變得更模糊。

並不是沒有任何靈感出現，也不是沒有新知可以分享。
而是它都變得比從前更加地分散，碎片化。頂多只能在心中留下一個隱約的輪廓，要再將它整理成一篇簡單、明確的文字。已經超出了我目前的文字功力了。

可能是因為好一陣子沒有打文章了，也可能是日子過得太亂了，也不排除是因為對於想打出的文章中，結構、主題甚至是排版都有了更高的標準。

而一次又一次的無法達標，是一件讓人覺得挫折的事情。
只能再一次的灰頭土臉地，試著站起來，四處看看還有哪些是沒作的，還沒嘗試過的。

真的，不知道成功的未來是不是在路的盡頭，也只能硬著頭皮去走看看了。

回到打文章上面，一直以來，我都想要經營一個由自已主導，能夠分享不同於別人想法技術部落格。雖然目前為止文章裡的含金量不算沒有，但還遠遠低於我所期望的。
是得作點改變，或是改進作法吧~

和自已的工作有點關係，由最初的 PHP 到 Android 到 Java 到如今 HTML5 Javascript 為主的程式生涯，跳得語言太多。底子不夠，內向的個性也讓我沒有跟上資料爆炸的車。因此評估自已目前的功力，已經遠遠算不得是前段班的了。

不過同時自已也發現，現在想要追上那些神人，以中文而言，好像沒有太多論壇或是討論區能夠參與，不是我這種宅在家裡的人可以快速提升自已。
說實話，就算是要提升，也得先找到一條合適的方向，偏偏這對目前的我來說，也是個大問題。

因此，換個角度來說，把這段過程中自已想法記錄下來，似乎也是個可能性。
來嘗試看看吧！ 或許可以給某個人，或是未來的自已一些幫助。

當然囉~ 也許哪天我會重新建一個符合我希望的 Blog 站，有著我覺得理想的輸入模式。
這中間把一些想法打在這上頭，誰也說不準未來是如何，但總得要求自已不斷走出去，不是嗎？

寫文章

遙想十多年前，還是大學生的我剛學會了 BBS 的使用方法，覺得新鮮的我，開始試著在上面發表自己的文章。一篇、兩篇⋯隨著文章的發表，打字速度的提升，慢慢我的文章越來越長，開始把自己的一些平常的想法，放在剛建好的個人板上。

既使被一些朋友抱怨過文章太長，文字太多也不以為意。只覺得那我個人想法的舒發，不以作家為職業目標的我，文體和用字就不需要太在意了。當時我並沒有想到，那段時間是我打字最快，也是寫文章最舒暢的時光。

後來試著改變過文體，也在入了社會之後，試著以技術分享為主題發表了一些文章。不過想不到總是沒有辦法抓到一個理想，能讓我續持寫作的感覺。以至於擺脫不了斷斷續續的毛病。光是這個 Blog ，也好長一段時間沒有更新了。

中間當然不只一次的立志好好寫點東西，筆記的形式、教學的形式、生活雜感產生的心得分享，都曾經是被考慮成為這個 Blog 的主軸，顯然的，最後這些想法都以失敗告終。不是一段時間內都找不到靈感，就是一直沒有累積、歸結出能夠拿得出手的結論。空了一陣子，就是連自己都忘了要好好寫點東西的初衷。

會回來打這篇文章的裡理，也是在意料之外。為了工作忙碌了好些年，事情卻沒有都上軌道的感覺卻總是揮之不去。學習力並沒有如經驗增加一般地漸漸提升，反而在一些技術驗證上，常常出現愄首愄尾，遲遲沒有付諸實行的情形。

發現到，我被這個社會「一作就只能成功」想法給制約了，變成一個只犠牲成就結果，而忘了也要試著享受中間過程的人。

所以，我想由鍵盤敲下這篇，沒啥大道理，也不具有任何結論，不預設要哪個人看，甚或能不能產生什麼正向幫助的文章。單純的想找找、享受回從前那種把心裡想法藉文字釋放出來的輕鬆感。也許哪天會找到幾個能持續撰寫文字的主題，但希望這股寫文章的好感覺，能夠被一直保留下來。

嘗試的精神

大約是這幾年吧～在前一份工作的時候漸漸覺得自己的學習能力開始下䧏，對於程式理解變得越來越慢，對於自己寫出來的東西感到不踏實。本來猜想是因為進入到以往不熟悉的領域導致的正常現象，直到換了工作過了一年，才隱隱覺得其實不是這樣。

對於從前常用的 PHP 語言，我依然有不太差的反應，能給別人建議，甚至對於一些我從來沒接觸過的部分，也能提出想法。以往帶人的 Live coding 感覺，也能如自己預期一樣進行。反倒是後來學的 Java, javascript 就沒那麼有把握了，往往一卡住就是幾個小時到幾天的時間。

總不可能是因為語言帶了「Java」就成了我的弱點了吧！程式的撰寫畢竟是一個偏向科學的工作，超自然的影響應該不常在這種地方發生。

上周打算把剛學的 Electron 拿來作個簡單的 Asciidoc 閱讀器，不過才剛開始沒多久，連環境都還沒建置完成就宣告失敗了。原因是我打算使用 Asciidoctor 提供的 chrome extension 來組合出成品，不過 Electron 並不支援 extension ，所以還沒下載完 npm 套件，就宣告這個計劃的結束。

事後覺得自己很瞎，一個開新瀏覽器新視窗就可以達到的功能，實際上並沒有太多打包成應用程式的必要，還是一個肥大的應用程式。如果早一點想到，也許連嘗試、下戴套件的時間都可以省下來。

事情總不只一個面向，幾天前的想法就在稍早洗澡的時候被推翻。這個不成功的嘗試不單不會全然無用，反倒是點出了我現在正缺乏的東西。

要不是我有了這個想法，我不會知道 Electron 不支援 chrome extension 引用這點。也許這個資訊有些微不足道，但是積少成多，就成為我現在所擁有的全部知識。而我現在覺得學習速度變慢，主要的原因出在我已經越來越少去作「嘗試」了。

前一份工作的形態，讓人缺少嘗試新技術的空間，大多時候都是儘量用自己已有的知識來解決問題。其後一些政策上的因素導致心灰意冷，用新方法解決問題的念頭也越來越少。自然，學習速度也一點一點的慢了下來。

不計成敗的嘗試，一點一點發現自己的不足之處去改進。我想，才是最適合我成長的方式吧～在這裡打打自己的心得也是，練習用文字來表達，練習歸結出自己零散的想法。

學習 Elecrton 的一些感覺

工作因素，自認對前端技術還不夠熟悉的自己，開始試著使用 Electron 這個能將前端技術打包成「AP」的工具來開發產品。一兩週的學習與測試，讓我仍然在許多方面處於混亂，摸不著頭緒的狀態。也許，改天把一些理清的部分的轉化成文章分享，不過現在我只想單純聊聊這中間的感受。

技術變革的快速，一次又一次打破我的想像。對於「AP」的印象，一直停留在 Access Point 這個網路設備的名字上，在這次的機會中，才知道原來「APP(Application)」一詞已經更廿廣的被使用在手機的 Mobile Application 上面，而 Desktop Application 則改用少一個字的「AP」了。

不得不說，手機的 APP 開發似乎比電腦用的 APP 還要熱得多。也許是還沒達到飽荷，有許許多多人想加入，在網路上的熱烈的討論，以至於常常佔用了搜尋結的版面，不知道哪個人決定使用「AP」作為縮寫，真是一個糟糕的主意。

Electron 是一個融合了 chrom （或準確一點的說，是它的開源專案 chromium），以及 Node.js 的開發工具。講起來很簡單，兩者都是具有各種平台的版本，所以把兩者的交集：Javascript 程式，以及用以呈現畫面的 HTML, CSS 技術，就能讓專注前端開發的人，使用平常就在使用的知識就能夠開發桌面應用程式(desktop application)了。

聽起來很合理，實際上也真的可以運作。不過是不是只要「前端技術」就能順利完成？個人是不太相信。這中間用了幾次我在其它領域學到的不完整知識，勉強地撐到現還還沒放棄。

要說會卡住的原因，我想一部分是來自於現在的我習慣於 Mac 上開發。又或著應該這麼說，似乎許多程式的開發者，都習慣於在 Mac 或是 Unix Like 的系統上開發。而導致一個作好的功能要移到 windows 平台的時候，才發現有許許多多的問題要解決。

寫程式嘛～解決問題本來就是理所當然的事情。Google 上有許多的問題與答案幫助工程師解決問題，但也是如此，當 Google 到答案都是無解或是斷頭(沒下文)的時候，就特別的讓人覺得焦燥。

得先作假設，再像是傻瓜一樣一個又一個假設慢慢去試。有時候半天過去了，最後還是一無所得，放棄的念頭浮現早已多到數不清了。最讓人無力的地方是，只知道程式不能運作，但是連卡在哪一個環節都不知道。

開源能夠成就很大行的案子，讓眾人的成果能夠像積木一樣堆疊成偉大的建築。在理想上，每個小片斷的開發者，只要完成自己那個部分，維護完美的狀態就行。不過呢，實際上每個部分都有可能因為開發者一個念頭的改變，或是單純的手誤造成後面的程式全盤出錯。

Node.js 就是我所知道最為混亂的地方之一，許許多多相似，又沒有用的功能，排在一起，偏偏沒有人能告訴你哪一個才能滿足需求，有時候讓我不禁去想，也許自己去把相關知識學起來，會比在這個大海撈針來得快一些。我想，可能不少開發者有一樣的想法，所以後來的人，就看到了更多相似名字，但依然不知道要如何選擇的模組出現在清單上。

本來我覺得，一個被多人肯定的模組，應該問題不大。不過就遇到一次因為沒有測試在 windows 的運作，沒有考慮到 Unix like 系統裡資料夾只是一種檔案類型，而 windows 不是的差別，也沒有預想到 windows 下 "." 開頭的檔名是不合法的問題。撐了許久，最後決定爬原始碼之後才發現，暫時解決了這些問題。

但是怎麼把這些修改後的程式碼弄回網路，通過原作者的審核，這又是另一個問題了。要學的東西真多，不過那裡就是接下來要研究的東西了⋯

在新年的一些反思

在幾天的放鬆日子後，開始試著找找自己生活的重心。持續忙忙碌碌的日子久了，忘了自己為什麼什麼而努力，想追求什麼樣子的生活。

看了幾集小說，看了一些佔用硬碟許久的動畫，也玩了幾個 RPG 類型的遊戲。忽然之間我開始思考一個問題：為什麼我對於這些東西會產生沉迷，不惜延後就寢的時間，犠牲睡眠就為了知道那個不會跑掉，改變的結果。

我猜，答案可能就在於，無論是小說、動畫，甚至是遊戲都有一個「確定」的結局吧！這樣的確定感，既使它們不過是「別人故事」，將自身代入主角的臨場感覺，也會讓人覺得「付出的時間是值得的」。

相比現實的生活，那些忙了半天一無所成，甚至得到反效果的情境相比。虛幻的世界要吸引人得多。就算知道人依然是應該活在現實的當下中，不過仍然抗拒不了到這些世界裡躲上一段時間的念頭。

就遊戲而言，目標與成果都明確，甚至有的有詳盡的攻略、密技。無論是努力的「練功」或是用現實的金錢成為「台幣戰士」，如果兩者皆無法答成目標，大不了換另一個遊戲就好。

就小說或動畫而言，主角光環會讓主角總能一次次的化險為夷，除非少數 Bed Ending 的狀況，大多都是「從此過著幸服快樂的日子」一般的結局。

對於人生的方向該是如何？生活中的每件事物各別應該分配多少比重？要犠牲到什麼程度，才叫作對工作負責？這些問題的答案，並沒有隨著「長大」而清淅，反而越來越模糊不明。到如今，連尋找答案的方向，都已經沒有數年前的自己那些有把握。

低頭向前衝了不知幾年，依然沒有「豁然開朗」地找到答案。一面思考是不是走錯了路的同時，也回頭看看自己是不是錯過了什麼，方向不見得是錯的，也許真的漏了什麼東西，是應該被發現的。

翻翻從前自己的想法，自己身上的能力累積地不算多，也不算一無所成，該找找那些從前的夢想，看那些曾經定下的志向，那些已經可以化作理想，成為可以一步步實現的。作最這陣子的短期目標。

至於那個「人生的價值」，可能得再過些時候，才能夠被看得清吧～

翻譯 LiveScript Style Guide

前陣子同事在說明專案要用到的 LiveScript ，提到網路上有個 LiveScript 的語法建議。個人還滿認同程式的寫作風格一致所能帶來的好處。因此就把網路的版本抓回來，由原來的 markdown 語法，改成另一個我正學習的 asciidoc 格式。

同樣把內容放在 github 上，也許第一次翻譯這種東西，多少會有所缺失。不過好歹也算是有個起頭，希望哪一天能夠幫到對它內容有興趣，但英文不好的程式同好。

翻譯的內容在這裡

改寫既有的程式

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

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


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

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

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

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

爪哇程式語言

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

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

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

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

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

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

行動與拖延

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

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

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

學習 Unit Test 之二

萬事起頭難，Unit Test 也不例外。在練習使用的過程中，「要如何開始」這個問題困擾了我很久。手上有的是剛寫到一半的值物件類別，不能確定是不是應該替他們寫測試程式。只是單純的檢查「資料記到變數裡」，沒啥意義。經過一些測試，慢慢抓到一些模糊的感覺，在這裡作點記錄。

回到程式的本質，就是處理資料。所以撰寫測試程式就應該是確保「資料被正確地處理」。所以測試程式的輸入和輸出，應該是不一樣的。既使只是數字變成字串，或是物件變成 XML 格式字串都算是改變的一種。當然輸入、輸出的改變可能是數值計算、整理作為 API 回傳值或著是分析、篩選出滿足條件的內容之類，總之，就是「有處理，就有測試」這樣子原則。

所以，一開始建立值物件的時候，不需要寫測試程式。在撰寫由檔案/資料庫讀出、建立值物件時，就要測試來源資料和值物件的內容。當確保了值物件的初始建立後，就可以拿這些建立好的值物件來進行其它運算，分析的工作。這樣，不用在測試程式中一行一行的打程式建物件，把更多的時間用在思考如何驗證結果，撰寫邏輯規則。

沒有資料，就很難進行的模擬的測試。反覆使用程式碼一個個地建立物件，足以消磨一個人的心。而且一旦物件格式改變，那麼需要異動的程式碼可能也會隨著專案發展變多。所以由統一建置的「工廠」來提供資料有是需要的，能夠快速複製新的版本，再修改來滿足其它測試需要。

所以，我覺得測試驅動的程式發展，應該是由值物件，以及建立讀取外部資料來產生值物件的類別開始。接著才會有許多不同變化的資料組合來模擬不同情境。

重構時間

最近回頭看看自己的工作清單，發現有許多事情常常會一拖再拖。不知不覺之間，一兩周就這麼過去了，感覺真是不應該。開始思考發生了什麼事情，讓事情被拖延，或是問題實際上出現在事情的安排上，讓它們本身就具有「容易被拖延」的特質。

觀察了每天時間分配上，有許多片斷但無法控制的時間花費。像是在通勤上遇到塞車，和人相約的等待，回到家等水開，等肉退冰。這些時間不是完全不能預測，卻很容易被人遺忘。當然時間是公平的，把這些時間抽出後，讓我突然發現每天回到家裡的時間少得可憐。如果再加上臨時起意的出門、聚會之類的，感覺上能夠讓人作事情時間實在是不足。

不過，再去看看每天作的事情中，發現有趣的是，一些「真心想作」的事情常被擺著沒動，反倒是遊戲，尤其是手機線上遊戲的進度無論再怎麼忙，似乎都能維持的進度前進的狀態，不會一擺擺上了兩三天。自問自己不是一個容易沈迷遊戲的人，反而是一個無法對遊戲「很認真」的人，所以要作一出「放著遊戲不玩」的決定並不困難。

難不成「不會太認真」，是造成進度能不能持續的原因？當然不是囉！但是太認真，反而會讓事情不容易開始。回想要開始「認真作」一件事情的時候，常常會思考它將需要一段能夠專注、不被輕易打擾的時間，最好還能夠進入所謂的「沈浸」狀態。但是一天之中，會有幾個半小時甚至更長的時間，能夠專注作件事情呢？所以，那些零散破碎的時間反而被「玩個三五分鐘就好」的線上遊戲被佔滿了。

「重構」、「單元測試」的想法又浮上心頭，能不能把想要作的事情，切碎成三五分鐘能成完的片斷？當事情能夠片斷進行，並且能夠容易地在下次接續進行。我想才是能夠滿足現在大多都是破碎時間的合理安排吧！讓想作的事情持續有進度，不會後輕易地被許多小，但不那麼重要的事情瓜分光。

專案開發自勉

作為一個程式人員，總想著能利用程式來作些自己覺得有趣的事情。作個能 Open Source 的專案，在心中已經萌芽一段時間，卻一直未能正真進入開發階段。到咖啡館看書的時候，剛好聽到鄰座的教授和學生討論專題，心有所感。綜合之前看過的一些文章，將當下心得記錄下來。
相信工具 讓事情開始進行

相信工具 讓事情開始進行

隨著接觸過的專案越多，考慮的點也跟著的變多。開始的時候滿足於自己能夠「顧全大局」的成就感，但是也漸漸發現自己撰寫程式的速度不如以往。雖然寫出來的程式品質有跟著提高，但也隨著專案進行，發現許多當時考量的東西，最後不是沒有用到，就是需求改變而不敷使用，時間在無形中被浪費掉。倒不如早早開始動工，相信以依照現在的方法和工具，都有機會能夠將偏離的方向導回，沒考量到的部分予以補齊。

當然光是「相信工具」是遠遠不夠的，還要去學，去實踐那些工具和原則。像是不斷確認開發是朝著目標走，以此定義單元測試，並在發展的過程中反覆進行程式碼的重構。否則，只是單純的盲目前進，以及天真的期望哪天醒來，所有的問題會自然消失。

真正了解工具的背後意義，相信它們能夠幫助修正問題，然後就開始實作吧！不斷讓這些工具加入，讓事情發生！

解決問題 遠比用新技術更重要

無論一台機器功能再多，性能再好，如果不能用來打電話就算不上是一台手機。當為了追求的新的技術、新的管理方法、新的設計流程，一旦遺忘了根本的初衷，那麼產出的只一個堆積許多功能的四不像。一個連自己都不知道有什麼價值的東西，當然難以得到其它人的認同。所以產品的定位，想要解決的問題以及讓使用的人得到什麼價值，遠比用哪一種技術重要得多。

不管是 Scurm 專案發展、UML 圖或是 Big Data 、RWD ⋯⋯等等技術，都是為了解決在產品開發上，會遇到的一些問題。但也大多止於「產品開發」上，而不是「滿足客戶需求」或是「創造價值」。雖然學習各種新技術，能夠減少一些時間的無謂浪費，增加一些新的可能。但絕對不應該將所有的焦點都放在「新技術」這個議題上。選擇、引用，甚至是學習新技術，顯然比研究客戶問題、提出解決方案要簡單、不費腦力。看過一些人沉浸在新技術的堆疊，近乎在逃避解決客戶問題的責任。必須引及為戒，不能陷到這種狀況中。

片段時間 就開始 重要的是方向定下來

「我有想法，但沒有時間，找不到適合開始的時間點。」這個問題困擾了我許久，總是在一個念頭的開始，伴隨著公司加班，或是親友或自己的事情干擾，導致最終念頭仍然只是一個念頭，還是沒有被實現。因為如此，我的在職碩士，花了我整整五年的時間才完成，回頭來看還滿有趣的。前兩年我順利的完成所有的該上的課，沒有一科被當或出現危機。然而一個碩士論文卻花了我三年，而實際用在製作我的畢業論文的時間，大概才半年，那忙亂的半年中產出了一篇足以讓我畢業的碩士論文。而那半年之中，還有公司的專案趕工、上線等壓力在，常常強迫自己早點睡，六點起來寫一點文字，最後組成整篇論文。

事實上，我在完成論文的那個時段並沒有比較輕閒，所有的文字都是在片斷時間中撰寫，最後一兩週才抽出比較完整一些的時間去順槁。因此由小看大，表示別等著完整的時間才開始想作的事，既使只是片斷的工作成果，也能夠積少成多讓自己離目標更近一些。有一個明確，短時間不會被改變、大幅調整的目標，就可以開始動工了。大原則不變，其它的東西一面作一面微調方向就可以了。讓事情發生！比大量的規劃卻零產出有意義得多。

需求優先 別卡在細節

一個功能能夠有多少種變化？使用者操作上會不會看不懂？需不需要防呆機制？網站的安全性夠不夠？效能能不能讓主機承受上萬人同時操作？雖然這些問題對於一個成熟產品來說是必要的，需要常常去檢視，研究尋找更有好的解決方案。不過對於一個剛開始的計劃而言，這些都太遠了，不值得讓它們佔用本來就不太夠用的腦袋空間。人們可以忍受要等上一兩秒才算出報表的統計程式，但不能接受一個全世界最快，但只能算加法減法的計算機。

專案的目的是什麼？最核心想達成的功能為何？什麼是達到功能的最小可檢視流程？這些才是最需要常常問自己的問題。不斷的探索使用者遇到的問題，嘗試想出各種滿足需求的可能，去驗證它，分享它，再回頭去看看和大方向是不是一致。等到組合成一個夠完整的解決方案，再回頭去思考其它和需求比較沒有關連的問題或是優化產品的效能。

如果擔心一開始的程式規劃無法面對未來的變化，那就要在每一次的開發流程中，導入重構的技術。去相信重構的技術能幫助我們重新設計程式規劃，然後，開始進行吧！

第一個版本在哪裡？prototype？

產品終究是要給自己以外的人使用，所以，可展示的版本，或稱之為產品的原型，是發展的里程碑。最終目標太遠，往往會讓人失去想要達成的動力。最好能夠早一點作出能夠給別人看的原型產品，一來目標較近，有機會能在燒完全部熱情前完成，二來可以聽聽其它人對於這個東西的看法，能夠早一點作出修改，或是增強部分功能的力度。總之，都要比自己閉門造車完成後，才發現不合交通法規上不了路的好。

也許現在的想法有一些未盡理想之處，不過就像前面所說的，總是要先起了個頭，才能知道要如何改進，才知道對的方向在哪裡。

越是學習，越是覺得自己渺小

又換了一次工作，新的環境有比較多的時間，讓我能夠好好地對一些技術作深入研究。這在之前的工作中，還沒有發生過。往往是連續的專案進度壓力，或者是不斷需求方向改變。技術的理解往往停留在「能用」但是「不精熟」。

工作上需要用到 Flash，所以就把數年前想學習的 FlexUnit 拿出來學習，花了大約一週的時間看完放在 Apache 官網上的教學文章，總算是建立了一個能夠自動化測試 Flash 程式的環境，不過在回過頭要來修修手上的程式時，卻發現困難重重，不知要如何下手。因此又開始研究起所謂的「程式重構」是怎麼一回事。

重構是讓程式變得「乾淨」的步驟之一，而測試則是確保重構的過程中，仍然維持程式應有的功能。在看相關的資料的同時，發現了許多從前遇到問題的解法，程式架構與設計原則也在重構的重新詮釋下有了新的風貌。收起了自以為已經了解程式的自滿之心，同時也開始漸漸不能接受自己原來寫的程式，就像資料中提到的，我的程式已經長到一個難以擴充功能，也難以讓其它人理解的狀態，而天真的我還認為這是程式應有的風貌。

當然，就我那個時候的程式水平，會有那樣的想法並不意外。學習過程中，想法的被推翻與在連續的錯誤當中試著爬起，都讓人多多少少感到鬱悶，但在回頭看看自己的成長，已經有很大的進步，還是滿讓人興奮。終於能夠再接近高等程式應用一些，達到心中理想的境界。

興奮之餘，也發現到自己的渺小，能力的不足，在這個年紀才這樣的水平實在是不夠。既然現在有了時間可以研究技術，就得好好的把它們都補回來。充實自己的技術，才能發揮出更高階的價值，有資格的得到更多的薪水。畢竟，年紀不小，也到了支出要開始直線上升的時期了，得快快把自己準備好。

希望囉～在這系列的研究工作之餘，也能夠把所學多分享出來。也算完成多年前就希望作到的事情。

學習新技術雜感

在連續差不多半年的碩士論文主題製作、撰寫的「死亡行軍」終於到一個段落之後，終於可以把一些時間拿來學習累積許久沒動的新技術，幾天來學習過程，讓我再一次感覺到，現在的環境對於要進入一個領域的初學者來說，有越來越不「友善」驅勢，除非有人帶或是從很早的版本就開始接觸，要進入一個新技術的門檻也越來越難。

這樣子的問題，由一些「XXX 入門」或是「XXX 簡單學」的書中可以看得出來，不知道是為了節省篇幅還是單純習慣使然，一些書本的作者喜歡用某某工具，用簡短的步驟、精簡的話語帶過一開始的環境建置工作，如果照著作可以功能那還好，但偏偏就是出現一些小問題，讓學習的人面對看不懂的錯誤訊息，在嘗試幾種方式仍無法解決的狀況下，「放棄學習」的念頭會浮現。

以上，就是最近我在學習新技術的縮影，有幾年程式經驗，對電腦應用有粗淺底的我都如此，可以想見比我更「資淺」的新手，想必會感受到更大的挫折吧！

使用 MDM Zinc 遇到的兩個問題

MDM Zinc 是一個能夠把 Flash 發佈檔 swf 打包成應用程式，能在 windows, mac, linux  上直接執行，除此之前，藉由呼叫它所提供的函數庫，能讓 Flash 程式具有如同一般應用程式的能力，達到像是寫入檔案、取得網卡 Mac Address…等原本 Flash 不允許作的事情。第一次和它接觸好像是在五，六年前，還是 2.0 的版本，為了作一個單機、展示用的行銷光碟。

幾個月後，因緣之下又接到類似的需求，為了要讓 Flash 能夠寫入檔案，我又再一次選擇了這個工具，只不過不同的是，這次 4.0 的版本反而讓我吃了不少苦頭，花了兩三個星期的工夫才找到問題答案。在此作一下記錄，也許哪個遇到一樣問題的人，有緣看到這篇文章能夠少繞一些路。

這次發佈程式的平台是 mac，使用的是 ActionScript 2 的語法。遇到的問題分別是「文字輸入框裡無法出現游標，退位鍵在刪除一個字後就卡住了」，另一個問題則是「當程式打包成安裝檔，順利安裝到 mac 之後，不管多少支程式，在 launchpad 裡都只有一支程式的圖示」。

文章寫作的一些反思

最近我常常在思考一個問題，要怎麼寫出一篇好的分享文章。 什麼樣長度比較容易接受，而一篇文章中帶有多少概念恰當。隨著一篇篇文章的發表，開始思考 寫出來的 文章，於看 的人而言是不是有幫助。

最大的轉變，在於寫文章的目的，由 單純舒發自己心情，變成希望能夠 利用的文字來改變所及的環境。目前想作的，是把自己的一些心得，分享給其它人。

分享的重點是在於看的人最後得到什麼，而不是作者隨心所欲講些自己才看得懂的東西。 所以就看教學一樣， 需要把想法的順 序作一些的轉換，需要一些鋪陳、一些舉例，找出讓其它人容易了解的寫作方式。

談程式學習…初學與教學 — 學習篇(三)

(發現自己習慣的分段寫法，好像不適合 blogger 的顯示，試式改變排版試試。)

底下分享自己經歷過，或是看過一些新手常進入的誤區…

誤區一︰程式只不是寫給「現在的自己」看的…

在指導新人的時候，偶而會聽到「這個程式能跑就好，你不要管我用什麼變數、函數名稱」的回應。如果今天只是一個用來展示，未來將會重寫的程式，換言之就是用完即丢的程式，的確沒有必要要求這些。但是在撰寫程式的過程中，修改、擴充既有的程式，實際上佔絕大多數的時間。既使是常常接外包，作新案子的公司也一樣，總是希望能夠留下一些重複功能的程式片斷，能夠作為函數庫引用，或至少好讓人剪剪貼貼。

面對別人或是幾個月前自己寫程式碼是無法迴避的問題，所以程式碼的可讀性，必要註解的撰寫是重要的。並不是要求剛入門就必須要寫出多優良的程式，而是「替未來看這段程式的人著想的心」，必須一開始養成。否則工作之中除了抱怨別人的程式碼很亂很糟之餘，也在不斷產出「傷害別人的程式」，不論是腦細胞，還是感情。

怎麼寫出優良的程式，這是需要許多經驗累積才能學會的。雖然有這類的專書，但是沒有經歷過那些讓人不愉快的經驗，那些原則很難被讀到心裡。常常思考，這段程式在幾週後的自己，能不能看得懂，慢慢的改進，才能寫出更好的程式。

談程式學習…初學與教學 — 學習篇(二)

每次學習一種新的程式語言，都會讓我有「回到新手」的感覺。
工作上「需要早點應用新技術」的壓力，促使我嘗試用其它語言學到的知識，來解釋新的語言，
就結果而論，還滿不錯的，除了加快學習，上手的速度，也能夠對原來的知識有新的了解。
底下分享一些我學習程式的觀點。

練拳不練功，到老一場空… 那程式的基本功是什麼？

前文提到，理解是學習程式的真理。但是新手常面臨到的問題，卻是看似遠無止境的東西需要理解。
就事實而言，程式語言是一種集體創作的產物，所以總是有新的東西出現，可能是一個研究成果，或是一個框架想法。
因此對於新手，甚至是還沒有入門的人而言，我建議先嘗試去解釋基本規則背後用意，能夠講得出來，就表示有一定的理解。
不用太擔心解譯錯誤，當發現自己的解釋有誤，就去修正，這樣會慢慢的接近正確的想法。。
也許在剛開始的時候，不得不混雜著一些死背東西，當解釋的比例越來越多，需要死背的東西也相對減少。

談程式學習…初學與教學 — 學習篇(一)

緣起…學程式也好幾個年頭，有感程式領域之廣，讓人能夠同時體會老手與新手的感覺。
心中的一些想法，想要訴諸文字，希望分享給在程式路上的舊雨新知。
也期望能夠帶給人一些不一樣的想法，也歡迎批評，指教。

先簡單介紹一下自己…

• 不是生在程式之家，也不是相關科系畢業，學習程式是前半段，只有電腦書而沒有別人討論。
• 學習程式的資質並不高，常對人說「光一個 Class 的概念，就花了我一年的時間才了解」。
• 對於自己經歷過一點命令列時代感到幸運，對於下指令，以及之後學習其它作業系統有很大的幫助。
• 玩遊戲的功力很差，所以常用修改軟體，誤打誤撞讓我明白了記憶、變數的使用。
• 程式功力不曾進入「高手」的領域，一直在數種不同的程式語言間打轉，被不同平台、框架玩了許多年。
• 在某種語言前，會是完全的新手，但是在另一種語言前，經驗足夠讓我指導新人、完成專案。
• 除非是常在講的專有名詞，否則完全記不起來，徹底表現出「看過即忘」的特質。