The future of software developer in Taiwan

I have a stirring of emotion when I see this article. By the way, this is my first blog article written by English. I want to go to the world, even though my English is poor. I will study English hard. And I 'll try to translate old article to English version gradually. Maybe the words are not the same, but the meaning is never change. You may ask why I use different words to represent the same meaning? Because one version is Chinese_ZH and the other is English_US, translate words for wrods is impossible.
Although ZK is the light of Taiwan, but come back to the reality. How much money they made? After serveral days of thinking, I found my goal is to buy things but don't need to see the price label. This may what I want. Just I say, most important is to understand what to want. :P. But this is just 'may'.... . I also want to do something for the world. This is the way to wealth. I don't have evidence to proof it. Ok..turn back to the reality. Honor is honor, how about money? I don't know. I will try to find some information about these developers' wealth.

中國的教育

今天台南發生重大車禍，22死4傷。Team裡面的programmers便又在七嘴入舌的討論了起來：偉大的立法委員會否又因為今天的車禍再定下一些法律?

經過一翻看似邏輯的討論後，我們的結論是：1.不管法律怎麼定，總要有人遵守。法律制定時就會有處罰；而當違反法律而不會被處罰時就會有人不去遵守法律。因此第2個結論是中國總是用處罰，而不是用獎勵，去期望學生/子女去做某些行為。也就是說當處罰不存在或是不能被落實時，學生/子女就不會去做這些期望的行為或是遵守法律。當然從反方向來說，沒了獎勵或目標，就不會去做這些行為或是遵守法律。然而中國的教育卻很少從獎勵面來執行教育，都是從處罰面來教育。可以看看在教育event中，處罰的event次數遠多過於獎勵的event次數。

而對於成功人士來說，他們是積極的。他們有目標、有夢想，而且會去追尋夢想。就結論面來說，他們因為有目標、有夢想，而且會去追循尋夢想，所以會成功。

Tag

階層架構被認為是人類最偉大的發明。它的原則是每一個item都可以被放在特定一個的category下。這可以讓人類依category很容易的找到想要找的item。時至今日，這個假設已經不再合用。很多情況下，一個item已經無法被歸類在特定一個category下。難道這個item就可以被同時放在2個以上的category中?不，不可以，這會有資料一致性的問題。
於是就有人不再以category去尋找資料。他們直接去搜尋item。偉大的google自始至終都一直強調搜尋演算法，如何才可以快速的找到想要的資料。很明顯的，google做的還不夠好，因為每次我在搜尋時總有好幾百萬筆；不過這也不能怪goole，因為連我自己要找什麼都不太清楚，怎麼能要求那種電腦演算法能給出我一個正確的東西。然而這卻是在人類使用category時，會面臨的情境：我就是不知道我要找的是什麼，所以才用category去找。....有點扯遠了。回到開始有人直接去搜尋item...。
搜尋的問題可以用「直接搜尋item」與「提高演算法精確度」來解決。但階層提供的功能不只是只有幫助搜尋，他也為item真的提供了分類的功能。這個分類並不是為了讓item可以快速的被搜尋到，而真的只是幫item做歸類。那如果沒有了category，分類怎麼辦?於是tag這種東西就出現了，它幫item做了一個分類，認為這個item應該屬於這個category，我就給你屬於這個category的tag。就如同所謂「真的分類」的功能，tag也就「真的只是分類」。那好像是屬於這個category又好像是屬於那個category的item怎麼辦?沒關係，我就給你這個category的tag與那個category的tag。這樣就解決了1個item隸屬於2個category，卻又不會造成資料不同步的問題。

STRUTS使用Module?

Struts與Tiles我就不多說了。我們在設計網頁時，需要決擇在一個網頁裡在不同的輸入部份應該使用相同的一個form或是不同的form。一個例子是畫面上右上角的使用者登入輸入帳號密碼的欄位與主畫面功能的資料輸入欄位。使用者登入欄位always會出現在那裡讓使用者可以在任何時候登入(當然也可以設計成只是一個連結讓使用者可以在任何時候連結到登入頁面)。在這樣的情況下，設計者必須決定該使用一個form或不同的form。
再加上另外一個條件：我們在開發時使用不同的module。Struts可以將不同的action與form寫在多個struts-config檔裡。這有2種情況，1種是真的只是寫在多個struts-config檔裡，另外一種是以module的型態來設計。一但使用了module，request中module的轉換都要使用switchAction(看不少文件都這麼寫...，但我本身也試過使用module卻不使用switchAction的情況)。在同一個畫面有必要使用2個form的情況下，struts action與form的區分我建議使用第一種方式：將action與form的設定分散在不同的struts-config 裡。因為當登入部份與主畫面的form屬於不同module時會無法執行；在switch module後，整個頁面就是那個module了，不可以有另外一個module的action path或form存在。當然，如果前面這個假設條件不成立的情況下，當然是使用module了。如果要說用不用module有什麼差別，我認為就如同JAVA的Class有沒有放在package裡一樣；如果你可以保證class name怎樣都不重覆，又在檔案不管有多少的情況下，都可以找到想要的檔案，那package的用處可能也不太大了。

做想做的事與得到想要的事

最近在讀的一本書：「先別急著吃棉花糖」，說明著延遲享樂才可以成功。我覺得這與利息的產生有同工異曲的妙用：你現在所做的事，隨著時間，在未來會有會更高更多的回饋。現在盡情放開享受生活，以後就會有不枉此生，不會有年少留白的遺憾(可能會是三餐不繼的覺得不枉此生)；現在努力，未來就會功成名就財富滾滾而來(可能再也沒有機會與體力四處遊山玩水)。換個角度來看，也就是說為了以後的回饋，現在必須要放棄一些事情，來換取未來的價值。
然而不管怎麼說，我認為最重要的還是要知道自己想要的是什麼。因為是自己想要的，所以未來不會後悔。現在努力工作，未來就不會後悔虛渡青春，因為得到自己想要的財富，反之亦然。這起因在於現在想做的事總與想要的事互斥，現在不放棄想做的事，未來就得不到想要的事。當然互斥是一個一種條件假設，並不是絕對。像有些人真的很喜歡工作，也可以因為工作而賺大錢，我想這種人應該很快樂吧(並非所謂的工作狂，工作狂之所以狂工作是有理由的，喜歡並沒有理由)。
我常在想，如果想做的事沒有副作用，可以直接導致想要的事的話，那該有多好。

BeanCoomparator

有沒有寫過自己的bean呀?自己寫的bean會有一個問題(當然不只一個問題)，就是排序。一般來說，要對物件做排序，要嘛是實作comparable的compareTo方法，要嘛是另外再針對每種不同的bean在Collection裡丟入Comparator。實作compareTo就顯得不夠彈性，另外再寫Comparator就顯得有些麻煩。但是，現在jakarta-commons-beanutils的BeanComparator可以讓你很輕鬆的建立comparator。
先看一下情境：假設我現在有一個menu物件，menu有子選單，是menu的一個property，型態是Set，名稱是menus；另外有一個orderSeq property，現在就是打算要讓取出來的menus依照orderSeq來排序。從資料庫產生物件時因故(反正就是有原因讓我們不能取出記錄時做排序，例如程式是別人寫的，programmer不想再去改之前寫的程式碼....)無法排序。現在我要對menu作排序。
先看一下代碼(唔..可能是最近老是在看大陸文章，台灣的講法是「程式碼」)：

public class Menu implements java.io.Serializable {
private Long pk;
private Set menus = new HashSet();
public Set getMenus() {...
public void setMenus(Set menus) {...

排序的程式碼：

Set menus= m.getMenus();
BeanComparator bc = new BeanComparator("orderSeq");
Collection returnedMenus = new TreeSet(bc);
returnedMenus .addAll(menus);

這樣所產生的returnedMenus就會依照orderSeq property來排序了。

權限模組功能搜集

我習慣使用Struts中的dispatch action來開發專案.
就經驗來說, 權限功能可以區分

1. 使用者有使用者群組的概念.每個使用者隸屬於某個群組.
   
2. 功能可依據Struts中 action,method去區分.每一組action,method定義成一個function.
3. function有function group的概念.
   
4. 每個群組可以使用數個function group.
5. 每個使用者群組可以設定except function.

不知道還有沒有其他可以填進這張列表?

Callieo's Tec: 李怡志的個人網站 Richyli.com

Callieo's Tec: 李怡志的個人網站 Richyli.com

工程師的笑話

參加產品demo可是不參與任何行動 , 猜一人體器官。

答案:膀胱(旁觀)。

可口可樂百年來最大的管銷失誤

可口可樂百年來最大的管銷失誤
這篇文文章說明1985年可口可樂推出新口味產品失敗的原因。而我比較著重在於樣本測試那一段:可口可樂掏資400萬找19萬消費著做口味測試, 但是有39%對新口味感冒。這個訊息顯示當新口味推出後也相同的會有39%的消費者會懷疑新口味。針對於19萬比上2億8仟萬(全美國人口數), 反彈也會成正比的增加。我想這也是導致可口可樂在推出新口味失敗的原因之一。只是在猜想, 如果可口可樂不理會這些抗議人口或是採用安撫手段安撫的話, 堅持推行新配方是不是會比較可以成功? 或者在推出新口味時, 不這麼大事宣傳, 而只是漸漸的推出新產品成功的機率會不會比較高?

新年開工

新年開工 , 除了對公司有一種莫生的感覺外, 也外加了一種懶懶散散的感覺。最主要的原因可能在於整個新年好像都是在忙錄中渡過。老婆昨晚也才在哀嚎:今晚是晚上睡得最久的一次;整個新年期間, 他都在忙著拜訪同姑姑舅舅姨婆姨丈。我自己也去拜訪了一位高中同學。
中國的習俗真是螫騰人。不過仔細想想, 對於一年下來都沒有聯絡的朋友, 難得的一次朋友聯絡期, 似乎也是有它必要的存在價值。就自身而言, 要不這次結婚要寄喜帖, 恐怕都要失去聯絡了。雖然對於這些朋友的失去聯絡不會太感到可惜, 但是還是有那麼些許的遺憾。
對於新年, 大多數的人都將他視為是一種假期, 現在想想, 將他視為親朋好友聯絡期會更好。

婚紗照(4)

連攝影師都說我們笑起來很像^^

婚紗照(3)

這可是我難得的一張獨照唷

婚紗照(2)

我們笑起來很甜吧^^

婚紗照(1)

最愛老婆笑的時候的樣子

好美唷

五月天的歌曲

在聽著五月天的歌, 才發現五月天其實很有市場眼光。他們發現了一個嶄新的市場:台語歌曲的搖滾市場。以前的台語歌, 大部份都是情歌, 無論是分手的情歌還是兩情相悅互訴感情的情歌。這點五月天也是一樣, 畢竟歌曲就是一種感情的表達方式。然而特殊的是五月天的的歌曲雜含了很多流行曲風, 這種曲風在國語流行市場裡是履見不鮮, 但是在台語市場裡, 這倒是很少見的。

這樣不可以

小時候 父母常說:現在我們會告訴你那裡做錯, 以後就不會有人告訴你那裡做錯了。 因此常說這裡不可以這樣做, 沒有人這樣做, 那裡不可以這樣做, 那裡要這樣做才對。
長大後, 也確實是很少有人在當時明指著說這樣做不可以, 或這裡應該怎麼做。而是在事後, 在做了之後會在背後指指點點說:那個傢伙搞不清楚狀況, 居然這樣做。然而就自身的感覺是:以前做事總是非常的不自由, 不自在, 都被別人限制住, 長大後, 雖然這層束縳沒了, 但是卻又要承擔做完事情的後果: 一是實質上的損失,這點還好。 二是別人的批評。
雖然所有的書上都說明了別人的批評是不需要在意的, 但是要做到這點還真有點不容易, 因為不知名的原因, 人總很希望都透過別人的肯定來肯定自己, 要得獎, 要稱讚...。從另一個角度來看, 責罵,批評就是否定自己。所謂的"爭一口氣", "不要被別人瞧不起", 這些描述詞都顯示了自己的價值bundle於別人的評價上。
很榮幸的, 我本身天賦異稟, 臉皮特別的厚, 做到這點還不難, 只是有時候父母仍會有些限制, 因為他們仍然很忌諱別人的批評。這跟需不需透過別人來肯定自己沒有關係, 只是在做事情的時候會有些限制。

STRUTS原來也可以整合JSF

既tapestry這種 page-event-base的framework出來之後, struts也出了shale framework來補足之前對於網頁event控制不足的地方。
struts-shale

結婚了(1)

2/18要結緍了, 最近一陣子都在為籌辦婚禮的事忙得暈頭轉向, 中國的禮俗真是麻煩。希望在有生之年的一個禮俗,可以照著西洋的方法來走, 乾淨、簡單。

用Hibernate做批次刪除與新增

用Hibernate做批次刪除與新增
對於單一table可以:

session.beginTransaction()
session.delete(pojo)
//沒有evict
session.flush()
session.save(userInputPojo)
session.commitTransaction()

如果是pojo中的set集合則

session.beginTransaction()
pojo=session.get()
Collection deleteTmp=new ArrayList();
for(element:pojo.set){
if(availableForDelete(element)){
session.delete(element);
session.evict(element);
deleteTmp.add(element);
}
}
session.flush();
pojo.set.removeAll(deleteTmp);
for(userInputPojo:userInputPojos){
session.save(userInputPojo)
}
session.commitTransaction()

注意事項

1. session.flush()要放在removeAll之前(不知道為什麼)
2. 單一table不能evict(不知道為什麼)
3. set裡要evict(不知道為什麼)
4. 要remove pojo.set裡被delete的pojo

希望能買的電腦

看著公司爛爛的電腦, 忽然很想生台新電腦出來....:

• 64Bit的雙核CPUX2 使用64 Bit的OS
• 4G的Ram
• 很好的顯示卡
• 300G的硬碟

還有網路卡, 無線網路, 固定IP,...

開發速度好慢

公司的電腦, 速度不錯, 記憶體也夠大, 可是在用jbuilder開發, 開到後來就是記憶體會吃到2-300MB。不過最令我自己感到生氣的是為什麼自己開發得這麼久。在上一間公司時, 開發速度會慢很明顯的是因為使用model2與model1的差別, 不過在這間公司, 大家都同樣使用model2的架構, 速度還會那麼慢, 我就很想不透, 難道我真的打字打的比別人慢? 還是工作時不專心?都在寫Blog? OO''

感覺上, 會花比較多的部份在於:

1. 一開始定了演算法, 或決定SD的部份, 可是在implement時, 會遇到一些困難, 而這些困難有時候會導致整個SD的framework改變。感覺上這可能是真的花比較多時間的地方。經驗所培養的直覺不足, 可能是導致這個問題的原因, 因為那些困難都是在SD時所沒有想到的。
   
2. 會在許多tradeoff之間花許多時間做考慮。
3. 會重覆寫一些別人已經寫過的功能。會做這種事, 通常是基於一些原因: 不想去看別人的程式碼、為了功能性的分類、別人寫的程式不完全適合自己使用, 所以會複製一份再來修正。
4. 會有一些SD的文件製作時間。例如像visual, 或是demo的prototype。這部份好像也是花蠻多時間的。

這些問題, 有解決辦法嗎?

重覆的OO的開發方式

使用OO的開發方式, 我都會先寫好method, 然後再實做method裡的方法。由於method是在一開始撰寫模組就命名好的,因此當中有許多功能相近,卻是2個不同的方法名稱, 導致之後再撰寫時, 一直搞得有點混亂, 總覺得這個功能好像寫過, 可是method卻明明是空的...。

public Object readRelFromByPk(String relFromtype, Long relFromId) ;

public Collection readRelFromDetail(PageIterator pi, String relFromType,
String relToType,
String conditionProperty,
String condition, String orderProperty) ;

當中有許近似的功能, 卻是放在2個方法中, 這都是在後來再重新檢視程式碼才發覺的. 不過在實作時, 卻會傻傻的copy 2份...。
還有可以使用明人的程式碼, 卻會再重新寫一份。

public Object readRelFromByPk(String relFromtype, Long relFromId) {
// Session session = HibernateSessionUtil.currentSession();
// return session.load(specifyRelDAO(relFromtype).getItemClass(),
// relFromId);
return specifyRelDAO(relFromtype).read(relFromId);

}

STRUTS VS JSF(2)

就這2天在研究STRUTS與JSF, 以下是感覺到的一些差異:

1. JSF聽說在Control上會比較弱, 但是不知道會弱在那裡。不過在JSF上並沒有看到如STRUTS般可以單獨執行1支execute method的方法。也許是弱在這裡。因為JSF有negative, 就如同STRUTS的struts-config, 都是負責流程控制。
2. 會吸引我使用JSF最大的原因在於使用Sutdio Creator-他的網頁編寫方式。然而使用了Strudo Creator後也就意味著網頁的美工也同時落入了programmer的手上。
3. JSF本身有TableSet這對分頁來說是很有用的。

在tapestry方面:

1. 聽說resource比較少, 有點擔心在實用上的問題。1個是在台灣, 因為resource少, 所以可能沒人在用, 沒人在用學了就可能沒什麼用。
   

BLOG轉換(2)

Blog的轉換終於完成了-。
花的功夫還不太多, 在轉換過程中最令我覺得稱奇的是BloggerStarSpot的操作介面。一個網頁這種stateless的東西,可以寫跟一般AP差不多的的程式, 我想真要花不少功夫吧。不知道這底層是用什麼語言寫的。在執得的時候,偶爾會看到.do出現, 可能是struts,不知道有沒有tapestry或JSF等技術。這也令我想要學JSF的心開始有了動搖。

心情懶懶, 需求變動不想改

不知道是不是因為昨天晚上太晚睡, 導致今天的工作情緒不太好, user的系統需求變動就不太想改。也不是說他們的要求太過份, 只是當初也沒這麼說, 只是說了要這種功能, 可是在做出這個功能後(XD,還挺複雜的功能),再嫌這裡不好, 那裡不方便。
心得是: 一個好的programmer應該站在user的角度來思考UI的操作。對於使用者, 可能方便性是第一優先考量。系統的彈性及需求變更會放在其次, 重點在於只要目前可以用就好了。這段描述的隱含假設是:

1. 使用者是新系統使用者。他們沒有舊系統遺留的操作習慣。
2. programmer需要對使用者的domain know-how有一定的認知。否則很難了解對於使用者來說什麼才叫做方便。

付出的代價是:

1. 之後可能會很難去因應需求變更。
2. 針對於web-base的操作介面, 為了滿足user的方便性, 難度會提昇很多。
   

Can JSF speed up Web application development?

這篇文章說明如何使用Studio creator及JSF快速的建立網站。
Can JSF speed up Web application development?

STRUTS VS JSF

這篇文章是由Craig McClanahan's 撰寫。他是STRUTS的原始創作者也參與了JSF的開發。
Struts Or JSF? Struts And JSF?

BLOG轉換

正嘗試著將BLOG的資料從無名小站轉到Blogger來, 之所以會選擇Blogger是因為

1. 沒有廣告。
2. googlo支援。Goolge向來是我最愛的網展/機構/設計模式。

然而轉換成本也花了我好多時間。然而在轉換的過程中, 我還是得捨去無名小站有提供, 而Blogger沒有提供的功能。其中一個就是文章分類。.....google的分類好像不是很好;或者說google並不著重於分類, 他用搜尋來完成分類的目標-方便找到標的物。

由我會作這次的轉換, 我想最大的原因不在於Blogger的各個特色, 而可能是我本身就是那麼的喜新厭舊。

檢討

昨天PM同我抱怨, 去客戶那裡裝設暫時設備時, 原本大家是要使用靜態網頁, 主管卻要將資料複製一份到暫存機器上。PM和我抱怨說主管總是堅持用自己的方法來做事, 可是卻是花了很多時間去完成。相同的情況也發生在我身上。這次的關聯設定程式, 也是依照我自己的方法, 可是實際完成的時間卻比我預期的要多了很多......多了太多。從之前被上間公司踢出來的情況來看, 這樣是行不通的。

為什麼會這樣子?

我 們都有自己的理由。我在寫程式上都追求相當程度的品質...或者說在做事情上都有追求相當程度的品質, 會用比較新的方法, 不過卻是自己控制不住的方法。去使用自己控制不住的方法, 是進步的一種方式, 可是卻不是商場職場該有的行為。主管這次會被PM這麼嫌, 我想是因為他覺得這個方法他比較熟悉, 但是他卻沒有用這個方法做過這樣的行為, 相較於將程式碼複製到另外一台機器上, 寫一個靜態網頁要容易的多了, 因為在複製時, 作業環境已經不一樣, 便有許多參數需要做調較。不過不管是什麼原因導致主管會花了許多時間在做這件事, 我所認為的1個重點是他"習慣"這個方法可是沒有這個經驗。我想這是經驗上的問題。另1個是他習慣於使用自己的方法。這點我覺得有點要命。因為自己習慣的方法不見得是最好的方法。有時候他在同我們說某個東西的效率如何時, 他會說:這簡單, 寫一支程式跑一跑就知道了。有時候我會想: 這會不會太小題大作了點...!!難道重點在於習慣?一開始我認為他的作法是殺雞用牛刀, 也許有些人也會認為我的做法也是一樣, 總認為他們自己的方法會比較簡單。但是我想習慣可能才是重點, 只是有時候, 我習慣的方法對於做某些事來說, 真的是殺雞用牛刀...,而且會handle不住, 也可能不是最有效率的。

那該怎麼辦?

1. 沒事要練練自己handle不住的技術。
2. 有事要使用自己handle得住的技術。
3. 在做事之前先問問看大家的意見或調查一下各種方法, 討論一下那種技術才是解決問題的最適方法。

新年新希望

以前每當這個時候, 老師總會叫我們用這個標題做作文題目,那時只有無聊加煩悶可以形容。長大後, 居然重新在做這種事。不是別人逼,而是替自己為未來的一年訂一個目標, 期許自己能有進步、能在那裡進步、能進步到什麼程度。對於像我這種日出而作日落息的上班族, 這是一種有必要的guildline。會覺得這件事對我來說很重要,是因為在思考了3秒後, 我找不太出來今年的目標應該定位在什麼地方。希望有很多, 可是不知道那一個該是今年的希望:減肥,學英文,學電腦,賺錢,練口才ETC...。