五月天的歌曲

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

這樣不可以

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