[好文章] 黑咖啡的甜味

細心體會辛苦付出後所得到的東西吧！當苦難過去，甘美就會到來。──德國文學家 歌德

有一位上了年紀的企業家，當他決定要把公司交棒給兒子之前，特別親自煮了一杯咖啡，給已近不惑之年的兒子，並且堅持一定要他喝黑咖啡，不能加入糖和奶精。

兒子喝了幾口黑咖啡後，企業家問：「喝出甜味了嗎？」

兒子失笑說：「黑咖啡怎麼可能有甜味？」

白髮蒼蒼的企業家笑著說：「每種咖啡都有甜味的！」

在兒子的疑惑中，企業家緩緩說道：「在我還是你這麼年輕時，曾經失敗過。那陣子，我創立的第一家公司經營不善，欠了一屁股的債，最信任的助手也同時離開我，帶著我辛苦研發的技術，跳槽到對手的公司。」

「你母親因為承受不了經濟上巨大的壓力，一直吵著要和我離婚，當時的我，真的是走投無路。就在我即將宣布破產的前一晚，我一個人待在辦公室裡，直到深夜，思考著到底該怎麼辦。我愈想愈絕望，抬頭看著滿天的星星，心裡卻感到無盡的孤獨。」

「也就是在這個時候，我第一次為自己煮了杯咖啡，因為平常都是祕書幫我把糖和奶精加好，所以我根本不知道要怎麼處理眼前又黑又濃的咖啡。但是當時的我非常焦躁，只求能靜下來，所以也不管三七二十一，端起來就喝，沒想到──」

企業家看了一眼聽得入迷的兒子，繼續說：「黑咖啡還真苦，苦得我吐也吐不出，嚥又嚥不下；但是過了一會後，這苦還真讓我安靜了下來，而且我還發現，咖啡不只是苦，還很酸。」

「接著我又發覺，如果一小口一小口地喝，在苦澀和酸楚之後，會有一種淡淡的，帶著果香或花香的甜味，從喉嚨往回走，布滿整個口腔。我在那個晚上才真正懂得咖啡的味道，加了奶精和糖，你就喝不出這個真味道了！」

兒子聽父親這麼說，就再度捧起咖啡，認真地細細品嚐，想要理解父親所謂的咖啡的甜味。

就在此時，企業家又開口了，他說：「如果你喝得出黑咖啡的甜味，你就會理解，人生有高有低，即使是再苦的日子裡，都會有值得你細細品嚐的甜。」

突然間，企業家的兒子感覺到了酸苦之後的淡淡甜味，也了解父親為什麼要堅持他喝這杯黑咖啡了。

心靈小語

再苦的日子裡，都有值得細細品嚐的甜，只要我們不輕易放棄。

而且如果不是因為夠苦，那份甜也不會顯得珍貴而獨特，讓人想要一嚐再嚐。

也只有經歷過真正的苦，才會珍惜得來不易的甜。

生活的真諦，全都可以由一杯黑咖啡體現！

當我們受到磨練的時候，先謝謝上天，給我們有展現自我價值的好機會。@


摘編自 《毛毛蟲以為的絕境，其實是蝴蝶美麗的開始：有時候，我們以為的無路可走，往往只是自己恐懼的投射》 人本自然文化事業有限公司 提供

Linklist 實作

Linklist的資料結構型態是類似以下的結構

typedef struvt node {
     char *data;
    struct node *next;

} Listnode;

Listnode n,*p;

他是一組結構包括資料,和指向另一節點的指標
變數n是一個Listnode 節點, p 是一個指向 Listnode 的指標

我實作了一個用linklist建立的一個binary tree


#include

typedef struct node{
    int data;
    struct node* left;
    struct node* right;
} Listnode;

const int Misc[11]={
    50,10,33,55,23,12,44,99,100,0,
};


void main(void){
    Listnode List1[10],List2[10],*ptr,*p1,*p2;
   
    int num,layer;
   
    for(num=0;num<10;num++){
        List1[num].data = Misc[num];
        List1[num].left = NULL;
        List1[num].right = NULL;
    }

    for(num=0;num<10;num++){
        cout << List1[num].data << endl;
    }
//    ptr = List1[0];
//    p1 = List1[0].left;
//    p2 = List1[0].right;
   
    for(num=1;num<10;num++){
        ptr = &List1[0];
        while(1){
            if(List1[num]->data > ptr->data ){
                if(ptr->right == NULL){
                    ptr->right = &List1[num];
                    break;
                }
                ptr = ptr->right;
            }
            if(List1[num]->data < ptr->data ){
                if(ptr->left == NULL){
                    ptr->left = &List1[num];
                    break;
                }
                ptr = ptr->left;
            }   
        }
       
    }

    ptr = &List1[0];
    while(1){
        if(ptr->left != NULL){
            cout << ptr->data << endl;
            ptr = ptr->left;
        }else{
            break;
        }
    }
//    while(1){
//        if(ptr->right != NULL){
//            cout << ptr->data << endl;
//            ptr = ptr->right;
//        }else{
//            break;
//        }
//    }   
}

在WinPE 64位元 出現 Error: The subsystem needed to support the image type is not present”

 在實作一個TOOL時,發現在WinPE 64 bit OS 會有問題

error message如下
"The subsystem needed to support the image type is not present”

這是因為WinPE 64位元並不支援32bit AP(一般Win7 的64bit 可以)
所以必須要利用Visual  studio  2010 重新build X64版本即可

技術債 -- 翻譯自wikipedia

之前看到一篇文章在講技術債的,
我就到wikipedia查了一下


有鑑於wikipedia沒有中文翻譯,
所以我想我就鱉腳的翻一下也好,希望以後有有心人士去update上去

Technical debt

技術債

Technical debt (also known as design debt or code debt) are synonymous, neologistic metaphors referring to the eventual consequences of poor software architecture and software development within a codebase.

技術債(通常也稱作設計債或源碼債)是一種對於不好的軟體架構和對基礎程式的軟體撰寫造成的結果的譬喻.

Common causes of technical debt include (a combination of):

通常造成技術債的原因包括以下幾點

• Business pressures, where the business considers getting something released sooner is of more value than avoiding technical debt

商業壓力,

當盡快推出產品比避免技術債更加具有價值時.

• Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications

缺乏流程或缺乏了解,

當對於技術債缺乏了解,並且並未思考潛在問題的思考.

• Lack of building loosely coupled components, where functions are hard-coded; when business needs change, the software is inflexible.

缺乏建立鬆散的對應元件

功能是以hard-coded方式寫成,當功能需要修改,而軟體的彈性不夠.

• Lack of documentation, where code is created, but may be difficult or time consuming for anyone other than the author to understand, as functions are not documented

      缺乏文件

      當程式已經完成,但沒有足夠的時間或心力讓作者以外的人了解,像是一些未寫在文件的功能.

"Interest payments" are both in the necessary local maintenance and the absence of maintenance by other users of the project. Ongoing development in the upstream project can increase the cost of "paying off the debt" in the future.

在本地的維護及看不見的其他用戶的維護成本都必須付”利息支出”. 對之前專案的持續維護也會增加未來還債的成本

Best Practice in paying down technical debt is to refactor code as part of ongoing development.

最好的降低技術債的嘗試是對正在進行的處理和撰寫的部分進行重構

"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.

— Meir Manny Lehman, 1980

當正在進化的程式一直持續的改變,它的複雜度,反映出來的日益惡化的架構,一直增加,直到花力氣去維護或減少他.

                                                                                  — Meir Manny Lehman, 1980

While Manny Lehman's Law already indicated that evolving programs continually add to their complexity and deteriorating structure unless work is done to maintain it, Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:

當Manny Lehman的定律已經指出進化中的程式繼續增加其複雜度和日益惡化的架構,除非花力氣去維護他.Ward Cuningham在1992年第一次寫下對於技術複雜性和科技債比較的經驗報告

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.^[1]

讓第一時間的程式碼跑掉就已經進入債中. 小債有很長的時間會加快撰寫的速度,而必須藉由重寫來償還它.危險發生在債沒有償還.每分鐘使用”不太對”的程式碼是必須計算利息的.債務負擔在合併撰寫或物件導向時,對整個工程或組織會帶來一個僵固的結果

In his influential 2004 text, Refactoring to Patterns, Joshua Kerievsky presents a comparable argument concerning the costs associated with architectural negligence, which he describes as "design debt".^[2]

在Joshua Kerievsky具有影響力的2004文件,重構到設計,,展示了一個對於架構溝通的成本考量的比較參數,他稱之為”設計債”

Activities that might be postponed include documentation, writing tests, attending to TODO comments and tackling compiler and static code analysis warnings. Other instances of technical debt include knowledge that isn't shared around the organization and code that is too confusing to be modified easily.

會拖延的行為包括了建立文件,撰寫測試,試圖使用TODO註解,和不理編譯器和靜態程式分系器的警告.其他技術債的成員包括理解知識並未分享給整個組織並且程式碼修改簡易到令人疑惑.

In open-source software, postponing sending local changes to the upstream project is a technical debt.

在開放原始碼軟體,延後送出本地改變給線上的專案,也是一種技術債.

將Linux裝在USB隨身碟

因為硬體同事需要測VGA在Linux環境下
而他安裝的系統又進不去(硬體太新了)
我只好使用LiveCD的方式幫她進系統

不知不覺發現幾個將LiveCD灌到USB隨身碟的辦法
1.Fedora和Ubuntu的話,可以使用Fedora出的Fedora USB creater.exe 將iso檔安裝到USB
不過要注意的是,當安裝完開機後,系統會找不到 image kernel ,
這時候就要在boot下輸入Live,按下enter,就會順利進去liveCD

SUSE 的話要用SUSE自己的 imagewriter.exe 安裝,用Fedora的程式會失敗