[嘆世間] 我談加班

最近在客戶那裡常常聊到加班。幾個客戶公司的年輕人們這陣子常常被主管拗加班，我自己也有時候會被要求留下來做晚一點，對此，其它人是敢怒敢怨而不敢言。我想藉此來聊聊我想聊聊我自己對「加班」這件事的想法。

--前言到內文之間的分隔線--

定義「加班」：勞基法第四章第三十條明文規定：勞工每日正常工作時間不得超過八小時，每週工作總時數不得超過四十八小時。
因此，每天工作超過基本工作時數一個小時以上，對我來說就算是加班。至於加班的酬勞如何計算，就看各家公司自己如何規定，只要是對員工有一定程度的保障，我就都還可以接受。


那我是怎麼看待「加班」這件事呢？那就是去你媽的！

我在資訊業上班。我個人覺得這種消耗腦力、精神力的工作，一個正常的成年人，每天可以全心全意專注在工作上，不可能超過四、五個小時，就算是分段進入專注的狀況，一整天下來也不會超過七個小時。
專注工作的時候是生產力最強的時候，其它剩下的上班時間，用來處理一些不需要專注思考的雜事、省視一下自己的工作…有時候休息一下，上個廁所、抽根菸、聊聊msn、瀏覽一下facebook我覺得都不算什麼過份的事。
而一個人的工作效率要達到最高，精神力在專注的狀態下要維持得久，每天都必須要有充足的休息時間才行。不僅僅只是單純肉體所需的睡眠，還要能讓精神得以放鬆。
綜合以上理由，我認為上班時間就專心地工作，下班後就好好休息，讓隔天能有足夠的精神和體力來面對工作，這樣才是對工作、對做事的人都好的做法。
所以，加班只能偶爾為之，不能成為常態。否則將進入「加班→休息時間少、沒辦法充份休息→工作效率差、產出受到限制→再加班→休息時間更少…」這樣的惡性循環，事情永遠沒有做好的一天，只會讓自己一天比一天還累，一天比一天更虛弱，而要做的事情一直都沒有被少。
尤其是在精神渙散的時候寫程式，你可能會在睡飽之後看到自己的Code裡面有一些根本不該出現的錯誤，然後得花更多時間修改這些蠢問題。


所以當有人要我加班，最好要給我一個合理的理由。否則，和顏悅色地拒絕是客氣；打槍是基本；如果我那時候在煩其它事，就會被我罵回去。
順便一提，趕專案從來就不是合理的理由。會需要趕從來就不是開發程式的人的問題，主管、專案經理或是談需求的人…這樣的高階上游角色才是真正該負責的，多做一點點東西可以視為舉手之勞，趕很多嘛…我倒想問問，為什麼我要花我的時間來收你們捅出來的包？

--以上就是我對加班的看法--

「你是我花錢請來的人，我叫你做什麼你就給我做！」
『你一天只買我八小時，其它時間我是自由的。』

「我隨時都可以叫你滾！」
『你現在願意花錢找我來工作，就是因為我的技術能解決你的問題。在你的問題沒完全解決之前，我認為我都是安全的。』

「幫我做嘛…我付你加班費。」
『再多錢都買不回我失去的時間，還有健康。』



我不是把資方全然妖魔化，我也明白當老闆的有很多足以決定公司興亡的壓力。
但是，誰不是人生父母養？誰沒有家庭？


當你們想要你們的傭兵能隨時隨地滿足你們的所需，請想一想在他們背後等待他們回家的家人們。

我相信良好的雇傭互動關係，雙方都可以好過很多，而且事情可以做得比較順。

[ SQL ] JOIN in T-SQL

最近在某神祕專案裡常常會看到現有的Code在抓報表資料的時候，會讓資料庫一次、一次、一次地取大量資料，然後在server-side程式裡做轉換、統整、用LINQ查詢、統計以後再輸出給client端。
這樣的做法雖然在程式的閱讀上會很明確，哪個欄位代表什麼意義或過濾什麼條件都會很清楚，但是資料量超過一定程度以後，每一次從資料庫取出來的資料量本身就是一個負擔，再加上把資料做型態上的轉換、不斷宣告新物件裝資料、再用LINQ做查詢整合，從下命令到得到結果中間時間會變得非常久。

LINQ很方便，可以用，但不要過度地依賴。把SQL Script的基本功打好，一次把要所需的資料全部精準地過濾、計算，回傳到server-side程式的時候就是一個完整的結果，再來就只要輸出就行了，雖然可能中間會JOIN好幾張表，但只要Index建好，查詢效率就不會太差。

一個案子裡的程式開發人員能力有高有低，不是每個人都能夠寫出DBA等級的查詢句，再加上時程壓力，很多開發人員都會不願意動腦子想SQL該如何下比較好，而是急著把成果生出來而以最直覺的方式去下指令，然後就會寫出在迴圈裡把資料庫的連線開開關關，然後抓出來的資料還要轉成特別的物件再用LINQ去下過濾條件的程式，按下查詢之後可能天都黑了才生出報表（前提是不會跑出奇奇怪怪的Exception）。

這樣的情況一路開發到後期，或是再下一期兩期，後面的每一隻程式都是複製貼上，大部分的查詢都是用同樣的方式在開開關關建建放放，系統負擔不大才怪。

根據這樣的假設和跳躍式思考，我認為如果能夠活用各種JOIN的方式，把所需的資料一口氣全找出來，能夠減少資料庫的負擔，進而增加系統處理的效能。

聽說這篇原本是要寫JOIN？

--廢話終於講完了的分隔線--

簡單來說，JOIN就是把兩個集合（資料表），透過不同的方式得到不同的集合。而在T-SQL（SQL Server）中，常用到的JOIN方式不外乎那幾種：

1. INNER JOIN：取出來的資料為兩個集合都有的資料。
2. LEFT (RIGHT) OUTER JOIN：以左邊（或右邊）的集合為基底，查詢與另一張表相對應的欄位。
3. FULL OUTER JOIN：左外關聯和右外關聯的聯集。
4. CROSS JOIN ：兩個集合的每一筆資料都會被取出來。

來用範例讓這中間的差異變得更明顯。

---

現在，我們有一些資料表和資料....

這是會員，裡面只有簡單的ID、姓名和職業，其中職業是以代碼來表示，來源是另一種表。

在這裡，我特別設計了一個會員，假設他用了一些特殊的方式寫入這個系統，使他允許在「職業」那一欄沒有輸入東西。

職業，就只有ID和名稱而已，超級基本的代碼表。

產品，內容有ID、名稱、類型代碼和庫存量，和會員那裡一樣的是：類型代碼的來源也是另一張表。

老梗的代碼表，這是產品類型。

我的例子還需要一些「交易記錄」才完整，長得就像上面一樣。我要記錄的資料並不多，只要知道「哪個會員在什麼時間買了什麼東西，買了幾個」就可以了。所以設計出來就如圖所示。
會員就存會員ID、產品就存產品ID、交易時間就存寫入資料表當下的系統時間，還有一個整數的數量。

就這樣，我們就建好了簡單的環境，再來就是仔細的看一下各種JOIN方法會呈現什麼結果。

---

INNER, LEFT, RIGHT JOIN：

假設今天我要找出會員及其職業名稱，那我可以這樣下句子，並且得到以下的結果.....

我也可以這樣下....

我還可以這樣下....

差異在哪裡？

INNER JOIN所抓出來的，會是JOIN左右兩邊資料表都有互相關聯的資料。這個環境裡，沒有會員是「無業」，也有一個戳戳的傢伙沒有輸入職業，這兩種東西就不會顯示出來。

LEFT JOIN就是LEFT OUTER JOIN。它就會以JOIN左邊的Member當底，然後把JOIN右邊的Job相對應的資料撈出來顯示。重點來囉！JOIN左邊的Member資料，只要沒有下特別的條件去過慮，那每一筆資料都會被取出來，即使Job裡沒有相對應的欄位，它也會弄一筆資料出來，空的欄位就用null來表示。

RIGHT JOIN和LEFT JOIN不一樣的地方，只有方向而已，把上面那段的左邊改成右邊就行了。範例就是…沒有無業的人，它還是會把無業抓出來，然後把前面的欄位放null。

還有一種特別的JOIN叫作FULL OUTER JOIN，其實就是....LEFT JOIN和RIGHT JOIN有出現過的資料全放一起就對了，專業的名詞叫作「聯集」。瞧，例子在下面。LEFT JOIN和RIGHT JOIN有出現過的資料全出現在下面。

CROSS JOIN：

說起來CROSS JOIN是一種滿特別的JOIN方式：它不管JOIN左右兩邊資料表的資料有沒有任何關聯，它都會把每一組配對組合資料都顯示出來。下面那張圖，得到的結果就是職業和產品類型的各種配對。

「這種沒有關聯的兩張表，配對出來的結果有什麼用？」

如果你想知道「各種職業購買各種產品的記錄筆數總和」之類的東西，這就有用了。

如此一來，我就不用在程式裡跑迴圈下查詢查到死。

--好睏哦....--

善用JOIN，你的人生將會一片光明 (超敷衍)。

至少在面對統計報表或是神祕的實體關係時比較不會有所畏懼。

是的，我最近在搞報表，快被搞死了。


[範例Code，含建置和查詢]

[狗大便] 不容易被發現哪裡出問題的問題 (2) - Int to StringFormat

只要扯到字串，事情就會變得很麻煩。
有學過C就知道，我們看到的字串(string)都是由一組字元(char)陣列組合而成的，而字串最後還有一個'/0'的符號作為字串的結尾。至於要怎麼去操作字串，加大或縮小，複製或貼上，都得用控制陣列的index和動態記憶體配置來實現，而在約耳的書裡也提到，用程式來調配記憶體是最麻煩的一件事。你就知道以前在搞字串的時候有多麻煩。

然而，現在許多高階語言(.NET, Java, ....等)都有字串的原生資料類別，還有武功高強的virtual mechine在OS之上、程式碼之下運作。
那真是一項偉大的發明。不僅減少了開發人員許多麻煩，讓開發應用程式的人越來越不需要考慮太多字元與字元間和記憶體的問題，同時也減少了開發人員靈活動腦的機會(越來越笨囉)。

總而言之，這次的問題就是跟字串有關。我相信這雖然似乎在我的部落格中是第一篇和字串有關而且容易debug沒留意到的問題，但不會是最後一篇。因為字串太麻煩了。

--廢話分隔線--

一般人的邏輯裡沒有什麼"整數"和"字串"之間的分別，嘴巴裡講出來的數字能加能減能排序都非常的直覺。但是在寫程式的時候，編輯器可沒這麼聰明。一開始宣告他是哪一種資料型態(data type)，它就是該型態，沒給它做特別的動作的話，它就不會變態 (喂)。

今天的問題是什麼呢？反正就是跟資料型態有關。

需求：
我希望在開一張新訂單的時候，訂單編號能夠由系統自己產生，格式為兩位數的西元年份加三位數該年度的訂單數量+1，中間用dash隔開(yy-ccc)，如：12-001

聽起來很容易吧？而且需求也非常的明確，應該是不會有什麼大問題？
問題都藏在開發者內心的空隙，也就是粗心啦！

這個簡單的需求分了兩部分：兩位數的西元年份和三位數的訂單數量。我們一個一個來看。

1. 西元年份
.NET的DateTime直接呼叫Now，就會自己回傳本機的系統時間。我們取其中的年（預設為西元年），再取後兩位，就可以得到我們要的部份。
想法很簡單，但是那是聰明如我們才這麼覺得。沒做什麼特別的編程，程式是不會做任何跳躍式的思考的。所以，我們在中間還得再考慮資料型態的問題。

直接用DateTime.Now，取出來的系統時間，資料型態為DateTime。
再拿其中的年，可以得到以int來表示的西元年。
我們要拿西元年的後兩位，必須先把取得的int西元年用ToString()轉成字串以後，再用Substring(2, 2)來取後兩位。
看見沒有？短短一個「兩位數的西元年份」，做了幾次的轉型？串起來的結果就像這樣…

　　string strYear = DateTime.Now.Year.ToString().Substring(2, 2);

不過這個問題倒還好。反正中間如果轉型沒轉好，在IDE那裡按下play的時候也不會給過。


2. 訂單數量
訂單數量要從Database裡去得到明確的值，所以現在已假設有一個DAO能回傳正確的當年度訂單數量，我們得到這個值之後再加一，就是我們要的值了。

　　string strCount = (dao.getCount() + 1).ToString();

就這麼簡單，就把我們要的搞定了。

事情結束了嗎？

--還沒結束的分隔線--

還沒結束是因為輸出並不如預期。

　　string strOutput = strYear + "-" + strCount;

就這樣輸出，結果會變成 12-1, 12-2, 12-3...
關鍵就在於數量被轉成字串的時候沒有特別給他既定的格式，所以直接輸出成沒有補0或其它格式的樣子。

數量被轉成字串之後也來不及再做轉型了。你可能會直覺地去改輸出格式：

　　string strOutput = string.Format("{0:00}-{1:000}", strYear, strCount);

輸出結果還是12-1, 12-2, 12-3...
因為字串資料不會因為在format裡面給了哪些pattern而格式特別的變化。


所以，要輸出像是12-001, 12-002這樣的組合字串，要嘛就是在數量被轉成字串之前就先給他pattern

　　string strCount = string.Format("0:000", dao.getCount() + 1);

要嘛就是最後輸出的時候再轉成字串。

　　int iCount = dao.getCount() + 1;
　　string strOutput = string.Format("{0}-{1:000}", strYear, iCount);

這個東西不難，寫過點.NET的學生其實都會。就怕常常一時粗心，這樣的問題卡了三、四百塊

[ 感 ] 從使用者的角度看軟體開發 - 胡言亂語篇

這幾天我購入了一隻$ony的高階智慧型手機，用到現在雖然還不到一個月，但整體來說還算滿意。

開始使用了智慧型手機，就開始關注「它能為我做什麼？」的問題。一夕之間，我從一個才疏學淺的軟體開發人員變成使用者。開始以使用者的角度來看軟體。

身為一個窮酸的宅宅，平常上班和在家的時間都接觸得到網路，隨時隨地使用網路的需求就沒這麼急迫，所以就沒有再加上吃到飽。簡單來說，我等於是帶著一台可以放在口袋裡的、而且可以打電話但是沒網路的電腦在身上。

在這種條件之下，我要用它來做什麼呢？

打電動？這種需求我曾經和內人討論過：用潮機在公開場合打電動到底算潮還算宅？就算機器拿得再潮，做的事情還是跟宅宅無異，而要打電動打得盡興應該還有更專業的機器才對…

老子才不要變成那樣！要打我也要打高級遊戲！

聽音樂？....雖然我喜歡聽音樂，而且喜好廣泛，但是還是希望在一個人（？）的時候保持內心的沉靜。

看電視？　嗯，我喜歡看日本動畫，但是我不想在搭車的時候暴露這個個人特色XD。而且我也不喜歡在走路的時候邊走邊看畫面，這會讓我容易跌倒或撞到東西。

　　　　謎之音：這個傢伙有夠難搞的。

　　　　我也覺得。

我仔細想像自己需要這台「隨身電腦」可以幫我完成哪些事。

憑良心說，會真正使用手機"do something"的時間實在是不太多。上班和在家都有網路可以用，沒必要上個facebook也要用手機來上，而騎機車的時候又不好拿手機出來（我很重視在交通上的專注），能用手機的時間，說穿了就他媽的只有在搭捷運或在外面等人的時候。

所以其實使用的時間上是很零零碎碎的，不會特別把一天中挖一塊時間特別來使用手機在做什麼事。

1. 基本手機功能：打電話、傳簡訊、照相.....之類的
2. 記帳：以前在記帳的時候總是因為要再拿個筆和小本子出來記，久了就嫌麻煩而放棄。希望能夠透過手機來完成這個目的。
3. 行事曆：出了社會以後，最重要的就是我學生時期所最缺乏的時間觀念。事情一件一件來，什麼事情需要在什麼時間內完成或交辦，這些在個人時間管理上都是很重要的課題。在電腦上我可以用Google Calendar來完成這件事，希望在手機上不只能達到同樣的目的，同時能夠和Google Calendar維持同步。
4. 筆記：想到什麼記什麼，畢竟靈感稍縱即逝。可能利用一點瑣碎的時間把工作中該仔細思考的流程圖或關聯圖設計好，以利接下來工作的進行；或是記下什麼東西要買，什麼事情確定要做，做一個checklist，看到一個就點掉一個這樣。
5. 優化OS：電源管理、存取空間管理.....等

好的，本篇的重點不在"我需要什麼"（至少現在不是），而是，我從一個身兼分析設計和時程管理的半調子軟體開發人員，切換角色成一個「使用者」。列出我的需求，就像寫Story一樣。只差沒有一個開發團隊可以為我量身打造我所想要的軟體。

於是，我根據我的需求上Google Play找一些有的沒的。看起來像是能滿足我需求的軟體就都把它載下來玩一玩，不喜歡、不好用就解除安裝、真的很喜歡就會考慮付費買專業版。

在我沉浸在這種輪迴時才驚覺一件事：軟體業一樣是相當現實殘酷的。被我扔掉的軟體，背後一定也是一個（或一組）開發人員花了不知道多少時間才做出來的，而我用十分鐘就把它刪掉了。

而我們立場轉換一下，變成開發軟體的開發商。如果不是專案的客戶沒有足夠的選擇空間，我們是不是還能夠從他們手上拿到足夠養活自己還仍有盈餘的費用？

這樣講雖然不夠客觀，畢竟專案客戶在選擇開發商的時候不只看軟體，還會看專案的時程和管理方法，能夠滿足客戶需求並且在限時內完成，就是好的開發商。但是，只要考慮到使用者在操作軟體時的感受，我們這種軟體工程師是不是還能很大聲地跟他們講「你們就這樣這樣做就可以達到目的了！」只要使用者的選擇夠多，我們產出來的軟體是不是還能在萬軍之中騷到敵將的癢處？

所以，使用者介面的操作設計和基本功能的品質是何其重要？尤其在競爭激烈的環境－行動裝置的APP、包起來在外面賣的軟體或遊戲……等－使用者只要再另外花三分鐘，就可能會找到比你做出來的還要更優秀的軟體。

這告訴我們什麼？無法掌握使用者操作軟體功能的感受，就等著看使用者的臉色喝西北風。

約耳在他的blog裡提到（現在有中文版的書，以下非原文）：

暢銷的軟體，應該要簡單容易上手，而且功能穩定品質良好。這些條件必須快速做到定位，以取得市場的佔有率。

千萬不要畫了一個超大大餅，然後因為時程壓力把做到一半功能不完整的東西扔出來讓使用者玩，那只會讓人感到這個軟體爛到令人印象深刻。

偉哉約耳大大，他在好多年前講的東西，現在在我心中得到了印證。

至於另一本書的哪個資深的開發人員所強調的「快速開發以取得先機，讓市場先認識我們的軟體」，.....嗯，我只能說自我感覺太過良好。我記得講出這句話的資深開發人員，他們做出來的東西超爛的。

我積了好多主題沒有po....

[ 鬥 ] 怎樣的競技是會被讓人站起來鼓掌的？

讓武士全心投入戰鬥的樂趣，在於與有意思的對手交手的過程，你來我往的短兵相接當中，展現出華麗且目不暇給的戰技，交錯出燦爛的火花。
這樣的感覺，不只在戰鬥中的武士能夠感受到，更能把奮戰的熱情和求勝的慾望展現給觀眾。當觀眾看到戰鬥的華麗技術、不輕易言敗的韌性和追求榮耀的心，分出勝負的一瞬間，讓觀眾留下深刻印象的，不會是誰勝誰敗，而是戰鬥的過程。

勝負的結果，真的不是最重要的。

---

昨天晚上看完職業電競聯賽Taiwan Open的星海２總冠軍賽，我個人是覺得十分精采，餘韻猶存，雙方對勝利的渴望，令我印象十分深刻。
中間還存在著一些向對手挑釁的動作和行為，在戰場中間丟礦騾、在對方門口蓋主堡、擺出贏得很無所謂的姿勢…等。我覺得這都沒什麼，甚至覺得雙方心裡一定也有底，做一些這種動作，能夠把交戰的氣氛再炒得熱一點，可看性也夠。簡單來說，就是一個"秀"的效果而已。電競圈子不大，而且沒有物理上距離的問題，並不會因為不是在同一個隊伍，選手之間變得很不熟或怎樣的，就像自己朋友在打球或打電動，跟對方嗆聲一下，意思一下，無傷大雅。
當然，比賽有輸有贏，分出勝負的瞬間，有人狂喜，一定也有一方感到失望。無可避免。


在那之後，敗方教練的粉絲團小編在facebook上po了一些不是很好看的言論，指責對方沒有風度，又再企圖以"對方違反規則"來把勝利移轉到自已這方。
看到那些言論的當下，我的情緒開始湧了上來。我不只是怒，而且還感到失望。

選手們的努力付出，演出了精采的比賽，奮戰了三、四個小時，渴望戰勝對手的榮譽心，就這麼讓你幾句話給破壞了。
小編以教練的身份po一些亂七八糟的東西還沒屬名，是想幫他經營粉絲團，還是把教練的形象破壞掉？

這種交手，這種比賽，在眾目睽睽的環境下公平競爭，是個乾淨的比賽！沒有任何一方有什麼作弊的行為！沒有人用什麼骯髒的手段來取得勝利！那是一種武士交手中求勝的那種純淨信念！

公平、高尚的比賽、雙方選手的心，豈能容許被如此踐踏！


於是，我回文了。用溫和但絕對的言詞指責了小編。
最後，他刪文了。幾篇不好的東西都刪掉了。

爛！連處理的方式都爛！
如果哪天哪個跟我有關粉絲團小編是這個樣子，應該會被我斬首示眾。

[狗大便] 不容易被發現哪裡出問題的問題 (1) - DateTime

去你媽的這篇文居然在電腦跑很慢的時候被吃掉了，害我又得再重po一次，幹你媽的！

--幹你媽的分隔線--

問題背景：

以下是source code。

這段method的主要動作，是檢查兩個實體物件的內容是否完全相同。
像這種左右對稱的寫法，看起來好像沒什麼問題，常理來說應該可以達到我預期的目的。

但是實際在運作的時候，就是會有時候和預期中的運作結果不一樣。有時候可以很正常，有時候就會錯，搞得全等都不全等了。
那麼，到底是哪裡出了問題？

--解答在此--

資料型態的轉換，中間會有一個讓人頭疼的風險：資料的失真，尤其是失真的過程還讓人不知不覺的時候。

那像這種資料，在什麼情況下會失真？

實驗的結果為：把從C#程式裡取得的DateTime寫入SQL Server的DateTime的過程。
DateTime是一種用來表示日期和時間的類別，在寫應用程式的時候十分的泛用。但是各家的定義為何，就不太一定了。

大方向上當然是不會有什麼問題，問題是出在Ticks這種微小精細的東西上。.NET的Ticks定義為從0001-01-01 00:00開始的計算100奈秒的差距量；而SQL Server的Ticks則是1970-01-01 00:00開始。定義上有差，跑出來的數字當然就不一樣。

想當然爾，如果把一個從.NET取得的DateTime存進SQL Server，再原封不動地拿出來和原本的值做全等比較(==)，自然就會有讓人感受不出來的差異。 

所以，我把程式稍做修改，世界就和平了～

ref:
[1] http://hi.baidu.com/raybook/blog/item/6702d32a98ce88315343c18b.html
[2] http://seesharper.wordpress.com/2008/07/08/sql-server-datetime-vs-net-datetime-battle-of-accuracy/

[嘆世間] 自主

曾經有幾次和我的摯愛聊到一些小人齷齪事，聊到後來我比她這個當事人還火。我只能說：我對無恥過敏。



媽的，我就針對你。人間異語：資優教育扼殺我的發展

好你個蘋果日報，這麼無恥的話你也敢報出來？該文記者小姐，你已經報過好幾篇報導是會磨損在人生道路上奮鬥的熱血精神的，居心十分可議！還有畫面上的那位先生，我得向你道個歉，我不該把你說的話po在我的facebook塗鴨牆上，讓我每看到一次你的臉我就想扁你一次。

--前言結束的分隔線--

說文解字：自主。
教育部國語辭典線上版於2012/04/28查詢出來的結果是這樣說的：能依自身的意志、權力行事，不受他人干涉。如：「婚姻自主」、「獨立自主」。老殘遊記˙第八回：「眾人攙著，勉強移步，走了約數十步，方纔活動，可以自主。」
假如這麼清楚的解譯都看還不懂，那還有更簡潔有力的說法：自己是自己的主人啦！

這句話今天我不吝保留地告訴你算你賺到，覺得刺眼不願意聽的話，你就一輩子活在別人的期待裡吧！我要說的是：你是你，你應該活出你自己，別人給你的期待讓你過得不開心，他們不需要負責任的，你所得到的只是自怨自艾過一輩子，不滿現在的生活，抱怨過去的選擇。沒錯，就是你現在在做的事。

--分隔線之後看你講了些什麼--

你說：像建中生都有個包袱跟標籤，就是要會念書又會玩，如果做不到就很奇怪，結果大家都無法放開視野，均衡發展。反而我看到許多不是念明星高中的同學，自由自在，做著自己想做的事，獲得在學校沒辦法看到的成果，活得很精采。
怪我囉？
你說：也許有些明星高中學生會很開心，因老師特別兢兢業業，資源也較多，學生可以得到想要的幫助，但那都是極少數。對想有個開放環境，可以做出不一樣東西的學生來說，這種環境很壓迫，被學校的想像、同學的表現，還有自己覺得自己該是什麼樣子壓迫。
怪我囉！？
你說：被所有期待跟標籤壓到必須非常努力，人格發展受很大擠壓；直到大學畢業，個性都無法伸展，老覺得應該要怎麼樣，怎麼這麼多年都沒達到？念建中就覺得要上台大，不是滿意的系，就努力轉系，轉到物理系後發現成績不太好，上不去；想出國留學，又考不上，就卡在那，好多這種人。他被升學再升學那種單一想像壓住，認為成功就是要出國念名校，不會想自己可能不適合，就一年一年的考，一年比一年消沉。
怪我囉？
你說：我覺得我不該念數理資優班，因我國中就有很多人文社會科學想法，但數理資優班不管這部分，當這種特質沒人引導時，就無法開拓。所以我高中都在看小說，想探索世界，但還是被綁住，看家族有人當工程師，覺得也是條路，可是念到大二，就覺得我繼續上去可能就是念光電所，然後進光電產業，過著一板一眼的工程師生活，我會感到自我有種滿足嗎？我怎麼想都不會。反而當我愈探索自己想做的事，愈感受自己渴望在沒公式的東西裡找尋感動。
怪我囉！？


咳嗯，我要冷靜一下，快要不知道該從哪裡吐槽了....




對啦，建中生都很辛苦，都受到別人都給你些什麼社會給你們的期待所壓迫。話都是你在講。
我想問問，沒滿足社會給你們的期待，你會死嗎？別人給你的壓力你把它扔一邊，學自己想學的，看自己想看的，你會因此而下地獄嗎？況且這些期待還都是你自己憑空想像的！真正資優的學生，並不是真正會玩又會唸書，而應該是真正知道自己想要學的東西是什麼，而且學得很好、很享受這種學習的過程。就我所知道，明星高中的自我學習風氣可是很強烈的，你自己都已經知道自己想要學些什麼東西了，幹嘛不自己去學，而選擇等到什麼東西都做不好的時候再來靠杯別人太強自己太弱然後又學不到東西？
考得上建中很了不起嗎？我就算考得不好，過得還是比你開心。因為我學的是我所想學的，我還是屬於擁有充實生活一那群人中的一個，你還是每天只會對著牆壁哭。
你選擇了一條你不想走的路，然後學不好又在怪老師怪學校怪社會，你怎麼不講自己一開始的選擇就有問題？你怎麼不講你自己沒試著做一些改變做一些突破？非得等到屬於你的青春已經過去了，才在靠杯說自己沒學到自己想學的，關於這一點，你要怪誰？


我從頭到尾只看到你一直在講你以前被這種環境壓迫，一直到大學都還沒有什麼改變。你不斷在抱怨自己的人生有問題，不斷在抱怨因為當時的情況造成一些連帶關係，而使現在過得不快樂，從頭到尾都在講別人。你有沒有檢討過你自己？你有沒有發現你當時只要換個念頭，換個決定，換個選擇，你可能就不會講出這種無恥的話？
你該照照鏡子看看你那是什麼嘴臉。你那樣就很像別人沒幫你打手槍就躺在馬路哭鬧的屁孩樣子，扁你一頓感覺也是剛好而已。


中間有一段講你國中就有自己的想法，就知道自己想要唸些什麼東西。有想法有屁用啊！沒去實現都是假的啊！活到快三十了還不了解這種事嗎？不要再靠杯別人給你怎樣的期待還壓力了，那些都只是沒有勇氣嘗試改變的藉口，那根本不值得同情。
你講到唸其它學校的同學活得很精采，我得讓你先認清一個事實：並不是因為他唸哪間學校比較閒，還是唸他自己喜歡的東西才過得精采；而是有足夠的行動力來改變生活，甚至可能有一些破釜沉舟的革命勇氣，來追求自己想要的東西。這才是事實！就我看來，你的行為只是因為你沒有勇氣、沒有決心、沒有行動力去追尋自己的夢，然後搞得好像社會大眾害你沒有辦法做想做的事。
給我看清楚「恥」怎麼寫。除了你自己之外，沒有人需要對你的這個人生負責。就算有其它人（父母...?）逼著你去選他想要你選的路，但那還是你選的，別人並沒有拿槍指著你的頭要你做什麼事，一切都是你自己選的。

你的結論更鬼扯。我從來沒看過有人甘願拿這麼一點錢就夠用的！
你15000就可以過一個月是現在的你覺得夠用的，那我問....你中間如果電腦壞了拿什麼錢來修？你家如果漏水了或什麼電器壞了，你拿什麼錢來修？你中間如果受傷生病快死了住院了，拿什麼錢來付？你要娶老婆還是要買外籍新娘的時候，拿什麼錢來結婚？我的假想是：這些問題你從來沒想過，反正有當初叫你去走他想要你走的路的父母幫你撐著，你不需要考慮這些零零總總雜七雜八和自己好像有關又好像沒關但是會不斷讓你花錢的事。說穿了，不就是個離不開父母庇蔭的溫室花朵嘛？這只是我的假想啦，你可以反駁，而我也不想對此多做著墨，反正這裡是要談自主。

讓我再一次強調：除了你自己，沒有人需要為你的人生負責。你認為該是屬於你的，就應該用你的雙手雙腳盡力爭取盡力追求，而不是等其它人來主動給你；你發現自己想要學些什麼東西，就應該盡自己所能好好地去學習相關領域，而不是讓其它人來干擾你的學習和想法。
有果決的行動力和覺悟，做出自己真正所想要的選擇，才算是活過，你的靈魂才算真正存在過。這就是自主。
每條路都艱苦難行，你選擇了你要走的路，就沒資格後悔、沒資格埋怨其它人給你這種人生規劃。如果你從頭到尾都在怪別人、怪環境，而不檢討自己該做的有沒有做好、想做的有沒有做到，那就是無恥，表示你根本從來沒用檢視別人的眼光來審視自己，還好意思大言不慚地講出一些莫名其妙的言論。
而這一篇文，就是在你發表你那莫名其妙的言論以後，我所做的回應。
雖然我不認識你，雖然你唸書比我厲害，考得可以比我好，我還是瞧不起你。因為你根本沒有勇氣走自己想走的路。

--脫離主題的分隔線--

我隨便用一小段來說明我對「廢明星學校」的看法：我堅持反對廢明星學校。
優秀的學生不該被和庸才放在同一個空間互相干擾，那才是真正阻礙國家未來真正的競爭力的發展。九年國教制度，國中時在某些科目有過人才華的學生們就都已經被和其它同學關在同一間教室逼著上同樣的東西了，這種惡性風氣還要延伸到高中去？

[ 記 ] 對話記錄：抱怨（不喜勿入）

--抱怨開始分隔線--

我 說:
． 待過真正苦過的環境就會覺得這裡還不錯
． 不知道我有沒有跟你抱怨過
友 說:
． 還蠻常抱怨吧   死大陸人~~#$#%#%
我 說:
． 以前我們老闆常常在講：公司營運最重要的就是獲利，得到獲利以後再與大家分享。
． 然後上一次基隆港的案子結束以後，我問公司有沒有專案獎金，老闆說沒有，還說「如果公司虧損要不要扣薪水」
． 我印象中好像有在facebook上還是blog上貼過類似的東西
友 說:
． 幹   爛死了~
． 虧損就是上頭決策的問題~~
我 說:
． 幹你媽的你營運不善怪到我頭上來咧
友 說:
． 有濫有濫  XD
． 你在那應該每天都 deep blue
我 說:
． 幹  那段時間我極度不爽
． 我見識到什麼叫老闆滿嘴空口白話
． 開會就在扯東扯西胡言亂語怪力亂神，要他的員工相信他
．腦子不夠清楚還真的會被騙去，操他媽的跟神棍一樣
友 說:
． XDD
． 真假    神棍
我 說:
． 連在網路上看到「上班打卡制，下班責任制」都要特別跟我們開會來消毒 + 討拍拍一下，講說不要跟著這種文章在起舞，要看得清楚我們的目標
． 作賊心虛也不過如此
友 說:
． 真是吃飽沒事幹
． 那....這裡真的好多了...知足知足~
我 說:
． 去年好像十月還是十一月是我第一次提離職，那時候我持的理由是「無法配合天天跑基隆」
． 老闆親口跟我說「基隆不一定會是你去，不用擔心」
友 說:
． 結果  真的天天跑  =  =
我 說:
． 結果咧..... 連續測試兩個月我和我們經理天天跑，上線保固第一個月我自己天天跑
． 就這樣跑了三、四個月有餘 (連續測試兩個月是工作天，所以總共跑了快三個月)
友 說:
． 靠....   這....
我 說:
． 我就在facebook上面po"我上班的地點是政大，不是他媽每天得花四個小時通勤的基隆"
． 老闆就在skype表示說他有看到，然後沒講什麼
． 真要說我對他的信任什麼時候徹底瓦解，應該就是從那時候開始
友 說:
． 幹   真的是出一張嘴~
． 當賺錢工具
． 不過你之後會外派嘛 ?  還是做專案?
我 說:
． 不知道耶   我現在還是在T01專案裡，以後會出差外派還是要幹嘛不太曉得，應該還沒有這種規劃才對
． 聽到我的遭遇，你有沒有覺得你在天堂\
友 說:
． 有有   感受到了~
． 我同學考上公務員高考   更爽
我 說:
． 倒也還好....公務員很無聊
． 每天要面對那些官僚
友 說:
． 說的也是   沒挑戰性 XD
我 說:
． 對  我還要再抱怨一件事
． 我們以前老闆壓根兒瞧不起寫程式的技術
友 說:
． 靠   怨念太深了    XDD
． 真假
． 這算啥科技公司
我 說:
． 常常在開會的時候講到「你們要成為balabala (好像是說會規劃會管理會設計吧? whatever) 的人，不要只會寫code，會寫財產系統的人外面一堆都是啦！」
． 「會寫應用程式不需要太艱深的技術，沒什麼了不起的，重點是要會管理....」
． 你了解什麼叫做「在科技公司裡，自己的專業被否定，卻沒有人比你懂更多理論知識」的感覺嗎？
友 說:
． 嗯~  果然很爛  !!!!
． 營運應該不好吧   這種老闆
我 說:
． 留不住人才啊
． 所以台北的人一直都不到十個

--抱怨結束分隔線--

想知道我以前公司是哪一家嗎？歡迎詢問。
我還會告訴你更多祕辛和詭異生態

[說文解字] 道

這裡說的道，不是指什麼道可道非常道，也不是道教的那個道。

而是指合氣道、劍道、空手道、柔道、跆拳道、茶道、花道、武士道的那種道。
道，我們比較容易想像的具體東西就是道路、指引，進而形成方法。英文的Aikido、Kendo中的do，直接翻譯成Way，我認為是非常貼切而且容易理解的。

與友人討論後得到一個結果：劍道、空手道、茶道、花道、武士道……等等的這些道，其實是一種透過特定的方式（劍術、空手搏擊、茶藝、花藝…），達到一種穩固、沉靜的心靈狀態。其它的禮、義、和平、圓融等，都是這種心靈所散發出來的一小部分。

很多武術和技藝一開始都在練技法。而透過這些方法，過程中也不斷讓修習之人慢慢體會一種追求極致、沉穩、純淨、不被其它外界事物干擾、有招化無招、不變應萬變的一種禪宗心靈。
雖然每一種道所追求的精神不盡相同，但是體悟了這種禪宗心靈以後，所散發出來的氣息是神聖、純粹而且不可侵犯的，甚至趨近於一種信仰、意念。

就像劍君在死前的最後一戰，就是戰鬥中不斷地思索他所追求的劍是什麼樣子。
劍，就是他的道，也是最後的精神。

道，是方法，是路途，通往所追求的精神心靈的路途。

像那種「道」就是規矩，沒有規矩就是沒有學過道這種鬼話，不要再外流出去了，那只會讓懂的人貽笑大方、讓不懂的人覺得你多自以為了不起。

程式設計能不能成自成一道呢？由理論、經驗和技術所綜合而成的現代技藝？

Ref:
[1] 新店合氣道
[2] 訪談交流 with 劍道友人
[murmur] "道"這個字的意義，我居然是看英文的文獻才懂....

[ mail ] Reply

Hi <收件人>:

事實上，我還沒離職就已經先找好工作了，所以基本上沒有空窗的時間就銜接到新的工作了。

新的地方環境不錯，大家都是寫程式的工程師，而且技術都很不錯，我認為能夠在這裡學到一些我本科老本行的東西。

讓我離開泰又的原因其實不少，像是

...我覺得做開發的環境不是很好，不太容易有很良好的管道可以和開發團隊溝通。網路無遠弗界，我們可以透過skype輕易地和大陸的研發部門溝通，但是在做開發的時候，除了能夠面對面溝通的空間，不然都是不夠用的，很多時候溝通需要在黑板上畫圖，這一點skype就不好辦到。

...再來，我認為研發團隊也沒有真的很積極去想把一個軟體做到很好，也不是很用心在設法將使用者的感受和現有的技術 (或還沒學到的技術) 結合起來。市場端的人大部分都不會寫程式，對很多技術也都一知半解，所以也不可能去叫大陸的團隊做到什麼，畢竟，連自己希望能做到什麼 (需求) 都不知道的情況，怎麼叫開發的人做出來。

...還有，研發團隊不太重視設計。好的程式設計可以讓日後的維護變得較為輕鬆，維護成本降低，甚至開發成本也能降低。但是沒有人有做。真以為使用者提出的每個問題都是特別跑來找麻煩嗎？怎麼沒想過，他們只是把在測試的時候沒有發現的問題再提出來而已？維護不完的軟體，怎麼沒有人發現能夠在開發前的設計多下點工夫，就能避開這些麻煩？

...公司要進步不是光靠管理流程而已，會用正確的方法做正確的事才是更重要的！什麼是正確的事？什麼是正確的方法？每個人見解不同，但是確實都得要有強而有力的人來執行。這些千里馬，可不是用隨隨便便的雜草就餵得動的。吃雜草的馬，就只能做出「吃雜草」所獲得的養分的事。公司留不住人才，這件事是我剛進來你就跟我提過的，公司這裡的主管有沒有想過是什麼原因？

我還不夠強，不敢稱自己為赤兔，但是就我所感受到的是：1. 我不想吃雜草。2. 我希望有和我相同水準的人和我一起跑。

我這時候說我不重視錢，大概也不會有人信。但是我還是得說：我真的不是非常重視錢，但是我不想過那種「今天的晚餐是理想，然後端出空盤子」的工作生活。

說太多了。請當我發發牢騷就好，請別外傳。這種東西讓<Boss>知道，你們應該就會有好幾天聽不完的古，其中會有一大段在罵我自私現實、一大段討拍、剩下的再要求現在還在職的人員相信他。

總之：

1. 流程很重要。但是有流程，卻沒有執行流程的方法，事情一樣做不好。
2. 不要小看任何一門學問。管理有管理的學問，工程方法一樣有自己的學問在。我們做ERP的，賣軟體給別人，卻總是把「寫程式沒什麼了不起」掛在嘴邊，是要讓誰信服？

這些，就是我在還沒找到工作，就堅決離職的理由。

真是抱歉，我的任性妄為帶給你諸多不便，請見諒。

希望下次見面，可以以朋友的身份把酒言歡。

Best Regard

Break

[嘆世間] 七原罪 - 貪婪

http://www.youtube.com/watch?v=oqyO0DEOEN8

這篇，來自文林苑都更案

---蓮花指（？）分隔線---

這篇，沒有要談內幕，沒有要談八卦，沒有要談是非。
也沒有要聊那篇影片的世界觀和背景。
更沒有要宅Vocaloid和還是宅悪ノP。


只是要抒發一下"貪婪"後的心情

喜歡這段影片，除了它好聽之外，更有影響力的是，它真實的很讓人痛心。


這陣子常常聽到很多很匪夷所思的事，像這件都更案，再配上這篇這種都更面臨到的解決方案，要我怎麼相信台灣發生的這一切不是官商勾結？要我怎麼相信這私底下沒有利益流通？

什麼時候民眾開始不相信政府所做的一切是為了百姓？
把一些拿黑錢的高官和炒房地產的奸商殺掉，台灣會不會變得比較好？
機械公敵(I, Robot，威爾史密斯主演)裡演機器人方的理念，是不是光明未來的唯一解？
已經污穢不堪的世界，究竟是素還真的重構理念，還是寂寞侯的天下止武能夠讓社會永續生存？
難道，真的非得出現天罪，重新洗牌可以？

善良、人性、公理、正義…在錢面前，彷彿不值一提。

有權位的人，敵不過貪婪的惡魔，形成社會亂象。
這種事情在歷史已經不斷地再重演，也說明了後果都不會好到哪裡去。
但是也從來沒停下來過。

還對世界懞懂無知的時候，學校教我們：做人不能貪心，要對得起自己的良心。
現在有誰能夠貫徹這一點？良心都在哪裡？
有利益衝突的時候，有誰記得自己的所做所為會害死別人？
有利益衝突的時候，有誰看到自己的一念斟酹會傷害到別人？

恐龍法官、幫助罪人脫罪的律師、不食人間煙火的人本組織……
當你們做出足以撼動社會信任度的決定和動作時，要人怎麼能不相信背後有利益關係存在？
各個都是高知識份子，唸過的書比我多上十倍有餘，為什麼小學教的道德觀念都忘了？

是不是優渥的環境，就會讓貪婪原罪更加醜陋地浮現出來，而且還能振振有詞地說「這就是成長，這就是社會，這就是現實」？

有一則末日預言說過：在1999年時，惡魔會降臨，人們會張開雙臂歡迎它。
曾經我一度懷疑這個惡魔是指Internet（Internet雖然讓人與人之間的距離更加貼近，但卻失去了隱私和在現實生活中正常溝通的能力）。
現在我開始懷疑是貪婪人性所帶來的社會亂象。

末日，也不定是指天災。
誰知道會不會是憤怒的人民直接以武力對抗這不公不義之事？



莫非這篇是假抱怨真推廣？

[傻眼系列] 大學免學費？要不要乾脆水電瓦斯都不要錢？

神啊，我有罪。我不該犯賤去點新聞出來看。

但是這幾個新聞實在.....讓我傻眼，完全不知道該說些什麼。讓我懷疑台灣的言論和集會自由是不是放縱得太over了。

學生團體反漲學費 「還應調降」

學團到教部抗議：學費應逐年調降

---來源前言分隔線---

假設真的有這回事好了，不是媒體虛構的。


我先表示我的立場：我不贊成學費免費或調降。
台灣高等教育的學費已經太便宜了，比起其它國家，已經便宜太多太多了，便宜到養出一大群態度不好、專業學不好，又不願意吃苦耐勞的廢物，還不知道自己正在學生和出社會之間的關鍵點中浪費自己的時間。
再更便宜下去，只會讓學子們越來越不懂得惜福，不知道教育資源得來不益（私心認為就像台灣民眾普遍不知道醫療資源得來不益），不知道自己存活在被學校保護好的世界裡。過個五年，看還有沒有哪個畢業生有像樣的競爭力。
我所謂的競爭力，可不是在召喚峽谷的競爭力。

你知道那些學團的嘴臉像什麼樣子嗎？
你有沒有看過小孩子在媽媽的旁邊吵著要糖吃？不給就大哭大鬧，然後引來一堆旁人的白眼。
學團吵著跟企業要錢、靠夭大家都不給幫忙，然後又怪教育部在這時候漲價落井下石。
我是不知道有沒有人覺得那種小孩很可愛啦，我是覺得那很吵很煩。

讓我告訴你一件事：大學生的時間很值錢。那是一段可以學會很多東西，時間又很自由的時光。你可以利用你的空閒時間做任何事。你可以去參加抗議活動、你可以打工、你可以在地上吵著喊沒有糖，你也可以多看兩本書、多寫兩行Code、多練文筆、多看看世間百態，還可以在艾澤拉斯冒險、在召喚峽谷殺人。
這些時間，出了社會就不一定會有了。只要你願意，你可以多充實自己，讓企業注意到你。

---想太多分隔線---

理想中，學生、企業、學校、政府等立場，可以做些什麼呢？
我一向推崇賞善罰惡，也認為嚴竣的競爭環境可以造就一流人才，淘汰無能廢物。所以，學費要調降要有前提：廢物都去死。我可不想讓我自己繳的稅來補助沒用的廢物來完成高等學歷，畢業之後卻又什麼也不會。

無論是用獎學金、或是比較直接的方式來幫助努力不懈的學子，我覺得這是一種投資，付出多一點時間和成本來培育一流人才、減少不入流的傢伙，讓不久的未來，這些學子都能成為可用之才，沒有什麼不好。
至於其它只會浪費糧食的學生，我覺得去當兵來報效國家說不定會好一點，總之不要出來危害社會，形成社會問題。

學校和企業可以多規劃合作案。企業可以和學校或系內合作，提供實習機會，讓學生能在出社會前更早一步接觸業界所會面臨的壓力和所使用的技能。讓學生在學校裡的所學能夠快速和業界接軌。企業就不會三不五時靠夭「應屆畢業生還要花一、兩年的時間從頭訓練.....學校在衝三小」之類的。企業也可以藉此機會觀望一流人才的流向，使其在畢業前就有更好更穩定的出路。

重點當然就是學生啦！學生要自愛，你們能夠用很便宜的價錢得到許多教學資源，幾乎都是靠台灣人民所繳的稅來支撐著的。正如前面所說：你們的時間很寶貴，多看一本書、多寫兩支程式就是為自己儲備更多競爭力。所以一天不要浪費四個小時到八個小時的時間在喊歡迎光臨和搖飲料，更不要花四個小時到六個小時掛facebook上面的遊戲和獵人頭。
（一天花一個多小時在玩遊戲抒抒壓我自己倒也常幹）
相反地，除非你有確定想做的事，否則最好盡可能地充實自己，並且和外面的企業廠商接觸實習機會，或是乾脆做一些你們可以和三五好友同學能夠一起做的小案子，讓你的所學能夠在某些程度地應用在業界，一方面讓你學起來不會無聊；一方面接觸出社會後所會面臨到的工作壓力。不只是錢，還有更多的是責任和時程，和面對一大群比你老的傢伙報簡報的心理壓力。

當然，在學的過程中有想做什麼事，需要把握當下來去做，就不要懷疑，沒有殺人放火走私販毒就去做。青春和機會是不會再給你一遍的，不要留下遺憾最重要！愛你所選。

---訐譙分隔線---

啥？你說這太理想，台灣不景氣不會有這種環境？
關我屁事！真要想做不會自己想辦法去找機會哦！連這東西都要我幫你鋪好路，那要不要我幫你打手槍？

[嘴炮軟體] 可用性(usability)

這篇不談測試、數據、程式…等這些資訊相關的玩意兒，單純聊一下可用性。

可用性 (usability) 是什麼玩意兒？很重要嗎？可以吃嗎？不考慮它會死人嗎？
ISO對usability做出以下定義[1][2]：

The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.

（這個也可以定義？不知道該說嚴謹還是無聊）

簡單來說，可以將它視為使用者用某樣工具達到一個特定目標的容易程度，即對操作介面感受到的有效性（是否能夠達到使用者的目的）和效率（達到目的所能減少的時間）。
看吧～　使用者介面 (User interface)。
根據研究和分析，可用性包含了以下幾個因素[4]：

• Learnability: 使用者在第一次用就能學會的容易程度
• Memorability: 經過一段時間之後再重新使用這UI還能熟練操作的容易程度
• Efficiency: 使用者能用這個UI多快完成任務
• Errors: 包括使用者有多容易出錯、錯誤有多嚴重、以及有多容易從錯誤中回復回來
• Satisfaction: 使用者用這個UI時會覺得愉快的程度

上面的list直接引用第４篇的ref，該文裡有針對上面列出的因素進行說明和提出案例，裡面寫得很詳細，值得一看！

總之，它可能不是一套軟體、系統的核心技術，但是會直接影響到使用者的喜好厭惡。

---可用性理論雜七雜八分隔線---

知名的大公司做出來的產品，肯定都對可用性下過一番苦心。

說到這個總少不了扯一下Apple，賈伯斯對這個東西就真的很會。
我覺得與其說他會設計，倒不如說他很重視使用者在操作的當下所得到的感受，講得難聽一點，某些程度來講算是掌握使用者的情緒。只要能保證使用者在操作產品的當下心情是愉悅的，就一定能賣！
另一個直覺想到的就是微軟。雖然微軟做出來的產品好不好一直飽受爭議（看看那IE56789精美的相容性），但是不得不承認他們在做使用者介面真的做得不錯。
至少，電腦一開機進到桌面以後，不需要經過什麼訓練就能直接操作OS或其它軟體，做一些基本的操作都可以很直覺，包括像他們的Office系列，要用、要學都可以快速上手。
主觀認為，Linux的桌面開發了好一段時間，才有一點像樣的成果，前幾年的Linux就算有桌面也不是很容易使用....（這裡不要扯"Unix系列操作command line和open source coding才是王道"，我沒有說Linux功能不強，但是桌面和相關軟體的可用性比不上微軟是事實）

其實我個人對可用性的標準沒有真的很高，稍微摸一下，能夠操作一些基本的功能，能滿足普羅大眾的需求，就差不多有80分了。所以，大部分的套裝軟體，能賣錢的、能存活的，就我主觀上、時代經驗的客觀上，可用性應該都不會差。
想想看，如果你接觸到一個功能很強大，但是讓你摸不著頭緒該如何使用的軟體系統，你會不會想立刻讓它從你的桌面上消失？如果你還有其它可能滿足你需求的替代品，你會不會拿用替代品來玩玩，然後讓那個強大但是每次使用胃都會痛一次的東西從你的記憶裡刪掉。


連操作都不討喜的軟體，沒有人喜歡使用，怎麼會賣錢？一天到晚做出這種軟體的公司，怎麼會存活？

不過這句話在台灣軟體產業界就會活生生被打臉。
在台灣，使用者介面設計師這種行業超級少，需求量比起一般的程式設計師，還要少少少少少。我不確定到底是軟體廠商不知道可用性的重要，還是根本連可用性這三個中文字 (the word "usability") 都不會寫，搞到後來都是一般的工程師在畫畫面（還稱不上是設計咧！）

使用者介面設計之類的學問，歷史大概和極限編程差不多悠久，還有很多實務上的高手和學術界對此做了非常精闢中肯的分析和指引。我總覺得台灣長久以來對軟體 + 電腦的觀念就一直停留在自動幫人完成複雜作業的機器，使用者介面感覺就都是勘用就好，停留在台灣早期"國難當頭、一切從簡，有就好！"的風格，又他媽的跟簡約風那懂有質感的風格不一樣。
結果當然就變成剛拿到開發出來的軟體的時候都不會用。有些時候是連點出來那個畫面是要做什麼的都不曉得，有些是看到那個畫面後直覺地去操作，結果得不到想要的結果，無論如何，這都是可用性沒考慮清楚所產生出來的結果。
最機掰的是使用者還習慣了。



謎之音如是說：再教育訓練就好啦～


嗯，去你媽的。
軟體做出來，是為了滿足使用者的需求。做了一套使用者都不會用的軟體有個屁用？
軟體做出來是讓使用者用的，不是做出來教他們怎麼用。
所謂的教育訓練，應該是把一些軟體系統裡的細節講清楚說明白，而不是講一些核心功能面的東西。
你有看過一個拍賣網站有在做教育訓練教你買東西的嗎？你有看過facebook有派人去你家教你怎麼在你的friend list裡加入你的朋友嗎？你有看過Google開發的相關軟體有在特別發表什麼演講來說明Gmail還是Google Map怎麼操作嗎？
以上例子都沒有所謂的教育訓練，那你會用嗎？
希望你不是那個在我facebook裡看到這篇文，又常常講"再教育訓練就好啦～"的人材。

---抱怨結束的分隔線---

在約耳趣談軟體一書裡，約耳有提到他的約耳測試１２步驟中的最後一個「走廊使用性測試」(hallway usability)[6]，指的就是在走廊上隨意抓五～十個路人進來試用你做出來的程式，並且觀察他們在操作系統時所遇到的問題。如此做法，可以抓出約90%的可用性問題。
還放出一個網址讓人免費查閱他自己寫的線上使用介面設計書[7]，真是貼心！

其實保持著一個重點，做出來的UI就不會太差。"Eating one's own dog food" (吃自己的狗食) 就是把自己實際去操作產出來的系統。自己的感受如何，用戶的感受絕對會更為負面，所以要是如果自己的狗食都無法說服自己，怎麼拿你產出來的狗食去餵你的客戶？ (哦幹這句話好髒)

在約耳續談軟體一書中，約耳又提到一個Beyond usability的東西：社會性介面 (social interface) [3]。書裡有很多例子，設計、行銷上也做了一些概略性的說明。我對這個方面還不很了解，我得再多看一些書和例子，做一些冥想才有辦法想通。只知道，這個東西沒做好，usability做得再好，軟體一樣會失敗，而這個，牽涉到的不是資訊產業會搞的東西，而是社會學、人類學等社會科學；要做的研究不是書上翻一翻，上網查一查就搞得出來的，而是要走出門，去到不同的人群裡訪談研究不同族群之間的差異。

很有趣，不是嗎？跟人有關的東西就有理工科完全無法預期的變數，對此，社會科學反而是可以依賴的研究技術。（不然你用工程的角度來告訴我為什麼簡訊這種比電話還難用100倍的東西會受歡迎）
台灣學術界、產業界都不甚重視社會科學，認為研究出來的東西對產業界沒有幫助。事實上，只要和人、族群等有關的議題，社會科學都能提供比科技產業還要更可靠的研究技術和成果。社會科學提供的幫助很隱晦，不這麼直覺，但是只要用對方法，絕對有效，而且效果非凡。
不久的未來，我將引入這套技術，作為軟體開發方向的決策參考，讓社會科學能夠得到更多的重視。為了台灣的產業，也為了我的摯愛。

ref:
[1] Usability from Wikipedia
[2] 易用性 from Wikipedia
[3] 約耳續談軟體
[4] [HCI] 談人機介面設計與Usability
[5] 要求手繪 Logo 字體的迷思！怎麼讓現成字體也很有個性 by evenwu from T客邦
[6] 約耳趣談軟體
[7] User Interface Design For Programmers

[Programming] 設計模式 (1) - 策略模式 (Strategy Pattern)

さ～我們就來看看抽象(abstract)和介面(interface)的設計應用，看看它如何讓程式變得彈性又功能強大，而把物件導向程式帶領到另一個次元去～

在開始之前，你可能會需要先看看之前幾篇[1]，了解一下物件導向程式設計的起因和操作。

所以在這裡，是都假設對抽象、介面這些都明白了，只是還不知道怎麼去應用在實務上而已。

另外，class都沒建的程式設計方式就不在這裡討論了。

----廢話的分隔線----

首先呢，我們來看看我們的需求。

1. 建構一個"財產"類別。
2. 已知的財產很多種，如土地、土地改良物、機械設備、交通設備、雜項、物品等。
3. 會需要對財產進行異動，如新增、減損、重估等，異動流程有些一樣，有些不同。
4. 日後要能夠對財產種類和異動種類進行擴充。

看起來算是很實際的例子吧？如果有觀眾在做ERP，這種案例應該隨時會遇到。

這個例子，也是我在出社會後第一個進行開發的專案。雖然還是有些許的不一樣，但大體上差不多啦。

這個，應該就能夠滿足他的需求....

如果你是哪個經理還是老闆，你覺得你的員工壓榨起來讓你很舒服，或是做出來的軟體日後不需要維護，你就可以這樣做。

我光是畫這張圖就累了！除非拿槍指在我的頭上，否則我無法接受我自己寫出來的程式長這個鳥樣子！

但是，相信我，一定還是有些人會這麼做。當我和沒有正確程式設計觀念的人共事時，就發現沒有什麼事是不可能的。

這個時候，我們應該平心靜氣地，把這些類別中相同的部分取出來，讓各個類別繼承。

然後就變成下面那樣子....

我們先把各個財產都有的屬性全都拿出來，放到一個Property(財產)抽象類別去，然後讓每一種財產都去繼承。這樣子看起來，好像還不錯？至少變數都拿到抽象類別去了。

然而，尷尬的點在於下面的那些財產，他們還有異動的方法還沒抽出來。如果是上面那樣的話，等於我在每個類別裡都要再另外寫異動方法；那如果是下面那樣....

好像就可以不用重寫太多東西了？會不會有哪裡怪怪的呢？

需求的點在於：異動流程有些一樣，有些不同。我們應該把哪些一樣的流程丟到Property去？哪些放在類別本身？

需求又說：日後要能夠對財產種類和異動種類進行擴充。這就表示，根本沒辦法知道哪些流程重複性比較高，哪些流程比較少用。

我們學過一個東西叫做介面 (interface)，能夠強迫每一個實作它的類別實作一些方法。所以，我們還會看到下面那種東西…

如果你學了一套新方法，不確定怎麼用的話就不要亂用。幕容復就領悟過：再怎麼華麗的招式，也只是招式上佔上風，如果使用這些招式會因不熟練或其它因素而減弱傷害力，還不如不要用。這也是為什麼，日本的劍道和空手道的上段高手，每次練習的時候還是有再練基本的揮劍和正拳中段攻擊。

扯遠了。反正，如果一種方法不會讓你的工作量變少，就不要亂導入。看看上面那張圖，想像一下：這和第二張，剛把變數抽出來放到Property裡有什麼不一樣。

沒什麼不一樣！這樣還是得在每個類別裡實作異動方法啊！！

還有，不要覺得複製貼上程式碼是很容易的事。這種事情做多了，就像用火燒藤甲兵一樣，會損陽壽的。等到哪天業主一道指令叫你改掉什麼東西，你會發現你的時間都浪費在以前不知道複製幾次的程式碼上面。

----各種可憐情境的分隔線----

GG (good-bye garbage)，跟那些爛code說再見吧！這個時候，就可以看到優秀的程式員如何用知識解決問題（工作量大的問題？？）。

我們來整理一下問題。前面遺留下來的困難點在於那一堆神鬼莫測的異動流程，因為有些財產用的異動流程有一樣，有些不一樣，所以很難去特別把哪一種異動流程抓出來繼承。

那麼，就全部抽出來好了。

設計守則第二點就寫著[2][3]：

Program to an interface, not an implementation.
寫程式是針對介面而寫，而不是針對實踐而寫。

原因則是....

以前的作法是：行為是繼承自超類別的實踐方式而來或是繼承某個介面並由次類別自行實踐而來。這兩種作法都是依賴「實踐」，我們被實踐綁得死死的，沒辦法更改行為（除非寫更多的程式碼）。

所以，我們接下來的作法將迥異於以往。

我們另外做一個Operator的介面，然後把各種異動流程方法獨立出來，並且實踐該介面。這麼做，無論是Property或是Land...等財產類別，都不會被這些演算法套牢了。這就是「程式是對介面而寫」，或是「對超型態而寫」。
這樣子設計，財產那裡需要什麼異動方法，就加在這裡就好了，和財產本身就一點關係也沒有。各類財產需要哪些異動方法，再自己呼叫就行了。

於是，經過整合以後，我們就可以得到這個圖....

看見沒？那些有的沒的異動方法全和財產分開了！而Property那裡和Operator有關的，就是定義一個Operator類型的屬性，而財產本身如果要做什麼異動的時候，把各個演算法定義清楚，就可以操作了。

就像這樣....

//土地財產
public class Land extends Property {

    ///Constructor
    public Land(){
        ID = "";
        PropNo = "";
        PropNoSeq = "";
        cost =0;
        val = 0;
    }
    
    ///不動產新增流程
    public boolean Add(){
        operator = new EstateAdd();
        return operator.operate();
    }
    
    ///不動產減損流程
    public boolean Dero(){
        operator = new EstateDero();
        return operator.operate();
    }
}

那麼，假如我想要把不動產的新增流程，改成使用動產的新增流程，我只要改.....

    ///動產新增流程
    public boolean Add(){
        operator = new ProductAdd();   //這裡
        return operator.operate();
    }

一行就好了。


當然，你要把它做得更細緻一點的話，也可以再改一下.....

看到了嗎？利用這套模式，就能夠把程式變得彈性很夠，隨時能夠加以擴充，而不用修改到原本的程式。abstract和interface的混合應用，由這個例子可以看到，能夠把程式（或是系統架構）變得有彈性，程式之間的相依性變得低一點。
而這個，就是設計模式 (Design Patterns) 中，所謂的策略模式 (Strategy Pattern)：

策略模式定義了演算法家族，個別封裝起來，讓它們之間可以互相替換，此模式讓演算法的變動，不會影響到使用演算法的程式。

設計模式沒有對與錯，只有有效或無效而已。
是否有效改善程式結構，讓軟體變軟。

----還有一些打破主題的廢話分隔線----

設計模式這種東西，其實是一些先賢烈士面臨到需求環境的多樣化後，加以設計，並且一般化而成的設計方法。當然，他們遇到的情境和我們將要面對的可能又不太一樣，若要直接套用，會是有風險在的。但是如果能夠把設計模式裡的想法和精髓融會貫通，情境、需求有變，就做出不同的設計就行了。

不過，約耳在他的書上表示：設計模式是一種讓程式設計生活從普通變得不錯、有趣的一種途徑，即使沒有它，程式一樣能動，只是可能維護上會變得比較麻煩（可能麻煩很多）、程式跑得慢一點…但是它還是能跑。

而低階一點的C/C++，如果指標沒弄好，出了差錯，程式會直接死在你面前，別想它會繼續往下走，你的程式設計生活就會很悲慘，所以做C/C++的程式員是非常辛苦的，可能會有抓不完的bug，和無法預期到的exception。但是在這種環境下訓練出來的程式員就特別強[5]，邏輯能力強不強是超乎另一個次元的問題（被指標和遞迴洗禮過的人應該不會邏輯能力差吧？），程式員本身的韌性也夠。理解指標和遞迴的能力，與成為優秀程式員的能力有直接的關係。

所以，約耳覺得，在學校裡學Java、.NET這種高階語言，訓練出來的學生層次感不明顯，無法很立即能夠判斷哪些程式員是真的非常優秀非常聰明的。

Java和C#給程式員的幫助真的太多囉～它們就像是電腦一樣；而C/C++就像是紙張報表和筆。熟悉C/C++就會發現平常要想一天做半天的東西，用Java兩秒就解決了，而且還有很多容錯機制和回收機制，不用怕出錯。而使用過Java的人，要再回去寫C/C++…可能連字都不會寫吧。
我就快到了不會寫字的生活了。

ref:

[1] 狼．眼裡的世界 - 物件導向系列

[2] 深入淺出設計模式

[3] Program to an interface
[4] 約耳續談軟體

[Programming] 物件導向 (5) - 介面

什麼是介面 (interface) ？這個名詞有沒有很熟悉？還是覺得很陌生？還是覺得很熟悉常常聽到又不知道具體的意義是什麼？
我們常常在講的使用者介面 (user interface) 或人機互動 (human-machine interaction)，從維基百科上已有具體的文字定義[1]：

The user interface, in the industrial design field of human–machine interaction, is the space where interaction between humans and machines occurs. The goal of interaction between a human and a machine at the user interface is effective operation and control of the machine, and feedback from the machine which aids the operator in making operational decisions.

簡單來說，就是一個能夠有效控制機器，或是從機器裡得到回應的空間。廣義來說，作業系統、程序控制器、重機械控制器、汽車方向盤和計速器…等，都算是使用者介面。
我個人是將它想像成人和機器互動的中間那一層，而人可以從中間那一層去控制機器，機器會透過中間那層來傳達讓人知道的訊息。

那在物件導向程式設計裡，介面又代表什麼？
這裡所說的介面，並不是指「使用者點了什麼按鈕，然後程式就會執行什麼動作」的那種介面，這是被歸類在使用者介面的範圍裡，和OOP中的介面不一樣。
這裡所謂介面，指的是一種特別的抽象類別，裡面有一個（或一群）方法，讓不同物件實現這些方法的時候，能做不同的事。
這是不是聽起來很熟悉？現實出來的效果是不是有點像多型？沒錯～它是一種多型的實現方式（請參考三相之力[4]）。

定義講多了，就好像都在嘴炮理論一樣。我們來看一下實際的例子。
有一個類別圖如下。反正就是有一個系統設計者，丟了這樣的類別圖給你，要你做出一個interfaceAction的介面，然後讓Fighter和Archer這兩個類別可以實現它。

這就是介面的長相：

public interface interfaceAction {
    void Run();
    void Walk();
    void Jump();
    void Sit(); 
}

這是Java語法。其實C#、PHP等OO語言都差不多，而且這裡要注意的不是語言上的差異。
一個介面，這樣寫就算完成了。眼睛一看就會發現它沒有定義各個方法實際要做哪些事，就只是把方法名稱列出來而已，等其它類別來實現 (realize) 它。

然後如果有其它類別要使用這個介面的時候，它就會這樣去做：

public class Fighter implements interfaceAction {
    public Fighter(){
        System.out.println("Fighter Creation!");
    }

    @Override
    public void Run(){
        System.out.println("Fighter running...");
    }
    
    @Override
    public void Walk(){
        System.out.println("Fighter walking...");
    }
    
    @Override
    public void Jump(){
        System.out.println("Fighter jump once!");
    }

    @Override
    public void Sit(){
        System.out.println("Fighter sitting!");
    }
}

這段程式第一行比較要注意的是，在Java裡要完成一個介面時，中間要掛implements關鍵字，然後在後面加interface的名稱。假如程式很複雜，需要implemets兩個以上的interface，那就把interface名稱用逗點隔開就行了。
然後，這個實現interfaceAction的類別，要逐一實現interfaceAction裡的每一個動作，不然基本上編譯器不會給過。然而，每個要implements interfaceAction的類別，裡面的方法動作可以不一樣，多型就這麼實現了。
基本上使用上就是如此。如果有其它類別，比方說是Archer類別，要實現interfaceAction，就用同樣的方法來實現介面，並且在要把interfaceAction裡的方法也都寫過一次。

你可以把它想像成一個使用者介面（像是遙控器的按鈕和面板），上面每個哪裡有幾個按鈕或哪裡顯示東西都是固定好的，然後把它接到不同的機器元件上面之後，它的按鈕動作和顯示出來的東西就不一樣。OOP的介面只是把這種概念實現出來而已。


啊？你說每個動作都一樣，重寫一遍太麻煩？那就不要用interface啊！
我這樣講並不是不負責任的說法，不過這是設計上的問題，下次再說。你在這裡只要先知道：實現interface的元件，必須把所有interface裡的方法都實現出來。
也許你會在程式書上面看到「abstract和interface之間的比較」之類的章節[3]，我不打算在這裡提。因為abstract和interface之間雖然行為上有這麼一點相似，但是它們的概念卻是大大的不同。我認為，直接從這兩種東西的原始定義來看程式和用法，會容易理解許多。



ref:
[1] User interface from Wikipedia
[2] Interface (computing) from Wikipedia
[3] Java Gossip: 介面（interface）型態
[4] [Programming] 物件導向(3) - 三相之力

[嘆世間] 奴隸與責任制

有人說會寫作的人就有基本的影響力，所以我決定三不五時就寫一些內心的想法。
就從台灣的責任制開始吧！


從wikipedia上面所編輯出來的「責任制」來看，它是一種工作制度，允許員工在預期時間內完成公司所指派的工作或任務，而不受上下班打卡的時間限制。
制度的起意是好的。畢竟每個人的作息條件不一樣，有些人適合在晚上的時候工作，有些人相反，所以只要把工作指派給它，並交代完成時間，就不需要再太強制去要求員工的上下班時間，這種和工作內容沒有實際關係的事情上。

這種制度的發明，是基於資方的天地良心和勞資雙方對彼此的信任。相信所指派的工作內容和工作量是合理的、相信員工會用自己的責任心來完成事情…所以，如果勞資雙方其中一邊的天平傾斜了，事情會變得如何？
資方打著責任制的名號將大量的工作分配給少量的人力，使勞方無法在有限時間（正常上班時數）內完成自己的工作，必須加班才能把事情做完－可能還做不完。因為是責任制，所以資方不給額外的補助。
另一種情況是，勞方以沒有責任感的態度來執行責任制，以制於上班時間不穩定、預排好的會議因私人因素無法參與，使團隊裡應該協調討論的相關事項無法達到有效的溝通效果。
雙方都不信任彼此，就會開始進行這兩種天平加碼的拉鋸賽，最後什麼事情都沒辦法完成。

注意囉，再來就是台灣的現實面。

我愛台灣。台灣好山好水，物產豐饒，政府勤政愛民，人人知書達禮，而且是中華文化的繼承人。嗯....其實沒有這麼好，台灣還是有一些浮出水面的敗類，但是浪漫如我，我還是願意相信大部分的台灣人都這麼優秀，至於要戰兩岸嗎？來啊！幹。
總之，我愛台灣，所以我不願以看熱鬧的心情來詛咒台灣。但是身為台灣人，看到台灣的就業、社會現象，我得說一聲：幹你媽的！

在台灣，責任制已經是常態，但有良心的責任制卻是少得可怕。台灣的資方經常為了壓低人力成本，希望能夠利用把每個月付給員工的薪水發揮到最大效果，而分配給員工過多的工作、過長的工時，或是減少輪班班次等，讓員工事情永遠做不完，事情只會一天比一天多，一天比一天勞累。
我個人是做資訊業的，我就體驗過什麼叫「一輩子都奉獻給公司」的感覺。
當時在我出社會的第一間公司，主管是個資訊產業的大外行，又自以為了解軟體工程，認為管理流程是製作任何東西的一切，忽略了被流程包起來的技術方法，用錯誤的方法做事，花了一大堆時間在做虛工、重工和補那些補不完的破洞，然後一副學到東西的樣子，還要員工花自己的晚上的時間上課還是開會等。
不是我對它有什麼偏見。有哪個軟體資訊業的廠商，會把按鈕觸發的一切動作都寫在那個按鈕上的？有哪個軟體資訊業的廠商，在做報表的時候會把同一張報表畫個四、五次的？有哪個研發團隊會連自己要什麼都不知道就下去寫程式的？有哪個研發團隊不懂資料結構、演算法、設計模式…等技術的？我不是真的很懂，我想學，我想從實務中學習有用的技術，但是在這個研發團隊裡學不到，只會要你在有限時間內用複制貼上的方式把source code貼來貼去，之後有錯再來追進度來改。這些，全是資訊技術方法的問題，流程不管這個，但是對軟體廠商來說是個建國根基，偉哉主管不懂，也不管，只知道一些他想知道的，他可愛的研發團隊也不管，甚至我懷疑他們連我在寫什麼都不是很清楚。
所以我離開了。如果你是這間公司的員工，而且反對我的說法，麻煩，舉個實際的案例來說服我一下。如果只是想對我發脾氣的話就省省吧～就事論事，別扯其它的。
我相信還有很多從事軟體資訊業的先進大德們，也和我有同樣的感受。其實仔細觀察，就會發現這種現象不只充斥在資訊業而已，服務業、保全業、醫師....等各行各業，在現今的台灣社會裡都看得見，而且非常普遍。

普遍，不代表正常。所謂的正常的制度，應該是一種能讓公司、讓社會永續運作的制度流程。這種具有台灣特色的畸形責任制[2]，完完全全展現出華人短視近利的缺陷和不尊重員工的惡習，為求短時間的成本減少，而必須付出更多的成本來填補破洞。
最簡單的例子：把一個人弄累了、弄垮了、弄不爽了，使該員必須（或一定會）離開它的崗位，那麼，資方需要多少時間培養一個和他有相同技能，能夠完完全全取代他的人？這些時間，對資方來說都是成本。資方可能再繼續使用同樣的方式逼迫新人盡速上手，再一次的壓縮休息放鬆的時間，雞生蛋蛋生雞的哲學問題就又實現一樁了。
這種畸形的責任制，可不單純只是影響工作或某某產業而已，還會延伸到許多社會問題。

1. 家長在忙工作，沒空陪小孩、沒空教養小孩，小孩就容易孤單，容易學壞。
2. 家長習慣性地試著用錢來改善沒空陪家人的家庭關係，容易造成價值觀的偏差。
3. 工作量過多，家長帶著疲憊身體日復一日、年復一年，使人還在還有生產力的年紀，就已無法再工作。
4. ....

再更多的連帶關係，我這裡就不再多談了。早在好幾年前就已經有一大堆的文章曾經點出這些問題了，但是沒人理還是沒人理，也沒看到政府用什麼有威嚇力的方式壓制這種情況。

我只是個不學無術的傢伙，不敢說永續運作的制度應該如何推動，也不知道有哪些方案能夠推動。不過身為一個資訊業的小齒輪，還看過所謂的40工時，意即每週工作40小時，平均每天工作8小時，也就是從早上吃早餐的時間，做到吃晚餐的時間。讓人工作一天的壓力，能夠在吃完晚餐後得到放鬆、集中力得到休憩，做自己喜歡做的事，看書進修或看電視打電動等等。（有人會質疑打電動背後的意義，就算無法獲得個人能力上的進步，也能精神上的放鬆，那就有意義）
尤其是程式員，平常就都是在用大腦在工作的，每天沒有適度的休息和放鬆，怎麼能期待得到精神飽滿狀態下的生產力？為什麼台灣的老闆都想不透這一點？一個人沒吃飽沒睡好，身體還有病痛，能夠把工作做好嗎？這麼簡單的道理居然看不見？在過勞的精神狀況下工作，做出來的成果品質會有多好？多少人為疏失的起因都是源於精神疲累？
說到這裡，不要跟我鬼扯「有成就的人應該多花點時間在自我進修和成長上。」或是「愛你的工作就不會有壓力。」這種鳥事。媽的我以前老闆最喜歡講這種話了。
每個人休息的方式不一樣，有些人確實會用看書、玩未知的技術來作為休息，有些人會看電視喝酒打電動睡覺來紓壓，無論如何，它們的特點就是他們會得到放鬆。而老闆在要求自己的員工用進修來當作放鬆，當你叫你的員工進修時，對員工來說就是指令，那只會無止盡地延長工作時間，因為透過這種方式進修，並不會得到休息放鬆的效果。

因為我愛台灣（光這篇文我就重申了三次了），而且看到了這個問題會深深影響台灣的未來，所以想要把這種畸型的制度鏟除。
多麼異想天開的想法！一個寫程式的小工程師，怎麼改變這種幾近成為定局的大環境？老實說，具體的做法我還沒有想到。所以我認為，至少從自身做起，有原則地挑戰這種制度，並且宣揚這一套想法，讓台灣的勞工有尊嚴地做他們的工作、愛他們所做的事，就能夠一點一滴地蠶食掉這種詭異的觀念。說到這....我也不知道為什麼台灣上一代兩代的人們會認為做管理職就是升遷，一輩子做技術員就是沒出息，一個可以解決手上任何問題的技術員，為什麼會被視為比廢物主管垃圾經理還要沒價值？
我所謂有原則的挑戰制度，並不是真的用很強硬的方式跟主管講：「老子就是不加班，有本事你就來做我的事！」，也不是徹頭徹尾地去反對責任制。而是，每天該做多少事就做多少事，該做多少時間就做多少時間。有時候事情比較多，比較急，需要大家一起趕，或是需要幫其它同事cover一下什麼事，那當然也是沒有問題啊，但是那僅限於偶爾為之，不能他媽的每天都忙每天都趕，或是每天都在有多的事情要做，像是下班前半個小時說要做什麼事，明天一大早要看。他媽的我絕對會叫你去死，你不去死我就殺了你。

當我把這個念頭和我幾個我認為有企圖心的朋友們知道時，讓我在這麼冷的天氣裡又被淋了一頭冷水。
同學S是我一位強者同學（強者我同學真的不是我），在我找工作的時候他幫了我不少忙，也給我滿多的信心。問起我所能接受的工作時間的時候，一開口就說「不能再多一點嗎？一天12個小時？」，後來還補「我是社會化比較深入」「和不錯的工作夥伴共事還是不錯，多花一點時間沒什麼的。」之類的話。
學弟D是一位當兵接我業務的同學，我觀察他的心得是正義感也很強，是非分明。當我問他對現在台灣的責任制有什麼改善的方法時，他跟我回「移民，或是當公務員」。
What the ....咳。FUCK!!
為什麼大伙們都知道那是個問題，卻都還是接受它，或消極地逃避它？我知道改善這個問題不是容易的事，但是最重要的第一步，應該還是要先從勞工的觀念開始著手吧！告訴人們勞方不是奴隸，不應該奴性這麼重！我也知道一切嘴巴講都很容易做到很難，但是用時間、用行動來證明這套理論才能提供更多的生產力，不就能夠慢慢的改善這個環境了嗎？很難，我也知道要達到那種理想很難，但是如果不走出第一步，也就永遠停留在現在這個階段了咧！
讓我大受打擊的是…強烈的企圖心，強烈的正義感，在面對這件事情的時候居然這麼消極，居然如此被動。
難怪在台灣創業這麼容易，因為老闆的奴隸都不會想反抗。

---

看到這裡，還記得我寫這篇亂七八糟的動機嗎？
沒錯，就是為了影響力。約耳在他的管理經驗書[3]裡提到：

「平庸的程式員和優秀的程式員之間的差別，並不在他們會多少種語言，也不在於他們喜歡Python還是Java。重點是能夠和他人溝通自己的想法。優秀的程式員藉由說服他人而獲得影響力。」

「如果你有能力寫作，不論是在何處工作，很快就會發現自己會被要求寫規格文件。這意味著你已經發揮自己的影響力，還讓管理階層注意到你了。」

所以，我決定開始認真寫些有的沒的，來傳達我的理念和想法。
首先，就是這篇「奴隸與責任制」。

16世紀，葡萄牙人將西非的黑人渡到南美洲當奴隸。黑奴為了自由，為了持續自己的文化活動，發展出卡波耶拉(巴西戰舞)，作為對付葡萄牙人的武器[4]。500年前，幾乎什麼都沒有的黑人們，為了自由，有勇氣研究出這套徒手攻擊技能來對付葡萄牙人的火槍；500年後，地球的另一端，百姓富有、物產豐饒的21世紀台灣，存在著幾近奴隸制度的扭曲責任制，而且沒有人想反抗。
真的是這樣嗎？

接下來的詩篇，將由我們親手撰寫。究竟會是悲歌，或是凱旋之歌，取決於我們的一念之間。
站起來吧！

ref:
[1] 責任制 in wikipedia
[2] 責任制，阻礙國家進步
[3] 約耳續談軟體
[4] 卡波取拉 in wikipedia

[Programming] 物件導向(4) - 抽象

我們常常會對一種模糊不清的東西，以「抽象」來形容它。而在OOP裡，也有抽象的類別可以定義。正如「模糊不清」的形象，抽象類別本身並不能被實體化，而是需要被能夠實體化的類別繼承了以後，才能真正使用。抽象的概念不是指「模糊不清」的東西（模糊不清的東西是要怎麼寫成程式？），而是一種有範圍性的大方向，或是一種大種類的東西。

以下是範例，就和很多教科書一樣，只寫怎麼使用，感受不出它的威力。

public abstract class abstractPerson {
    protected String Name;
    protected boolean Sex;
    protected String Email;
    protected String Offer;
}

public class Engineer extends abstractPerson {
    private LinkedList Skills;
    public Engineer(){
        Name = "";
        Sex = true;
        Email = "";
        Offer = "";
        Skills = new LinkedList();
    }
}

上面那個例子，我設計"人"的抽象類別，然後讓"工程師"來繼承它，若我還有"行政作業員"或"財會小姐"之類的類別，也同樣可以透過這樣的方式繼承"人"。
其它例子....像是"財產"可以做成抽象類別，而"土地財產"、"建物財產"、"運輸設備"這些類別就可以繼承"財產"；
或是"棋子"可以做成抽象類別，"國王"、"皇后"、"主教"....各別做成繼承"棋子"的實體類別。

還有另一種思考的方向是.....抽象類別可以視為繼承它的實體類別的大種類，用白話文來說，可以講成"是一種 (is a kind of)"。像前面財產的例子，就可以翻譯成土地財產是一種財產、運輸設備也是一種財產…等。用這種方式來思考，是比較容易將抽象類別應用在系統設計上。

[Programming] 物件導向(3) - 三相之力

三相之力。(From 魯阿魯)

好吧，我承認我很宅。

---

三相之力是LOL裡三種不同類型的中等武器合成的高級武器。會用三相之力來當副標是其來有自的。物件導向程式設計的概念中，有三種強大的能力，算是當年程式設計中跨時代的發明，分別是封裝(Encapsulation)、繼承(inheritance)、多型(polymorphism)。


封裝
如果要以一句話概括封裝的話，應該可以這麼說：外部的程式不能直接去存取物件裡的成員，而是必須透過特定的public存取權限的成員來存取物件內容。如果沒有封裝的概念，物件的意義就變得不怎麼重要了，C語言的struct也做得到同樣的事。把原本散成一團的程式封裝成一個一個的物件，就是為了讓程式裡物件和物件之間的依賴性變小，也就是隅合度變低，讓程式碼不會像一團陽春麵一樣，抓一條麵就把整團揪結在一起的麵全抓出來。
這應該不難理解。試著想像一下，如果你的封裝特性做得確實，外部程式在存取物件的時候就能透過幾個特定的方法而已，而這個物件實際經過哪些動作，外部的程式根本不需要知道。這時候，如果有什麼地方要改，看是物件裡面的動作，或是外部程式要改，而不至於需要把整隻程式和所有動作全部改掉。
然而，封裝只是建構物件導向設計的第一步而已....


繼承
有的時候，或很多時候，你會發現你需要用到的物件和其它物件只差一點點東西而已，只要稍微將原有的物件加以改寫或加工就能滿足你的需求。這時候，你不需要從頭到尾重新建置一遍，只要建立一個新類別，然後繼承那個需要加工的物件，就可以開始加工新類別來滿足自己的需求，而且不用動到一分一毫原有的類別（要動到的話也是可以）。
假如今天B類別繼承了A類別，我們會稱A類別是B類別的父類別(superclass)、B類別是A類別的子類別(subclass)，此時，正如前述所說，B類別會擁有A類別的一切特徵，然後再看你要怎麼去寫B類別。
上述那使用繼承的案例，比較明顯的動機是重新使用(reuse)。事實上，繼承更強大的威力不只是reuse而已。透過繼承抽象類別，就能夠把不同的類別整合起來，產生一個更有彈性的架構。比方說，我有人、狗、貓三種類別，我就能夠把這三種類別相似的地方抽離出來，另外做出一個「動物」的抽象類別，並且讓人、狗、貓這三個類別繼承動物，之後，人狗貓這三種類別，同時也有動物的類別特性，之後在呼叫「動物」的時候，是能夠代入這三種類別的。幾乎所有設計模式(design patterns)都會用到繼承，而且都會用到抽象類別或介面的繼承。當我們日後介紹到抽象或設計模式的時候再詳細描述吧！
要注意的是，C++可以允許子類別繼承多個父類別，而Java和C#不行，詳細的原因不太清楚，只知道這種多重繼承會讓程式的複雜度提高很多，就算允許也不建議使用。


多型
簡單來說，它允許一個類別的同一個函數，在不同物件（被實體化的類別）裡做的事情不一樣，但是必須透過繼承才能達到這個目的。所以，先有繼承的概念，才能實現多型。
舉例：既然要繼承，當然必須有一個基層父類別A，還有繼承出來的子類別B和C。此時B和C就能夠透過override把原本A類別裡的方法a'，根據自己的需求做改寫。讓B和C各別的a'執行自己的動作。
後來在拜讀了搞笑談軟工裡所介紹的多型，才明白其原理：今天如果呼叫一個物件裡的函式，並不是由呼叫函式的那一端 (sender) 來決定呼叫到的行為，而是由接收端來解釋。當我們由物件D裡呼叫B和C的a'，執行的行為並不是由D來決定，而是由B和C來決定，所以，我們會在物件D裡得到B和C各別執行完a'的結果。




透過這三種概念，物件導向的發展空間開始擴大，設計出有彈性、可擴充、容易維護的軟體架構。
只要你會用的話。


ref:
[1] 思考物件導向(1)物件導向與封裝
[2] 搞笑談軟工

[Programming] 物件導向(2) - 名詞定義

自從在案子裡教了程式開發的教育訓練以後，就不斷在寫程式開發的文.....

---

有鑑於在物件導向程式設計裡，比起原先的基本程式開發的專有名詞還要再更多一點，而且根據地區性的不同還有不同的翻譯，為了避開這種語意上的混淆，我決定先整理一下物件導向程式設計裡會用到的專有名詞和其意義。

所謂的類別 (class)，就是像我們上一篇所提到的Student那樣，可以把它想像成一種自己設計的特殊變數型態。就像標準C語言中的int, char....這種型態的意義是一樣的；也可以把它想像成是一種建構物件的藍圖，程式能夠以這個藍圖，產生出物件和藍圖一模一樣的物件。很多時候類別都會包含一個建構子 (constructor) ，用來定義該類別被實體化後的初始狀態。

而物件 (object)，就是已經用new和該類別的建構子將類別實體化後產生出來的東東。

上面這張圖是我在做專案的程式開發教材時所畫的圖，版權沒有。

如上述的圖所示，當宣告一個Guy類別，變數名稱為joe的時候，只會先產生一個叫做joe的Guy類別參考，還沒有實體記憶體可以來存資料。等到經過new以後，才會在實體記憶體裡抓一塊空格出來讓程式存東西，然後把joe這個參考指到這塊記憶體裡，這個動作稱為實體化，抓出來這塊記憶體，就稱之為物件(object)，或稱之為實踐(instance)。
所以，物件是真的有實體的。就像現實生活中，眼睛看到的每個東西都算是物件，而它們都有實體，而不是抽象的概念。

現實生活中的各種物件都有它自己的動作 (operation)，或是被使用後產生什麼變化或結果。在物件導向程式設計裡，物件自發性的動作，我們稱之為方法 (method)，以C語言的概念來說，也有人稱它為函式 (function)。
像上一篇中Student類別裡的SexTransform()就是方法，做法是讓學生女變男或男變女。.....咳嗯，SexTransform(性轉換)嘛....自發性的動作...嗯。
總而言之，像鴨子會飛或是會呱呱叫，或是人會走路會跑步會跳會攻擊等等的，可以對該類別做成一個一個方法來使用，所製造出來的物件就不光只是個裝資料的容器而已，它還會動。不過有一點要注意的是，這些方法，因為是寫在類別裡面，所以是針對物件去做處理的方法，所以在還沒建一個實體之前，這些方法是不能用的。

當然，也是有一種類別或方法它是不用先把實體建構出來就可以呼叫方法的函式。這種東西，我們稱為靜態方法 (static method)。這種方法在一開始被呼叫後，就會把記憶體空一塊空間出來處理方法裡面要做的事，執行完了之後，空出來的記憶體不會被釋放掉，所以裡面的區域變數，狀態都會被存下來，不會不見。
所以，假如你的類別裡有一個靜態方法，然後程式在執行的過程用這個類別宣告了好幾個物件，這好幾個物件，都會共用同一個靜態方法，連方法裡的變數都是共用的。這個部分如果沒有掌握好，在debug的時候會把頭髮抓掉一半都不知道問題出在什麼地方。

有靜態方法，當然也有所謂的靜態類別 (static class)，原理上和靜態方法是類似的：就是呼叫完之後記憶體空間不會不見。它和一般類別不一樣的地方在於：它不能被實體化，裡面也不能包含實體方法。其實這種靜態類別，通常被用於定義整個系統都會去使用，或是共用的函式集，像是存取資料表的動作、設計模式中的獨體模式 (Singleton) ...等。

以下程式碼為靜態類別和靜態方法的例子，保證不能使用，但是大致上來說就是如此而已。

static class DB
{
    private static SqlConnection sqlConn;
    private static SqlCommand sqlComm;
    private static SqlTransaction sqlTrans;
    
    public static bool Open(){
        try {
            sqlConn = new SqlConnection("");
            sqlConn.Open();

            sqlComm = new SqlCommand();
            sqlComm.Connection = sqlConn;

            sqlTrans = sqlConn.BeginTransaction();
            sqlComm.Transaction = sqlTrans;

            return true;
        }
        catch{
            return false;
        }
    }

    public static bool Update(string strSQL) {
        try
        {
            sqlComm.CommandText = strSQL;
            sqlComm.ExecuteNonQuery();
            return true;
        }
        catch {
            Close(false);
            return false;
        }
    }

    public static void Close() {
        Close(true);
    }

    private static void Close(bool succeed) {
        if (succeed)
        {
            sqlTrans.Commit();
        }
        else {
            sqlTrans.Rollback();
        }
        sqlConn.Close();
    }
}

ref:
[1] 網站製作學習誌
[2] 程式設計筆記byChris

[Programming] 物件導向(1)

不妨仔細想想，為什麼要用OOP？使用OOP有什麼好處？沒有它難道就會死人嗎？

C語言以前是以程序導向的方式做資料的交換和運算，並沒有什麼模組化、結構化的概念在裡面（其實還是有struct可以用，但是功能不強）。日子久了，同一隻程式不斷被維護、修改，或是又再增加新的需求，只會讓程式變得越來越難懂，越來越難維護，時間久了程式就沒辦法再持續維護下去了，程式就壞掉了。
這種程式呈現出來的樣子，就很像把三百五十種水果一起放到果汁機裡面打成汁再喝下去，你沒辦法知道讓你拉肚子 (bug) 的原因是哪一種水果，或是哪些水果的組合。

而OOP，能夠較容易將現實生活中的一切把它mapping成程式物件，進而描述物件和物件之間的關係，使程式容易和現實業務背景相結合，如此一來，就程式撰寫、閱讀上比較能夠容易被理解。所以，物件不光只是一個可以裝有客製化變數類型的"容器"而已，還有很多更近一步的關係可以建立及使用，以達到提高可維護性和「one rule, one place」的目的。
簡單來說：物件導向程式設計，能夠讓程式較容易被理解，也容易將其模組化。

當然，一切都是以「能夠設計出適合的物件關係為前提」。

---

物件導向程式設計(Object-oriented programming, OOP)已經存在好長一段時間了，十多年前開始接觸VB的時候應該就有這種程式設計概念了，讓寫程式不光是用複雜（或不怎麼複雜）的程式指令來控制變數、計算和輸入輸出，更能讓現實生活中的實體概念直接對應到程式物件裡來，使程式更容易維護和撰寫。

要寫一個物件導向的程式其實沒有很難。就像在現實生活中，看得見的或看不見的實體，都可以把它想像成是一個個的物件，物件中有屬性，然後由外力來控制物件。寫該類程式也是如此。最基本的做法就是把要用程式表達出來的東西寫成類別(class)，然後在需要使用到它的時候再宣告成一個（或多個）物件(object)。
一個超級老掉牙的例子：一個學生的類別，要記錄該生的姓名、性別和成績。
這個例子我完全不知道性別和成績之間的關係，但是管它的，反正需求就是這樣開....

class Student{
 private String name;
 private boolean sex;
 private int grade;

 //Constructor
 public Student(String name, boolean sex, int grade){
  this.name = name;
  this.sex = sex;
  this.grade = grade;
 }

 public String getName(){ return name; }
 public int getGrade(){ return grade; }
 public void SexTransform(){ sex = !sex; }
}

這樣寫，Student就非常簡單、草率、無用地完成了(請不要問我一個學生幹嘛要SexTransform()方法，我只能說這很宅)。
然而，如果OO概念只能達到這種程度的功能，那它不會流傳數十年，至今仍被人大量使用（應該吧？）。


つづく......

ref:
[1] 搞笑談軟工

[未來日記] 謹此紀念一名勇士： 戰場馬克(7th.)

雖然你的髮型真的很醜，但是你是個真男人。

戰場馬克：讓我們重新自我介紹一下！我們是7th.，戰場馬克！
美神愛：同為7th.，美神愛。
Both：這就是我們的日記，交換日記！

夫妻倆的華麗登場。

馬克：吶～1st. 你相信愛的力量嗎？我的日記是為了保護愛，一直持續觀察著愛的love日記。
愛：我的日記是為了保護馬克，一直持續觀察著馬克的love日記。
Both：也就是說，所謂交換日記，就是將這兩個合起來的love love日記～(小花)

其實這畫面滿搞笑的XD

單挑來說，愛不是我妻的對手，我妻居然可以用匕首格擋飛刀....太作弊了吧！？於是兩人決定先徹退，讓後勤部隊把房子燒了。

讓我真正對這對夫妻留意的是....火燒房子之前，還把中間的受害路人救起來，拖出房子外，還加以療傷....應該是個寧願光明正大戰鬥也不願連累無關路人的熱血笨蛋吧？比起我妻那種可以隨便犧牲別人來換取一時的脫逃，夫妻倆相對來說可是善良多了。 

於是再兩人再重回火場，義無反顧地用背影回答.....

馬克：當然是做個了斷，那些傢伙的love根本不是愛！


同樣不是外掛仔2nd. 我妻由乃的對手。但是因為兩個人都願意以自身性命保護對方，所以還是外掛我妻還是在大火中被逆推推掉了。


這時候，1st. 廢雪也語出驚人地講出一句不該是由主角口中講出來的話.....
馬克：你為什麼不救你的女人？女人陷入危險的時候即使是火海也要跳進去！這才是男人！這是不關乎愛的原則問題啊！(怒)
廢雪：由乃說了，說我依賴她就行了....
馬克：你到底是有多差勁....
廢雪：我也沒辦法啊！我也知道我很差勁啊！可是.....我真的很弱啊......(泣)
馬克：...........(青筋) 去死吧！

劇情演到這裡，我就徹底對廢雪絕望了。就算他有神愛世人的溫柔，就算聽說他以後外掛開得比我妻還兇，我還是無法喜歡他。
更何況他是個只想到自己的安全，利用著喜歡自己的女人的人渣。


在那之後，廢雪和我妻雙雙住院。廢雪還在住院的時候得到哥德式炸彈妹的幫助，管他去死。
而馬克正利用從廢雪和我妻的未來日記得到他們的現況，並且用計把他們拐出來，再教訓一頓。而且，就在這時候，他們決定結婚了！

愛：這是怎麼回事？(陰沉)
馬克：啊？
愛：[馬克和神祕女人幽會還樂呵呵的聊著天]
馬克：蛤？ (汗)
愛：這女人是誰？(陰沉)
馬克：我哪知道啊......
愛：少裝傻，日記上寫得一清二楚
馬克：等等....那是....(汗)
愛：[馬克興高采烈的收下女人的禮物].....難以置信，我被拋棄了嗎....(闇)
馬克：我....我怎麼可能這麼做....我可是對愛妳...
愛：好過份！我那麼信任你，你說過會永遠愛我！Q口Q(哭)
馬克OS：這....這到底是怎麼回事.....我不可能會背叛愛的....
愛：[馬克看著收到的禮物心花怒放得下巴都要掉下來了]
愛：[馬克叫我出來說有話要談]....一定是要提分手！Q口Q
馬克：不可能啦！
愛：我被欺騙了嗎？Q▽Q.....(淚)
馬克：這絕對是誤會啦！
愛：[馬克把那個小盒子給了我　打開一看　裡面是一枚漂亮的戒指].........馬克...這是....?
馬克：啊.....那個～我想差不多是時候了...是有這個打算...
愛：馬克！O▽Q(飛撲) 果然馬克是我的darling！
馬克OS：去買戒指吧！(笑)

這一段我笑好久XD，而且好甜蜜啊～

劇情發展到這裡，簡單來說就是馬克看不爽廢雪的無能懦弱，決定用人質、未來日記、戰鬥來激發他。
又是一次戰鬥，馬克要求廢雪出來單挑，當然是被打臉，但是就氣魄上來說，是有長進一點。但是單挑到一半，這座塔就被爆破了.....



畫面回到馬克和愛邂逅的那一天.......
「我們很快就回來哦～在這邊乖乖等著哦～」

「我們很快就回來哦～在這邊乖乖等著哦～」
「我們很快就回來哦～在這邊乖乖等著哦～」
「 很快就回來 ～」
「 很快就回來 ～」
....
那是十四年前，愛被雙親拋棄的那天
愛：「.....差勁透頂！」(淚)
馬克：「這是好事啊～今天差勁透頂，就表示明天一定會比今天美好！對吧？」
那是十四年前，愛被馬克撿回孤兒院的那天（馬克也是孤兒）

那是高中剛入學時.......
馬克：「喂....為什麼跟著我啊？」
愛：「 為什麼.... 」
馬克：「 一年級的教室在樓下吧？ 」
愛：「 是.... 」
馬克：「 別跟著我了....趕緊學會自立吧！ 」
愛：「......」(垂頭, 不安)
馬克：「 .......啊啊～真拿你沒辦法 」
愛：「^__^」

來到櫻見塔，也是起點......
愛：「我....想在這裡舉行婚禮。馬克說的沒錯，馬克把我從差勁透頂的人生變得美好....」
愛：「我就喜歡這裡....」



那是，兩人為彼此立下誓言的那天
愛被同學以馬克的名字誘騙到廢工廠，被輪姦。等馬克急忙趕到現場的時候，一切正在進行式，於是，理智線斷裂、瞳孔放大....

馬克：「對不起.....」
馬克：「如果我在你身邊.....」
馬克：「妳就不會.....」
馬克：「怎麼會變成這樣.....」 (看著手上染血的蝴蝶刀)
馬克：「我已經完了....發生了這種事，已經無法挽回了.....」 (舉刀)
愛：「不要！」
愛：「不要啊.....馬克痛苦的時候我來保護你.....難過的時候我陪你一起哭......」
愛：「所以.....所以不要丟下我一個人......」
馬克：「.....我不會丟下妳的.....我會保護妳，直到世界的終結.......愛..」

那是，兩人發誓，永遠在一起的那一天。

未來日記動畫第17集在撥OP之前花了將近七分鐘的時候交待他們的過去。



回到爆破的場景，我也懶得多說明戰鬥的內容，反正就是.....
馬克的戰鬥能力比我妻更勝一籌，最後還是被用計婊掉了。
最後馬克被支開，我妻直接轉身割開愛的喉嚨。這時候，天花板崩塌，把廢雪、我妻、愛三人困住。
此時....我妻以重傷的愛為人質，要求自由之身的馬克把石頭挖開。
馬克：「等著我！愛！我馬上就救妳出去！我們不是要一起成為神，永遠在一起的嗎！不管發生什麼事我都要保護妳！」
愛：「不要....馬克....反正我都要死了....」
我妻：「不，這樣很好，繼續下去。這個女人是人質！」
廢雪：「夠了，由乃.....」
馬克：「這不是讓他住手的問題吧！1st！明明不弄髒自己的手，只會讓2nd保護你，還說什麼要人道的話，你說的話還真是不要臉啊！」
廢雪：「........」
馬克：「你在幹什麼！你給我在下面推一下啊！1st！」
廢雪：「但是....這不就正中由乃的下懷了嗎？」
馬克：「是誰在不斷保護你，殺死敵人，你只是想把髒活累活全推到2nd身上吧.....」
廢雪：「......」
馬克：「不行了.....喂！2nd！你也來幫忙！」
我妻：「少對我發號施令！」
馬克：「你也是一樣！說什麼要保護1st，卻任意地扭曲1st的想法，這根本不算是協助，這是自私！」
我妻：「你給我適可....」
馬克：「該適可而止的是你啊！你這臭小鬼！你認為我是受到威脅才做這些的嗎？不要小看我，我一開始就沒有打算要逃走！」
愛：「馬克，住手.....已經夠了，我馬上就要.....」
馬克：「就快要死了？跟我沒有關係！那種東西給老子滾一邊去！別把我們的愛跟你們的愛相提並論啊！」
撐開石頭之後，眾人發現馬克的腹部被銅管刺穿。
愛：「馬克.....」
馬克：「抱歉啊.....我也中槍了....」

馬克：「我....又沒有趕上呢....」
馬克：「成為神，兩人永遠在一起的計畫，失敗了呢。」
未來日記：馬克來救我了，果然還是馬克最好了。7th DEAD END。

馬克：「但是啊....這，也算是永遠吧。」




櫻見塔倒塌。



年紀越大，對這種東西越沒有抵抗力。
看第一次就流淚了，記錄這篇又流一次淚。