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

今天是傷後兩個月,術後五個星期,長石膏後三個星期. 距離上一次走路已經是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

Refactor
(圖片來自: 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

Refactor
(圖片來自: 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

Refactor
(圖片來自: 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

Value and 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

Refactor
(圖片來自: 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

Refactor
(圖片來自: 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

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

不要亂幫別人畫大餅

Pizza
(圖片轉自: 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

至於如何看出資料結構,我是先參考 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 跳掉.

鬼vs惡魔
接著就會進入選手進場畫面,這次比之前 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

第三十四章-軟體工藝

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

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

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

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