阿基里斯戰記-膝蓋露臉了

今天是傷後兩個月,術後五個星期,長石膏後三個星期. 距離上一次走路已經是35天前的事了!

出發

戀愛巴士的下一個目的地是-台北榮總. 今天要回去換短石膏,開心的是不用在看到直挺挺的那一根(勿想歪)了,怕的是再次碰到天殺的北北(請見:阿基里斯戰記-石膏 No Zoom Air II代). 反正不管怎樣,今天完又是一個新的開始!

診斷

跟馬醫生沒說到什麼話,整根包住他看不到也不能說什麼. 很怕他問我 "有沒有好一點?",這麼外行的話出自專業人士嘴裡,會覺得是故意問的. 在我前面一個女生發生機車車禍,去台大醫院照MRI診斷為後十字韌帶整個斷了,馬醫生觸診(醫龍 Orz)+看片子診斷為部份斷裂不用開刀,平平是一樣的片子,結果卻是大不同,果然還是要多跑幾家醫院比較客觀. 看那女生開心的走出診療室,為何我看完片子還是要被開刀(我心裡是這樣想的). Orz

拆石膏

進石膏室前,內心真是坎坷不安,深怕又遇到上次那個天殺的北北. "暗......爽",我看到的是另一個理小平頭的技師(我也不知該如何稱呼). 先跟他良性溝通一下,若要對我的腳做什麼動作請先通知,我一定盡力配合! 果然年紀相近比較好溝通,整個過程都是他一個口令我一個動作,順利地拆完長石膏(是有一點可怕,但完全不痛,跟扳腳比我已經算完全豁出去了!),看到我那不成腿形的右腿,實在不知如何形容,大概只有病友才會了解! 自己硬ㄍㄧㄥ著右腳踝,盡力讓它保持90',深怕一不小心就有人來助你一把我就鰓林老師. 其餘過程就跟上次差不多了! 樹脂石膏上到膝蓋下方,新台幣800+元.

走時,天殺北北突然出現在石膏室,只能說我今天真的走狗屎運! 兩人眼神對了一下,你不認識我,但我會記住這張臉一陣子吧! Orz

右腳

膝蓋已經五個星期未彎過了,整個腫,整個不順,整個無力,整個很難彎,已經不是我的膝蓋了! 這麼冷的天氣,我只能說慢慢來吧!

腿整個是萎縮狀態,更別說五個星期沒洗產生的皮屑了(一整個嘔爛),無力是一定的,僵硬更是一定要的,難過是一定有的,這就是人生! Orz

腳踝! 我只能說整個僵硬,接近90'就整個停住不動了! 若未來無法背曲5',就考慮去改判體位吧,但我還是希望能順利恢復,身體是一輩子的! 國防役只剩兩年!

接下來三個星期,就按醫生說的,沒事就走路. 走出心得再寫一篇"完拆前的復健(不是富堅)篇"好了!

這次的代價實在太大了! 持續著沒有腿的日子!

Wii新年

跟小老頭交換了 薩爾達-曙光公主 來玩,外加 GF 買給我的 銀河馬力歐 . 我這個 RPG + ACT 苦手的人,這個農歷年一定要把其中一片全破啊!

我覺得上大學之後,我買 Game 只為了收集而買 Game. 有印象全破的遊戲大概就 NBA 跟 第一神拳系列 吧~!!

原本是想買 任天堂明星大亂鬥 ,但看到水貨商價錢炒成這樣(2400+),我不想再忍痛入手啊! Wii Fit 到現在我還沒玩過! Orz

重構-Making Method Calls Simpler

(圖片來自: http://sourcemaking.com/)
以下為學習 Making Method Calls Simpler 的筆記.

Add Parameter

若方法需要呼叫方的資訊,就在方法介面加上參數,讓呼叫方傳入參數.

Encapsulate Downcast

方法若回傳需要轉型的結果,請在方法內直接轉型好再回傳.

優點: 其他使用到此方法的部份不用在做轉型.

Hide Method

若 public 方法沒有被其它 Class 使用,將 public 改成 private .

Introduce Parameter Object

若傳入的參數在概念上可群聚在一起,將這些參數包裝成一個新的物件.

/* 利用身高體重算出的 BMI 來決定是否健康. */
public boolean isHealthy(int height, int weight)
{
  int bmi = weight / (height * height);

  if (18 < bmi && bmi < 24)
  {
    return true;
  }
  else
  {
    return false;
  }
}

Class BodyMassIndex
{
  /* 建構子. */
  public BodyMassIndex(int height, int weight) // 兩個傳入參數.
  ...

  /* 回傳 BMI 的值.
   * 計算方式被封裝起來,可重覆利用. */
  public int getValue()
  {
    return (weight / (height * height));
  }
}

/* 利用 Parameter Object . */
public boolean isHealthy(BodyMassIndex bmi) // 簡化成一個物件.
{
  if (18 < bmi.getValue() && bmi.getValue() < 24)
  {
    return true;
  }
  else
  {
    return false;
  }
}

優點: 解決參數過多不易閱讀的問題. 若群聚參數產生的物件能提供一個合適的地方,以儲存跟參數有關的行為.

Parameterize Method

許多方法都在做類似的工作,差別只在於數值的不同. 合併成一個方法,並將不同的數值部份改成方法的傳入參數.

有點難解釋直接舉例:

/* 打九折. */
public int tenPercentageDiscount(int price)
{
}

/* 打八折. */
public int twentyPercentageDiscount(int price)
{
}

/* 合併成一個方法,折數由傳入參數來決定. */
public int dicount(int price, int percentage)
{
}

優點: 減少重覆的程式碼. 支援的方式也從原本需新增加方法(重覆程式碼)變成根據傳入參數來決定.

Preserve Whole Object

某個方法傳入的參數都是來自於同一個物件,再考慮過耦合度的情況下,直接將傳如參數改成該物件.

int height = jack.getHeight();
int weight = jack.getWeight();
int bmi = caculateBmi(height, weight);

/* 修改參數改成直接傳入 People 物件. */
int bmi = caculateBmi(jack);

/* 傳入參數由原本的兩個 int 改成 一個 People 物件. */
public int caculateBmi(People people) // 和 People 產生關聯.
{
  /* 只要 People 物件有的成員都可以使用,且不用修改傳入參數. */
  int height = people.getHeight();
  int weight = people.getWeight();
  ...
}

優點: 易閱讀. 彈性高.

缺點: 增加耦合度.

Remove Parameter

移除方法中沒用到的傳入參數.

優點: 表達出程式碼真正要傳達的訊息(無用的參數帶來造成誤會的訊息).

Remove Setting Method

一個只在建立物件時確定且以後不會再變化的成員變數,移除該成員變數的 setter().

優點: 表達該成員變數的真正意圖 - 建立後就不允許修改.

Rename Method

當方法名稱無法表示出其意圖時 - 重新命名.

優點: 好的命名帶來正確的意圖.

Replace Constructor with Factory Method

當產生物件時不單單只是單純的建構,而想要有更複雜的建構方式時 - 使用工廠方式.

Replace Error Code with Exception

使用 Exception 取代 Error Code.

優點: 易閱讀. Exception 將 問題程序 從 正常程序 分離出來.

Replace Exception with Test

Exception 該用在例外的行為上,不要用 Exception 來做條件判斷.

Replace Parameter with Explicit Methods

方法根據傳入的參數執行不同的區段 - 抽取出每個區段建立各自的方法.

Replace Parameter with Method

方法傳入的參數為本身可自行取得 - 移除參數,由該方法自行取得.

int percent = getPercent();
int finalPrice = discount(1000, percent);
...

public int discount(int price, int percent)
{
  ...
}

int finalPrice = discount(1000);
...

public int discount(int price) // 減少了傳入的參數數量.
{
  int percent = getPercent(); // 由 discount() 自己取得打折的折數.
  ...
}

優點: 減少傳入參數數目,增加閱讀性.

Separate Query from Modifier

若方法回傳數值並且修改本身物件的狀態 - 將其分成兩個方法: "查尋" 和 "修改".

優點: 避免不在預期內的 side effect .

重構-Simplifying Conditional Expressions

(圖片來自: http://sourcemaking.com/)
以下為學習 Simplifying Conditional Expressions 的筆記.

Consolidate Conditional Expression

看原文例子比較容易懂! 一系列條件測試且都回傳相同的值,可將其集中成同一個條件式,然後抽取成一個方法.

優點: 簡化程式碼.

Consolidate Duplicate Conditional Fragments

看原文例子比較容易懂! 每個條件測試之後,若有相同的程式碼片段(代表每個條件都會執行該段程式碼),將其搬出讓所有條件共用程式碼片段.

優點: 簡化程式碼.

Decompose Conditional

看原文例子比較容易懂! 當程式碼中有複雜的條件陳述區段時,將 條件判斷 和 條件判斷內的程式碼 各自抽取成新的方法.

優點: 簡化原本複雜的條件陳述區段.

Introduce Assertion

利用 Assert 來驗證程式內的假設是否正確.

優點: 驗證意想不到的錯誤.

Introduce Null Object

系統中常常出現 "判斷某個物件是否為 null 的判斷式",產生一個空物件來取代 null.

Class NullCompany extends Company
{
  /* 取得員工數目. */
  public int getStaffNumber()
  {
    return 0;
  }

  /* 取得公司住址. */
  public String getAddress()
  {
    return "";
  }
}

/* 若沒有空物件的寫法. */
int staffNumber;
if (rebarCompany = null)
{
  staffNumber = 0;
}
else
{
  staffNumber = rebarCompany.getStaffNumber();
}
...
String address;
if (rebarCompany = null)
{
  address = "";
}
else
{
  address = rebarCompany.getAddress();
}

/* 使用空物件的寫法.
* 若該公司被掏空,就會傳進一個 NullCompany .
* 這樣空物件跟一般物件都共用同一段程式碼. */
int staffNumber =
  rebarCompany.getStaffNumber(); // NullCompany 回傳0.
...
String address =
  rebarCompany.getAddress(); // NullCompany 回傳空字串.

優點: 處理為 null 時的預設行為,全部集中至空物件中. 簡化原本需要判斷並處理 Null 的區段.

Remove Control Flag

看例子比較容易懂! 當程式中有一個用來當做條件控制旗標的變數,用 break 或 return 來取代.

以下為原文範例: 囧rz

/* 是否跟崩潰有關,一找到就停止比對. */
bollean isFound = false; // Control Flag.
for (int i = 0; i < list.length; i++)
{
  if (isFound == false)
  {
    if (list[i].equals("魚翔拳"))
    {
      isFound = true;
    }
    else if (list[i].equal("蔡老頭"))
    {
      isFound = true;
    }
    else if (list[i].equal("五分埔"))
    {
      isFound = true;
    }
  }
}

/* 是否跟崩潰有關,一找到就停止比對. */
for (int i = 0; i < list.length; i++)
{
  if (list[i].equals("魚翔拳"))
  {
    break;
  }
  else if (list[i].equal("蔡老頭"))
  {
    break;
  }
  else if (list[i].equal("五分埔"))
  {
    break;
  }
}

優點: 簡化邏輯.

Replace Conditional with Polymorphism

條件判斷後的行為是根據物件的類型決定時,將其不同的行為抽出到各自的子類別(使用多型)當中.

/* 原本程式. */
String name = people.getName();
if (name.equal("AskaYang"))
{
  System.out.prinln("我只是喜歡唱歌!!(哭哭)");
}
else if (name.equal("YuXiangChuan"))
{
  System.out.println("嗚~(崩潰中)");
}
else if (name.equal("YangShinHsuan"))
{
  System.out.println("我有憂鬱症!(藥袋上看診時間:案發後一天)");
}

Class AskaYang extends People
{
  public String doSomethingWrong()
  {
    return "我只是喜歡唱歌!!(哭哭)";
  }
}

Class YuXianChuan extends People
{
  public String doSomethingWrong()
  {
    return "嗚~(崩潰中)";
  }
}

Class YangShinHsuan extends People
{
  public String doSomethingWrong()
  {
    return "我有憂鬱症!(藥袋上看診時間:案發後一天)";
  }
}

...

/* 修改後的程式.
* 根據傳入的 People 子類別的不同,印出不同的訊息. */
System.out.println(people.doSomethingWrong());

優點: 當程式中反覆使用相同的條件判斷時,利用多型將不同行為封裝至子類別,原本程式碼中的條件判斷 可改成 傳入不同子類別 來取代.

Replace Nested Conditional with Guard Clauses

當巢狀判斷迴圈無法清楚表示出執行路徑時,使用 Guard Cluse 取代所有其他情形.

• 當使用 if - else 架構時,代表 if 跟 else 內的程式片段一樣重要.
• 當使用 Guard Cluse 時,代表 "這是很少發生的事件,若發生請做處理然後跳出!"
• 一個方法只有一個入口,但不一定只有一個出口(一個 Return).

/* 又帥又有錢才能做我的男朋友. */
public boolean beMyBoyFriend(People boy)
{
  boolean result = false;
  if (boy.isPoor())
  {
    result = false;
  }
  else
  {
    if (boy.isUgly())
    {
      result = false;
    }
    else
    {
      result = true;
    }
  }
  return result;
}

/* 使用 Guard Cluse. */
public boolean beMyBoyFreind(People boy)
{
  if (boy.isPoor()) // Guard Cluse.
  {
    return false;
  }
 
  if (boy.isUgly) // Guard Cluse
  {
    return false;
  }

  return true;
}

優點: 增加閱讀性.

延伸閱讀: XD
壓力大到變狼人？ 楊士萱公開道歉認錯 坦承伸鹹豬手
楊宗緯坦承年齡造假灑淚別星光
余祥銓(維基百科)

誰不想做隻傭懶的貓?

天氣變冷了! 家裡有隻貓整天睡! 睡整天!

但只要她的主人準備開睡,她就活了! 一下要睡我身上,一下要鑽到 GF 被子裡睡. 不鳥她便開始找東西亂抓發出怪聲!

只能說..

圓圓! 妳是貓? 還是人?

久未發的圓圓文再現!!

重構-Organizing Data

(圖片來自: http://sourcemaking.com/)
以下為學習 Organizing Data 的筆記.

Change Bidirectional Association to Unidirectional

兩個 Class 之間有一個雙向的關聯,但其中一個 Class 並無使用到另一個 Class . 將其雙向關聯改成單向關聯.

優點: 降低維護時遭遇的複雜度/耦合度.

Change Reference to Value

如果 Reference Object 很小,很難管理,是不可變性(Immutable)的. 可以把它轉成 Value Object.

以 Java 的 String 來解釋 書中這段解釋不可變性的句子:

you need to replace the existing String object with a new String object rather than changing the content on an exisiting String object.

String msg = "Hi!";
msg.concat("Jack!"); // 直接修改原本的 String .
System.out.print(msg); // 印出"Hi!".

msg = msg.concat("Jack!"); // 用新的 String 取代.
System.out.print(msg); // 印出"Hi!Jack!".

Value Object:

• 最好是不可變性的.  如果是可變性的,得保證修改某個 Value Object ,其它所有代表同一事物的 Value Object 也得被修改,此時還不如使用 Refernce Object(大家都指向同一個物件位址).
• 在分散或同步的環境下是很有用的.

範例解釋:

修改前: Currency Class 利用類似 Factory Method Pattern 回傳合適的 Currency ,整個系統只會有一個 Currency 代表 Currency("USD").

因為 Currency 自身維護系統內所有的 Currency 物件,為此將建構子設為 private. -> 造成使用上的不便!? 所以改成 Value Object !? Orz

修改後: 整個系統能有多個 Currency 代表 Currency("USD").

Change Unidirectional Association to Bidirectional

兩個 Class 之間需要使用彼此的功能,但只有單方向的關聯時,加上 Back Pointer ,然後改寫管理兩邊關聯性的方法,使其方法同步修改兩個 Class 彼此間的關聯.

Change Value to Reference

當你有一個 Class ,它有很多相同的實體,而你想要簡化成單一實體時,將 Value Object 轉成 Refernce Object.

• Reference Object 就像是客戶/帳號. 每一個 Reference Object 都代表一個存在於真實世界的物件,你必須透過物件身份(Call by Reference)去比對是否相等. ex: 同一家銀行不可能兩個人擁有同一組帳號.
• Value Object 就像是日期/金錢. 它們完全是根據數量來定義. 你完全不用在意有多少個備份存在於系統. 你不用藉由比對 兩個物件是否一樣(同一個物件) 來確定兩物件是否相同,而只需要覆寫 equal() 和 hashCode(),比對兩物間中你想比對的值(成員變數...). ex: 你可以有一張100元,別人也可以有一張100元,不會有兩個人指向同一張100元.
• 並不總是很明顯能判斷何時用 Reference / Value .

Duplicate Observed Data

GUI 流程中會產生資料物件的概念,有需要一些跟存取資料相關的方法. 產生一個物件去保存資料,利用 Observer Pattern 來同步 GUI 層/資料層 這兩份資料.

優點: 簡化 UI 的程式碼. 將邏輯和 UI 分開.

Encapsulate Collection

若方法直接回傳 Collection(ex: ArrayList, Set ...),改成回傳不允許修改的 Collection(ex: unmodifiableCollection ...) 並提供 add/remove 的方法.

List friendList = alex.getFriends(); // 回傳整個 List.
friendList = new ArrayList(); // Alex 的朋友清單被別人整個置換而不自知. 在複雜的系統內,這會是一個很難找的的 Bug.

優點: 隱藏資料集合的實作細節. 管理資料集合的操作集中在原本擁有者身上.

Encapsulate Field

將 public 欄位改成 private 欄位,並提供存取方法. Orz -很基本

Organizing Data

Page not Found

Replace Array with Object

幹! 這篇應該要 mail 給我前輩啊!!!

當你有一個陣列,裡頭的元素代表不同的事物時,將 陣列 轉成 物件,陣列內的元素 轉成 物件內的欄位(成員變數).

當你發現你說出 "串列中第三個元素裝的是員工的家庭成員陣列..." 類似的話,相信我! 你應該是在找死! RD 的腦不應該是在裝這些細節啊~!!

優點: 讓 RD 的腦少裝點沒用的東西.

Replace Data Value with Object

Class 內含有一個需要額外行為或其它資料的資料項目時,將其資料項目抽出建立新的物件.

優點: 將責任分散,每個物件只專注在自己該負責的事物上.

Replace Magic Number with Symbolic Constant

程式碼中不要有魔術數字,用常數來替換它.

Replace Record with Data Class

請參考 Replace Array(算是 Record 的一種形式) with Data Object .

Replace Subclass with Fields

子類別間的差異只在於回傳不同資料答案的方法,此時將該方法移至父類別,並刪除衍生的子類別.

• 有 "行為" 不同於父類別 -> 建立子類別
• 有 "特性(欄位)" 不同於父類別 -> 不需建立子類別,在父類別利用 Map 來動態儲存變動的特性. 如此就不用維護一堆看起來沒什麼差異的子類別.

Replace Type Code with Class

類別內含有不影響其行為的 Type Code (ex: off = 0, on = 1 ...),產生一個新的 Class 去紀錄這些 Type Code .

優點: 將 Type Code 放置更合適的地方. Type Code 實際對應的值被隱藏起來.

Replace Type Code with State/Strategy

有會影響其行為的 Type Code 而沒有使用子類別,使用 State Pattern / Strategy Pattern 建立對應 Type Code 的子類別.

Replace Type Code with Subclasses

有會影響其行為的 Type Code(Immutable) 而沒有使用子類別,建立對應 Type Code 的子類別.

Self Encapsulate Field

直接存取成員變數 vs 間接存取成員變數

延伸閱讀: http://www.blogjava.net/ivanwan/category/2732.html?Show=All

重構-Moving Features Between Objects

(圖片來自: http://sourcemaking.com/)
以下為學習 Moving Features Between Objects 的筆記.

Extract Class

當一個 Class 負責它不該處理的事時,建立一個新的 Class,將不該處理的變數和方法搬移到新的 Class 中.

優點: 符合 OO. 一個類別只專注在一個事物上.

Hide Delegate

建議參考原文圖7.1,類似 Facade Pattern ,客戶端(最上面層次)透過主機端(中間層次)提供的方法來使用 Delegate 物件. 如此,客戶端將不知道到 Delegate 物件的存在以減少關聯性.

/* 若未使用 Hide Delegate ,在 Client 端的程式碼會常出現如下的狀況. */
Server server = new Server();
server.getDelegate().getMethod(); // 火車頭現象.若換物件去實作,此處要修改.
// server.getMethod(); // Hide delegate. 實作物件被隱藏.

優點: Class 的關聯越少,之後的修改所需的變動越少. 變動被主機端(中間層次)隔絕.

Inline Class

剛好跟 Extract Class 相反. 當你覺得 Class A 做的事不太太多時,將 Class B 整合進來然後刪除 Class B.

Introduce Foreign Method

當你想加入新的方法(這方法常常要被用到)到 Server Class 中,但該 Server Class 不允許修改(ex: Date, String)時. 此時在 Client Class 加上一個以 Server Class 為參數的方法達成目的.

若你發現你產生了多個 Foreign Method ,請改用 Introduce Local Extension .

Foreign Method 其實算是以能先編碼為導向的,最好的方法還是想辦法修改 Server Class ,將合適的方法放到合適的地方.

優點: 可重覆使用原本 Class 未提供的功能.

Introduce Local Extension

當你想加入新的方法(這方法常常要被用到)到 Server Class 中,但該 Server Class 不允許修改(ex: Date, String)時. 利用 繼承/Wrapper 產生新的 Class 來加入新的方法.

最好是只加入新的方法,而不要覆蓋原本的方法(容易造成混淆).

優點: 在不修改原 Class 下,擴充新的能力.

Move Field

Class A 的成員變數被 Class B 用的次數多於 Class A ,將此成員變數移至 Class B .

Move Method

Class A 的方法被 Class B 用的次數多於 Class A ,在 Class B 中建立相同的方法,然後將 Class A 中的方法移除 或 Delegate 至 Class B .

Moving Features Between Objects

Page not Found

Remove Middle Man

剛好跟 Hide Delegate 相反. 當 Server Class 需要提供太多方法讓 Client Class 去使用 Delegate Class ,何不直接讓 Client Class 直接去存取 Delegate Class .

重構-Composing Methods

(圖片來自: http://sourcemaking.com/)
以下為學習 Composing Methods 的筆記.

Extract Method

將程式碼抽出,放在方法名稱能解釋其程式碼作用的方法內.

優點: 增加閱讀性. 可重新使用被抽取出的程式碼.

Inline Method

將 A 方法的內容移至呼叫 A 方法的 B 方法中,讓方法內容跟方法名稱能門當戶對. 有時方法內容已經夠簡短清楚了! 就不需要使用 Extract Method!

優點: 減少過度傳遞的呼叫流程,增加閱讀性.

Inline Temp

將所有參考用表示式取代.

優點: 減少不必要的程序碼行數.

Introduce Explaining Variable

利用 變數名稱 或 方法名稱 來解釋並取代陳述式(ex: 落落長的條件判斷式).

優點: 增加閱讀性.

Remove Assignments to Parameters

在方法中,建立一個暫時變數來取代傳入的參數.

千萬不要重新指派傳入的參數,尤其是 Call by Reference 的情況下.

優點: 一個變數不會負擔額外的責任. 避免不小心指派傳入的物件參數.

Replace Method with Method Object

當無法套用 Extract Method 時,可考慮將方法改寫成一個方法物件,所有的變數都變成該方法的成員變數,而原本方法中的程式碼也會變成該方法物件的一個方法,此時再繼續套用 Extract Method .

優點: 封裝實作細節至獨立的物件中.

Replace Temp with Query

若一個暫時變數(Temp)存放著陳述式計算的結果. 將陳述式抽出至一個方法(Ouery),將原本使用該暫時變數的地方改成使用新產生的方法.

優點: 計算實作的方法被封裝在方法當中. 其它地方可重新使用新產生的方法.

Split Temporary Variable

利用同一個暫時變數,不斷去存放不同運算取的結果. 這種情況下,最好是為每一個運算結果產生各自的暫時變數.

優點: 避免混淆. 一個變數只代表一個意義.

Substitute Algorithm

當找到比較簡單的演算法(程式碼),將其替換比較困難的版本.

優點: 越簡單看懂,越簡單維護.

入戲過深

這篇笑點很低! 請搭配後面文字使用,要不一定看不懂!

我跟我 GF 最近迷上緯來日本台正在撥的醫龍. 每天都看到熱血沸騰! 久久不能自己! 於是..

至於我手幹麻一直舉著? 基於無圖無真相的簡單道理,請賞圖.

因為劇情是在述說醫院的故事,所以每集都有大量的開刀劇情. 當準備要開始手術前,就會看到主角群雙手抬得高高的,一個一個走入開刀房. 主刀醫生: 朝田龍太郎,第一助手: 加藤 晶,第二助手: 伊集院登...

越看越熱血! 雙手就忍不住跟著巴提斯塔小組一起抬起來了啊!! \(- ..  -)/

最後放張醫龍二的圖! 好熱血啊! 醫龍二第一集就三檯刀啊! 我快受不了了!!

四十個讓專案慘死的理由

剛發現這篇被貼上去了! 先聲明! 這篇只是學習筆記! 大家請看原文不要被我爛英文誤導! 原文寫的不賴,會接觸到 "專案" 人看到,應該會點頭如搗蒜! 此篇為方便本人有需要看的導讀文! 非翻譯文!

基本上,我是因為看到 一網打盡軟體開發的設計模式、錯誤模式、重構 這篇推推王的介紹才知道這個網頁,我只能說這是我最愛的菜啊!

資訊很多的壞處就是:

• 很難一次吸收!
• 要用時找不到!
• 吸收完又還給它!

所以為幫助自己學習,就只好邊看邊寫,寫些無聊的話語加強記憶了! 原則上有看就寫,先看個大概(快速掃描),日後碰到可先看此篇找到繼續看下去的入口(資訊太多的下場 Orz). 今天先看 Antipatterns 這部份:

整篇看完,發現大部份的議題著重在政治面上,再來是設計,幾乎沒有編碼技巧的部份.

Reinvent the Wheel

不要重新造輪子!

Death by Planning

不要過度設計!

Intellectual Violence

因為專業知識造成的誤解. 可靠團體內知識分享的會議來解除.

Design by Committee

什麼都要靠開會決定!

The Feud

人際關係! 解法: Pizza Party Orz

Throw It over the Wall

知識傳達的正確性.

Irrational Management

不當的管理(這應該是很多人的痛)!

Spaghetti Code

一堆爛到不行的程式碼,連寫的人都看不懂. 解法: 重構,寫之前先動腦...

Cover Your Assets

一堆沒有做出決定的文件.

Fear of Success

專案快結束了卻開始害怕東害怕西!

Viewgraph Engineering

做不完的圖表報告!

Project Mismanagement

直接翻譯: 專案的不當管理. Orz

The Blob

一個 Class 負擔了太多的責任,裡頭包含了大量的程序,看起來像是 procedural-style .

這讓我想起最近改寫的惡夢 - 一個 OK 按鈕下去就是 500 行以上的爛扣!

解法: 把責任分散出去.

1. 根據設計合約來檢查屬性和方法,將其移至合適的地方.
2. 生命會自己找到出口(原文也很玄,原諒我用這種不負責任的翻譯方法!). 將它放到它該住的地方. 狗身上不會有狗的鼻子,看不出來,你就不是個夠格的 RD!
3. 移除關聯性太弱的連結.
4. 移除弱連結,加上合理的新連結. 有點像公司的組織,董事長不會跟每個人都有聯結,一定是他管理你的老闆,你的老闆再管理你. 此例中,就是移除董事長身上跟所有基層員工的連結(因為這不合理),然後每個中頭目跟小頭目上加入他所管理的成員.
5. 將可抽取的行為搬出來(Strategy Pattern).

Continuous Obsolescence

使用的語言,函式庫...不斷地改版.

Lava Flow

時間一拉長造成的問題:

• 程式碼越來越龐大.
• 逐漸失去正確性的註解.
• 專案成員的替舊換新.

總歸一句, "專案依舊,人事全非".

Ambiguous Viewpoint

恕小弟無知,我看不懂!

Functional Decomposition

自以為用 Java 就是在寫物件導向的程式.

Poltergeists

"我不知道這個 Class 做啥的,但我知道不能刪掉它!" - 工程師 菜先生(28)

Boat Anchor

做一個沒有市場(或自以為有市場)的產品!

Golden Hammer

黃金鎚! Orz

Dead End

修改了一個原本廠商已經沒有在維護的可重用元件,之後維護的工作就落在自己身上.

Input Kludge

沒有針對使用者的輸入做合理的處理.

Walking through a Minefield

Bug 無所不在!

Cut-and-Paste Programming

CP 大法!

Mushroom Management

管理方式導致 程式設計師 跟 使用者 想法上的差距.

Autogenerated Stovepipe

軟體改版成分散式架構所遭遇到的問題.

Stovepipe Enterprise

一個企業應用程式下,分成各自獨立的多個系統,造成後續開發或維護需要付出更多的成本.

Stovepipe System

一整個就是廢的系統!

Jumble

垂直式的設計方式和水平(層級)式的設計方式不適當的混用,造成架構上的混亂及很難重新使用寫好的程式碼.

Vendor Lock-In

專案依賴第三廠商開發的軟體,該軟體的改變有造成整個專案實作需要修改.

解法: 在程式架構中加入一個新的中間層次,將抽象概念和實作概念切割開來.

Wolf Ticket

產品宣稱符合了新的標準. 但實際上,與其說符合新標準替使用者帶來好處,不如說是廠商為了增加品牌可見度而開發了該產品.

Architecture by Implication

做過類似的專案,而輕乎了現在手頭上類似的案子.

Warm Bodies

20個 RD 開發一個專案的效率 != 20 * (1個 RD 開發一個專案的效率)

Swiss Army Knife

一支包山包海能上天能遁地的 Class.

The Grand Old Duke of York

編碼員 vs 系統架構師

Blowhard Jamboree

太多自以為內行的專家,討論或散佈不一定正確的資訊.

Analysis Paralysis

過多為了追求完美的設計或行為.

Corncob

組織內的麻煩人物.

Smoke and Mirrors

一開始行銷或承諾畫了一塊大餅,在不可能達成的時限內,使用者往往只是拿到一個殘缺不全的四不像.

E-mail Is Dangerous

E-Mail 在某些狀況下不是個好的工具.

Fire Drill

管理階層花了大半的時間在規劃,壓縮到編碼及測試的時間.

不要亂幫別人畫大餅

(圖片轉自: http://big5.soundofhope.org/news_images/2007/1/6/pizza-hut-pizza-ss.jpg)
剛改完一個客戶臨時提出的需求,腦袋放空掃瞄一下自己的 MSN 清單,發現公司友人的名稱上丟出 沒說出來的話不要亂猜 這篇連結,看完真的感觸良多!

以下引述自原文:

有很多人曾經跟我抱怨某某公司的某某人很爛，事情也不明講，搞得我們必須猜測他的需要而做東做西，連帶幫他蒐集資訊兼打雜，結果，還是沒有接到訂單。上述情況也許真的是客戶希望引誘你投入資源幫他們做事情，然後坐收漁翁之利。但是，客戶沒有說的事情，我們自己去瞎猜去做，然後又覺得委屈被騙，這能怪誰呢？

說真的! 我是個有工程師個性的人! 眼裡容不下半個 Bug!

使用流程太長! 改短!
介面很醜! 找看看別的元件來用!
圖片不好看! 自己畫!
顏色不好看! 買書自己調!
看到沒被發現的 Bug! 開始改!

醒醒吧! 做出不在需求內的事是沒有幫助的!

沒有加薪!
突顯不出自身的價值!
可以動就好了!
猜錯被要求改回來!

除了滿足自己小小的成就感以外,其實看起來是百害無一利!

Work Smart != Work Hard

接到工作,先好好想清楚,哪些是老闆要你做的,哪些是老闆在乎的. 避免去做些自爽性的額外工作,用最少的力氣完成效益最大的事! 人家又沒要你做,自己何苦那麼賤.

PS: 這篇是寫給看自爽的我看的. Orz

Google Data APIs 筆記-取得並使用GData

根據 Requesting and using JSON feeds . 使用查詢的方式,將取回的回應透過 alt=json-in-script 包裝成 JSON in a script tag,然後使用 callback=functionName 來呼叫 JavaScript 函式.

http://www.google.com/calendar/feeds/developer-calendar@google.com/public/full?alt=json-in-script&callback=myFunction

下面改寫網頁上的例子,從 Feed 中讀取所有 Entry,寫出所有文章標題並帶有連結.

<script>
/* 印出訊息. */
function write(inMsg)
{ document.write(inMsg); }
</script>

<script>
/* 印出所有文章並帶有連結. */
function listEntries(root)
{
  var feed = root.feed;
  var entries = feed.entry || [];

  for (var i = 0; i < entries.length; ++i)
  {
    var entry = entries[i];
    var title = entry.title.$t;
    var link = entry.link[0].href;
    write('<a href="' + link + '" target="_blank">' + title + '</a>');
    write('<br>');
  }
}
</script>

<script src="http://blogger名稱.blogspot.com/feeds/posts/default?alt=json-in-script&callback=listEntries">
</script>

套用至 Blogger 效果如下:

至於如何看出資料結構,我是先參考 GData JavaScript Client 1.1,另外直接在瀏覽器打入 "http://blogger的名稱.blogspot.com/feeds/posts/default?alt=json-in-script" ,看實際格式來輔助我判斷資料結構!

延伸閱讀: 其它在 Google 上的範例.

待看: Blogger Data API>Developer's Guide: JavaScript

前輩你在想什麼?

原文為 The Mind of a Programmer ,以下為自己看完的心得. 標題會這樣寫,是因為作者另一篇文裡的引語: "Smart people are not meant to be programmers. " . 我覺得我前輩實在是太聰明了! 我難以望其項背! 故以此標題緬懷他! Orz

解決問題總有不只一種以上的方法,更別題寫程式來解問題了! 原文中以判斷奇數/偶數來做例子.

// if divisible by 2 then is even else is odd boolean
isEven = number % 2 == 0; // 直接使用數學運算.

// if last bit is 0 then is even else is odd boolean
isEven = (number & 1) == 0; // 使用位元運算.

對我來說,第一種方法會有比較好的閱讀性. 使用第二種方法的考量可能在效率,或者是你就是作者所說的天生好手(natural born programmers).

不過若是以效率做考量的話,根據 Code Complete 給的建議:

1. 任何的最佳化,一定要經過實際測量才能確定其效率,要不然都是 "紙上效率" .
2. 以閱讀性為優先. 真的有必要修改,效率待經過(1)的測試,並且補上完整的註解,才是比較好的作法.

至於在使用這些資工課程上學到的 Common Pattern,我會比較傾向將敘述封裝至一個方法當中,而不是到處都可以看到此敘述的寫法.

public boolean isEven(number)
{
return (number & 1) == 0; // 使用位元運算.
}

把不必要曝露出來的實作細節集中並封裝到 isEven 方法.

延伸閱讀: KISS principle ("Keep It Simple, Stupid").

Anchoring

以下(改成自己看得懂的格式)轉自 http://blog.cnyes.com/My/YesFX/Content.htm?DocumentId=27572

定錨效應(anchoring)

先決條件: 市場走勢包含恐懼才會有這種現象. 恐懼要發生,不但要有重大利空(讓市場氣氛和輿論一致悲觀),還要產生夠快的跌勢(怎麼我最近有此感覺 Orz). 人們最難執行停損的情勢就是現買立刻大賠.

解釋: 投資人在衡量自己損益時,往往不是根據客觀的平均成本. 把印象最鮮明(最近的那筆交易)當作成本. 以此當作後續所有盈虧的感覺基礎(想想! 當你加碼後如果套牢,或者作差價後重新買進若再跌. 是不是就會浮現"等回本再平掉"的想法??). 因此,在找尋損益兩平點時,只需要考慮最後一個波段轉折即可.

若印度跌破停損就打算砍掉重練了! Orz

能源,好掙扎! 再看看吧! Orz

Prospect Theory

以下(有重新修改成自己看的懂的編排)轉自 http://yesfx-global-invest.blogspot.com/2008/01/prospect-theory.html ,寫給自己看的,邊看邊寫大腦比較容易吸收. 以下純屬筆記非教學文!!

前景理論有以下三個基本原理：

1. 大多數人在面臨獲得的時候是風險規避的(恐懼).
2. 大多數人在面臨損失的時候是風險偏愛的(貪婪).
3. 人們對損失比對獲得更敏感.

測試自己的小測驗:

問題1
A是肯定贏1000元,B是50%可能性贏2000元,50%可能性什麼也得不到. 你會選擇哪一個呢?

問題2
A是你肯定損失1000元,B是50％可能性你損失2000元,50％可能性你什麼都不損失. 你會選擇哪一個呢?

請先做答再看答案!!

問題1考驗你面對獲利時的心理. 選A是風險規避(賺到就跑). 選B是風險偏愛(等它繼續漲).

問題2考驗你面對損失時的心理. 選A是風險規避(認賠殺出). 選B是風險偏愛(怕自己賣在低點).

AA: 0

AB: -1000 or 1000

BA: 1000 or -1000

BB: 0 or 2000 or -2000 or 0

結論

找出市場上的損益兩平點,接近損益兩平點便進入盤整盤,由此點出發的走勢速度或斜率應該是最快的(廢言 Orz).

第一神拳勝利之魂 Normal 難度全破心得

前言

本身算是第一神拳系列的粉絲,當初只是因為不知道要收什麼漫畫(想收的都收了),勉強開始買的漫畫,現在已經收到81集了! 現在就算想停也沒有回頭路了! Orz

在收這片 PSP 版本之前,玩過 PS2 版本的第一神拳和 XBOX 360 的暗黑格鬥3,之前 Wii 版本的第一神拳聽說操作性不如想像中的體感,所以我就跳過了! Orz

這次 PSP 版本,我只有玩故事模式難度 Normal 全破,所以我沒說到的要素不代表沒有啊! 有興趣的自己去買一片來玩! Orz

畫面

這次的劇情從第1集打到第81集,每場戰鬥間都會穿插一段 AVG 式的漫畫走馬燈,裡頭的畫面都是從漫畫中截取的,嫌煩的人可以直接按 START 跳掉.

接著就會進入選手進場畫面,這次比之前 PS2 版本(印象中)進步許多,每場戰鬥都會仿造漫畫內容有不同的動畫,比如第一神拳史上最黑暗的戰鬥-澤村龍平 vs 間柴了,動畫最後雙方還會在擂台中間互瞪,看到這一幕真的會想拿起漫畫復習一下! Orz

戰鬥畫面就跟我印象中 PS2 的版本差不多! 不過 PSP 版本有些小地方會讓我覺得製作小組還蠻仔細的,有時選手被打爆就會吐血(以前 PS2 版本好像沒吐血),再慘一點連牙套都會吐到地上. 打到後面,人的臉上也會有瘀青. 讓我最小吃驚的應該是幕之內 vs 快速星-牙木 那一戰,打到一半牙木綁馬尾的布會掉,瞬間披頭散髮(又想去翻漫畫了).

音效

劇情畫面完全無語音,就只有圖片跟文字.

比賽中,進場會有主持人的介紹選手語音. 擊倒時也有那個萬年不變的 "One~ Two~ Three~ ...". 連我GF都會學了,就知道有多麼萬年不變. 場邊的觀眾在某些情形下,會開始鼓噪喊口號,但好像沒有後樂園的 "LALLAPALLOOZA". Orz

遊戲中的音樂我覺得還蠻熱血的,當你控制的選手快不行的時候還會突然換緊張的音樂,一聽到就知道自己又快仆街了. Orz

遊戲性

這次劇情含蓋至第81集,不過我玩 Normal 模式並沒有碰到Randy.Boy.Jr ,可能要玩更困難的模式吧. Orz

人物應該有40名以上,要靠故事模式或連線模式解開,另外還有個培養模式我沒玩.

大家一定會問 "龍崎武士(全破 Normal 取得)是誰?",我本來不想查,畢竟要從81本裡慢慢找,但本著要做就做全套的精神,我終於在第18集找到,他是木村的對手(應該是很像某個實名選手吧). Orz

每個人物還多種狀態,同樣是間柴就有分 "普通版" 跟 "鬼間柴". 遊戲殼後面也可以看到鷹村的甲蟲裝,真的是 Orz!

戰鬥中,有時候擊倒時會進入慢動作撥放畫面,感覺除了爽外,還能趁此時在對手未倒前補上好幾拳,不過若是自己倒又狂被電腦偷尻,那就只有一個 "幹" 字形容!

一輪全破下來,我覺得很多選手特性都有做出來,不會有是同個模組然後換張臉而已的感覺. 比較有印象的戰役如下:

宮田 vs 吉米法西斯
主要不是吉米強,是宮田的拳頭真的超弱的. 上次 PS2 版本也是卡在這裡卡很久,吉米一拳大概抵宮田五拳吧.

習慣閃躲後再出拳的操作方式,傳家寶刀終於取下吉米的首級!

鷹村 vs 霍克
看過漫畫的都知道這是場硬仗,但我萬萬沒想到那麼硬. 不是說霍克有多強,是我覺得 PSP 版本的霍克根本是惡靈古堡的僵屍,倒了又起倒了又起,根本打不死! 有時後撐到第九回合,第十回合,不小心被他灌一拳,鷹村就去見閻羅王了!

克制住想摔機的衝動後,打定主意要靠判定取勝,撐了十二回合終於拿下世界冠軍! 40分鐘就這樣過去,真是殺時間的好遊戲!

木村 vs 電池
電池真的很快,但製作小組真的有用心,我狂打他腹部一下就趴了! 哈!

青木 vs 木瓜
不知道是不是眼花! 我真的覺得木瓜右手臂比左手粗,木瓜拳真的可怕! 挨兩下青木就快上西天了! Orz

坂垣 vs 星
坂垣的覺醒根本是第一神拳的大外掛啊! 白金之星停止五秒,誰都只有當沙包的份! 若問我這次玩誰最爽? 毫無疑問 - 坂垣學!

幕之內 vs 吉米法西斯
沒錯! 吉米又來了! 這次比對宮田那次還可怕! 根本是暴走狀態! 比幕之內還強,我挨沒幾拳就仆了!

最可怕的是,一開始還沒想起來吉米的大絕是啥,他就放了! 跟上圖一樣,一拳就直接仆,倒數10秒結束! 天哪! 這是啥外掛! 這場完我就一直有陰影,電腦狂用這招(跟漫畫一樣),超提心吊膽的!

吉米跟霍克一樣打不倒,我挨5拳可能就倒數了,吉米應該可挨15拳還沒啥感覺. 後來想起來漫畫裡吉米腦怪怪的(想說電池都有做出腹部弱點了),就只放右勾拳,還真的有用! 真的感謝製作小組的用心,要不我不知要卡多久!

感想

我只能說終於全破了! 我沒打算把所有人給打出來,這幾天有空應該就上網買了吧!

嚴格上這片"粉絲" 跟 "拳擊遊戲愛好者" 都可以入手,耐玩性部份若能有人陪我對戰,我就會想留久一點! 要我挑戰難度更高的等級,饒了我這個死上班族吧!

遊戲價格應該是1200元以上. 漫畫共81集. 不管漫畫或遊戲都推給大家!

花890元買個解脫-SONY RM-VL600

VITO SV3701 入手也滿一年多了,這台液晶電視只能用便宜又大碗來形容. 不免俗地還是有些小缺點,其中最為人垢病的就是搖控器真他媽難按. 有時按了沒反應,有時按一下等於按五下,好心情都被它搞成壞心情. Orz

當初買這台時,上網查就有看到網友用 Sony 的學習搖控器來取代原廠的搖控器了,還順便把 LCD TV 上 VITO 的 Mark 換成 Sony,整台變成 "偽.Sony LCD TV" . 這支學習搖控器,一來台灣沒在賣,二來我沒跟上團購,三請我舅買但遲遲無下文,這一年多回想起來真是惡夢一場.

終於,這兩天無意在 X 拍上發現,終於有廠商在賣了 - SONY RM-VL600 八合一學習型萬用遙控器,當下就訂了一支 890 元含運,昨天匯款今天就宅配來了.

基本設定後就能操縱電視的基本功能(選台,音量),但還是需要讓它跟原廠搖控器同步一下以學習一些進階功能(跳回之前台,子母畫面). 以上設定完成,原廠搖控器就可能丟到垃圾桶啦.

手感完全不能比,感應也好很多,使用兩小時也無按一下給你跳五台的情形發生. 心情變好好啊! 想當初只是想從 ESPN(CH 73) 轉到緯來體育台(CH 72)總是直接給我跳到 HBO(CH 65) 的囧樣, SONY RM-VL600 真的是好物啊!

我要中大獎

這篇要笑可能難度很大.. Orz
要待在小公司 + 幾乎人人有獎 的 讀者才知道笑點在哪.. 囧rz

2007年已經衰一整年了! 本來還不打算去吃尾牙(行動不方便),但本著衰那麼久說不定會抽到大獎的期待心理,我還是去了! Orz

說也奇怪! 一到會場就有著奇妙的不安感覺! 故意在抽獎卷上寫上 "哈哈" 兩字,因為最近老天都跟我做對,我寫哈哈,說不定他就故意賞我個大獎! 事實證明我想太多了!

好不容易移動到位置上,主持人在還沒上菜前就準備開始第一輪抽獎了! 不知為何,主持人從箱子裡收手的那一刻,我就覺得我被抽到了! 我常常有這種預測壞事的第六感能力,比如:老師要選一個人出來背課文. 在關西,班長點人出來出屎差. ...族繁不足備載. 反正我心頭就是一陣不對!

"員工編號:xxx" 幹! 熟悉的數字! 就真的中了! 現場馬上響起如雷的掌聲! 原來當初命中有一個感覺,有一沒錯,第 "一" 個被抽出來的人! Orz

人嵾...

PS: 這篇若推破個人紀錄就放上當時領獎囧臉. 囧rz

阿基里斯戰記-受傷後最常被問的問題

(圖為之前上班情形 - 這種狀況下撰寫出來的程式碼品質,可想而知.)
剛跟呂大師 MSN 聊到,覺得可以自我紀錄一下,就寫上來了!自從我阿基里斯腱斷掉之後,最常被人問到的前五大熱門問題:

Top 5 - 怎麼不自己開車?

通常問完的人,不待我回答就會馬上說: "啊!! 忘記你是右腳受傷!!".
我: "..."

Top 4 - 怎麼不請同事順便載你?

幹! RD 最好都是開車上下班! 我認識的都是騎摩托車上下班的啦!
不是人人都是竹科新貴啦!
年終平均4個月? 主管領7個月!員工領1個月啦!

Top 3 - 怎麼上下班?

我: "坐計程車上下班!!"
對方一定使出連續技: Top 3 -> Top 4 -> Top5 -> KO!!

Top 2 - 怎麼受傷的?

我: "打籃球受傷的!"
接下來最常聽到回應:

1. 打很激烈厚!
2. 跳很高厚!
3. 被人家踢到厚!

我只能說以上皆非! 時也命也! 欲知詳情此看 阿基裡斯戰記-受傷 .

Top 1 - 好點沒?

這句真的無言.
若硬要回答我可能只能擠出:"嗯! 我覺得肌腱有在長了!"
這根本不知如何回答吧!
腿包成這樣我根本不知道裡頭是怎樣!
膝蓋不能彎! 腳腫不會消! 腳癢也抓不到!
還能比這更好嗎? 我不知道!
若我這陣子得憂鬱症! 這絕對是壓倒我樂天本性的最後一根稻草!

結尾

個人想到過最有創意,但至今還沒有人問我的問題.

你為什麼要買 Wii Fit ?

呂大師提供的創意問題.

似乎很久沒看到你,最近都去哪玩了?

當程式設計師的壞處

牛仔今天很閒,所以我今天寫了三篇. 其實並不閒,只是在改前輩爛扣,改一改要放空一下,不這樣我怕我的靈魂被禁錮在陣列的迷宮當中. 囧rz

剛同事 Mail 給我的文章 - Downside of Being a Programmer ,是一個住在德國的美國 RD 寫的,還蠻幽默的(內容完全無技術),看完寫寫心得:

電腦書永遠追不上新技術 - 不過我大部份的書都是買些觀念書(工作越久越是如此),工具書幾本,新技術上網查就是.

電腦永遠不夠快 - 這點我倒是還好,我反而是大學,研究所有在玩 PC Game 時才有這種煩惱,上班後只要電腦穩定不要沒事重開機就好!

設計模式狂熱 - 的確,最近回去看自己之前套的模式,還真的得花些時間回想為何要套用此模式? 如何使用此設計? 看來讓程式碼解釋自己本身這方面的功夫我還下的不夠. 過度設計 + 沒有文件 = 改寫地獄 Orz

技術狂熱 - 我目前沒這煩惱,但多學總是好的. 之前也會使用別的語言或 Framework,但因為工作上用不到,所以沒多久又還給他了. 唉! 所以現在比較偏向學別的方面的東西. 技術這東西我已經看很開,公事上要用到再去 K 吧!

幫人修電腦 - 若我英文沒那麼爛的話,原作者應該是指別人只要知道他是 Programmer,就會要他幫忙電腦的事情. 原來,不是只有台灣的工程師有這樣的煩惱.

打完收工! 繼續去看我前輩的爛扣!

Navigator, Package Explorer 傻傻分不清楚

一如往常我打開我的 Eclipse 準備開始寫扣,卻發現有錯誤的 .java 檔案左下方卻不會顯示小小的紅底叉叉! 上網也只找到這一篇是跟我一樣的問題,但卻沒有正確的答案.

反反覆覆爬文了許久,就差沒重新"發佈" Eclipse.

雄雄在 Window/Show View 下發現還有個 Package Explorer,一打開大師兄就回來了!

我看我跟那個大陸人應該是都不小心把 Package Explorer 和 Navigator 弄混了! 以為是一樣的東西. Orz

以下引述自 Eclipse實作手冊:

Package Explorer 與 Navigator 類似,但它更符合 Java 專案的需求,譬如它看得懂 Java 套件,且會...(請買書來看)

反正兩個 View 長很像,一不小心就跟我一樣搞笑了. Orz

阿基里斯戰記-石膏 No Zoom Air II代

術後兩個星期 - 1/10,第一次回診,今天主要是回來給醫生拆線和換石膏.

回診

一去就是先把固定石膏拆開,不拆還好拆了真的都不太敢看. 整個腳腫得跟豬腳一樣,腳踝的部份因此長期支撐石膏不算輕的重量,整個瘀青紅腫,更別提那超長的傷口. 接著馬主任把我的腳往上扳. 真的是夭受痛,無法用筆墨形容,身體下意識就是往後閃不想在被扳. 腳跟小腿扳至45'我就痛到受不了,也許是之前被中醫亂扳留下的陰影,但我真的是怕被扳掉-砍掉重練.

拆線

馬主任看一看說:回復的不錯! 等等拆線換石膏!
我就到了隔壁房間,趴在床上拆線. 石膏拆完整個人超害怕去踩到腳,整個腳感覺就不是我的腳,一種很奇怪的違和感. 拆線就刺刺痛痛的,反正跟扳腳比,整個不能比就是. Orz

換石膏

因為石膏室的 Buffer 滿了,就被換石膏的阿北叫去外面等. 整個人超悽涼的站在門診等候區,往下看著那不像是腳的腳,深怕等待的途中不小心給踩下去.

換石膏的阿北很酷,一進去就要我上床,二話不說就直接扳我的腳. 幹! 真的超痛的! 就像你知道你踏這一步肌腱會斷掉,你還是得踏的心情. 我已經開始在想像我復健會發生的情形. 勉勉強強扳至30'~40'才開始上石膏. 這次上的是塑膠石膏,比較輕但要自費約1000多(給有需要的人參考),對於我這要上班的人,這是沒得選擇的選擇!

塑膠石膏三天心得

比較輕是真的,有種重力100倍降至重力30倍的感覺.

整個包覆至大腿,膝蓋完全不能歪,開始想像被扳膝蓋的情形. Orz

其它

自從 2007/11/2x 受傷至今(2008/1/14),就只有三個地方:公司,家和醫院. 實在是很無言的一種生活型態.

大家常問我的問題就是 - 好一點沒有?,這實在是一個非常難回答的問題. 我想在我完成復健之前應該都是不好吧. Orz

我不是一個變來變去的人

最近腳不是很方便,石膏打到大腿,躺也不是,坐也不是. 更別提上廁所,一般人很平常就能做的事.

這星期下班回到家,好不容易躺在沙發上爽時,電話響了! 本想不理它,想說應該不是什麼急事. 結果馬的響了超久都沒停,沒辦法怕家裡真的有急事找,爬到椅子上慢慢尻過去.

結果..

幹! 拜票電話!

什麼叫 "適得其反" ?

要一個掰咖接你的拜票電話就叫 "適得其反" !

PS: 這一篇應該只有住新竹市的人比較看得懂,若住新竹也看不懂代表這篇沒笑點. Orz

粉絲們! 推文前先聞一聞!

(圖片轉自: http://www.crimsonrain.com/2007/10/2007jay-chou-on-run.html )

昨天上 FunP 看文(我通常都只看當日熱門文章),看到艾瑪這篇 [隨書] 艾瑪很忙 ,共13人推外加大河馬加持,我就點進去看了.

點進去(1/8 艾瑪新增了一段文字進去)很無言,一張圖 + 一句話 "很忙... 沒空坐下來寫文章...",這樣都有 13 人推,只能說名人永遠舔蜜點,其他小兵舔屁眼. Orz

很明顯這跟艾瑪無關係,但這種見名人就推的推文方式,只能套用最常看到80/20法則來說服自己- 80% 的推都集中在 20% 的名人文身上.

PS: 覺得 Leon 的說法不賴! 但又不想完全抄他的 Idea! 就從他想的 "粉絲們，名人也是會放臭屁的！" 加一點自己 Style 變成 "粉絲們! 推文前先聞一聞!" .

明日的記憶

失去最重要的東西,才知道最該珍惜的是什麼. - 簡單的兩句話,但多少人已經體悟了這個道理呢?

認識這部電影是因為看了《明日的記憶》：無法頂住的遺忘與淚水 這一篇,不過那時候電影還在上映中,一向沒有去電影院看日本電影的我,遲遲撐到今年才看. Orz

引述自官方部落格的介紹:

如果過了明天 我連你都忘記了 也請緊握我的手 陪我繼續走下去….

佐伯雅行（渡邊謙）是知名廣告公司主管，工作賣力認真，不但受老闆肯定，也備受下屬愛戴。他能無憂地在職場打拚，是虧得溫柔體貼的妻子枝實子始終默默支持，兩人甜蜜的感情羨煞許多人。而女兒梨惠也即將出嫁，還有個未出世的小外孫，幸福似乎始終圍繞在他身旁。直到某日，他因為不堪長期頭痛暈眩的困擾而就醫，這才驚覺原來自己的健康早在不知不覺中流逝。

他開始想不起來每天一起工作的同事長什麼樣子， 每天上班都要經過的街道，卻變成了陌生的風景， 上一秒鍾才訂好開會的時間，下一秒卻完全忘記……

直到有一天，佐伯不知不覺來到當年與枝實子相識的地方，他想起年輕時候彼此承諾相愛一生，想起了那時她說「我願意」的溫柔語調，卻怎麼也想不起她的模樣。枝實子回家找不到佐伯的蹤影，無助之餘，便也來到這個回憶之所。看到佐伯從前方走過來，她好想上前給丈夫一個擁抱，只是佐伯看著眼前這位眼中盈滿淚水的女子，覺得既熟悉又陌生……

整部片並不沉悶可放心在六日觀看.

不太會寫心得文,加上腳痛實在是吐不出象牙,心得就以條列式的格式寫出.

1. 工作只是工作,還有許多比工作更重要的事!
2. 結婚就是要彼此關心一輩子,長期埋首於工作,跟公司結婚算了!
3. 生小孩就是要自己教育,生了不教,生了全都丟給別人教,乾脆先去節紮算了,也少一個社會問題!
4. 多關心真正重要的人事物.

渡邊謙真的很會演,最後一段因為自己的無能,想要故意罵跑老婆的段落,演到我一把鼻涕一把淚的. 忍不住會讓人思考,如果發生在我身上的話,自己又是會如果面對處理這樣的問題. 只能說我還是適合看無腦的動作片! 苦!

如何預防老人癡呆症(出處:http://www.tunghai74.org/letters/07-08-08-Alzheimer.htm):

腦血管性癡呆 要多吃這些
卓資彬醫師表示 , 腦血管性癡呆多是高血壓、糖尿病、高血脂症、動脈硬化等毛病所引起的 , 可經由改善飲食來預防 ; 例如 , 喝酒勿過量、不吸煙、少鹽、少油、少吃甜食 , 注意營養的均衡 。

另外 , 也可以從飲食補充 , 卓醫師建議 , 要預防癡呆症可多吃富含EPA和DHA等不飽和脂肪酸的鯖魚、沙丁魚、鮪魚等 , 來預防腦栓塞 , 並活化腦循環 ; 植物油、南瓜、綠黃色蔬菜、豆類、小麥胚芽等富含維生素E , 有抗氧化作用可防止腦細胞的老化 ; 紅酒、綠茶、可可亞等含多酚 , 可抑制自由基 , 防止老化和血管硬化 ; 枸杞子可促進血液循環 , 含維生素D的香菇則可防止血管的老化 。納豆激酉每則可溶解血栓 , 促進腦部血液循環 , 又有抗癌作用 。

補充乙醯膽鹼 減緩阿茲海默症
對於阿茲海默型癡呆症 , 飲食雖然無法阻止腦的變性 , 但可使腦細胞活化 , 緩和症狀 。卓資彬醫師強調 , 神經傳導物質乙醯膽鹼減少時 , 會導致阿茲海默型癡呆惡化 , 建議飲食多補充乙醯膽鹼來減緩其惡化速度 , 蛋黃、大豆、花生這些食物含有豐富的卵磷脂 , 是乙醯膽鹼和維生素B群的構成物質 , 對活化腦細胞有助益 。

動手動腳 活化腦細胞
卓醫師表示 , 老人家最怕整天臥床沒有運動 , 腦部缺乏刺激會使癡呆危險性增加 , 若每天散步 , 做適度運動 , 鍛鍊筋骨可預防跌倒 , 身體有在動 , 腦細胞才能被活化 。手指的活動和腦也有關聯 , 建議彈奏樂器、作料理、編織、折紙、園藝等都是很好的活動 。另外 , 老人家也要多參與社交活動和人群接觸 , 刺激腦力 。
活化右腦也可預防癡呆 , 因為現代人多數傾向使用擅長語言計算理論思考的左腦 , 若能活化右腦則能加強記憶和會話 , 所以平日可常用左手運動來防止右腦老化 。

捷運文化運動獎狀入手

等了好久終於來了!! 主要是等錢來!! 我客都請了錢卻遲遲未來!! 真怕是被騙了!! Orz

出不了門的日子,一點點小事都是大大的感動!! Orz

女性向

今天投票出爐了!!

共25人投票,13個女生對12個男生. 原來我的格都是女生在看嗎. 真害羞! (=/// = ) 明天應該就被GF宣佈倒格!

以後改走女性向風格好了!!

雖然沒有很多人投票,但看到直條圖拉長拉短就莫名的興奮起來. 難道我真的是寫程式寫瘋了嗎?

再想個無聊的題目來讓大家投好了. Orz

好好愛護你的阿基里斯腱

更多請看 阿基裡斯戰記 懶人包

腳跟酸痛就不要硬撐,運動前要熱身,運動完要讓腳跟泡泡熱水. 阿基里斯腱斷裂能開就趕快開,要不然下場就是(下圖有嘔心閃光)..

這是我第一次看到自己的傷口,整隻腳石膏根本看不到自己腳跟,腰跟腿的角度一小,腳跟就有被線拉扯的感覺,看到照片才知道原來是這樣. 話說現在看電視轉到籃球都不太想看,電影台看到布萊德彼特也瞬轉台. 石膏真的很重,角度也不好喬,腰也找不到施力點,才不到一星期,這樣的日子,還要好長一段時間!

各位請好好愛惜自己的阿基里斯腱啊~!!

軟體建構之道 (Code Complete) 第二版 第二十七章到第三十四章心得

第二十七章-程式大小對構築的影響

白話的說,專案越大所需要耗費的心力越多,在小專案中認為是理所當然的事,也必須詳細地設計討論才能用於大專案中.

第二十八章-構築管理

要求專案成員寫出具有閱讀性的程式碼.

落後的進度時,加入更多的人力並不會扭轉情勢.

根據統計,程式設計師有30%的時間花在非技術性的活動(Orz).

越尊重程式設計師的公司,越容易得到程式設計師的回報(Orz).

請把程式設計師當人看(Orz).

第二十九章-整合

直接看書卡實在. 跟以前上軟體工程教的東西差不多. Orz

第三十章-程式設計工具

工欲善其事,必先利其器.

第三十一章-配置與樣式

程式設計師工作的一小部份是寫電腦能讀的程式,更大部份是寫人類能讀的程式.

將完成一件工作相關的程式碼集中於同一個段落.

讓大腦用於了解程式如何解決問題的大方向上,而不是花費時間在讀懂運算式,語法...等.

第三十二章-自行紀錄的程式碼

好的註解說明高階的抽象概念,爛的註解就是重複程式碼內容.

使用虛擬碼程式設計流程減輕加上註解的時間.

第三十三章-個性

強烈建議不知道該不該買此書的人,先去書店翻一下這章,心有戚戚焉再敗吧!

程式設計資訊變動的特性,讓"經驗"不在那麼吃香.

第一次學習新事物時,請以正確的方式學習.

程式設計中最重要的工作即是思考,但人在思考時看起來不會有太忙的感覺(被誤認為在混?). 真希望老闆們知道這個道理. Orz

第三十四章-軟體工藝

寫程式給人看,而非寫程式給電腦看.

一次就寫好一個好的程式碼,而不是花很多時間寫一個複雜不好懂的程式碼.

一個專業程式設計師一定寫可讀的程式碼.

一拿到問題就開始狂寫程式碼,然後花更多時間來除錯.  - 這不是聰明的工作方法.