如果引用或轉貼,麻煩註明出處與本網誌連結,否則視為侵權。

2005年6月20日

J2EE Design Pattern - Business Delegete筆記

Fred Wang中譯與整理 2005/06/20 (http://fredwang.blogspot.com)
解決問題 :
隱藏遠端存取商業服務(business service)元件的複雜度

直接存取遠端商業服務(business service)元件的問題如下 :
1. 直接與商業服務(business service)介面程式互動,當商業服務程式碼異動時,需求端的程式碼也要異動。這將增加所需的維護量及降低系統的彈性。
2. 與網路的效能有關,當需求端直接與商業服務API互動時,需求端單一的動作可能需要與商業服務(business service)多種的互動,這將導致商業邏輯包含到需求端程式內, 且沒有任何需求端的暫存機制(caching)或服務結果的彙整,將降低可維護性。而這些行為跨網路執行也降低網路的效能。
3. 與商業服務API緊密的互動表示需求端程式內需要一些與遠端分散式中介層(remote distributed middle tier)有關的基礎程式碼,這些基礎程式碼就是命名服務(naming services)如JNDI, 網路連線失敗的處理與重試的邏輯。

重點 :
1. 從展示端元件及客戶端如devices, web services and rich clients等存取商業層元件。
2. 將客戶端與商業服務的耦合關係最小化,隱藏商業服務內含的應用細節如naming / lookup services and access
3. 將網路例外處理(exceptions)轉成應用或使用端的例外處理,如java.rmi.Remote exceptions, JMS exceptions等。
4. 隱藏服務的建立,重新設定及失敗重做(retry)等,不必將問題丟回給需求端。
5. 將商業服務的結果暫存(cache)以降低網路負擔,提升效能。

Business Delegate使用Service Locator來找到business service,Service Locator負責隱藏商業服務的lookup程式碼內的應用細節。
與 Session Façade為一對一的關係,因為與多個商業服務互動的邏輯封裝在Business Delegate內,而這些商業服務的細節又封裝在Session Façade。

Class Diagram


Sequence Diagram



實作策略
1. Delegate Proxy Strategy
Business Delegate以interface的形式存取商業服務API內含的功能,作為遠端商業服務的代理(proxy),除此之外還可加上一些驗證及暫存商業資料的機制。暫存(caching)機制可以包含對session bean’s home or remote objects的遠端參考,藉由減少lookup的次數以提升效能。
Business Delegate也可以使用Service Locator將遠端的參考轉成字串表示(IDs)。
2. Delegate Adapter Strategy
在B2B的環境,與你的系統互動的系統可能不是J2EE的應用,那麼必須提供與這些外部系統互動的解決方式,最常見的是使用XML。

Sequence Diagram using Adapter Strategy

2005年6月17日

搜尋引擎的其他選擇 - 使用群組技術的搜尋引擎

使用群組技術的搜尋引擎

搜尋引擎的技術, 仍不斷演進, 下面幾個運用群組技術的搜尋引擎, 也令人驚艷

群組技術 : 試著在最吻合搜尋條件的網頁之中尋找模式,以便把搜尋結果分類成更小的群組。分類模式可能包括常用字、同義字、相關字,甚至可能利用特殊的規則,辨識出高層次的觀念架構。這類系統會為每個連結群組標上相關字詞,使用者可選擇其中某個群組,進一步縮小搜尋範圍。

1. Clusty
2. Mooter :以視覺方式把群組呈現在搜尋者眼前。在搜尋結果頁面的正中央,有個代表所有結果的按鈕,周圍則是各個代表次分類的按鈕,看起來就像一個輪軸。只要點選群組按鈕,就可讀取相關連結的清單,新的相關群組也會列在一旁。Mooter還會記憶使用者選擇的群組,只要鍵入新的查詢項目,然後點選「縮小搜尋範圍」(refine),Mooter就會在先前選取的群組中進行新的檢索,為使用者找出更精準的結果。
3. Kartoo : 運用了視覺效果。把使用者的查詢傳送到其他搜尋引擎,然後以視覺方式呈現出匯整後的結果。Kartoo不僅列出了各網站的關鍵字,而且會顯示一張「地圖」。地圖中以圖示代表重要的網站,不同的網站之間連有路徑,並且在路徑上標示著網站之間的關係。使用者可點選標示,縮小搜尋結果的範圍。

參考 : 比Google厲害的搜尋引擎

2005年6月15日

J2EE Design Pttern - Interceping Filter 筆記

J2EE Design Pttern - Interceping Filter 筆記

Fred Wang (http://fredwang.blogspot.com)
2005.06.15

用來解決什麼問題
將request前置處理與response的後置處理與核心應用程式碼分離, 並集中處理避免相同的程式碼, 在不同的程式內剪貼使用

Interceping Filter的用途 :
1. login checking : 檢查是否合法使用者 (這個常用!!)
2. IP banning : 禁止或允許某些IP
3. 限制http request只能用哪些url path
4. 檢查是否使用者為網站所支援的瀏覽器型態
5. Character encoding : 例如將 response/request 轉成一致的格式
6. 檢查request是否加密或壓縮
7. 紀錄(Logging)每個request的資訊

http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/Filter.html
內提到的應用有下列九種 :
1) Authentication Filters
2) Logging and Auditing Filters
3) Image conversion Filters
4) Data compression Filters
5) Encryption Filters
6) Tokenizing Filters
7) Filters that trigger resource access events
8) XSL/T filters
9) Mime-type chain Filter

Class Diagram


Sequence Diagram


實作策略
Standard Filter Strategy
- 使用deployment descriptor(web.xml)增加或移除Filters, 並設定相關的控制
- Servlet 2.3 Interface : javax.servlet.Filter
- 不提供postprocessing
Custom Filter Strategy
- 彈性及功能都比Standard Filter Strategy差(用Servlet 2.3的標準功能較有彈性也比較強大)
Base Filter Strategy
- 當作所有Filters的共用superclass
Template Filter Strategy
- 專注於preprocessing and postprocessing logic的實作

Web Service Message-Handling Strategies
Description :
- Handle pre and postprocessing of web service requests
- Message handling : intercept incoming messages and perform pre and postprocessing on information in the message
Ex:
- Validate a digital signature
- Sign a message
- Log information about a message
A. SOAP With Attachments API for Java or SAAJ
- Custom SOAP Filter Strategy
- Using a SOAP library, such as SAAJ
B. JAX-RPC Filter Strategy
- Performed by the JAX-RPC runtime engine
- Build message handlers with JAX-RPC using SAAJ

參考 :
1. Core J2EE Patterns - Intercepting Filter , Sun Microsystems
2. JavaWorld技術論壇 http://www.javaworld.com.tw/jute/post/view?bid=25&id=19581&sty=1&tpg=1&age=0
3. Core J2EE Patterns : http://corej2eepatterns.com/Patterns2ndEd/InterceptingFilter.htm

J2EE專案10大風險

J2EE專案10大風險
原文在 http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html
避免本文所列之10大J2EE風險,確保企業級Java專案成功

作者:Humphrey Sheil
簡體中文翻譯參考:Blueski
繁體中文整理與翻譯 : Fred Wang (http://fredwang.blogspot.com)

風險1:沒有真正理解 Java, EJB, 和J2EE

這個問題可以分解為3個部分,以便於分析:
1. 沒有真正理解Java
症狀:
A 重複開發JDK核心API中的功能或Classes
B 不懂下列中的某些項目:
- 垃圾收集器 (train, generational, incremental, synchronous, asynchronous)
- 物件在何時能被進行垃圾收集 -- dangling references
- 使用的繼承機制及其優缺點
- over-riding和over-loading方法
- 為什麼java.lang.String 提供的性能不好
- Java中的Pass-by reference語意和EJB中pass-by value語意的比較
- 使用 == 或者使用equals() 方法 for nonprimitives (非基礎型態, 基礎型態primitives有char, byte, short, int, long, float, double, boolean )
- 在不同平臺上Java threads的運行順序方式(例如是否是pre-emptive方式)
- 新線程(Green thread)和本地線程(Native thread)的比較
- Hotspot技術(以及為什麼舊的性能調整技術降低了Hotspot 的優化效果)
- JIT,以及什麼時候好的JIT變得不好
- The Collections API
- RMI

解決方案:
需要不斷加強Java方面的知識,尤其是深入瞭解Java的優勢和不足之處。Java的存在價值已經遠不止是一種語言,了解平臺(JDK及工具等)也同樣重要。嚴格地說,你應該是經過認證的Java程式師,如果不是的話,也許有時會為還有那麼多不知道的內容而感到驚訝。另外,也可以加入Java的郵件列表(Mailing List)等。從同行中學到技術,這將是你最好的資源。


備註:
如果你或者團隊中的成員不真正瞭解程式語言和平臺,怎麼還能希望企業Java應用系統能夠成功呢?能幹的Java程式師之于EJB和J2EE,就像是鴨子之于水一樣。相反的,比較弱、沒有經驗的程式師只能開發出品質低劣的J2EE應用程式。

2. 沒有真正理解EJB
症狀:
- EJB在第一次被叫用後沒有再被叫用到(尤其是stateless session bean)
- 沒有重複利用價值的EJB
- 不理解開發者要做什麼,容器(Container)提供什麼
- EJB沒有依照規範定義(fire thread, 載入了native libraries,試圖執行I/O,等等)

解決方案:
要加強關於EJB方面的知識,可以找一個周末來閱讀EJB規範 (1.1版有314頁),然後閱讀2.0規範(524頁!),這樣可以瞭解到1.1沒有定義而在2.0規範中補充的內容。EJB開發者從18.1及18.2章節開始閱讀是比較合適的。

備註:
不要從供應商(Vender)的角度去看EJB,要確切地知道規範所支援的標準EJB模型和基於這些模型的特殊應用之間的區別。這也有助於移轉到別的供應商平台(或版本)的時候所用。

3. 沒有真正理解J2EE
症狀:
- "Everything is an EJB"的設計方式
- 用手工交易(transaction)管理取代了容器-提供(container-provided)的機制
- 自行設計安全機制 -- J2EE平臺在企業級計算中,從表示邏輯到後臺處理,已具有最完整的整合安全架構。

解決方案:
學習J2EE的關鍵元件,並且瞭解它們的優缺點,依次用它們替代每一個服務;“知識就是力量”在這裏行之有效。

備註:
只有知識能夠彌補這些問題。好的Java開發者會成為好的EJB開發者,此後也應逐漸成為J2EE得道高手。Java和J2EE知識掌握得越多,設計和開發工作就會越出色。在設計階段一切都會有條不紊。


風險2: 過度設計(Over-engineering) (採用 EJB或者不採用EJB)
症狀:
- 過於龐大的EJB
- 開發者無法解釋EJB做什麼,以及其間的關係
- 當需要重複使用某些EJB、元件或服務時, 卻無法做到
- EJB啟動了新的交易,而該交易本該由一個已存在的EJB啟動
- 為了安全,把資料分離級別(Data isolation levels)定得太高

解決方案:
過度工程化的解決之道就是極限編程 (XP)方法:用最小的設計和程式碼來滿足需求。除非明確知道今後可能的需求,如將來的負載要求,或者系統在最高負載下的表現,否則大可不必為系統將來的情況做太多考慮或猜測。另外,J2EE平臺已經定義了可擴充性(scalibility)及容錯(failover)等特性,可以讓伺服器系統為你進行處理。

在小型系統中,只包含一個個小元件,這些元件只做一件事,且只要把這件事做好,系統穩定性就已經得到了提高,而且,系統的可維護性會變得很強,在未來要增加功能以滿足新的需求也將變得容易。

備註:
除了上面所列方案之外,可以運用設計模式(Design Pattern) -- 它們可以顯著地改進你的系統設計。EJB模型也廣泛使用了設計模式。例如,每個EJB所帶的Home 介面就是Finder和Factory模式的實例。EJB的remote介面扮演了一種實際bean實現的Proxy,並且對於提供容器的能力也是至關重要的,這些容器截取叫用信號並提供如透明(transparent)的負載平衡的服務。

另外:僅僅是為了使用EJB而使用EJB是危險的。在你的應用系統中的某一部分可能並不需要EJB,甚至你的整個應用系統都不需要。這是過度工程化所走的極端,而且我確實也目睹了一些良好的servlet和JavaBean應用被重構為EJB,而這樣做並沒有很好的技術上的理由。


風險3: 沒有將商業邏輯與前端顯示邏輯分離
症狀:
- 過於龐大、不便的JSP程式
- 在商業邏輯改變的時候必須修改JSP
- 在要求改變使用者介面顯示的時候需要修改並重新配置EJB和其他後臺元件

解決方案:
J2EE平臺使你有機會將顯示邏輯和流程控制分離,進而與商業邏輯分離。這稱為Model 2架構。

備註:
使用一致性的設計來進行用戶介面框架(UI Framework)的連接(例如可以使用taglibs),這將幫助你避免邏輯分離的問題。不要擔心需要自己建構GUI framework, 已經有許多現成的應用可供選擇(例如Struts等, 對每一個分別進行評估,然後採用最合適的框架(framework)。


風險4: 沒有在開發環境中進行適當的配置
症狀:
- 經過多日或數周的時間才能轉到實際(Live)系統
- 上線過程仍存在大量的風險,有很多不確定性及主要的功能情境(scenario)沒有被測試到
- 實際(Live)系統中的資料和開發、測試中的資料不同
- 無法在開發者機器上進行建構 (Build)
- 應用行為在開發、測試及生產環境中各不相同

解決方案:
解決之道是忠實地複製實際(Live)環境到開發環境,讓開發環境接近於要上線的實際環境。如果未來環境是JDK 1.2.2及Solaris 7,那麼不要在JDK 1.3及Red Hat Linux上進行開發。對於所用的應用伺服器也是如此。不可預期的資料透過下面過程就不會發生:
- 資料核對(Validation)規則
- 系統行為測試
- 系統元件間的協定(特別包括:EJB-EJB間以及EJB-資料庫間)

最糟糕的是,這樣還可能發生異常、空指標,以及你從沒見過的問題。

備註:
開發人員常把安全性問題放到Test階段才開始解決。要防止這樣的陷阱產生,你也可以花費同樣多的時間在業務邏輯中改進安全性。

上線(Go live)是一個複雜的過程,其中充滿了技術性問題和非技術性問題。你可能會陷於想不到的問題中。開發及測試環境過程提供更多產生這些問題的機會,及發現這樣的問題的地方,利用它,就可以大大減少風險。

你做的專案越多,你就越能瞭解什麼是可行的,什麼是不可行的。盡量將工程問題記錄下來,以避免同樣的錯誤重複發生。



風險5: 選擇了不當的供應商
症狀:
- 開發人員要使用更多的時間來處理工具方面的問題,而不是很有成效地使用這些工具
- 為了應付已知的和未知的問題,而不得不進行大量的系統重新設計
- 在不同的工具之間很難進行整合(應用伺服器與IDE工具,IDE工具與除錯器,原始碼控制與建構(Build)工具,等等)
- 對於IDE工具和除錯器等,開發人員往往排斥它們,而推崇自己所喜歡的工具

解決方案:
為了避免風險5,你需要一個很好的供應商選擇程序,風險10的解決方案也適用於此。
要真正評估IDE工具的方法就是實際地使用它。而評估一種J2EE應用唯一的方法是建立一種概念試驗(POC)來進行證明,在試驗中要包含你的應用框架。你不會希望在花費了3個月時間進行了培訓和開發後,在使用時又發現一些bug。

假設在開發到一半的時候,突然發現你的工具集有問題,你就會發現工具的驗證比其他的事情更為重要。如果所選的應用伺服器不能充分滿足你的需要,你只好修改原先的設定。如果IDE不好,則需要設置最低限度的程式設計標準,並讓開發人員任意選擇他們認為最有效的工具。

備註:
要真正瞭解到哪一個供應商對一項特殊的任務來說最合適,其實並不是一件一次性決定的事情。你需要不斷地跟蹤與評估這個市場。例如,在過去的一年裏我用過4種不同的IDE工具,這取決於我使用了什麼樣的應用伺服器、平臺,是否使用EJB等。


風險6: 不瞭解你的供應商
症狀:
- 開發所用時間超過了最壞預測的時間1/3以上
- 供應商已經提供了某項功能,但開發者在不知道的情況下重新進行了該項功能的開發

解決方案:
為了避免這樣的風險,可以訂閱供應商的網上資源,例如郵件列表、新聞群組、版本資訊(尤其是其中的bug修復的說明等),你能從中得到無法估量的重要資訊。

一旦你已經選定了供應商,那麼立即就要投資進行培訓,並且盡可能趕在專案啟動以前完成。然後,逐漸在團隊中建立對此供應商的認識及信任。試著建立幾個EJB並部署一下,再用表示層技術 (Swing GUI, JSP等)來叫用它們。如果你既要建立開發環境,又要同時在實現專案目標,就會產生一些不必要的衝突。實際上,我也見到過一直沒有進行建構過程的情況:“我們沒有時間。”因此,這些工作必須提早進行。有些人會說:“我們的計劃中沒有為我們提供這些時間。”我的回答是:“你的計劃中並沒有不給你時間使你不這麼做啊。”

備註:
在J2EE世界裏,各供應商產品的技術相容性究竟如何?讓我們看一下IBM和BEA的具體分析吧。兩者都分別在各自的應用伺服器中支援EJB 1.1。那麼,實際上BEA WebLogic 5.1和IBM WebSphere 3.5究竟有多少相似之處呢?
1. BEA WebLogic和IBM WebSphere的系統配置和管理方式幾乎完全不同。
2. IBM在WebSphere中採用了全面的GUI環境,而與之相對的是,BEA 在WebLogic中提供一整套命令行。
3. IBM WebSphere使用IIOP來和CORBA異常進行通訊,這些異常對程式師來說是可見的;WebLogic根本沒有CORBA構造,而預設使用t3協定。
4. WebSphere和Visual Age銜接緊密,而WebLogic是IDE無關的,實際上,你幾乎可以使用任何的開發工具。

由此可見,差異還是相當多。如果你是一種應用伺服器的專家,並不意味著你就是所有應用伺服器的專家。這種差異主要在IDE,debugger,build工具,配置管理等等方面。具備某供應商的某項特殊工具的使用經驗,可以在評估該供應商的競爭對手產品時具有一些便利。但是,不要奢望在不同產品之間進行無縫(seamlessly)的轉移。因此,你不得不花費更多的時間在熟練掌握這些工具。


風險7: 設計中沒有充分考慮到可擴充性和產品性能
症狀:
- 無法忍受的緩慢速度
- 系統給伺服器端增加的沈重負擔,而無法利用到一些聚簇(Clustering)技術。

解決方案:
把精力集中於性能和可擴充性(Scability)方面的需求,明確開發要達到的性能指標。如果你需要每秒50個交易,而你的EJB設計只能提供40個,那你就需要考慮替代方案,諸如儲存過程,批次處理,或者重新考慮OLTP的設計。

盡可能讓你的供應商加入,他們應該非常清楚其產品的強項和弱處在哪裡,然後給你提供最直接的幫助。

備註:
本風險與風險2 (over-engineering)似乎有些衝突。實際上,兩者相互影響。 我對風險2給出的解決方案是,只在絕對必要的情況下才進行構建。而對與性能和可擴充性,你要預先劃分好什麼是必須要做的。

如果你認為強大的可擴充性是關鍵的需求,那首先需要選擇一個有很強的Cluster支援及Transactional Cache的應用伺服器。另外,應把業務物件(Business Object)設計為EJB,以充分利用伺服器架構的優勢。


風險8: 過時的開發過程
症狀:
- 專案計劃看上去類似瀑布模型: “首先進行系統設計,然後在一個很長的周期裏進行開發。”
- 由於沒有構建(build)程序,因此每次構建都像是噩夢
- 構建的日期等於損失開發的日期,因為什麼也沒有做成
- 在整合以前元件沒有分別被充分地測試過,而整合測試意味著將2個不穩定的元件放在一起,然後查看堆疊裏的追蹤(Trace)結果。

解決方案:
好的軟體方法學將提高你的軟體生命期。此前我已經提到XP方法,你可以在網上找到很多這方面的資料。

備註:
JUnit可以用來進行單元測試,Ant工具可以進行編譯與構建,這2種工具都對XP方法有很好的支援。


風險9: 沒有好的架構(Framework)
症狀:
- 核心庫中有Bug的部分在程式碼中使用了很多次。
- 沒有建立日誌(Logging)標準 -- 因此系統的輸出很難讀取或者解析。
- 不良且不一致的異常處理。在有些網站中甚至可以看到,低階的系統錯誤訊息直接顯示使用者,例如在使用者在他的購物車核帳時發送一條SQLException Stack Trace資訊,用戶接著會怎麼做?打電話給資料庫管理員要求修正primary key限制嗎?

以下工作已經以各種方式處理過,這些應該列為架構設計的首要目標。 
- 日誌(Logging)
- 異常處理 (Exception handling)
- 與資源的連接(資料庫,Naming service等)
- 建立JSP頁
- 資料正確性檢查(Data Validation)

解決方案:
我是一個輕架構(Lightweight Framework)的信徒和實踐者。我在JavaWorld 上的第一篇文章 -- "Frameworks Save the Day" -- 就是研討在企業Java環境中的架構。即使你已經開始開發,此時考慮一下架構仍然是值得的。可能你不得不忍受一下重構帶來的異常處理和日誌處理,但從長遠來看還是值得的,這樣既省時間又省錢。

備註:
思考一下架構及元件開發的可重用性區分不同等級。第一級別是plumbing,具有0.9以上的可重用比例,也就是說,有90%的專案可以對它重複利用。 服務越特殊,重用比例就越低。換句話說,我需要建立一個會計服務,以提供資源的使用及管理,並便於其他50%專案中可以對它們進行重複利用。對那些需要這些資源的專案開發者來說,能得到這些資源,那真是太棒了!


風險10: 根據市場宣傳決定專案計劃和設計,而非實際技術需求
症狀:
- 輕率地進行技術決策,認為EJB只是為了可移植性(portable)的目的
- 選擇供應商的時候沒有隨即進行產品的試用
- 在專案的生命周期內還需要更換工具

解決方案:
不要輕易相信專案外部的任何人的看法,這些人可能已經有一些既得利益,不要相信供應商的說法(除非你早已經瞭解),也不要相信白皮書。如果要取得關於應用伺服器的建議,可以在網上取得。還可以下載這些工具進行評估,用它們做一些原型(prototype),並執行一下其中的案例。(好的供應商都有這樣的案例)。

總而言之,你的專案選擇最好的供應商及工具需要時間,而你可能沒有太多的時間。你可以把選擇範圍限制在3-4個種,然後用一周時間進行比較和檢驗。最後從中選出比較滿意的工具和產品。

備註:
如果你缺少J2EE經驗,則可能會在專案前期就產生問題。在前期所確定的決策會影響整個過程,並進而影響專案的成功。好的J2EE諮詢專家將能夠幫助你選擇好的供應商,並為設計和開發刻劃出一個好的架構。

結論
總而言之,以上10大風險是企業級Java專案開發過程中將面對的主要困難。相信在你的旅程中一定還有更多的陷阱,相信上面所提到的風險已經涵蓋了主要的問題。最後按照優先順序重新列舉一下10大風險: 


- 沒有真正理解Java, 沒有真正理解EJB, 沒有真正理解J2EE
- 過度設計(Over-engineering)
- 沒有將業務邏輯和顯示邏輯相分離
- 沒有在開發環境中進行適當的配置
- 選擇了不當的供應商
- 不瞭解你的供應商
- 設計中沒有充分考慮到可擴充性和產品性能
- 過時的開發過程
- 沒有好的架構(Framework)
- 根據市場宣傳決定專案計劃和設計,而非實際技術需求

部落格(Blog)的歷史

終於了解Blog怎麼誕生的!

"博客中國網站董事長方興東指出,部落格最早的原型誕生於一九九三年,原本是一種網路過濾器(filter),功能僅限挑選一些網站,並做些簡單的介紹。一九九四年美國史瓦斯摩爾大學(Swathmore College)大學生霍爾(Justin Hall)建立了第一個Blog,然而卻因受限於技術,直到一九九九年「Blog」名稱正式出現時,全球也不過只有二十三個部落格。

但也在那一年,美國網路工程師威廉斯(Evan Williams)開發出方便市井小民自助架設部落格的網站Blogger後,和其他類似的網路服務商一舉帶動起「部落格全球風潮」,至今全球已經有三千一百萬個部落格(與加拿大一國人口相當)。美國網路產業調查公司Perseus更預估,此一數字在微軟和雅虎相繼推出免費部落格設站服務後,預計到二○○ 五年底將再成長到五千三百萬個,也就是平均一天冒出四萬──當下每過一分鐘,就有二十八個新部落格在世界各地誕生。"

- 摘自 數位時代電子報 "解讀Blog全球旋風", 2005/06/13

2005年6月14日

多數成功者做著自己最喜愛的工作

Fred Wang(http://fredwang.blogspot.com)

工作如果能與興趣結合那麼即使一天工作12小時也不會覺得苦. 《選對池塘釣大魚》書中,作者雷恩吉爾森引述一項關於美國成功人士的訪談調查,發現九四%以上的人回答成功的關鍵因素都指向一個:「他們都做著最喜愛的工作。」

不過對自己的目標設定要廣一點, 例如 : "網頁程式設計師", 這個範圍比較小, 可以改變目標設定涵蓋網頁設計師, 及網站架構師(Architector), 最好的目標是網站專家.

網站牽涉到的技術能力很廣, 要做頂尖的網站專家, 可能的領域有 :
1.網頁設計(美工設計含靜動態設計, 可用性設計, 可存取性設計)
2.網站應用系統設計(網站技術架構規劃, 電子商務, 電子交易系統, 網頁內容管理系統, B2B, B2C, 電子市集, 電子行銷系統, 客戶關係管理系統, 後勤系統整合, 流量分析系統等等)
3.網站經營與管理(網站企劃與策略規劃, 網路廣告, 網站推廣與行銷, 網站效能管理, 網站系統與資料庫管理, 網站安全管理)

上面從美工, 程式設計, 規劃及管理, 所涉及的能力相當廣, 當然與溝通協調的能力也不可少, 而除了大型公司, 才可能有比較精細的工作角色區分, 而一般企業可能一到二人就要負責這所有的工作, 要成功的做好並不容易. 而且這樣的人才在市場上也少. 市場價值也越高.

其他行業也是, 當競爭者多時, 如何多提升自己增加能力, 多用心, 多努力, 做的比別人好, 哪麼也能成為這行的佼佼者.

參考: 商業週刊916期'選對行業,當黑馬!'

2005年6月10日

公告: 已更新網頁的RSS連結

2004年12月本網站由http://fmwang.blogspot.com改登記網址為http://fredwang.blogspot.com
但是網頁中的rss連結仍是舊的網址, 因此部分RSS reader只會讀到舊網址的內容, 現在已經更正!

Fred Wang 2005/06/10

2005年6月7日

Xoops Add-on模組整理

Fred Wang(http://fredwang.blogspot.com) 20050607
Xoops標準模組有系統模組, 夥伴網站, 友站新聞, 票選, 常見問題及解答(Faq), 精華區, 新聞區, 討論區, 網站連結, 檔案下載等, 除了這些標準模組外, Xoops有許多人致力於開發Add-on模組的開發, 讓Xoops能有更多網站應用功能, 如本文介紹的各種模組, 小型工具到大型的應用都有

主題 :
Plugin 模組
1.xoops討論區 - newbb
2.訪客計數統計模組 - istats
3.線上報名表單 - eGuide
4.萬用嵌入網頁程式 - isstpage
5.文件管理系統 - iContent
6.自訂表單 - Liaise
7.嵌入自製內容模組 -TinyD2.0
8.Blog軟體 - WordPress
9.強悍的電子相簿 - xcgal
10.超讚行事曆模組 - piCal
11.樹狀選單模組 - treemenuxl
12.電子商務模組 - Xoops Shop, osCommerce
13.專案管理模組 - wsproject
14.WebMail系統模組 - SquirrelMail
15.企業內容管理模組 Enterprise-X
16.入侵防護模組 - Xoops Protector
17.文字擷取分類工具模組 - FreeContent
18.事件管理模組 - Agnedax

下面各模組的簡介摘自其模組說明文件
xoops討論區 newbb 2.0.1 Final
用來取代舊版的討論區模組
功能概要:
●結合投票模組(xoopspoll),能夠擁有投票的功能。
●支援附加檔案上傳,可以利用附加檔案的方式上傳檔案。
●搭配KARMA值(社區威望),並讓文章可以分別不同威望者的觀看權限。
●能設定必須回覆後才能觀看的權限。
●討論區代表標題圖示。
●可以自己定製樣板圖示並在後台作設定。
●文章評價功能,可以針對文章來做評分,讓文章的可信度或歡迎度公開。
●可以針對不同的討論區設定不同的權限。
●快速回復以及更改log的顯示,新增了直接回覆主題的快速回覆框。
●可選擇編輯模式的切換。
●啟用網路串連格式(RSS)。
●修改過本文時會有修改紀錄顯示。
●精華文章功能,可以標示好的文章為精華文章。
●多樣化瀏覽模式,未讀文章、精華文章或是只顯示未讀文章的瀏覽模式。
●內定搜尋選項,可以根據文章內容、標題或是文章加標題的進階搜尋選項。
●自由排序討論板。
●可以設定某些特定討論區標題類別的前置選項。
●在討論區下方可以有個專屬的誰線線上區塊,依照等級顯示不同顏色的帳號。
●可於後台開啟 HP/MP/EXP 等級顯示模式。
●可以使用真實姓名替代帳號的顯示模式。
●所屬群組顯示欄位對每個發表者在網站裡的所屬群組顯示。
●快速連結下拉式選單,可以方便於通往各討論區的快速連結。
●使用者每進入討論區時下方會有權限列表的顯示。
●可以開關顯示張貼者IP位置於版主或網站管理員。
●版主以上可設定於討論區標題內使用HTML標籤能有多樣變化比較醒目。
●依照設定值,無論是會員或是訪客都能夠有匿名發表的可能。
●可以針對連續發表、編輯訊息、或是刪除的時間限制。
●免責聲明的提醒,可依討論區性質決定是否使用免責訊息。
●結合新聞模組,直接發表文章為新聞。
●文章可以自動轉換為pdf檔。


訪客計數統計模組 istats
功能簡介:
● 訪客計數器
● 每小時、每日、每週、每月流量分析
● 瀏覽頁面分析表
● 訪客系統分析表(瀏覽器、作業系統、解析度、上線主機)
● 可以設定是否顯示計數區塊或是分析區塊
● 日期顯示格式的設定
● 可自訂Cookie的有效時間
● 可自製計數器圖檔

線上報名表單 eGuide
這是一個可以在XOOPS網站內公開活動訊息的模組,同時也支援線上報名表單的生成,可以在線上直接填寫報名申請。報名方式支援人數限制以及自動審核功能,也可以開放讓特定群組新增活動內容。
同時也可開放讓使用者自己登記電子郵件信箱,有新活動發佈時會自動以電子郵件通知已登記的使用者。

萬用嵌入網頁程式 isstpage
instpage 是一個可以讓您把網路上的任一網頁或網站嵌入您的XOOPS2網站中的工具,您只要把他解壓縮,並放到XOOPS2的根目錄底下,然後利用瀏覽器執行:http://網址/instpage.php
即可開始設定嵌入網頁。

文件管理系統 iContent
iContent 是一個XOOPS2專用的文件管理模組,您可以利用它從線上新增網頁,也可以上傳自己的網頁,它具有完整的文件管理後台,您可以自行新增各種資料夾來擺放文件,也可以很方便的啟動、移除或隱藏資料夾或檔案。

自訂表單 Liaise
不錯的表單模組,從連絡站長到問卷調查應用範圍可以相當廣泛。預設一組表單提供參考,其變化可以依照網站需要自己設定,可支援多組不同的表單生成。

嵌入自製內容模組:TinyD2.0 多國語言版
TinyContent是一套相當好用的網站內容編輯模組,您可以利用該模組,在 XOOPS2 網站中崁入任何您所需要的內容。而TinyD則是TinyContent的改良版,因為有時候我們會因為網站需求,而想要同時安裝好幾個TinyContent模組,若您是用原來的TinyContent模組,那麼是很麻煩的,您必須修改設定檔,修改資料庫檔案,還得修改主程式,相當棘手。但是利用此模組,您只要會複製模組目錄,並改個名稱即可做到,而無須修改任何程式,例如:Tinyd0、Tinyd1、Tinyd2...等,最多可安裝 11 個TinyD模組

Blog軟體 WordPress
WordPress是目前最流行的Blog軟體之一,WordPress原始程式官方網頁:
http://wordpress.org/
模組原作者: http://www.kowa.org/
簡體中文化: http://xoops.org.cn/ 作者:phppp(D.J)
繁體中文化: http://briian.com/

強悍的電子相簿 xcgal
此模組是由著名的 Coppermine 電子相簿改編而來的!非常好用!功能強大,除了可開設各類相簿外,還可做電子賀卡,並支援批次上傳,有多種方式可以製作縮圖,此外,還有非常多的區塊可以使用。

超讚行事曆模組 piCal
piCal 是一強大的Xoops2行事曆模組。此模組可以動態產生 iCalendar 的資料檔,亦可經由連結或電腦硬碟資料來匯入 iCalendar 的資料檔。
piCal 也有一些群組軟體的小功能,當然,此模組有完整的行事曆功能,例如有四種的觀看模式:每日(view -Daily), 每週(Weekly), 每月(Monthly), 或整年(Yearly)。
此模組包含英語、日語、德語、西班牙語、法語、荷蘭語、俄語、繁體中文、瑞士語、葡萄牙語等國的語言檔。本站主選單的行事即為 piCal 行事曆,非常適合各種單位使用。

樹狀選單模組 treemenuxl
很可愛的樹狀選單模組,可以用來取代主選單區塊。

電子商務模組 Xoops Shop(osCommerce)
http://www.xoops.org/modules/news/article.php?storyid=1948
http://www.myxoopsshop.org

專案管理模組 - wsproject

WebMail系統模組 - SquirrelMail
SquirrelMail has all the functionality you would want from an email client, including strong MIME support, address books, and folder manipulation.

企業內容管理模組 Enterprise-X
Enterprise-X is a Corporate Presentation module for Xoops Content Management System

入侵防護模組 - Xoops Protector
Xoops Protector 是一個可以讓您的 XOOPS2 免於病毒或各種入侵攻擊的侵擾

文字擷取分類工具模組 - FreeContent
FreeContent allows you not only to present easily a variety of contents but also to make concept/topic oriented WebIntelligence, to organize community discussion with always up to date and fresh content and information.
Freecontent WebDigest uses advanced and powerful Text Retrieving Technics to automatically generate relevant contents for your website.

事件管理模組 - Agnedax
Agenda-X is a flexible and feature riche calendar application for Xoops with recurring events, Smarty templates, Category, Search, Image upload, day-week-month-flat views and (much) more.

越來越多用Xoops製作的網站

覺得Xoops的確是一個非常優秀的網站建構與管理的軟體

下面舉出台灣一些用Xoops建構的網站
社群
數位網路社群 http://www.dns.com.tw
圓球城市 http://www.roundballcity.com

組織
新竹市動物保護協會 http://www.sawh.org.tw
財團法人仰山文教基金會 http://www.youngsun.org.tw
台灣動物科技研究所 http://203.204.110.36/xoops/modules/news/
台灣國際醫學聯盟 http://www.tima.org.tw/xoops/html/modules/news/

企業
艾桃科技 http://www.osobiz.com/xoops/
竹山自然療法資訊站 http://www.chushan.com.tw/
網站達人 http://www.meto.com.tw
風水命理專業網 http://www.cnbc.com.tw/xoops/

教育
人文社會科學教育先導型計畫 http://hss.edu.tw/ or
http://hss.edu.tw/xoops/modules/news/
北區中小企業研訓中心 http://nsme.nccu.edu.tw/xoops/modules/news/
新竹市科園國小 http://www.kyps.hc.edu.tw/ or http://163.19.138.131/xoops/
台中縣教師會 http://www.tccta.org.tw

個人
島先生的家 http://www.mrbert.idv.tw/xoops/