2006年11月1日 星期三

OOAD-導入 J2EE 質疑與解說


其實談到 OOAD 很多人的見解都不同 , 像我們公司裡面一堆 微軟派(VB + ASP)的 ,
在先前我們導 J2EE 時 , 有引用了一些Framework(Struts) 或是樣式(MVC) ,
最常碰到的質疑


質疑1: Java (J2EE)寫系統真難用 , 一個功能要分成很多個Class 跟頁面才能完成
解說:
當你將Web 系統使用MVC 觀念並且導入 Struts Framework 時 , 沒錯一個功能是要分成很多個Class 跟頁面才能完成 (但是這些增加的工作 , 有他背後的效益在 , 例如較易維護修改等等)
而質疑的人 , 常常是寫ASP的 ,寫ASP 的沒有引用所謂的MVC 觀念來開發 , 所以相關的檔案數就會比較少 , 有沒有看過把 輸入畫面 , 處理頁面 , 錯誤處理頁面 , 重導頁面通通寫在一個 asp 檔的沒有 ,
檔案數只有一個 , 可是有比較好維護嗎???
如果用ASP 開發時 也導入了 MVC 的樣式 , 那麼它的檔案數也會變的多起來 ,
這個跟你用什麼語言沒關係 , 而是你用了哪些樣式(Patterns)
可是質疑的人根本就不懂 , 他只單純的認為J2EE 就是難用...
可他不知 , MS 系列的開發 , 一旦也導入了相關的設計樣式時 , 也一樣不太好用...

質疑2: Java(J2EE) 是 OO 導向 , 很難學 , 很難用
解說: 看起來好像如此(當時 .Net Frame work 1.0 還沒推廣) , 許多玩VB 的同事質疑 ,
但是今天 .Net 2.0 已經都出來了 , 即便是VB 到了 VB.Net
你也不能以VB 的玩法去寫VB.Net  , 而且 .Net 幾乎都是 OO 導向 ,
(還要再找藉口嗎 ? 當作是自己不想要會的理由嗎 ?)
或許可以問問那些提質疑的人 , 是不是改成 .Net 他們就有把握可以做的出來???

注意: 我不是說 .Net 不好 ,  爭論 J2EE 或是 .Net 那個比較好 , 並沒有意義
(你個人喜歡用什麼就用什麼 ,
但是就企業來說 , 必須要有一個大方向在 , 用的東西太多太雜 , 只是增加維護人力罷了 ,
一個維護人力又要會 AS400 又要會 .Net 又要會 J2EE , 又要會 #X&$# , 又要會#X%$ ,
苦的是維護人員 , 出包了是整個IT 部門要負責

選 J2EE 或是 .NET 都可以 ,

但是如果有公司是兩邊都選的 , 只是苦了那些維護的人 ,
明明本職技能就差了 , 還要都摸一點 , 結果更是什麼都不會...)
我自己也熟MS的東西 也實際開發過相關的系統 , 對於MS 或是 J2EE 我都可以玩 ,
(沒有一定要偏好哪一種)

J2EE 或 Net 或是 OO 都只是他們的藉口罷了 , 不會的永遠不會...

2006年10月13日 星期五

分析_讓人銘記在心的主角_就是不斷的給他苦難


分析_讓人銘記在心的主角_就是不斷的給他苦難

忘記是哪個作家說的 , 不要對自己筆下的主角人物太好 ,
要給那個主角(男主角 , 女主角) 不斷的磨難與磨練...
根據這個法則 , 有些主角越是受到痛苦的折磨 , 越能獲得人心(讀者 / 觀眾)

所以像金庸筆下的 楊過 , 讓他身世坎坷 , 讓他受到欺凌 , 讓他斷臂 , 讓他與心愛的小龍女分離 ...

又像 喬峰 從眾人敬仰的英雄豪傑 , 變成人人喊打喊殺的異族 , 又來了一個對他傾心的阿朱 ,
有那麼一個機會可以兩人過著與世無爭的放牧生活 , 卻又為了報仇 , 親手打死了阿朱 , 又回到了孤單一人 ,  甚至到了最後 , 必須死在兩邊都不承認他的中間 , 來替自己的一生畫下句點...

而越是令人落淚的愛情故事越是如此 ,
反正呢 , 不是男主角死了 , 就是女主角死了 , 為什麼?
因為只有不完美的愛情 , 才會令人記住 , 也因為如果兩方可以順利的繼續下去,
也許接著的 , 是兩方的爭吵 , 又或者是一方受到誘惑 , 又或者是家族 , 朋友等其他因素而爭吵 ,
最後完美的愛情只留下了一堆令人嚼之無味的殘渣, ...也許就這麼畫下句點 ,
令人感動落淚的愛情故事嗎 ? 沒有 , 現實中很難存在

東京愛情故事的莉香與完治 , 或許也因為他們沒有在一起 , 他們的愛情也讓人印象深刻
還有很多吧 , ... , 看看日劇與韓劇 , 受歡迎的愛情劇 , 多多少少都有這種味道在吧...

2006年10月12日 星期四

程式設計-應用系統_多國語言_設計及注意事項01


現在的應用系統 , 因為全球化的關係 , 除了商業化套裝產品之外 , 一般大型企業內部開發的系統也會開始講求要支援多國語言的需求.

講支援多國語言其實也是一種含糊的說法,因為有很多細項可以談,這些細項逐一列出來,你就會發現為何說支援多國語言是一種含糊的說法.
首先有3個名詞要注意的,
1.語系(或者稱之為語言 Language)
2.編碼(Encoding 或 Charset)
3.字元集

(I)語系/語言/Language
以語言來看 , 你直接看一下IE的語言項目就會知道
IE 功能表-> 工具->網際網路->語言
光是中文就有分為
中文[zh]
中文(台灣) [zh-tw]
中文(中國)[zh-cn]
中文(香港特別行政區)[zh-hk]
等等.

那英文又可以分為
英文[en]
英文(美國)[en-us]
英文(英國)[en-gb]
英文(加拿大)[en-ca]
等等.

或者是日文,韓文等等.
語言選項代表的可能是詞彙的替換,也可能是編碼的配對選擇.
例如當你選擇語言為 zh-tw 時,一般來說配對的編碼會是 Big5 或是 UTF-8
又或者當你選擇語言為 zh-cn 時,一般來說可能配對的編碼會是 GB2312/GB18030/HZ  或者是 UTF-8

另外一個則是詞彙的替換 , 例如
中文(台灣)用語: 選單 , 休眠 , ...
中文(中國)用語: 菜單 , 冬眠 , ...
再來就是貨幣格式 , 日期格式 , 時間格式等的替換

講了一大段 , 還沒有講到重點  , 只講到一些很基本的項目  , 有點累先休息一下...
可能要至少要講 7 篇才有可能把東西講清楚

2006年10月8日 星期日

男人不壞 , 女人不愛?

男人不壞 , 女人不愛?

這個問題已經有很多人討論過了 , 也不是什麼新的話題了 ,
來看一個最實際的例子吧 ,
有很多女生都拼命說 , 我最討厭抽煙的人 , ....然後呢 , 可能她就找了一個會吸煙的男生當她的男朋友
是怎樣 , 你自己選擇了一個你不喜歡的 ,

同樣的 , 女生可能會選擇一個花花公子當男友 , 即便他花花的聲名在外 ,
然後呢 , 過不久 , 花花男友劈腿了 , 變心了 ,
 女生這時就會找一大群朋友(親友團)哭訴 , 那男生有多壞 , 不應該這樣對她 ,
怪誰呢 ? 這是你的選擇 , 不是別人強迫你的 ,
有些女生還屢屢專找這種男生  , 之後被玩了 , 就怪說 男生都很壞 ,
搞到後來 , 這些女生眼中就只有男生都是壞的 ,
拿好人卡的男生呢 ?在這些女生的眼中根本就是透明的 ,
-----------------------------------------------------------------------------------------------------------------------------
你不能去點一份麻辣鍋 , 然後要求說要不麻不辣 , 不麻不辣的麻辣鍋嗎 ?
那就不是麻辣鍋了!!!

同樣的 , 如果你選擇了一個花心的男人 , 然後又要他不花心 ,
不是沒機會 , 只是機率不高 ,
一個花心的男人不花心 , 那就不是一個花心的男人了....
-----------------------------------------------------------------------------------------------------------------------------
我一直在想根據進化論 , 物競天擇 的理論 ,
壞男人(花花心) 因為花心 , 所以他的練習機會就多 (你看如果一個男人 , 他玩過的女人可能是拿好人卡男人的 100 倍 , 也就是說 , 壞男人比好男人多練習過100次 , 包含要去哪裡吃飯 , 會去哪裡玩會有情調 , 如何做會讓女孩子感動等等 , 包含肉體上的技巧等等 , )
你說 女孩子會選誰 ?
 知道如何取悅自己的壞男人還是只有一片真心沒有技巧不知如何取悅自己的好人卡男人 ?
這時男人的忠實不變心 , 突然就變成了笑話 ...
女孩子還是會選擇花心的 , 所以呢? 男人要不要學習與改變 ?


鳥的嘞 , 說說罷了 , 我還是沒種做壞事....

2006年10月6日 星期五

除錯心法4


除錯心法9:
當系統發生錯誤時,請檢查你的輸入內容是否有錯誤.

錯誤這個用詞有時被拿來濫用了,大家都知道電腦軟體是垃圾進,垃圾出.

舉例來說,你如果使用Outlook 來發信給你的朋友時,你的朋友一直收不到信,
這時就有可能有人說這是Outlook的錯,但是有可能是你自己輸入的Email 根本就不是你的朋友的Email .

所以這個叫錯誤嗎? 

自己輸入錯誤的資料,系統只是忠實的根據你輸入的資料去產生輸出而已.


這種事發生的機率也不少.

2006年9月29日 星期五

除錯心法3


心法8:詳細的閱讀回報的錯誤訊息以及log file
發現有很多人對於系統回報的錯誤訊息內容視若無睹 , 然後拼命要找人幫她解決問題


舉例來說:
今天在協助別人除錯某個報表時 , 發現報表程序有被執行 ,但是沒有如預期的送出報表 email
試了幾次 , (沒錯 我自己也會耍白痴 , 對於該檢查的錯誤訊息略過 ,
不過我略過的原因是因為一開始我去協助除錯的時候 , 負責的人就告訴我 有錯誤產生是那個報表程序本來就會有的)


再看一次錯誤訊息 , 發現錯誤訊息中有一個項目是說: 報表程序找不到某一個目錄下的某個附件檔案
(這個報表程序是會發出Email 並且將特定檔案當作附件送出) ,


我去檢查了一下那個目錄 , 發現沒有那個檔 ,
然後我想辦法 造了一個 報表程序要的檔案 , 重跑了一次報表程序 就有正常的產出了



我協助除錯的範圍還滿廣的 , 系統的設定 , 程式的內容 , 一些阿貓阿狗的問題
都會丟到我這裡來 ,
也算是同事長官們看的起我 , 給我機會 ,


我想說的是 在外人眼裡 , 我除錯可能就跟喝水一下 , 幾乎都能解掉 ,
就算不能解掉 , 也都找出問題的癥結 ,


我可以跟大家說 , 那些問題其他人 100% 也都能解的出來 , 只是時間可能花的比較長 ,


很多人告訴我  , bug 解不出來 ,
我實在不好意思告訴她們:
如果你願意當個傻子 , 不斷的嘗試 ,
將所有可能的變數 , 排列組合都測試一遍 , 你一定可以解的出來的 ,


可惜很少有人願意當傻子 , 傻傻的在自己的位子上 , 試著數種 , 幾十種 可能的解法
發現這個解不出來 , 就動腦想自己 還有哪裡忽略了  , ...
是不是漏了什麼沒有注意到 , ... , 動腦之外 , 要動手去測試 , ...
很多人可能在第二種解法解不出來時就放棄了...


如果你知道一個被別人號稱是"大師"的傻子
在別人面前可能三兩下就可以把別人困擾數個人月的問題 解決掉 ,
但是實際上在面對各式各樣的除錯歷程 卻是堅持奮戰 , 屢敗屢戰 , 直到把問題解決為止


被人稱"大師" 只是口惠而實不惠 , 調整工作職等時 沒有自己的份 ,
協助除錯 , 並不是自己份內規定要去做的 , 協助除錯也是需要佔用到自己正常的工作時間的


想除錯 沒有那麼難
不想用心 , 就解不開

2006年9月23日 星期六

除錯心法2







心法4:有時除錯不是只有靠技術,要靠正確的觀念跟概念.
心法5:比對法,找出異動點.
心法6:先畫出部署的架構圖(概念或是實際的)
解說:
那一個最近幾個月發生的除錯案例來解說好了,在部門內部會議中,有其他同仁反映了一個問題他們已經弄了一個多月還沒有搞定的問題.
他們使用ETL工具在對AS400與AIX進行轉檔,同時也會對MS SQL進行轉檔.
那個ETL工具是在執行在AIX上面,使用的是AIX上面的ODBC設定去對DB2或是Wiindows 上的MS SQL 做存取.
他們發現對MS SQL 一直無法正確存取並且寫入資料

其中的一位處理的同仁D在白板上說明了他的觀點 , 他認為是 MS SQL Server上面的ODBC 版本不對 ,
他認為要更新 MS SQL Server上的 MDAC 套件...

我當場聽了就有點昏去 , 那位同仁D據稱是DB高手 , 可能是我的表情太不好看了 , 老闆當場就將這個問題指派給我處理

隔天早上 , 我去找了相關同仁詢問必要的資訊 , (心法2:聆聽報案者的解說)
其中一個負責的同仁J告訴我 , "他們的作業原來是可以的" , [表示不是他們的程式或是設定錯誤]
我又去問了另外一位同仁B , 他說他們存取的MS SQL Server資料庫的機器並不是放在機房中, 而是擺在 IT 同仁的腳下,最近大家剛剛換了位子.[解說:我們一般的個人腳下的機器都是使用DHCP而不是固定IP]<-心法5,找出異動點.這裡發現有一個異動點
我又回過頭去請同仁J幫我在AIX上面叫出ETL使用的ODBC設定檔.
這麼一檢查,發現他們所使用的連到那台MS SQL 的設定是使用IP 而不是使用 Hostname 設定.
於是我請同仁J修改設定將原先的IP改成那台MS SQL 機器上的新的IP.並且將這個ODBC設定儲存.
然後再請網路管理的同仁K開放防火牆,讓AIX可以連到那個MS SQL機器(當然是設定成新的IP)

就做了這麼幾件事, 接著請同仁J再去測試 , 馬上就成功了.
一個困擾他們至少一個多月的問題,在半個早上就被我解決了.

這中間,所有的作業都是其他同仁進行的,我只有出一張嘴而已.
ETL 我不熟 , AIX 上的ODBC 設定檔的叫出 ,我也不會,防火牆的設定修改,我也不會.
那我憑什麼可以把問題解決?我靠正確的觀念與概念.

首先
同事D提到的MDAC 那個是DB Client 端的存取元件 , 但是在這個問題中 , 我們的DB Client (ETL)是在AIX 上面, 不是在 Windows 上 , 更何況是要把 MDAC 裝到 DB Server端去, 所以這個根本就是個錯誤的解法.
(心法6畫出架構圖,我在一開始的會議中就把圖畫出來,並且分出誰是DB Client 誰是DB Server的腳色,我才能快速的去確認問題的真正的癥結點在哪一部分,不然按照同事D的建議解法,可能到今天還在找問題出在哪裡!!!)

以上案例是我碰到的並解決的真實案例.我無意拿這個案例去攻擊或者是貶低任何人.只是拿來作為除錯心法的解說案例之一.
所以你不會看到內文中提到我們公司的名稱或是部門名稱或是同仁的姓名.

如果有其他同仁看到了,你會知道我是誰.但是我只是拿出來做解說,並且作為自己的除錯心法中的一個案例.

心法7:除錯有時需要一點運氣.
是的,有很多問題我相信別人也能解,但是我常常都能在別人解了很久解不出來的狀況下,把問題給找出來並且處理掉.
有時要靠一點運氣.但是人不會一直都有好運氣,所以我還是要靠正確的觀念與知識去除錯.