ORA-01452: cannot CREATE UNIQUE INDEX;

Problem
As DBA rebuilt index, it produced error report as following:

Root Cause
Based on the NIGT021 schema, it only has one primary key. Therefore, it may has abnormal and duplicate data in NIGT021.

Solution
1. Figure out abnormal data
2. Delete abnormal data
3. rebuild index

Here is the SQL statement template to find duplicate value in this table

   select column_name, count(column_name)
   from [table]
   group by column_name
   having count (column_name) > 1;

Here is an example to apply to NIGT021

   select pnsh_tp, count(pnsh_tp)
   from nigt021
   group by pnsh_tp
   having count (pnsh_tp) > 1;

OCEJPA(1Z0-898) Preparation Tips

OCEJPA(1Z0-898) Preparation Tips from Guo Albert

2013/06 高雄

85大樓

俯瞰高雄港

愛河夜景

駁二特區

Utilize SVN relocate to change repository's root URL

Problem
Administrator changed the location of repository for some reason. The content of the repository doesn't change, but the repository's root URL does.
If we utilized old URL, it will show failed error message as bellows:

Solution

We can use "SVN relocate" to change the repository's root URL.

Step1. Right Click --> TortoiseSVN -->Relocate

Step2. Change the repository's root URL, and click OK

Then you will get successful dialog as bellows:

Finally, we do SVN update to test if it works or not

2013/05 Singapore

Singapore flyer

Singapore flyer

Singapore Foods

Singapore早餐必備兩顆生雞蛋

The Jewelry Box

Bird view from Jewelry Box

Universal Studio

S.E.A Aquarium

Singapore Zoo

Singapore Botanic Gardens

Singapore 夜景

Singapore 夜景

Singapore 夜景

The Software Craftsman

The Software Craftsman from goeran

Top 10 Traits of a Rockstar Software Engineer

1. Loves To Code
2. Gets Things Done
3. Continuously Refactors Code
4. Uses Design Patterns
5. Writes Tests
6. Leverages Existing Code
7. Focuses on Usability
8. Writes Maintainable Code
9. Can Code in Any Language
10. Knows Basic Computer Science

http://readwrite.com/2008/04/07/top_10_software_engineer_traits

Test a string for a numeric value

Environment 
Oracle 11g

Problem
I write wrong value into specific column, it should accept numeric only.


Solution
To test a string for numeric characters, you could use a combination of the length function, trim function, and translate function built into Oracle.

You can use the following command:

This function will return a null value if vio_yr is numeric. It will return a value "greater than 0" if vio_yr contains any non-numeric characters.


Reference: http://www.techonthenet.com/oracle/questions/isnumeric.php

ALL_TAB_COLUMNS Usage

Environment 
Oracle 11g 

Problem 
Customer requests to update ACS_NO this column length from 8 to 10. But I have more than 100 tables in my system, how do I quickly get the table which have ACS_NO column? 

Solution 
Making good use of ALL_TAB_COLUMNS. ALL_TAB_COLUMNS provides by Oracle, it describes the columns of the tables, views, and clusters accessible to the current user. 

We can use this SQL statement to find out the result:


See....we can get the result easily, and start to author alter table script.

Reference : http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_2094.htm

JPA Lifecycle Events Practice

JPA lifecycle events practice from Guo Albert

什麼是“對用戶友好”

 原文(簡體): http://blog.sina.com.cn/s/blog_5d90e82f01014m7t.html

當我提到一個工具“對用戶不友好”(user-unfriendly)的時候，我總是被人“鄙視”。難道這就叫“以其人之道還治其人之身”？想當年有人對我抱怨 Linux 或者 TeX 對用戶不友好的時候，我貌似也差不多的態度吧。現在當我指出 TeX 的各種缺點，提出新的解決方案的時候，往往會有美國同學眼角一抬，說：“菜鳥們抱怨工具不好用，那是因為他們不會用。LaTeX 是‘所想即所得’，所以不像 Word 之類的上手。”

殊不知他面前這個“菜鳥”，其實早已把 TeX 的配置搞得滾瓜爛熟，把 TeXbook 翻來覆去看了兩遍，"double bend" 的習題都全部完成，可以用 TeX 的語言來寫巨集包。而他被叫做“菜鳥”，這是一個非常有趣的問題。所以現在拋開個人感情不談，我們來探討一下這種“鄙視”現象產生的原因，以及什麼叫做“對用戶友好”。

首先我們從心理的角度來分析一下為什麼有人對這種“對用戶不友好”的事實視而不見，而稱抱怨的用戶為“菜鳥”。這個似乎很明顯，答案是“優越感”。如果每個人都會做一件事情，如何能體現出我的超群智力？所以我就是要專門選擇那種最難用，最晦澀，最顯得高深的東西，把它折騰會。這樣我就可以被稱為“高手”，就可以傲視群雄。我不得不承認，我以前也有類似的思想。從上本科以來我就一直在想，同樣都會寫程式，是什麼讓電腦系的學生與非電腦系的學生有所不同？經過多年之後的今天，我終於得到了答案（以後再告訴你）。可是在多年以前，我犯了跟很多人一樣的錯誤：把“難度”與“智力”或者“專業程度”相等同。但是其實，一個人會用難用的工具，並不等於他智力超群或者更加專業。

可惜的是，我發現世界上有非常少的人明白這個道理。在大學裡，公司裡，彰顯自己對難用的工具的掌握程度的人比比皆是。這不只是對於電腦系統，這也針對數學以及邏輯等抽象的學科。經常聽人很自豪的說：“我準備用XX邏輯設計一個公理化的系統……”可是這些人其實只知道這個邏輯的皮毛，他們會用這個邏輯，卻不知道它裡面所有含混晦澀的規則都可以用更簡單更直觀的方法推導出來。

愛因斯坦說：“Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction.”我現在深深的體會到這句話的道理。想要簡化一個東西，讓它更“好用”，你確實需要很大的勇氣。而且你必須故意的忽略這個東西的一些細節。但是由於你的身邊都是不理解這個道理的人，他們會把你當成菜鳥或者白癡。即使你成功了，可能也很難說服他們去嘗試這個簡化後的東西。

那麼現在我們來談一下什麼是“對用戶友好”。如何定義“對用戶友好”？如何精確的判斷一個東西是否對用戶友好？我覺得這是一個現在仍然非常模糊的概念，但是程式語言的設計思想，特別是其中的類型理論(type theory)可以比較好的解釋它。我們可以把機器和人看作同一個系統：

1. 這個系統有多個模組，包括機器模組和人類別模組。
2. 機器模組之間的介面使用通常的程式介面。
3. 人機交互的介面就是機器模組和人類別模組之間的介面。
4. 每個介面必須提供一定的抽象，用於防止使用者得到它不該知道的細節。這個使用者可能是機器模組，也可能是人類別模組。
5. 抽象使得系統具有可擴展性。因為只要介面不變，模組改動之後，它的使用者完全不用修改。

在機器的各個模組間，抽象表現為函數或者方法的類型(type)，程式的模組(module)定義，作業系統的系統調用(system call)，等等。但是它們的本質都是一樣的：他們告訴使用者“你能用我來幹什麼”。很多程式師都會注意到這些機器介面的抽象，讓使用者儘量少的接觸到實現細節。可是他們卻往往忽視了人和機器之間的介面。也許他們沒有忽視它，但是他們卻用非常不一樣的設計思想來考慮這個問題。他們沒有真正把人當成這個系統的一部分，沒有像對待其它機器模組一樣，提供具有良好抽象的介面給人。他們貌似覺得人應該可以多做一些事情，所以把紛繁複雜的程式內部結構暴露給人（包括他們自己）。所以人對“我能用這個程式幹什麼”這個問題總是很糊塗。當程式被修改之後，還經常需要讓人的操作發生改變，所以這個系統對於人的可擴展性就差。通常程式師都考慮到機器各介面之間的擴展性，卻沒有考慮到機器與人之間介面的可擴展性。

舉個例子。很多 Unix 程式都有設定檔，它們也設置環境變數，它們還有命令列參數。這樣每個用戶都得知道設定檔的名字，位置和格式，環境變數的名字以及意義，命令列參數的意義。一個程式還好，如果有很多程式，每個程式都在不同的位置放置不同名字的設定檔，每個設定檔的格式都不一樣，這些配置會把人給搞糊塗。經常出現程式說找不到設定檔，看手冊吧，手冊說設定檔的位置是某某環境變數 FOO 決定的。改了環境變數卻發現沒有解決問題。沒辦法，只好上論壇問，終於發現設定檔起作用當且僅當在同一個目錄裡沒有一個叫 ".bar" 的文件。好不容易記住了這條規則，這個程式升級之後，又把規則給改了，所以這個用戶又繼續琢磨，繼續上論壇，如此反復。也許這就叫做“折騰”？他何時才能幹自己的事情？

TeX 系統的配置就更為麻煩。成千上萬個小檔，很少有人理解 kpathsea 的結構和用法，折騰好久才會明白。但是其實它只是解決一個非常微不足道的問題。TeX 的語言也有很大問題，使得擴展起來非常困難。這個以後再講。

一個良好的介面不應該是這樣的。它給予使用者的介面，應該只有一些簡單的設定。使用者應該用同樣的方法來設置所有程式的所有參數，因為它們只不過是一個從變數到值的映射（map）。至於系統要在什麼地方存儲這些設定，如何找到它們，具體的格式，用戶根本不應該知道。這跟高階語言的運行時系統(runtime system)的記憶體管理是一個道理。程式請求建立一個物件，系統收到指令後分配一塊記憶體，進行初始化，然後把物件的引用(reference)返回給程式。程式並不知道物件存在於記憶體的哪個位置，而且不應該知道。程式不應該使用物件的位址來進行運算。

所以我們看到，“對用戶不友好”的背後，其實是程式設計的不合理使得它們缺少抽象，而不是用戶的問題。這種對用戶不友好的現象在 Windows，Mac，iPhone, Android 裡也普遍存在。比如幾乎所有 iPhone 用戶都被洗腦的一個錯誤是“iPhone 只需要一個按鈕”。一個按鈕其實是不夠的。還有就是像 Photoshop, Illustrator, Flash 之類的軟體的功能表介面，其實把使用者需要的功能和設置給掩藏了起來，分類也經常出現不合理現象，讓他們很難找到這些功能。

如何對用戶更加友好，是一兩句話說不清楚的事情。所以這裡只粗略說一下我想到過的要點：

1. 統一：隨時注意，人是一個統一的系統的一部分，而不是什麼古怪的神物。基本上可以把人想像成一個程式模組。
2. 抽象：最大限度的掩蓋程式內部的實現，儘量不讓人知道他不必要知道的東西。不願意暴露給其它程式模組的細節，也不要暴露給人。“機所不欲，勿施於人”。
3. 充要：提供給人充分而必要（不多於）的機制來完成人想完成的任務。
4. 正交：機制之間應該儘量減少冗餘和重疊，保持正交(orthogonal)。
5. 組合：機制之間應該可以組合(compose)，儘量使得幹同一件事情只有一種組合。
6. 理性：並不是所有人想要的功能都是應該有的，他們經常欺騙自己，要搞清楚那些是他們真正需要的功能。
7. 通道：人的輸入輸出包括5種感官，雖然通常電腦只與人通過視覺和聽覺交互。
8. 直覺：人是靠直覺和模型(model)思考的，給人的資訊不管是符號還是圖形，應該容易在人腦中建立起直觀的模型，這樣人才能高效的操作它們。
9. 上下文：人腦的“快取記憶體”的容量是很小的。試試你能同時想起7個人的名字嗎？所以在任一特定時刻，應該只提供與當前被關注物件相關的操作，而不是提供所有情況下的所有操作供人選擇。上下文功能表和依據上下文的鍵盤操作提示，貌似不錯的主意。

談 Linux，Windows 和 Mac

 原文(簡體): http://blog.sina.com.cn/s/blog_5d90e82f0101ip7f.html

這段時間受到很多人的來信。他們看了我很早以前寫的推崇 Linux 的文章，想知道如何“拋棄 Windows，學習 Linux”。天知道他們在哪裡找到那麼老的文章，真是好事不出門…… 我覺得我有責任消除我以前的文章對人的誤導，洗清我這個“Linux 狂熱分子”的惡名。我覺得我已經寫過一些澄清的文章了，可是怎麼還是有人來信問 Linux 的問題。也許因為感覺到“輿論壓力”，我把文章都刪了。

簡言之，我想對那些覺得 Linux 永遠也學不會的“菜鳥”們說：

1. Linux 和 Unix 裡面包含了一些非常糟糕的設計。不要被 Unix 的教條主義者嚇倒。學不會有些東西很多時候不是你的錯，而是 Linux 的錯，是“Unix 思想” 的錯。不要浪費時間去學習太多工具的用法，鑽研稀奇古怪的命令列。那些貌似難的，複雜的東西，特別要小心分析。
2. Windows 避免了 Unix，Linux 和 Mac OS X 的很多問題。微軟是值得尊敬的公司，是真正在乎程式開發工具的公司。我收回曾經對微軟的鄙視態度。請菜鳥們吸收 Windows 設計裡面好的東西。另外 Visual Studio 是非常好的工具，會帶來程式設計效率的大幅度提升。請不要歧視 IDE。請正視 Emacs，VIM 等文字編輯器的局限性。
3. 學習作業系統最好的辦法是學會（真正的）程式設計思想，而不是去“學習”各種古怪的工具。所有作業系統，資料庫，Internet，以至於 WEB 的設計思想（和缺陷），幾乎都能用程式語言的思想簡單的解釋。

先說說我現在對 Linux 和相關工具（比如 TeX）的看法吧。我每天上班都用 Linux，可是回家才不想用它呢。上班的時候，我基本上只是盡我所能的改善它，讓它不要給我惹麻煩。Unix 有許許多多的設計錯誤，卻被當成了教條，傳給了一代又一代的程式師，惡性循環。Unix 的 shell，命令，配置方式，圖形介面，都是相當糟糕的。每一個新版本的 Ubuntu 都會在圖形介面的設計上出現新的錯誤，讓你感覺歷史怎麼會倒退。其實這只是表面現象。Linux 所用的圖形介面（X Window）在本質上幾乎是沒救的。我不想在這裡細說 Unix 的缺點，在它出現的早期，已經有人寫了一本書，名叫 Unix Hater's Handbook，裡面專門有一章叫做 The X-Windows Disaster。它分析後指出，X Window 貌似高明的 client-server 設計，其實並不像說的那麼好。

這本書彙集了 Unix 出現的年代，很多人對它的咒駡。有趣的是，這本書有一個“反序言”，是 Unix 的創造者之一 Dennis Ritchie 寫的。我曾經以為這些罵 Unix 的人都是一些菜鳥。他們肯定是智商太低，或者被 Windows 洗腦了，不能理解 Unix 的高明設計才在那裡駡街。現在理解了程式語言的設計原理之後，才發現他們說的那些話裡面居然大部分是實話！其實他們裡面有些人在當年就是世界頂尖的程式設計高手，自己寫過作業系統和編譯器，功底不亞于 Unix 的創造者。在當年他們就已經使用過設計更加合理的系統，比如 Multics，Lisp Machine 等。

可惜的是，在現在的作業系統書籍裡面，Multics 往往只是被用來襯托 Unix 的“簡單”和偉大。Unix 的書籍喜歡在第一章講述這樣的歷史：“Multics 由於設計過於複雜，試圖包羅萬象，而且價格昂貴，最後失敗了。” 可是 Multics 失敗了嗎？Multics，Oberon，IBM System/38， Lisp Machine，…… 在幾十年前就擁有了 Linux 現在都還沒有的好東西。Unix 裡面的東西，什麼虛擬記憶體，檔案系統，…… 基本上都是從 Multics 學來的。Multics 的機器，一直到 2000 年都還在運行。Unix 不但“竄改”了歷史教科書，而且似乎永遠不吸取教訓，到現在還沒有實現那些早期系統早就有的好東西。Unix 的設計幾乎完全沒有一致性和原則。各種工具程式功能重複，冗餘，沒法有效地交換資料。可是最後 Unix 靠著自己的“廉價”，“宗教”和“哲學”，戰勝了別的系統在設計上的先進，統治了程式師的世界。

如果你想知道這些“失敗的”作業系統裡面有哪些我們現在都還沒有的先進技術，可以參考這篇文章：Oberon - The Overlooked Jewel。它介紹的是 Niklaus Wirth（也就是 Pascal 語言的設計者）的 Oberon 作業系統。

勝者為王，可是 Unix 其實是一個暴君，它不允許你批評它的錯誤。它利用其它程式師的輿論壓力，讓每一個系統設計上的錯誤，都被說成是用戶自己的失誤。你不敢說一個工具設計有毛病，因為如果別人聽到了，就會以為你自己不夠聰明，說你“人笨怪刀鈍”。這就像是“皇帝的新裝”裡的人們，明明知道皇帝沒穿衣服，還要說“這衣服這漂亮”！總而言之，“對用戶友好”這個概念，在 Unix 的世界裡是被歧視，被曲解的。Unix 的狂熱分子很多都帶有一種變態的“精英主義”。他們以用難用的工具為豪，鄙視那些使用“對用戶友好”的工具的人。

我曾經強烈的推崇 FVWM，TeX 等工具，可是現在擦亮眼睛看來，它們給使用者的介面，其實也是非常糟糕的設計，跟 Unix 一脈相承。他們把程式設計的許多沒必要的細節和自己的設計失誤，無情的暴露給用戶。讓用戶感覺有那麼多東西要記，仿佛永遠也沒法掌握它。實話說吧，當年我把 TeXbook 看了兩遍，做完了所有的習題（包括最難的“double bend”習題）。幾個月之後，幾乎全部忘記乾淨。為什麼呢？因為 TeX 的語言是非常糟糕的設計，它沒有遵循程式語言設計的基本原則。

這裡有一個鮮為人知的小故事。TeX 之所以有一個“擴展語言”，是 Scheme 的發明者 Guy Steele 的建議。那年夏天，Steele 在 Stanford 實習。他聽說 Knuth 在設計一個排版系統，就強烈建議他使用一種擴展語言。後來 Knuth 採納了他的建議。不幸的是 Steele 幾個月後就離開了，沒能説明 Knuth 完成語言的設計。Knuth 老爹顯然有我所說的那種“精英主義”，他咋總是設計一些難用的東西，寫一些難懂的書？ 

一個好的工具，應該只有少數幾條需要記憶的規則，就像象棋一樣。而這些源於 Unix 的工具卻像是“魔鬼棋”或者“三國殺”，有太多的，無聊的，人造的規則。有些人鄙視圖形介面，鄙視 IDE，鄙視含有垃圾回收的語言（比如 Java），鄙視一切“容易”的東西。他們卻不知道，把自己沉浸在別人設計的繁複的規則中，是始終無法成為大師的。就像一個人，他有能力學會各種“魔鬼棋”的規則，卻始終無法達到象棋大師的高度。所以，容易的東西不一定是壞的，而困難的東西也不一定是好的。學習電腦（或者任何其它工具），應該“只選對的，不選難的”。記憶一堆的命令，烏七八糟的工具用法，最後腦子裡什麼也不會留下。學習“原理性”的東西，才是永遠不會過時的。 

Windows 技術設計上的很多細節，也許在早期是同樣糟糕的。但是它卻向著更加結構化，更加簡單的方向發展。Windows 的技術從 OLE，COM，發展到 .NET，再加上 Visual Studio 這樣高效的程式設計工具，這些帶來了程式師和用戶效率的大幅度提高，避免了 Unix 和 C 語言的很多不必存在的問題。Windows 程式從很早的時候就能比較方便的交換資料。比如，OLE 讓你可以把 Excel 表格嵌入到 Word 文檔裡面。不得不指出，這些是非常好的想法，是超越“Unix 哲學”的。相反，由於受到“Unix 哲學”的誤導，Unix 的程式間交換資料一直以來都是用字串，而且格式得不到統一，以至於很多程式連拷貝粘貼都沒法正確進行。Windows 的“配置”，全都記錄在一個中央資料庫（註冊表）裡面，這樣程式的配置得到大大的簡化。雖然在 Win95 的年代，註冊表貌似老是惹麻煩，但現在基本上沒有什麼問題了。相反，Unix 的配置，全都記錄在各種稀奇古怪的設定檔裡面，分佈在系統的各個地方。你搞不清楚哪個設定檔記錄了你想要的資訊。每個設定檔連語法都不一樣！這就是為什麼用 Unix 的公司總是需要一個“系統管理員”，因為軟體工程師們才懶得記這些麻煩的東西。

再來比較一下 Windows 和 Mac 吧。我認識一個 Adobe 的高級設計師。他告訴我說，當年他們把 Photoshop 移植到 Intel 構架的 Mac，花了兩年時間。只不過換了個處理器，移植個應用程式就花了兩年時間，為什麼呢？因為 Xcode 比起 Visual Studio 真是差太多了。而 Mac OS X 的一些設計原因，讓他們的移植很痛苦。不過他很自豪的說，當年很多人等了兩年也沒有買 Intel 構架的 Mac，就是因為他們在等待 Photoshop。最後他直言不諱的說，微軟其實才是真正在乎程式師工具的公司。相比之下，Apple 雖然對用戶顯得友好，但是對程式師的介面卻差很多。Apple 尚且如此，Linux 對程式師就更差了。可是有啥辦法呢，有些人就是受虐狂。自己痛過之後，還想讓別人也痛苦。就像當年的我。

我當然不是人云亦云。微軟在程式語言上的造詣和投入，我看得很清楚。我只是通過別人的經歷，來驗證我已經早已存在的看法。所以一再宣揚別的系統都是向自己學習的 Apple 受到這樣的評價，我也一點不驚訝。Mac OS X 畢竟是從 Unix 改造而來的，還沒有到脫胎換骨的地步。我有一個 Macbook Air，一個 iPhone 5，和一個退役的，裝著 Windows 7 的 T60。我不得不承認，雖然我很喜歡 Macbook 和 iPhone 的硬體，但我發現 Windows 在軟體上的很多設計其實更加合理。

我為什麼當年會鄙視微軟？這很簡單。我就是跟著一群人瞎起哄而已！他們說 Linux 能拯救我們，給我們自由。他們說微軟是邪惡的公司…… 到現在我身邊還有人無緣無故的鄙視微軟，卻不知道理由。可是 Unix 是誰製造的呢？是 AT&T。微軟和 AT&T 哪個更邪惡呢？我不知道。但是你應該瞭解一下 Unix 的歷史。AT&T 當年發現 Unix 有利可圖，找多少人打了多少年官司？說微軟搞壟斷，其實 AT&T 早就搞過壟斷了，還被拆散成了好幾個公司。想想世界上還有哪一家公司，獨立自主的設計出這從底至上全套家什：程式語言，編譯器，IDE，作業系統，資料庫，辦公軟體，遊戲機，手機…… 我不得不承認，微軟是值得尊敬的公司。

公司還不都一樣，都是以利益為本的。我們程式師就不要被他們利用，作為利益鬥爭的炮眼啦。見到什麼好就用什麼，就學什麼。自己學到的東西，又不屬於那些壟斷企業。我們都有自由的頭腦。

當然我不是在這裡打擊 Linux 和 Mac 而鼓吹 Windows。這些系統的紛爭基本上已經不關我什麼事。我只是想告訴新人們，去除頭腦裡的宗教，偏激，仇恨和鄙視。每次仇恨一個東西，你就失去了向它學習的機會。

The best programmers are the quickest to Google

You know the famous quote:

“Never commit to memory what can be easily looked up in books” - Albert Einstein.

So unless you’ve already memorized that sorting algorithm by heart, why in the world would you want to spend 2 hours trying to figure it out yourself? Worst, why would you want to re-implement something half-assed from scratch when you can just find someone who’s done it before?

Excluding for fun and educational purposes, I can understand some reasons wanting to build out something proprietary long term, but chances are, unless you’re an absolute genius, the collaborative efforts of an open source project will beat whatever you can do in 8 hrs.

If you need to implement something in code and it’s not cutting edge technology, Google it first. If someone else hasn't already done it yet, you’re either Googling it wrong or way off in what you’re trying to accomplish. If you’ve given it your best effort, find someone to ask for help.

The best programmers I know understand how to architect and build large projects piece by piece. They can focus on the macro because don’t get hung up in the pieces. They know how to use Google to find solutions fast. DRY.

http://blog.framebase.io/post/43973262180/the-best-programmers-are-the-quickest-to-google

【後宮甄環告訴我的事】

成大事必備9種能力、9種手段、9種心態

一：沉穩
（1）不要隨便顯露你的情緒。
（2）不要逢人就訴說你的困難和遭遇。
（3）在徵詢別人的意見之前，自己先思考，但不要先講。
（4）不要一有機會就嘮叨你的不滿。
（5）重要的決定儘量有別人商量，最好隔一天再發佈。
（6）講話不要有任何的慌張，走路也是。

二：細心
（1）對身邊發生的事情，常思考它們的因果關係。
（2）對做不到位的執行問題，要發掘它們的根本癥結。
（3）對習以為常的做事方法，要有改進或優化的建議。
（4）做什麼事情都要養成有條不紊和井然有序的習慣。
（5）經常去找幾個別人看不出來的毛病或弊端。
（6）自己要隨時隨地對有所不足的地方補位。

三：膽識
（1）不要常用缺乏自信的詞句
（2）不要常常反悔，輕易推翻已經決定的事。
（3）在眾人爭執不休時，不要沒有主見。
（4）整體氛圍低落時，你要樂觀、陽光。
（5）做任何事情都要用心，因為有人在看著你。
（6）事情不順的時候，歇口氣，重新尋找突破口，就結束也要乾淨俐落。

四：大度
（1）不要刻意把有可能是夥伴的人變成對手。
（2）對別人的小過失、小錯誤不要斤斤計較。
（3）在金錢上要大方，學習三施（財施、法施、無畏施）
（4）不要有權力的傲慢和知識的偏見。
（5）任何成果和成就都應和別人分享。
（6）必須有人犧牲或奉獻的時候，自己走在前面。

五：誠信
（1）做不到的事情不要說，說了就努力做到。
（2）虛的口號或標語不要常掛嘴上。
（3）針對客戶提出的“不誠信"問題，拿出改善的方法。
（4）停止一切“不道德"的手段。
（5）耍弄小聰明，要不得！
（6）計算一下產品或服務的誠信代價，那就是品牌成本。

六：擔當
（1）檢討任何過失的時候，先從自身或自己人開始反省。
（2）事項結束後，先審查過錯，再列述功勞。
（3）認錯從上級開始，表功從下級啟動
（4）著手一個計畫，先將權責界定清楚，而且分配得當。
（5）對“怕事"的人或組織要挑明瞭說。
（6）因為勇於承擔責任所造成的損失，公司應該承擔

成大事的九種手段：

1、敢於決斷－－克服猶豫不定的習性
很多人之所以一事無成，最大的毛病就是缺乏敢於決斷的手段，總是左顧右盼、思前想後，從而錯失成功的最佳時機。成大事者在看到事情的成功可能性到來時，敢於做出重大決斷，因此取得先機。

2、挑戰弱點－－徹底改變自己的缺陷
人人都有弱點，不能成大事者總是固守自己的弱點，一生都不會發生重大轉變；能成大事者總是善於從自己的弱點上開刀，去把自己變成一個能力超強的人。一個連自己的缺陷都不能糾正的人，只能是失敗者！

3、突破困境－－從失敗中撮成功的資本
人生總要面臨各種困境的挑戰，甚至可以說困境就是“鬼門關”。一般人會在困境面前渾身發抖，而成大事者則能把困境變為成功的有力跳板。

4、抓住機遇－－善於選擇、善於創造
機遇就是人生最大的財富。有些人浪費機遇輕而易舉，所以一個個有巨大潛力的機遇都悄然溜跑，成大事都是絕對不允許溜走，並且能縱身撲向機遇。

5、發揮強項－－做自己最擅長的事情
一個能力極弱的人肯定難以打開人生局面，他必定是人生舞臺上重量級選手的犧牲品；成大事者關於在自己要做的事情上，充分施展才智，一步一步地拓寬成功之路。

6、調整心態－－切忌讓情緒傷害自己
心態消極的人，無論如何都挑不起生活和重擔，因為他們無法直面一個個人生挫折，成大事者則關於高速心態，即使在毫無希望時，也能看到一線成功的亮光。

7、立即行動－－只說不做，徒勞無益
一次行動勝過百遍心想。有些人是“語言的巨人，行動的矮子”，所以看不到更為實際現實的事情在他身上發生；成大事者是每天都靠行動來落實自己的人生計畫的。

8、善於交往－－巧妙利用人力資源
一個人不懂得交往，必然會推動人際關係的力量。成大事者的特點之一是：善於靠借力、借熱去營造成功的局勢，從而能把一件件難以辦成的事辦成，實現自己人生的規劃。

9、重新規劃－－站到更高的起點上
人生是一個過程，成功也是一個過程。你如果滿足于小成功，就會推動大成功。成大事者懂得從小到大的艱辛過程，所以在實現了一個個小成功之後，能繼續拆開下一個人生的“密封袋”。

13 Things You Should Never Say At Work

Here are 13 phrases that should be banned from the office:

1. “It’s not fair.”
2. “That’s not my problem,” “That’s not my job,” or “I don’t get paid enough for this.”
• If your boss issues an unreasonable request, rather than saying, ‘You’ve got to be kidding me. I don’t get paid enough for this,’ instead say, ‘I’ll be glad to help. Given my current tasks of A, B, and C, which one of these shall I place on hold while I work on this new assignment?’ This clearly communicates teamwork and helpfulness, while reminding your boss of your current work load and the need to set realistic expectations.”
3. “I think…”
• To convey a command of content and passion for your subject, substitute the word ‘think’ with ‘believe’ and replace ‘might’ with ‘will.’”
4. “No problem.”
• In business and social situations, if you want to be perceived as well-mannered and considerate, respond to thank you’s with, “You’re welcome.”
5. “I’ll try.”
• “In your speech, especially with senior leaders, replace the word ‘try’ with the word and intention of ‘will.’
6. “He’s a jerk,” or “She’s lazy,” or “My job stinks,” or “I hate this company.”
• Avoid making unkind, judgmental statements that will inevitably reflect poorly on you. If you have a genuine complaint about someone or something, communicate the issue with tact, consideration and neutrality.
7. “But we've always done it that way.”
• This phrase reveals you are the opposite: stuck in the past, inflexible, and closed-minded. “Instead say, ‘Wow, that’s an interesting idea. How would that work?’ Or, ‘That’s a different approach. Let’s discuss the pros and cons.’”
8. “That’s impossible” or “There’s nothing I can do.”
• Instead, try something like, “I’ll be glad to check on it again,” “Let’s discuss what’s possible under these circumstances,” or, “What I can do is this.”
9. “You should have…” or “You could have…”
• Instead of making someone feel guilty (even if they are), take a more productive non-judgmental approach.” Say, “Next time, to ensure proper planning, please bring this to my attention immediately.” Or, “In the future, I recommend…”
10. “You guys.” 
• With fellow professionals such as your boss, co-workers and clients, substitute “you guys” with terms such as “your organization” or “your team” or simply “you.”
11. “I may be wrong, but…” or “This may be a silly idea, but…”
• Eliminate any prefacing phrase that demeans the importance of who you are or lessens the significance of what you contribute
12. “Don’t you think?” or “Okay?” 
• if your goal is to communicate a confident commanding message and persuade people to see it your way, instead of hedging make your statement or recommendation with certainty. Imagine an investment banker saying, “This is a good way to invest your money, don’t you think? I’ll proceed, if that’s okay with you.” Instead, you’d probably want to hear something like: “This strategy is a wise investment that provides long-term benefits. With your approval, I’ll wire the money by 5pm today.”
13. “I don’t have time for this right now,” or “I’m too busy.”
• To foster positive relations and convey empathy, say instead: I’d be happy to discuss this with you after my morning meetings. May I stop by your office around 1pm?”

http://www.forbes.com/sites/jacquelynsmith/2013/02/15/13-things-you-should-never-say-at-work/

Web Refactoring

Web Refactoring from Jace Ju

Clean Coding Practice

Clean coding-practices from Wakaleo Consulting

Top 6 Success Factors to Inspire a Team of Software Engineers

"You need a real vision, the trust of team members, the accountability for execution and a lot of passion. High emotional intelligence will be important to give advice and support in an appropriate way.  Don't forget to have strong luck and fortune."

http://www.sw-engineering-candies.com/blog-1/top-6-success-factors-to-inspire-a-team-of-software-engineers

3 Recommendation on Software Management

Contractor is not an employee
In software management, is normally best practice, well used, to use contractors for development, to train new employees or to make innovation analysis on new technologies. You should not use contractors for maintenance jobs.

Never buy from the same Vendor. Competition is the key to keep control
Market and Competition are the key. Buy from different vendor and make them compete to deliver better quality. If you successfully make it, you will gain control and you will simplify the replacement of people, if needed. 
A good manager is going to give to any company the same possibility and opportunities to get visibility and to struggle to delivery in time and with quality. 

Don’t ask or impose people to decommission themselves
If you have the mandate to rebuild or replace some legacy project or application, you should never ask to do that to people that have worked there for more than 2 years. The obvious consequence is a lot of resistance and contrast on your way to get your mission.
I personally would create a team (not bigger than 5 people, but depends) with basically three different roles: 1 business expert (or Product Owner), 1 technical lead and developers (50 % of them can be an offshore team after the first 4/6 months). The legacy team would be in charge of the legacy documentation, and to support the new team on the implementation. They  would communicate only with the business expert.

http://blog.foppiano.org/2012/12/17/3-recommendation-on-software-management/

How to extract unique distinct values from a column

Requirement
Unique distinct values are all cell values but duplicate values are removed.

Example sheet - How to remove duplicate values
Column A contains names, some cells have duplicate values. 

Step 1. Select column which have duplicate values

Step 2. Click REMOVE DUPLICATE button

Step 3. Click OK button

Step 4.  Click OK button

Step 5. Get distinct value

高股息ETF(0056)

昨日在「上班這檔事」，看到來賓提到高股息ETF（Exchange Traded Funds，指數股票型基金）此股票，感覺是風險較低的投資方式，比把錢放在銀行好多了


找到了一些資料

• 傻瓜投資日誌
• http://foolinv.blogspot.tw/2011/09/etf.html
• 小樂的生存知道
• http://allenlinp.pixnet.net/blog/post/28174193-%E9%AB%98%E8%82%A1%E6%81%AFetf(0056)
• WOW GOOD~挖股誌
• http://www.wowgood.org/2012/10/0056-etf.html

Tips on how to write a clean and meaningful code

Tip: Names for variables and methods/functions
Tip: Comments may be misleading
Tip: Separate method/function for each task
Tip: Separate classes if possible
Tip: Don't repeat yourself
Tip: Handle the exceptions
Tip: As few arguments for functions as possible
Tip: Leave SOME whitespace

http://compiledk.blogspot.tw/2012/12/writing-clean-and-understandable-code.html

XDate - A Modern JavaScript Date Library

XDate - a modern java-script date library from Guo Albert

20 Kick-ass programming quotes

1. “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
- C.A.R. Hoare (British computer scientist, winner of the 1980 Turing Award)

2. “If debugging is the process of removing software bugs, then programming must be the process of putting them in.”
- Edsger Dijkstra (Dutch computer scientist, winner of the 1972 Turing Award)

3. “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
- Bill Gates (co-founder of Microsoft)

4. “Nine people can’t make a baby in a month.” (regarding the addition of more programmers to get a project completed faster)
- Fred Brooks (American computer scientist, winner of the 1999 Turing Award)

5. “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
- Brian W. Kernighan (Canadian computer scientist, co-author of “C programming language”)

6. “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
- Martin Golding

7. “C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg.”
- Bjarne Stroustrup (Danish computer scientist, developer of the C++ programming language)

8. “When debugging, novices insert corrective code; experts remove defective code.”
- Richard Pattis

9. “Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.”
- Eric S. Raymond (American programmer, open source software advocate, author of “The Cathedral and the Bazaar”)

10. “Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.”
- Linus Torvalds (Finnish American, software engineer and hacker, principal force behind the development of the Linux kernel)

11. “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.”
- Rich Cook

12. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
- Martin Fowler (author and speaker on software development)

13. “Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’”
- Steve McConnell (author of many software engineering books including “Code Complete”)

14. “The problem with using C++ … is that there’s already a strong tendency in the language to require you to know everything before you can do anything.”
- Larry Wall (developer of the Perl language)

15. “People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones.”
- Donald Knuth (computer scientist)

16. “One of my most productive days was throwing away 1000 lines of code.”
- Ken Thompson (computer scientist, early developer of UNIX OS)

17. “Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.”
- Alan Kay (American computer scientist)

18. “Before software can be reusable it first has to be usable.”
- Ralph Johnson (computer scientist)

19. “Programming is like sex. One mistake and you have to support it for the rest of your life.”
- Michael Sinz

20) “If builders built buildings the way programmers wrote programs, then the first woodpecker that came along wound destroy civilization.”
- Gerald Weinberg (American computer scientist)

http://www.javacodegeeks.com/2012/11/20-kick-ass-programming-quotes.html

Coding Guidelines for the Developer During Development

1)Do use the Transactions in long running queries and many small-small queries

2)DON’T Use SELECT *

3)Avoid explicit or implicit functions in WHERE clauses

4) Avoid long actions in triggers if using

5) Use temporary tables and table variables appropriately

6)As a good rule of thumb try to replace all sub queries with joins

7)Order of Tables in Join Conditions.

8)Loop optimization

9)Parameter sniffing

10)Can use Fixed Index Hint while using the conditions

11)Size the data type wisely in the SP during declaration.

12)Efficient use of MAXDOP setting within query.

13)GROUPING SETS in SQL 2008

14)Always use the With rowlock, with no lock where occurring deadlocks.

15)Use Update From Rather than simply Update

16) UNION ALL instead of UNION

17) Avoid expensive operators such as NOT LIKE


http://phpflow.com/misc/coding-guidelines-for-the-developer-during-development/

如果你的薪水是別人給你的，你就是可以被取代的

理財專家給薪水族的忠告：如果你需要拿錢回家養家，那麼一定要遵守。如果有人養你，則另當別論。

記得以前有位同事離職前多拉了幾個人走，以為會對公司的業務造成影響，經我觀察的結果做了結論：完全沒有影響，缺人找人，頂多資深員工辛苦點，對公司來說，「所有員工在職時都很重要，離職後都不重要」，沒有一個員工是非留不可的，這似乎就是職場常態。

近20年以來，我長時間在美台兩地以理財專家的立埸談理財，幫助客戶及社會大眾做好理財。我常強調做好理財的目的是錢盡其用，讓錢發揮最大的效用，一個相關的重要原則就是凡事講究划算。

我覺得以這樣的現實觀點來看工作，和我倡議的『回到蠻荒』觀點倒是有相通的地方，那就是不做徒勞無功的事，或沒有成果的事。蠻荒的動物都能秉持這樣的原則工作。所以依現實的原則看工作，現代人工作的目的應該只是為了能賺錢，除此以外無他。

以下是探討這類觀點的專家所提供的一些工作原則，不妨做為參考：

原則1：工作真的只是一份工作

不要期待工作與生活能兼顧，事實上也沒幾個人能將工作與生活成功的整合起來，工作並不是生活，我們工作是為了要過生活，或保有自己所喜歡的生活。想想看，你一天或一個禮拜能有多少時間和家人相處，或和親朋好友去做一些你喜歡做的事，就可以知道要兼顧工作與生活是不可能的。

工作只是工作，目的是為了賺錢。錢只是一個工具，讓您換得食物、衣服、車子、房子、休閒育樂…換得「成就」…而「成就感」必須從個人所做的學習與事物中得到價值和肯定..


原則2：不要害怕換工作

工作既是為了賺錢，只要可能賺更多錢，或做起來更愉快、更有滿足感，何妨就換工作？而且，以這樣的原則換工作，收入當然會越換越多，跳槽可能也會變得稀鬆平常。要每次工作時都全力以赴，有稱職的表現，對雇主和業界都能交代，應該隨時可以找到下一個工作機會。但站在生涯規劃的觀點，要思考的不只是下一份工作，而是下下一份工作在哪裡。其如果已經三十歲以上，更應該將目標放在提早規劃四十歲以後的人生，就會知道自己該做好什麼準備。


原則3：一鳥在手勝過十鳥在林 

很多公司都聲稱他們有優渥的福利制度，包括退休金計劃。可是不斷有事實告訴我們，越來越多的人在屆滿退休之前就失去工作了。所以爭取眼前的福利可能更實際，比較值得期待，例如包括健康醫療保障在內的團體保險、托嬰照顧、親職休假、績效獎金的分發，增加加班費或年終獎金等等。

更值得思考的是---這份工作你能做多少，或是說---老闆會讓你做多久？然後呢？


原則4：謀生本事不厭其多

新世紀的工作與收入可能會變得不穩定，產業的興衰或輪替也會變得快速無比，在同一家企業內辛苦一輩子可能會以失業收場。所以橫向拓展各方面的技能，會比縱向的在企業的組織內向上攀爬追求位高權重還要實際。

其實現在已有不少企業也『學會』了一些聰明的技巧，對授予好聽的高階職位並不吝惜，可以讓你擁有耀眼的頭銜，但對薪資增加並沒有多大幫助。與其追求這種虛名，不如讓自己能具備十八般武藝可以多方面賺錢，隨時跳槽。
充實自己的技能讓自己無可替代，或者在風險控管下，掌握機會自己創業，才是M型社會生存王道！


原則5：做好份內工作就回家去

再提醒你，工作只是工作，公司少了你一個人的工作，照樣可以運轉下去。踏實的學習你的工作所該具備的技能，努力做好你的工作，但不要奢望你可以憑一己之力多為公司創造多少業績或產能。

不要因此耗掉你大量的私人時間，讓自己從盲目工作中抽離出來。記住，做好自己份內的工作，然後回家去。說真的，在老闆的眼中，你真的沒有那麼重要！面對現實吧！


原則6：遠離辦公室政治

你工作的目的是為賺取合理的收入，而不是追求虛名與權位，所以不用在心思在辦公室政治上。當紅炸子雞可能因改朝換代而去職走路，被冰凍的失志衰老也可能鹹魚翻身。與其耗費時間介入這些無意義的辦公室鬥爭，不如多花時間在自己的家庭。好好為自己的人生規劃準備才是最重要的。

10種不跟也罷的老闆

1. 別跟那些沒有個人生活的老闆
2. 別跟那些總是遷怒於你的老闆
3. 別跟那些總是扮演搞笑角色的老闆
4. 別跟總是掙扎求生的老闆
5. 別跟那些總是誇誇其談的老闆
6. 別跟那些總是和你爭的老闆
7. 避免那些總是說個不停的老闆
8. 別跟那些總是忙忙碌碌的老闆
9. 別跟那些沉迷於聲色犬馬的老闆
10. 別跟那些能活吃了你的老闆

http://www.life.com.tw/index.php?act=view&news_no=7322&t=1348128394

Failed to Apply Thousand Seperator / Text Pattern

Problem
I had set the text pattern to "#,##0", but it is not working.

Here is the setting in iReport


But it does not work as expected.

Solution
The root cause result from the expression class of this text field is java.lang.String. As I change to java.math.BigDecimal. It works now.

8 Common Code Violations in Java

1. Format source code and Organize imports in Eclipse
2. Avoid multiple returns (exit points) in methods
3. Simplify if-else methods
4. Do not create new instances of Boolean, Integer or String
5. Name public static final fields in UPPERCASE
6. Combine multiple if statements into one
7. switch should have default
8. Avoid duplicate string literals, instead create a constant

http://www.dzone.com/links/r/8_common_code_violations_in_java.html

Best Practices to Make Life Easier for the Programmer

Constants
Should you ever need a variable that is not changing over time (or in many cases just one time), you should use constants. Constants are quick-to-find variables and they help you minimize memory usage.

Configurations
The term ‘configuration’ means variables that are used a lot and rarely change but can be changed in the middle of execution, if needed. Constants can be made as configurations if it can be changed in the middle of execution. Otherwise, leave it as a constant.

Access Control
So many programmers don’t care about access-level modifiers. If you need broader access, use protected and, as a last resort, public access. This way you can protect your specific method or member from the ‘outside world’.

Comments
Comments let you remember code snippets, algorithms, sort methods, even randomized numbers you’ve created before. This is a big advantage if you’re working on a team. Because of comments, other people will understand your intentions.


http://architects.dzone.com/articles/do-not-delete-common

2012/08 神戶京都之旅

風見雞館

北野異人館街一隅

北野異人館街的星巴克

Kobe Tower

神戶港夜景

Kyoto Tower

琵琶湖煙火

伏見稻荷神社

藝妓回憶錄拍攝場景

奈良公園

宇治川煙火