使用者讓IT顧問(或技術支援人員)抓狂的十件事

譯者 : Fred Wang 日期 : 2011/11/30
摘錄翻譯自 : 10 things end users do that drive me crazy - TechRepublic
原作者 : Jack Wallen

作為本地的顧問公司的成員，我的主要工作是遠端支援和備份。因為如此，我常與客戶直接打交道。雖然我喜歡許多的客戶，但大部分的時候他們表現出來的行為，還是會令我抓狂。

1：控制遠端會話(session)

我會用LogMeIn的或TeamViewer進行客戶遠端支援。在進行遠端支援時，常遇到客戶不斷要展示給我看發生了什麼事，控制滑鼠點擊不同的東西，或者使用他們的機器一些其他不相干的事情(例如回復電子郵件這些應該可以晚點做的事)。這樣讓事情拖更久才能完成。

註 : 遠端會話(session)是指技術服務人員透過遠端遙控軟體，遙控客戶端的電腦，來協助解決客戶電腦發生的問題。

有時，似乎客戶並沒有意識到，其他客戶也在等待我的協助，他們認為可以任意佔用我的時間。但是，佔用時間的行為會讓技術人員覺得客戶不信任他們的工作。沒有人願意在這種情況下工作。

2：給太多跟問題無關的資訊

我真的想知道的是，你(用戶)點擊一封電子郵件的附件的狀況。我不在乎電子郵件是誰發給你的，電子郵件裡有什麼小貓和小狗的圖片。我也不關心，你是坐在辦公桌前或在吃酸奶配蘋果切片當午餐。給我問題的重點跟實況，我就會盡力做好我該做的。

3：把問題怪罪到我(或另一個技術人員)以前做的處理

我的確在你(客戶)的機器處理過一些問題。但是最後一次是幫你重新映射您的硬碟K槽，跟你不能與某個網路連接完全無關。相任我，這100%跟K槽無關。我可以說明兩者不相干的所有原因，問題在你根本不相信我。如果你還是不相信我，我有其他樂意協助你的顧問清單 - 直到他們不再樂意幫你處理問題。

4 : 說謊

這不應該需要做任何的解釋。但對於那些沒有經驗的騙子(客戶)，我給他們一些下台階。有次當我登錄到用戶的機器，發現，顯然他們(客戶)做了一些事 - 一個被刪除的配置文件或程式 - 這只有用戶可能做的。當用戶自己造成這樣的錯誤，他或她有時會試圖否認他們有做過任何事情造成這樣問題。這是大多數支援專家都可以看穿的謊言。我們都知道真相......所以承認沒有關係!。

5：控制對話

當我試圖解釋一個問題給用戶時，用戶的插話會讓我沒辦法效的說明問題或解決方案。如果這些用戶可以停下來好好地聽，將有助於他們不會再重複發生相同的問題。

6：用“快速的問題”服務

客戶使用“快速的問題”服務時不可避免要在30分鐘內很快速完成電話交談。許多客戶使用"快速問題"服務，以避免支付解決實際問題所需要的支援。這通常讓技術人員很難完整地瞭解問題並解決問題。

7：在我專注處理事情的時後跟我聊天

許多用戶，在我遠端支援時喜歡跟我聊天。在我在等待下載或等待應用程式的回應時是OK的。但當我試圖解決一個關鍵問題時，不要試著跟我聊天氣，王室婚禮，或天然氣價格。請讓我專心解決手頭的問題(特別是需要專注處理時)，之後我會很高興跟你(客戶)聊其他的事(只要在你之後沒有其他的任務)。

8：堅持親戚告訴他的才是事實

一些公司老闆找個懂一點電腦的親戚"Cousin Joe"幫他的秘書解決一個問題。如果Joe做的事造成了更多的問題，Joe是不會為你(客戶)負責解決的。雖然Jeo的意圖是好的，但是所作的對解決手頭的問題可能適得其反，這將會花你更多的錢。當然，你如果還堅持Joe說的或做的都是對的，那麼你肯定會需要找一個新的支援專家。

9：取消我所做的處理

如果你(客戶)取消(undo)過技術支援人員做過的處理，請舉手。我已經看過這種情況很多次。很多客戶也承認做過這樣的事。這些客戶並沒有意識到，我將很可能要回來重做這些我事，而這是我先沒有安排在行程的造訪 - 我還是得修復它們，這將打亂我的工作。

10：缺乏必要的資訊

當用戶請求協助時，75％的時候他們有解決問題所需的資訊。其他的25％？沒有這麼多資訊。事實上，這25％大部份需要增加近一倍的工作時間來收集問題相關資訊。所以... ...當你(客戶)請求協助前，請確保您有相關問題的所有資訊再做預約。否則，你是在浪費我的時間和浪費您的帳單的錢。

譯者註 : 原文作者整理顧問服務或技術支援服務人員常遇到的問題。

Information Dashboard的設計程序

作者 : Fred Wang 原作日期 : 2010/06

以下內容根據自己的經驗並參考Business Dashboards – A Visual Catalog for Design and Deployment”一書整理而成。

 

Dashboard開發專案的角色

• Project Manager –負責專案計畫與管理
• Data Architect –熟悉Data Warehouse, cubes及資料整合技術
• Data Source Expert– 熟悉資料來源及其存取方式，如DB Connections，Data Tables and Fields，Access Rules
• Dashboard Expert–熟悉Dashboard設計軟體與Dashboard設計方法
• Business Unit Manager/Key Users–了解業務需求與能夠提出希望看到與分析的Dashboard需求
• IT infra. Support–提供Server, Network, Database等技術支援

 設計程序

 1.業務需求分析

 

1.1 設計衡量指標與KPIs (Information Design)

 

請參考“Business Dashboards – A Visual Catalog for Design and Deployment”一書,第五章

 

1.2 選擇展示的方法並與用戶進行互動(建立一個故事板stody board)

 

a.使用工具如 Pen and Paper, Whiteboard, Powerpoint or Dashboard Prototyping Software

 

b.可參考templates, samples, best practices

 

c.運用元件包含 :

• Charts, Gauges, Tables…
• Warning and Alerts : Traffic lights, arrows, trend…
• Interactivity : Drill Down, Annotation, Actions…

 1.3 確認需求與使用者簽字

 

  

2 使用者介面設計

 

2.1 參考 best practices, samples and templates : 應了解正確的統計圖表與Dashboard設計表達方式

 

2.2 外觀佈局(layout)設計

 

a.顏色選擇 : 避免過多的顏色或依賴顏色表達重點，可以用對比方式突顯重點 (部分人士有色盲與辨色力問題)

 

b.字型種類與大小 : A.避免混用不同的字型，建議英文用Arial，中文用標楷體 B.避免使用太多不同大小的字型 C.避免使用太大或太小的字型，特別是中老年的使用者避免太小的字型 D.建議標題用12 or 14 pixel粗體字，一般文字用8-12 pixel的字

 

c.Dashboard大小: 設計大小應適合於使用者螢幕單一可視範圍，避免產生捲軸，當單一可視範圍無法放置所有的設計元件時，有幾種設計方式

• 使用可以展開與收合的元件 
• 使用層疊的元件，透過按鈕或其他選項切換 
• 使用Tab元件切換 
• 使用多個Dashboards，用選單，按鈕或連結切換檢視Dashboards 
• 使用參數過濾資料，顯示使用者要看的內容，例如使用時間選擇元件選擇某一季來顯示統計圖，而不是顯示4個圖

 d.元件放置 : 如果有超過兩個以上的tables, grids , scorecards or charts應如何放置 

• 與key users討論，哪些資訊最重要，通常依重要性由左至右，由上至下排序
• 根據控制流程由左至右，由上至下排序，例如先看Scorecard，才會看趨勢圖，然後點特定指標值，顯示明細的Charts

  

2.3 給定Dashboard標題與元件的標籤

 

2.4 設計核心的Dashboard功能(如filters，drill down, alerts, etc)

 

a. 定義控制流程
b. 決定展開路徑(Drill Paths)

 

2.5 展示Dashboard雛型給使用者，得到使用者建議, 修正與核可

 

 

3. 資料與系統設計

 

3.1 資料模型設計

 

a.決定每一元件的資料來源

b.決定每一個UI Component的資料格式與計算方式

c.決定所需歷史趨勢資料的保留方式(Data Warehouse)

 

3.2 Data Model轉換, 來源資料與顯示Dashboard所需的資料格式與粗細度可能不同，需經過計算或轉換後才能做為Dashboard的Data Model

 

3.3 系統設計

 

a.決定資料的存取方式

b.設計OLAP Cube的結構

c.設計整體架構，包含網頁設計，使用者權限等

 

 

4.架構設計 (略)

 

 

從專案角度可以分下面幾個步驟

 

1. 組成專案團隊

2. 建立專案計畫

3. 檢視衡量指標與KPIs

4. 根據風險，機會與成功要素排定Dashboard實作的優先順序

5. 開始外觀佈局(layout)設計

6. 定義軟體,硬體,安全與架構需求

7. 得到關鍵利害關係人的核可簽字

8. 開始建構dashboard與相關系統(包含測試)

9. 訓練使用者

 

IT(MIS)工作的十大缺點

譯者 : Fred F.M. Wang 日期 : 2011/11/28

摘錄並翻譯自 10 drawbacks to working in IT

原作者 : Brien Posey 2011/11/22 (TechRepublic)

試圖進入IT領域工作的人多半不清楚他們將會面臨怎樣的狀況。下面描述一些IT工作真實的一面。希望這篇文章讓想進入IT領域工作的人不要有不切實際的期望。

第一 : 工時長

有許多種類的IT工作型態，但共同的特點是工時長。如果你要在IT工作，最好要有在晚上或週末工作的心理準備。

第二 : 私人的時間會受到干擾

如果您在所在的單位扮演一個重要的支援角色，你會需要隨身攜帶手機。而且在任何時間可能會收到電話去處理一個警急事件。原作者曾在週五晚上第一次跟現在的老婆約會看電影時被Call去處理系統問題。也曾在耶誕晚餐時被Call。在IT工作幾乎像救火員或生命線。您不知道何時會有警急情況發生，不知道將要處理怎樣的問題。

第三 : 必須面對一些惱怒的人

在IT工作的人，特別是擔任helpdesk的角色最糟的事，就是遇到一些惱怒的使用者。每個打電話給你的使用者幾乎都是遇到某樣的問題感到挫折並期望你能馬上幫他解決。通常撥電話時懷者很大的敵意，因為他們認為都是你的系統造成他無法順利完成工作。

第四 : 有時間期限的壓力

多數IT工作都是有時間期限的。例如開發者有一定的準時結案的壓力。網管人員要在特定日期建立使用者帳號，安裝與測試新的系統。常常在大量的工作中要再安插一些工作，這些時間期限完全是不合理的，但是卻被希望準時達成。

第五 : 希望你可以修他們家裡的電腦

另外常發生的是希望你可以修理同仁個人的電子設備。當然IT人員通常抱有服務的熱誠，會儘可能幫忙他們，但是有時候真得忙不過來。作者曾遇到同仁想用很少的錢請他幫忙升級一台1988年的老電腦。

第六 : 別人常常對你撒謊

作者剛開始在IT工作時，發現許多人常常對IT人員撒謊，以掩飾因為自己的錯誤所造成的問題。你也會發現廠商的技術支援部門也會對你撒謊，作者已經數不清有多少次廠商的技術人員對他說這些問題跟他們的軟體無關，而是電腦硬體或是作業系統的問題。當然廠商銷售人員的謊言更是無法計數。

第七 : 必須學習最新的東西

IT產業持續在演進，IT專家必須學習大量的資訊才能完成他們的工作，而且這些資訊需要快速地更新。最好的方式就是不斷地學習成長。最難的是在工時長的情況而且預算緊縮下又要常常去上課或自我學習。

第八 : 電腦不如你預期的運作

最糟的是你嘗試在一定期限內完成的專案時，因為一些技術問題而被終止。電腦系統是複雜的，有時你下很大的工夫，他們還是無法如預期地運作。

第九 : 你必須面對很多官僚

作者二十年在IT工作的經歷，常常需面對許多的辦公室政治與企業官僚文化。近年來，官僚文化達到另一個新的水準。因為Enron醜聞事件，迫使IT專家必須面對無數的聯邦法規。這些法規讓IT工作變得更困難，更耗時也更昂貴。

第十 : 你的工作是讓自己過時

作者初次擔任網管人員時，一個老朋友告訴他，IT專家的工作是讓每個東西都完美地運作。但是，如果每個東西都完美地運作時，就不需要IT專家了。多年來，很多人告訴作者，只要你在IT工作，就永遠不用擔心失業的問題。但是，新一代的管理產品就是讓少數人來管理大量的系統。同樣，很多IT工作外包​​，或將系統移轉到雲端。因此儘管IT行業本身不會很快消失，但可以了解，IT知識絕對不是就業的保證。

譯者註 : 這篇文章點出IT工作的困難處，我想除了以上十點還有許多，例如使用者需求模糊不清，一改再改，不合理等，我還遇到有公司的IT人員要負責修理廁所的燈泡(可能是老闆看到他們常拿著螺絲起子拆裝電腦，以為IT工作跟水電工沒兩樣)，本文中最經典的一句話是"IT專家的工作是讓每個東西都完美地運作。但是，如果每個東西都完美地運作時，就不需要IT專家了"，常發生的是老闆平常覺得這些IT人員好像沒啥貢獻(因為一切都運作得好好的)，出問題時才來怪罪IT。我認為只要IT從業人員能保持領先的技術專業(不要只會一種技術)，而且保持對IT的熱忱，不管在企業IT，IT服務公司，軟體公司，相信都能遊刃有餘。 -- Fred Wang

無所畏懼追求真理的傳奇人物 - 尼古拉·特斯拉(Nikola Tesla 1856-1943) 資料整理

作者 : Fred Wang, 2011/11/27
“首次接觸到特斯拉的資料，深深被吸引，原來人類的科技文明是可以提前數十年，遺憾的是人們的自私，讓許多好的事物無法流傳與發揚光大，特斯拉偉大的發明因為影響到許多既得利益者，因此遭無情打壓，以其無所畏懼，追求真理，對人類具大的貢獻無法被輕易抹滅，相信歷史最後會還原真相。”—Fred Wang
頭銜 :
交流電之父、無線電之父、免費能源之父、現代物理學之父、雷達之父、電腦之父、網路之父、X光攝影之父、太陽能之父、死光之父、飛碟之父、人造衛星之父、二十世紀之父、火星探測之父、太空旅行之父、人造閃電之父、人造地震之父、人造氣象之父、意念控制之父、意識顯影之父、空間傳送之父、粒子牆之父、引力牆之父、人造星球之父。
事績

• 五歲時，自製一台嶄新的無葉片小水車，這種小水車不但能順利地在河流中轉動，並且比一般水車轉動得更快。
• 1879年，經由指導教授舉薦他到匈牙利完成第一款電話系統及揚聲器。
• 1882年，經引薦幫忙法國建立旋轉磁場的電器設備及發明了感應馬達。
• 1884年，被引薦到美國紐約的愛迪生財團總部任職於電器研發特別部門的一位主管，一年內就獨立開發二十四種產品，包含「直流發電機」的重新設計。
• 1887年，組裝了最早的無電刷交流電感應馬達。
• 1888年，發展出特斯拉線圈(Tesla Coil)的原理 ，這是一項能夠無限量供電的免費能源科技。(簡單的說，他證明了電可以免費從空氣中取得，這是不得了的發明，將造成多少石油公司與電力公司倒閉，影響多少人的生計，當然會被打壓封鎖 – Fred)
• 1889年，特斯拉在科羅拉多州的實驗室中證明了泥土是導電體並製造出人造閃電。透過自己的接收器觀察了閃電並研究了大氣電。計算得出地球的共振頻率接近8赫茲。
• 1891年，證實了無線能量傳輸，他用機電振蕩器進行了機械共振實驗，使周圍的一些建築物產生了共振，且在紐約一些地方無線點亮了那裡的電燈。
• 1893年至1895年，特斯拉研究高頻交流電。用圓錐形的特斯拉線圈造出了百萬伏的交流電，研究了導體中的「集膚效應」，設計了調諧電路，發明了無繩氣體排放燈，並無線發射了電能，造了第一台無線電發射機。
• 1893年的世博會特斯拉與喬治•威斯汀豪斯用交流電照亮了整個博覽會藉此向參觀者介紹交流電。一位參觀者記述道："房間內懸掛著兩個用錫箔包裹的硬橡膠板。兩個大約相距十五英尺。當電源接通，燈泡與燈管沒有電線連接，而燈泡發光了"。(同時點亮九萬盞燈)
• 1893年特斯拉在在費城的法蘭克林學院發表演講表示："許多年以後，人類的機器可以在宇宙中任何一點獲取能量從而驅動機器"。 (愚昧的後人仍無法完成此項成就--Fred)
• 1897年，特斯拉研究了粒子輻射，使他建立了宇宙射線基本方程式。
• 1897年，成為國際軍事派科學的首席大師，時年四十一歲。(之後的研究進入軍事機密領域，多被封藏)
• 1897年，舉世知名的「尼加拉瓜」發電站落成，此發電站是特斯拉運用了他9項專利發明設計了這個第一座達10萬匹馬力的發電站。
• 1898年，特斯拉創造了「遙控力學的藝術」（Art of Telautomatics），在麥迪遜廣場花園的一次電學博覽會上向公眾演示了無線電遙控船隻。發明了內燃機的「電點火器」即火星塞。
• 1900年，發明增加電子波動強度的儀器。
• 1900年－1911年，在紐約的「水邊發電站」，進行無葉渦輪引擎在100–5000匹馬力測試。
• 1901-1905年 在紐約附近的長島建造Wardenclyffe塔，是一座複雜的電磁振盪器，特斯拉利用此塔實現地球與電離層共振，後世認為此塔引發了1908年通古斯大爆炸。1908年，特斯拉時年五十二歲。
• 1910年，成為國際軍事間諜的幕後黑手，暗中主導各國的軍事單位，左右若干國家的首腦，包含美國、蘇聯、德國、英國等十餘個國家，時年五十四歲。
• 1912年特斯拉提出：「若把物體的振動和地球的諧振頻率正確地結合起來，在幾個星期內，就可以造成地動山搖、地面升降。」
• 1933年，美國戰爭部動用國力，近乎使用一個國家來交換他留在美國的機會，也確立了美國西部「51區」的誕生，時年七十七歲。
• 1935年，特斯拉在實驗室打了一口深井，並在井內下了鋼套管。然後將井口堵塞好，並向井內輸入不同頻率的振動。奇妙的是，在特定的頻率時，地面就會突然發生強烈的振動，並造成了周圍房屋的倒塌。當時的一些雜誌評論說：「特斯拉利用一次人工誘發的地震，幾乎將紐約夷為了平地」。(人造地震)
• 1937年，完成人類史上最不可思議的"引力的動態理論"，時年八十一歲。(理論主要內容是具體實踐的方式，包含「反引力」及「人造重力」的裝置設計，也是「人造星球」的重要基礎。其中關於「空間傳送系統」及「引力門系統」的設計，亦即接觸「良善的外星人」方法，另外還有「死光」的一系列裝置說明。「引力門系統」（釣飛碟系統）是直接通過「良善的外星人」得到高科技支持的方法；「死光」的主要用意是預防「非良善的外星人」的攻擊而作為防禦使用，包含摧毀外太空的隕石，其中也涵蓋了如何在宇宙的各角落去利用引力而成為取之不盡用之不竭的能源方式；「空間傳送系統」的大致內容估計要有「特定元素」才能製造，而這些元素在地球上都沒有，故而要先通過「引力門系統」去取得。)
• 1943年死後美國政府下令徹底銷毀他的生平及一切活動細節，1897年後四十五年間的作品全部被FBI列入絕對機密，至今仍無從得知細節。

其他

• 他在美國科學界被除名並遭到嚴重抹黑，原因是他否定「相對論」等其他理論，他認為有理論基礎就得去實驗證明，不值得空談高唱。1921年諾貝爾團隊否定相對論，基於尼古拉·特斯拉全面否定的緣故，因為他當時已經初步完成"引力的動態理論"，諾貝爾團隊有幾位科學家有涉獵，故1922年頒發愛因斯坦獎項時才決定公開否定相對論。
• 精通八種以上的語言，至少能閱讀十一種文字，至少可以使用六種語言進行複雜的專業溝通。（英語、法語、德語、梵語、拉丁語、捷克語、匈牙利語、義大利語、塞爾維亞語...）
• 特斯拉一生獨自獲得1000多項發明專利相當於發明大王愛迪生的通用電器公司實驗團隊的總發明數。
• 總共獲得十一次諾貝爾物理學獎，他都拒絕領取。
• 研究尼古拉·特斯拉的作品，從而直接得到啟發獲得諾貝爾物理學獎的比率佔了27%，甚至間接得到啟發的比率更超過65% 。因此被稱之「現代物理學之父」
• 不止準確的預知到第一次世界大戰的爆發日期、結束日期、爆發地點、結束地點，更預知第二次世界大戰的開戰日期、結束日期。
• 1912年不惜動用一切力量去阻止當年世界首富摩根（J.P.Morgan）搭上鐵達尼號，晚年的三十年中，曾經救過很多的世界富豪及政要。

尼古拉·特斯拉 (Nikola Tesla)語錄

• 「我的大腦就像一個接收器，太空中存在著一切東西的核心機密，他是我們知識和靈感的來源。我沒能瞭解這個核心的眾多秘密，但是它的存在是不容置疑的。」
• 「我和電磁粒子天生投緣，彼此之間關係密切，我想掌握他們的行為規則，每一個產生電磁效應的基本粒子，都是極其複雜的實體，是帶有只能的生命。從智慧的角度看，他們絲毫也不比你我來的差。與他們交流是一件時時發生，極其正常的事。」
• 「電給我疲乏衰弱的身軀注入了最寶貴的東西一一生命的活力、精神的活力」。
• 「我利用了宇宙射線，並且使它們操作一個成為原動力的設備。」
• 「我只是一位平凡人，我也沒有特殊能力。在宇宙中的任何一小部分都包含著整個宇宙的所有信息，在其中藏著某個神秘的資料庫又保存著宇宙的總體信息，我只是很幸運的可以進入這個資料庫去獲取信息而已。」
• 「太陽系有防護罩，通過旋轉進行共振放大才能脫離太陽系的囚牢，才能轉移到任何一點上。」
• 「太陽系是被製造出來的，我們被關閉起來，我們必須突破出去，我們必須努力進入宇宙的大家庭。」
•  「如果你想要通達宇宙本源真理，就要開始思維一切和能量，頻率，共振有關。」
• 「如果科學界開始研究非物質領域的現象，這一個世紀的進步絕對會更超越過去所有的記錄。」
  

 
參考資料 :

1. 尼古拉·特斯拉(Nikola Tesla) - 維基百科
2. 人造地震 - 錢神電信 (最豐富)
3. 可以不封神，但是不能不修煉——亞特蘭蒂斯之神特斯拉的啟示 
4. 尼古拉·特斯拉：太陽系是被製造出來的，我們被關閉起來
5. 尼古拉特斯拉--一位默默無名的重要人物
6. 不用電線就可以傳送電力？流言追追追-【實驗精華片段】
7. 東森關鍵時刻 20100517B (7/7) ~ 誕生在閃電中的天才特斯拉
8. 尼古拉-特斯拉紀念(Nikola Tesla)影片

彈性應用系統平台十種設計方向(Flexible Application Platform 10 Design Approach)

 

作者 : Fred Wang 日期 : 2011/11/26

甚麼是一個高彈性的應用系統平台，可能具備下面的彈性需求類型 :

a.使用者操作彈性，b.彈性可調整的外觀，c.支援多前端平台，d.功能可擴展性，e.開發人員分工協同設計，f.程式高度可再用性，g.彈性支援多種後端來源資料儲存與傳送方式，h.可彈性擴充後端支援的硬體

是否有機會做到呢? 下面提供一些設計方向，可以依據所需的彈性需求類型組合參考下面的設計方向來建構。在此僅說明設計方向，至於實現的技術需要獨立專文討論。

一，使用者介面個人化設計 : 如iGoogle，myYahoo等個人化入口網站，提供End User有限度地調整自己個人網頁要看的內容。

二，使用者外觀與資料分離式設計 : 將外觀如theme, styles抽離網頁內容，在Runtime時由展示層(Presentation Layer)動態組合成網頁後呈現到使用者前端(Client)，好處是可以獨立設計與調整外觀Theme，並可切換不同的Theme，這種設計在許多系統都已經實現，特別是WCM系統，IBM Portal, Quickr等。有些平台提供設計師上傳預先設計好的themes或styles檔案的介面，有些提供使用者介面(UI)進行Themes與styles有限度的微調，並可以儲存自訂的Themes與styles。    

三，多重網路協議層設計 : 為了支援多種的使用者前端如Web Browser，內嵌式設備，行動設備或自行開發的應用前端(application Client) 如Flex, Adobe AIR等，在展示層增加一個層次用來處理多種的網路協議(protocol)，將這些前端訊息格式轉換成一致的格式傳給後端層次的成式處理，也將後端層次的層次處理或抓取的資料轉成前端訊息格式回應給前端。

四，MVC架構或多層次架構設計 : 將不同類型的處理分層，一個層次的程式接收前一層的資訊加以處理再轉交/呼叫下一個層次的程式或透過委託程式(delegation)分配給後一層次的程式處理。這種設計可以提高功能的可擴充性，而且有利於大型專案的專職分工。

五，程式模組化設計 : 這是程式設計入門學問了，程式設計師必需具備的高內聚力，低耦合性等模組化程式設計素養，不管是前端的Javascript,邏輯處理的Java等都平常都要養成模組化設計的習慣，而團隊則要做好共用模組的管理，如測試，驗證，品檢，文件製作等才能提高再用性的效力；另外，Design Pattern與software framework的運用也是很好的方向。

六，Metadata結構設計 : 在資料庫的資料表(data tables)前增加Metadata層，程式不直接存取實體的資料表，而是存取Metadata層結構的資料，而Metadata與資料表的轉換有專屬程式處理，例如:Metadata與Oracle資料庫間有一組處理程式，而Metadata與MS SQL Servr資料庫間又有另外一組處理程式。此種設計廣泛出現在Data Warehouse，而知名ERP軟體SAP也是採用此種設計。

七，高度參數化設計 : 將系統中任何可能變動的參數甚至一些判斷邏輯從程式抽離，並設計使用者介面(UI)提供管理者進行調整。這些參數又分為系統參數與業務相關參數，可以區分不同權限管理。多數商用系統應該都有這樣的設計，很多是儲存在.ini檔中，而較好的是提供使用者操作介面，例如SAP的Configuration。

八，可客製物件設計 : 這種設計是將商業的元素物件化，例如:訂單是一個物件，訂單項目是另一個物件，每個物件有標準欄位與可自訂欄位，欄位值可以設定預設值公式，欄位檢查，並可以設定物件間的關聯，部份看起來是資料庫管理系統的作業，部分應該是程式中處理的，有些系統如Force.com將這些動作完全提供使用者介面，透過畫面以簡單的操作完成設定。

九，彈性資料表設計 : 這個設計是資料庫內表格設計的一種技巧，例如，物料主檔各類型的物料屬性不同，如果採用聯集，會設計出一個欄位超多的資料表，儲存資料時也將產生許多的空值或預設值，浪費許多的儲存空間。因此衍生彈性資料表設計，就是區分預設欄位資料表與彈性欄位資料表，前者包含key欄與一些共同的必要欄位，這些欄位可以設定索引快速搜尋，後者包含Key欄，屬性名稱欄位，型態欄位與內容欄位。

十，虛擬化與雲端化的基礎架構設計 : 這是近年最夯的IT話題，主要好處就是高擴充彈性的基礎架構(infrastructure)，服務容量將要不足時可以隨時加入硬體伺服器，任何一台伺服器要維修也可以不影響營運下抽離。有兩種不同種類的技術，一種是VMWare,Xen的虛擬技術，一種是Google Hadoop, MapReduce等技術。

作者: Fred Wang(http://fredwang.blogspot.com)，麻煩參考時請註明出處，本網站的連結，否則視為侵權。

十個免費的網頁草圖設計工具

作者 : Fred Wang
線框(Wireframing)是網頁設計和開發的一個關鍵步驟，它可以作為快速雛型設計，有助提早點出潛在的問題。可以視覺化的方式呈現內容，階層與佈局。

線框讓意見溝通更容易，減少範圍蔓延，降低因後續設計改版造成的專案成本，並提供更早的前端可用性和功能測試。

下面介紹一些免費的線框與草圖繪製工具。

1. Mockingbird

這是以Cappuccino框架為基礎的網頁測試版軟體，用來建立，連結，預覽和分享網站或應用程式的線框/草圖。

2.Lovely Charts

這是一個線上繪圖工具，可以建立flowcharts, sitemaps, 組織圖和線框等圖形。

3. Cacoo

這是一個線上繪圖工具，可以建立sitemaps, wireframes, network charts等圖形。

4. Gliffy

這是一個網頁應用程式，可以建立process flow diagrams，組織圖，Floor plans，商業流程，網路圖，技術圖，網站線框等
5. Lumzy

這是一個網頁與應用程式模擬與雛型建立工具，可以增加事件來模擬使用者的動作。也提供即時協作功能，如團隊編輯，對談等功能。
6. Mockflow

這是Adobe Flash平台的應用程式，具備乾淨簡約有組織的介面，編輯功能廣泛。可以拖拉元件模擬網頁的線框。

7. Pencil Project

這是一個open source工具，用來繪製圖表，GUI雛型等。有Firefox add-in與獨立的應用程式(linux and windows

8. SimpleDiagrams

這是一個小型的桌面應用程式，可以幫助你快速地表達想法。建構在Adobe AIR平台上可以在Mac, Windows和Linux上運行。輸出成PNG檔。

9. Denim

這是一個免費跨平台的桌面應用程式，提供素描，允許在不同的精細水準下設計，是早期腦力激盪與繪製線框的有效工具。

10. Website Wireframe

這是一個簡單快速建構網頁線框的工具。可以透過eMail,簡訊等傳送wireframe的連結提供意見回應，討論與建議。

參考資料 :

1.Grace Smith, “10 Free Wireframing Tools for Designers”, Mashable Tech. (http://mashable.com/2010/07/15/wireframing-tools/)

雲端服務選擇與評估檢查表(checklist)

雲端服務選擇與評估檢查表(checklist)



作者 : Fred Wang 日期: 2011

企業在選擇雲端服務時，應依其雲端應用的安全性要求與企業的資訊安全政策定義選擇與評估的檢查表，下面是一份整理自網路上各文獻的檢查要點，提供企業選擇上的參考。

1.網路傳輸安全性

1.1 是否具備網路傳輸中斷之資料儲存與接續處理機制?

1.2 是否具備網路傳輸資料加密機制?


2.用戶端安全性

2.1 是否具備憑證認證機制?

2.2 是否可以特定帳號在限定電腦執行?

2.3 是否有同一帳號限定同時多少台電腦可以登入使用?

2.4 是否具備防列印，剪貼或網頁另存等機制? 是否可以限定瀏覽器Cache的使用?

2.5 是否具備防機器程式，防側錄等機制?


3 伺服器安全性

3.1 儲存數據的安全保護方案是否有能力抵禦Internet駭客和病毒的攻擊?

3.2 一旦出現重大問題時是如何恢復數據的？能在多長時間內完成資料恢復?

3.3 有沒有業務連續(Business Continuity)和災難恢復(Disaster Recovery)保障策略？

3.4 有沒有災難異地恢復方案？

3.5 能否針對災難恢復時間和災難恢復水準出具書面承諾?

3.6 在解決和處理數據恢復和備份時，是否需要用戶中斷業務操作?

3.7 是否提供用戶自行備份服務?


4.應用程式與資料安全

4.1 資料與其他企業在相同平台, 應用程式和資料的隔離方式? 有沒有安全隔離和防滲透保護策略?

4.2 如何避免因其他客戶的系統當掉而受到影響?

4.3 所有涉及用戶機密資料是否採用加密保存，即便是系統管理人員也無法得到原文?


5.資訊安全保證

5.1 能否提供IT管理員與特有權限人員的相關資訊? 與避免資料外洩之保證? (2007/11/8 新聞 : Salesforce員工遭網釣攻擊，而洩漏自己的帳號密碼，使得駭客取得Salesforce的客戶連絡人名單。)

5.2 如何進行資訊安全管制? 有沒有部署規範化的安全管理制度?

5.3 是否可由外部機構來進行稽核或進行安全認證?

5.4 是否有第三方監理或相關安全認證?


6.司法與稽核

6.1 是否從屬於伺服器放置地所在國的司法管轄? 在這些國家展開調查時，服務商是否有權拒絕提交所所託管資料?

6.2 如果企業試圖展開企業內部違法或洩密活動的調查，服務商能否協助，提供system log? Log是否方便存取或查詢?


7.隱私權 : 服務商是否會對客戶資訊進行加值處理以達行銷目的? , 例如Gmail客戶打開信件可以看到與信件內容相關的廣告連結

8.智慧財產權 : 用服務商提供的API開發應用系統, 智財之歸屬問題?

9.資料所有權 : 為資料保全問題進行客戶資料的複製, 是否經過客戶許可?

10.服務水準 : 有哪些服務等級? 服務水準如何? 7x24x365? 是否有Local Support?

11.資料移轉 : 合約中止時如何取回資料? 是否可以用一定的格式轉入替代的應用系統 ?

12.帳號管理 : 是否有人員異動，離職，工作代理等權限變動管理機制?

Jakob Nielson的網頁可用性設計資源整理

. Jakob Nielsen 曾於IBM用戶介面研究中心任職，並獲得用戶介面設計/電腦科學的博士學位。1998年前他作為Sun公司的工程師，負責了幾次Sun公司網站和內部網的可用性設計和再設計工作,包括1994年SUNWEB的設計。此後他和Donald A. Norman博士共同建立的Nielsen Norman Group(http://www.nngroup.com/)。(資料來源 : 維基百科)

. Nielsen創建了"可用性工程"運動來快速低成本改進用戶介面，發明了多種可用性方法，包括啟發式評估法.他擁有75項美國專利，主要是在網頁易用性方面。


Jakob Nielsen的書籍

1.Jakob Nielsen,"Designing Web Usability",1999/12

2.Jakob Nielsen and Marie Tahir,"HomePage Usability:50 Websites Deconstructed",2001/12 (提出113條首頁設計準則)

3.Jakob Nielsen and Joa Loranger,"Prioritizing Web Usability",2006/4

4.Jakob Nielsen and Kara Pernice,"Eyetracking Web Usability",2009/12
 
Jakob Nielsen的網站


Jakob Nielsen的網站 : http://www.useit.com/

Nielsen Norman Group網站 : http://www.nngroup.com/

商務筆電與一般家用筆電有何不同? (商務筆電評比要點)

作者: Fred F.M. Wang 日期: 2011/11

商務筆電與一般家用筆電有何不同? 除了特殊工作需要，多數商務筆電不同於家用筆電對影音的需求，而是在行動性, 安全性與穩定性，下面列出一些重要的評比要點，提供IT人士參考

1.搭載的作業系統不同


商務筆電搭載Windows XP/7 Professional以上的版本，提供加入Windows網路(windows server domain)以分享檔案，遠端桌面功能提供IT人員遠端協助，壓縮檔案系統，軟體使用限制等。

2.商務筆電較輕薄

商務人士或業務人員需要攜帶筆記型電腦外出的機率較高，所以重量是考量的重點。

3.商務筆電電池續航力強

商務人士或業務人員需要較長的行動使用時間，因此對電池續航力要求較大，有些廠商提供附加的備用電池延長操作時間。

4.商務筆電具備撞擊防護

由於外出使用商務筆電，可能有較多撞擊情況，物理上的撞擊防護重要性高，許多商用筆電強調其強固性，甚至通過美國軍規標準。

5.商務筆電具備資料安全防護

由對企業資料保護的重要性，因此許多商務筆電具備防止資料盜拷，遺失尋回等功能。

6.商務筆電須開機快速

商務筆電即開即用的需求高，開關機速度近年成為商務筆電重要評選項目之一。

7.商務筆電穩定性高

商務筆電零件等級高，散熱，使用商務硬碟，經過較嚴格的測試等，因此穩定性高，不易當機

8.商務筆電保固期較長，並有企業級的售後服務

當然，商務筆電價格較高，企業大量購買通常會享有折扣優惠。
註 : Apple MacBook沒有區分商務與家用的規格，在也沒有企業特有的保固與服務，價格上也較硬。

除此之外，展示能力，如連接投影設備也是必要的，近年，一些新機種強調可旋轉螢幕，雙面螢幕，觸控等展示能力，也常常成為商務筆電的評選要項。

南歐人的工作觀與債務

樂觀,快樂,浪漫,悠閒的南歐人是如何過生活的? 代價?

• 希臘人的一天  (文中也有苦命台灣人的一天)

06:00起床, 07:30開始工作, 13:30吃午餐 , 15:30午休, 17:30休閒時間, 21:00吃晚餐, 22:30就寢
(原始來源: http://blog.livedoor.jp/dqnplus/archives/1674383.html)
債務 :

• 西班牙人的一天

早上8點前起床，先洗澡，吃早餐，然後從容去上班。
到了公司不急著打卡，先到書報間翻閱足球賽的比數和戰況報導。
10點為自己泡杯香濃的咖啡，邊吃餅乾邊和同事聊天。
11點開始收發E-mail，處理今天該做的正事。
下午2點午休，和同事到餐廳或各自回家，吃午飯。然後午睡半小時。
下午4點繼續處理早上未完成的工作。
傍晚6點到7點下班後，和同事在附近小吃店喝啤酒配Tapas（下酒菜）。
晚上10點回家吃晚飯。
午夜12點到各大酒吧和朋友狂歡跳舞，或純聊天打屁。
債務 :


下次再研究義大利人。

試想當一個生活悠閒, 輕鬆度日的人，為了維持過好品質的生活，向每天辛苦工作超過10小時的您借錢，您會借嗎?  不借!  好,他會給您更優惠的利息，如何? 有利可圖, 借他吧! 直到有一天您發現，他連利息都還不起了，才會警覺這個投資可能血本無歸，所以為了怕倒債，乾脆給他削減利息好了。
這就是歐債的現況。

試想台灣人辛苦工作，生產出毛利極低價廉物美的電子產品，讓這些高所得的歐美國家人民得以享受這些辛苦的成果，難道這是台灣人的宿命?

軟體開發生產線化探討

作者 : Fred F.M. Wang 日期 : 2011/11/12
軟體開發團隊的成功要點包含設計建立程式元件與累積程式元件庫並建立高效率的生產線，因此，要改善軟體開發效率可以將流程生產線化，並區分系統與元件兩類生產線。
1. 系統生產線。
a.根據不同技術平台建立不同的系統生產線，如SAP, VB, Java等。
b.技術平台應單純化, 避免過多的生產線; 架構也應單純化，避免太多類型的設計架構讓開發流程,無法標準化與一致化。
c.應妥善運用庫存元件,樣版與架構，如果沒有適當元件則會建立系統專用元件。
d.檢視系統專用元件是否具備可再用性，經過審核與品檢後納入元件庫管理。
2. 元件生產線
a.根據商業各領域知識,專家經驗,最佳典範與既有系統開發領域相關的功能元件,或樣版。
b.根據現有系統經驗與開發經驗開發公用元件,或樣版。
c.元件取得也可以透過外界取得,購買或外包開發,提高效率。
參考這篇文章 : "ZDNet基於構件技術的企業MIS開發及應用" 加以修改成下面生產線圖

企業應用系統的開發生產模式探討

 

作者 : Fred F.M. Wang 日期 : 2011/11/12

一般企業IT應用軟體開發模式相較於四種製造模式是屬於接單生產，雖然較容易貼近客戶的需求，但是資源的運用與TAT較差。本文將介紹四種製造模式之優缺點比較。

一般企業IT應用軟體開發模式相較於四種製造模式是屬於接單生產，雖然較容易貼近客戶的需求，但是資源的運用與TAT較差。本文將介紹四種製造模式之優缺點比較。

Build to Order 接單製造    : 完全根據客戶需求規格打造產品   
優點:完全符合客戶的需求
缺點:生產單位需要不斷配合客戶進行產品與製程的變更,效率較差,TAT長

Configuration to Order(CTO)接單裝配 : 將零件模組化,接單時再裝配為客戶需要的產品   
優點:生產效率較接單製造高,對產品客製化與變更的彈性也較後兩者大
缺點:可能無法完全符合客戶的需求

Build to Assembly 組裝製造 : 先製造半成品,接單後再進行組裝完成成本   
優點:生產效率較前兩者高
缺點:可能無法完全符合客戶的需求(半成品需要經過客戶認可)

Build to Stock : 製造標準化產品   
優點:可以計畫性生產,生產效率與資源運用最好
缺點:無法完全符合客戶的需求

IT若要縮短應用系統開發時程，又能盡量滿足客戶需求，應朝接單裝配或組裝製造的方向規劃。配合有效的專業分工與產能(內製或外包)控制,成熟的程式元件庫或樣版(半成品)，

 

有人知道這些奇怪的轉介網址嗎?

 

本月開始出現一些奇怪的流量來源,不知道有沒有網友有類似的問題?

.TK是免費的域名(Domain Name)服務

第一個bllog.tk因為惡搞, 被停止使用

 

Asmaa Heban警告大家不要連上這些網站!

 

如果各位Google部落格版主有這個問題,請將問題反映給Google，請他們阻擋這種問題的流量

軟體工程方法論與IT政策

 

作者 : Fred F.M. Wang  原作日期 : 2004/08/12

企業在進行一項軟體專案除了專案管理方法外還會引用一套軟體工程方法(Methodology)來完成應用軟體的開發或實作。而採用的方法往往會與使用的技術或專案的特性相關，而專案管理方法也可能與採用的實作方法相關。例如: SAP ERP導入會採用SAP的ASAP Methodology, 而J2EE Project業界流行的是RUP或XP, 而RUP及XP各有一套專案管理的方法，也各有適用的狀況，RUP以Process為主體，XP以人為主體，RUP適用於60人以上的專案而XP適合於現有系統的改善或小型的專案。

企業在方法的選擇及使用的技術會根據其管理的角度訂定IT Policy，而不同管理層面的考慮的優先順序將對企業的成本與效益帶來不同程度的影響。

軟體工程方法論的採用及選擇

筆者在二十多年前研究所階段就以軟體工程方法論的研究為主，最早的軟體工程方法論源於工業工程方法，由於軟體技術的演進及軟體應用層面的擴大，傳統的方法論以經無法適用於各種應用的開發，因此衍生出許多現代的方法論。而這些方法論無非是用來解決應用需求轉換為軟體系統的問題，協助軟體專案從需求定義，系統建構，上線等過程提供系統方法來完成專案。採用軟體工程方法論的目的整理如下:

• 使用者，分析師，與程式設計師等專案人員有共同的語言
• 一致的程序及交付項目
• 以系統的方法增加成功的機率
• 提昇專案品質
• 提高專案的可預測性，及早發現問題
• 成功經驗可以經過文件加以傳承
• 提高專案的效能

如同軟體工程方法論的演進史，不同的方法論是因應不同種類的應用才產生出來的，因此IT Policy應該制定選擇方法論的程序，而非限定單一方法論的使用。

應用系統架構程序

大型與複雜的系統往往無法用單一技術元件完成，特別是近年來J2EE的專案，因Internet而盛行，J2EE Project往往會牽涉多種技術，因此在架構系統的過程更形重要，Architect需在專案範圍，風險，專案時程及資源預算等限制下訂出應用系統的架構，此架構可能包含應開發的元件組合, 選用產品及APIs等，當然IT Policy也是限制之一。由於專案的內外部限制已經很多，因此IT Policy在產品或平台的選擇方面，若過於僵化將使專案的進行更形艱難。

最佳軟體方案(Best of Breed)，單一供應商與自行開發的決策

企業在選擇軟體系統解決方案，會有三種可能的選擇最佳軟體方案(Best of Breed)，單一供應商與自行開發，而這三種方案的決策會受下面的條件的影響:

• 企業現況及需求，包含企業規模，組織，需求的範圍及條件等
• 預算與投資
• 技術或產品的成熟度與市場的趨勢
• 資訊人員的技術能力

以SCM Solution為例, 此三種方案比較如下表:

(另外, 近年使用Open Source或租用則不列入比較 – 2011/11/11)

由上表可知，若政策上要求企業需求適用性為第一考量，則會以Best of Breed及自行開發為主。

不同企業採用的策略不同，年營業額七億以上的Starbucks以Oracle ERP為主幹，再以Best of Breed的方式選入其他產品作為該企業SCM Solution。而年營業額七千四百萬的Green Mountain Coffee Roasters則採用單一廠商產品的解決方案。但是Wal-Mart仍採用自行開發的方式。

以特有與創新的經營管理模式取得市場優勢的公司，往往無法在市場找到適合於此模式的產品，因此傾向於自行開發，如Wal-Mart，其條件是需擁有專業的資訊科技部門。

由於許多較具規模的企業，其業務型態較為複雜，資訊科技於商業應用領域也較為廣泛，因此單一產品往往無法滿足於各項應用，因此也會傾向於採取Best of Breed的方式，如Starbucks等，來滿足快速成長的商業應用，但是業務型態單純及規模較小的企業容易選擇合適的產品以完成企業的需求此時將傾向於選擇單一套裝軟體以減低IT人力成本及整合成本。

因此IT政策在解決方案策略的訂定，應該優先從企業規模及商業需求為優先考慮，以因應企業快速變化的需求，例如，可以制定選擇解決方案的優先順序或不同狀況及不同條件下該採用何種解決方案。

不同產品的適用領域與架構設計師

不同的產品、API或Solutions各有其適用領域，根據筆者的經驗，一個具備一般WCM功能網站用WCM產品與採用Jakarta Struts framework開發的時程差異為一比九。而Document Management System及Workflow System上Lotus Notes優於SAP，Transaction Process則SAP優於Lotus Notes，而開發平台上Domino Designer的彈性優於SAP ABAP Workbench，但SAP Workbench開發速度較快。若某項需求適合用Lotus Notes完成，卻錯誤的選擇用SAP開發，那麼開發時程可能就需花費如上面九倍或更長的時間。

軟體架構設計師(Software Architect)在此的角色，就相當重要，軟體架構設計師是計劃並監督建構過程的軟體技術設計人員，主要的任務就在規劃與系統架構層次相關的事務，評估可能的風險與成本，並有效運用有限的人力、物力 資源達成系統層次的需求，因此除了是資深技術人員，通常也是策略制定、組織協調好手、稱職的顧問與領導者。

一位好的架構設計師通常具有以下專業領域的技術素養：

• 企業需求
• 硬體與軟體架構
• 分析、設計與開發
• 產品支援
• 效能、安全性、容量規劃(capacity planning)、網路

架構設計師在專案過程中的角色:

• 研擬最初的高階架構藍圖(blueprint)並列出影響架構可能因素的清單。
• 審慎評估付諸實施的專案計劃對系統既有基礎結構(infrastructure) 與架構的衝擊，以及計算可能付出的成本與所帶來的效益而訂定。
• 制定專案的架構決策與其優先順序的判斷基準、定義問題領域 (Problem Domain)、決定可能解決方案的限制條件、確認有關可能解決作法的假設狀況以及辨識模組重用的可能性。
• 負責確保需求的達成，以及硬體、軟體、基礎結構、效能、安全性、容量、可用性和系統運作、管理與維護等等屬於系統層次相關技術之間的協調與平衡。
• 構建架構時期，預先列出這些可能的風險，然後在後續的開發時期配合開發人員予以適當地處理與解決。
• 領導開發團隊，保持與其它成員的良好互動，確保開發人員是根據架構藍圖來構建系統。

因此企業應重視軟體架構師的人才培育與投資。在政策上也應訂定正確的方法來進行軟體開發專案。

程式內的註解要寫些什麼?

原作時間 : 2003/2/7 作者: Fred F.M. Wang
 

基本上一個優良的程式撰寫風格就是最直接的說明文件, 不過這裡不辯證該不該寫註解的問題, 另外, 程式內的註解與系統文件還是有所差異, 其對象及目的也有所不同, 在此也不討論 :

註解的種類有 :

1.     repeat of the code : 就是用口語將程式重複說一遍, 像是給不懂程式語言的人看的

2.     explanation of the code : 用來解釋一些複雜或高技巧的程式, 不過往往是撰些時沒有注意程式的結構, 才會如此難懂, 不如用心思再將這段程式改寫的可讀性更高一些, 有關如何寫出優良的程式, 應該有不少書談論

3.     marker in the code : 程式設計師以特殊的標記如 /* %%Note%% ….. */ 留下暫時的標記, 以方便紀錄程式設計過程中, 未完成或待加強的部分

4.     summary of the code : 只取某段程式碼中的重點, 以兩三句話說明, 比重複整段程式來的有用多了

5.     description of the code’s intent : 解釋一段程式的目的, 不從技術面說明, 程式開頭的說明也是這類

如果在分析設計階段能用Pesudo Code或PDL(Program Design Language), 在實作階段在加入程式碼, 那麼這些PDL就是最佳的程式內註解, 不過PDL也有一定撰寫的規則的

SAP Phantom material(虛擬物料)觀念與設定

 

原作時間 : 2000/10/26 作者: Fred F.M. Wang

有些半成品當一組成立即被父項用掉, 因此不會從現場領出(無庫存), 這類的半成品可列為Phantom material, 或某些元件之間在BOM中均集合列出, 可用一料號代表以方便管理, 此代表料號就是Phantom material.

上圖中, 半成品 "X"就是Phantom material

SAP 物料主檔的設定 :

在MRP 1 view中的special procurement欄位選50(Phantom assembly) lot size key 選擇"EX" (lot for lot)

SAP MRP時間計算之四 : MRP date其它的決定因素

 

原作時間 : 2000/4/7 作者: Fred F.M. Wang

有時您會發現，您根據上面三個單元算出的MRP date，仍與系統算出的不同，那麼請看下面的兩項因素:

1. Time fence(計劃時柵): 指定某時間內產生的planning orders不再被變更，因此若某planning order推算出的MRP date若落在time fence內則會自動將MRP date改至time fence結束日後。Time fence在物料主檔的MRP 1 view中維護。

2. Lot-sizing procedure(批量程序): 若採期間批量法，批量期間為週，則MRP date只會落在每週的第一個工作日，若某planning order推算出的MRP date落在一週的第三個工作日，則系統會將MRP date自動改至下一週的第一個工作日。批量期間為雙週(by-weekly)，則MRP date只會落在每兩週的第一個工作日，批量期間為月，則MRP date只會落在每月的第一個工作日，依此類推。Lot sizing procedure在物料主檔的MRP 1 view中的批量欄維護。

直接在庫存/需求清單看主檔相關欄位

相關內容 :

• SAP MRP時間計算之一 : 外部採購物料的MRP時間計算
• SAP MRP時間計算之二 : 廠內生產成品/半成品的MRP時間計算(以基本日期)
• SAP MRP時間計算之三 : 廠內生產成品/半成品的MRP時間計算(以前置時間排程)

SAP MRP時間計算之三 : 廠內生產成品/半成品的MRP時間計算(以前置時間排程)

 

原作時間 : 2000/4/7 作者: Fred F.M. Wang

說明:

1. 本計算方式適用於物料的採購類型為E(廠內生產)的料號。(請見物料主檔MRP 2 view) ，且執行MRP/MPS時使用的MRP控制參數 “排程” 為 2。

2. Lead time scheduling 計算方式與上一單元的差異在in-house production time的算法不同，本單元僅就此部份進行說明。

3. Float before production: 生產前至order start date的緩衝時間。在物料主檔的MRP 2 view中的排程臨界碼維護，排程臨界碼在Customizing中設定。

4. Float after production: 生產完成至order finsh date的緩衝時間。在物料主檔的MRP 2 view中的排程臨界碼維護，排程臨界碼在Customizing中設定。

5. Interoperation time(作業間時間): 包含Move time, Queue time, Wait time。以lead time scheduling 方式計算，廠內製造時間將會根據routing每一站的設定合計經每站所需的時間，含作業間時間及作業執行時間。

6. Queue time(佇列時間): 在Routing的作業明細內維護。

7. Wait time(等待時間): 物料移至下一站處理前的等待時間。在Routing的作業明細內維護。

8. Move time(運輸時間): 物料由本站移至下站所需的時間。在Routing的作業明細內維護。

9. Execution time(作業執行時間): 包含setup time, process time, teardown time。

10. Setup time(設立時間): 由Work center的排程頁面中設定的”設立公式”計算得到，該公式計算用參數可為Routing內的標準值或可設為固定常數。

11. Process time(處理時間): 由Work center的排程頁面中設定的”處理公式”計算得到，該公式計算用參數可為Routing內的標準值或可設為固定常數。

12. Teardown time(拆卸時間): 由Work center的排程頁面中設定的”拆卸公式”計算得到，該公式計算用參數可為Routing內的標準值或可設為固定常數。

13. Lead time scheduling可在routing的畫面中選 附加>排程>時程，進行模擬計算。

相關內容 :

• SAP MRP時間計算之一 : 外部採購物料的MRP時間計算
• SAP MRP時間計算之二 : 廠內生產成品/半成品的MRP時間計算(以基本日期)

SAP MRP時間計算之二 : 廠內生產成品/半成品的MRP時間計算(以基本日期)

 

原作時間 : 2000/4/7 作者: Fred F.M. Wang

說明:

1. 本時間計算方式適用於物料的採購類型為E(廠內生產)的料號。(請見物料主檔MRP 2 view)，且執行MRP時使用的MRP控制參數 “排程” 為 1。

2. Goods receipt processing time(收貨作業處理時間): 在物料主檔的MRP 2 view中維護。

3. In-house production time(廠內生產時間): 可以設定與批量相關或與批量無關兩種計算方式，若與批量無關則須在物料主檔的MRP 2 view中維護廠內生產日數，若與批量相關則須建立工作排程view，並在此view中維護setup time, processing time, interoperation time and base quantity

• Setup time(設置時間): 包含所有的設置(setup)及拆卸(teardown)時間。
• Processing time(加工處理時間)
• Interoperation time(加工站間隔): 包含Move time, Queue time, Wait time, Float before production, Float after production, Planned delivery time of an operation processed externally等
• Base quantity(基礎數量)
• 批量相關的廠內生產時間 = setup time + interoperation time + (processing time * order quantity / base quantity )
• 注意:採”批量相關”計算時，請將MRP 2 view內的廠內生產日數設為零。

4. Opening period: 上一單元介紹過。

5. Release period: 決定production order應release的日期，與production order的維護有關，order release date = order start date – release period。在物料主檔的MRP 2 view中的排程臨界碼維護，排程臨界碼在Customizing中設定。

6. Backward scheduling: MRP類型屬於MRP或forecast-base planning(PD,VV)均採此方法計算。由物料的requirement date(MRP date)往前推算order start date，order finish date及plan opening date。

• Order finish date = MRP date - GR processing time
• Order start date = Order finish date – in-house production time
• Plan opening date = Order start date – opening period
• 若計算出的order start date落在過去則系統自動切換成Forward scheduling 計算。(也可依廠別在Customizing設定即使order start date落在過去也不自動切換成forward scheduling, txn:OPPQ)

7. Forward scheduling: MRP類型屬於再訂購點方式(VB,VM)均採此方法計算或Backward scheduling計算時，order start date落在過去則系統自動會改成Forward scheduling 計算。以planning date(MRP執行日) 為order start date往後推算至order finish date及MRP date。

• Order finish date = Order start date + in-house production time
• MRP date = Order finish date + GR processing date

 

相關內容 :

• SAP MRP時間計算之一 : 外部採購物料的MRP時間計算
• SAP MRP時間計算之三 : 廠內生產成品/半成品的MRP時間計算(以前置時間排程)

SAP MRP時間計算之一 : 外部採購物料的MRP時間計算

 

原作時間 : 2000/4/7 作者: Fred F.M. Wang

說明:

1. 本時間計算方式適用於物料的採購類型為F(外部採購)的料號(請見物料主檔MRP 2 view)。

2. lead time offset(前置期偏移 by 工作日): BOM上層組件(成品or半成品)的order start date的偏移值。正值表示該元件在製造開始後才有需要，負值表示該元件在製造前就應備好。因此元件的MRP date(requirement date) = 上層組件的order start date + lead time offset。在BOM元件項目的明細內維護。

3. Goods receipt processing time(收貨作業處理時間): 在物料主檔的採購view中維護。

4. Planned delivery time(計劃交貨時間): 若該物料有多家廠商，請設平均值。在物料主檔的MRP 2 view中維護。

5. Purchasing department processing time(採購處理時間): 採購文件所需的處理時間，依不同廠別在Customizing中設定(txn:OPPQ)。

6. Opening period: 為MRP controller將planned orders轉成PR or production orders的buffer time，例如，物管人員三天開一次PR則opening period應設為3(選排程臨界碼000)。在執行MRP前，將MRP控制參數”建立請購單”設為2(未確定期間的請購)，執行後planning open date落在planning date及planning date前的planning orders會自動轉成PR，例如，4/6日run MRP則order start date在4/6未來三天的planning orders均會自動轉成PR。僅在Backward scheduling有用。在物料主檔的MRP 2 view中的排程臨界碼維護，排程臨界碼在Customizing中設定。

7. Backward scheduling: MRP類型屬於MRP或forecast-base planning(PD,VV)均採此方法計算。由物料的requirement date(MRP date)往前推算order release(start) date，order finish(delivery) date及plan opening date。(註: MRP類型請見物料主檔的MRP 1 View)

• Order finish(delivery) date = MRP date - GR processing time
• Order start(release) date = Order finish date – Planned delivery time – Processing time for purchasing
• Plan opening date = Order start date – opening period

若計算出的order start date落在過去則系統自動會切換成Forward scheduling 計算。(也可依廠別在Customizing設定即使order start date落在過去也不自動切換成forward scheduling, txn:OPPQ)

8. Forward scheduling: MRP類型屬於再訂購點方式(VB,VM)均採此方法計算或Backward scheduling計算時，order start date落在過去則系統自動會改成Forward scheduling 計算。以planning date為order release(start) date往後推算及order finish date及MRP date。

• Order finish(delivery) date = Order start date + Planned delivery time + Processing time for purchasing
• MRP date = Order finish date + GR processing time

 

相關內容 :

• SAP MRP時間計算之二 : 廠內生產成品/半成品的MRP時間計算(以基本日期)
• SAP MRP時間計算之三 : 廠內生產成品/半成品的MRP時間計算(以前置時間排程)

網路專有名詞Cookie(指HTTP Cookie)由來

作者 : Fred F.M. Wang on 2011-11-8

這是個有趣的問題，為什麼用了那麼久，還是不知道網站技術的Cookie的命名是怎麼來的? 為何要叫做Cookie?

首先這個機制發明者是1994年Netscape瀏覽器的開發人員之一 Lou Montulli，為解決online shopping cart的問題，將通過Server端認證的身分識別資訊儲存在用戶端，以後每次進入網站檢查儲存在Cookie的認證資料就可以了， ( 他將此資訊形式稱為Cookie )，以減少用戶重複的登入與身份認證程序。

Lou表示Cookie源於當時(90年代) UNIX programmer慣用的詞彙"Magic Cookie” [1]，係指在程式間傳送，用來讓接收端執行一些動作的訊息("Something passed between routines or programs that enables the receiver to perform some operation.")，而Magic Cookie發明者不可考，有一種說法是源於80年代末期到90年代早期的電腦遊戲，在該遊戲中吃掉魔術餅乾可以有特殊的能力[2] (有點像早期任天堂的馬力兄弟遊戲)。

電腦技術人員喜歡打電動，而用電腦遊戲中的名詞命名的說法是比較可信的。

註 :
1.上面資訊經過Andrew Stuart寫信向發明者Lou Montulli詢問證實，如下http://dominopower.com/article/where-cookie-comes-from/，在下面連結http://www.cookiecentral.com/faq/#1.2 中也列出Lou Montulli自己的答覆。

2.何謂Cookies, https://www.opra.doi.state.ma.us/Home/OPRA_Cookies.asp

3.網路上另一種說法(錯誤)是，Cookie因為要當作識別用，每一個用戶的Cookie包含的內容都不相同，就好像Fortune Cookies(幸運餅乾，咬開後餅乾內的空心部分會有張小紙條，寫著你今天會有好運或一句勉勵的話)，每一餅乾裡面的紙條都不太一樣。(當然用Java/Javascript要搭配吃Cookies也是錯誤的)

4. Magic Cookie由來有兩種說法
a. Commonwealth of Massachusetts (https://www.opra.doi.state.ma.us/Home/OPRA_Cookies.asp)
"Cookies for the internet were originally developed in 1995 by the Netscape Communications Corporation. The word "cookie" comes from "magic cookie," a computer science term for a piece of information shared between co-operating pieces of software. So where does "magic cookie" come from? Some say it comes from the computer games of the late 80's & early 90's. Eating Magic Cookies in the game would give the player special powers. " (吃魔術餅乾的電腦遊戲)
註: 這是麻州的一個政府單位發布的

b. AboutCookies.org (http://www.aboutcookies.org/Default.aspx?page=5)
"Cookies for the internet were originally developed in 1995 by the Netscape Communications Corporation. The word 'cookie' comes from 'magic cookie,' a term in programming languages for a piece of information shared between co-operating pieces of software. The choice of the word cookie appears to come from the American tradition of giving and sharing edible cookies." (根據美國分享餅乾的傳統典故，因此以cookie表示軟體各部分間資訊分享的部份)
註 : AboutCookies是由Pinsent Masons法律事務所所提供的網站，致力於提供有關偵測，控制與刪除不同瀏覽器Cookies的相關資訊。

國外出差旅行使用電子設備安全守則

譯者 : Fred F.M. Wang 2011/9/30
原文 : “Traveling Overseas with Mobile Phones, Laptops, PDAs and Other Electronic Devices, Tips from the National Counterintelligence Executive”


這是2008年北京奧運前夕發佈"海外旅客使用電子設備安全守則"，也可以提供國人參考。

應該知道的事項


1.在多數的國家不要期望在網咖，旅館，辦公室或公共場所擁有隱私。在許多國家旅館的商務中心和公共網路是被監控的。在一些國家旅館房間還經常被搜索。

2.您傳送的所有電子資訊如傳真機，PDA，電腦與電話都可能被攔截。無線設備尤其脆弱。

3.公安與刑事單位可以透過你的行動電話或PDA追蹤你的行動而且可以打開設備中的麥克風。要預防追蹤，要移除設備中的電池。

4.公安與刑事單位也可能透過他們控制的連線，植入惡意軟體。如果你啟用無線網路，他們也能做到。當你連到主伺服器，惡意軟體就會移轉到業務，代理或主系統中，然後將資訊送回公安單位。

5.惡意軟體也可以由拇指碟，磁碟或光碟等贈品轉移到你的電子設備中

6.從海外傳送敏感的政府，個人隱私資訊是有風險的

7.公司與政府官員是最可能暴露在風險中，但也不要假設自己不顯眼而不會被鎖定。

8.外國的公安與刑事單位對”釣魚”很嫻熟-會偽裝博取你的信賴以取得個人或敏感的資訊。

9.如果海關官員要求檢查你的設備，或設備在房間而你不在時旅館房間被搜索，你要假設設備的硬碟已經被複製了。


旅行前

1.能不要帶電子設備就不帶。

2.避免將重要資訊放在電子設備內，如敏感的聯絡資訊，以防被外國政府或競爭者取得。

3.備份所有要帶出去的資料，將備份的資料留在家中。

4.如果可以的話，使用與平常慣用不同的手機，沒有用的時候就移除電池。

5.設備的準備

5.1建立長而複雜的密碼

5.2定時更新密碼

5.3下載最新的防毒程式與防毒碼，更新為最新版的作業系統與防火牆。

5.4更新的網頁瀏覽器，並做嚴格的安全性設定。

5.5取消紅外線ports及其他不需要的輸出入ports。

出境後

1.避免讓設備放置在運送的行李中。(應隨身攜帶)

2.儘可能使用數位簽章與加密功能。

3.電子設備不離身。如果必須隱藏行蹤，要取下電池以及SIM卡。

4.不要在自己的電子設備中使用別人贈送的拇指碟。也不要在外國的電子設備中使用自己的拇指碟。

5.在海外登入網站，不要設定讓電腦記住密碼，每次登入時重新輸入密碼。

6.在公共場所要注意誰在窺視你的螢幕。

7.不使用設備時，一律斷線。

8.每次使用網頁瀏覽器後就清除暫存檔，Caches, Cookies等。

9.不要打開不明發信來源的郵件或附件，也不要點郵件中的連結。每次使用結束清空垃圾資料夾與最近的紀錄。

10.避免使用Wi-fi網路，在一些國家，是由公安單位所控制的；因此都是不安全的。

11.如果設備或資料被竊，立即向家鄉組織和當地美國大使館或領事館通報。

回國後

1.變更您的密碼

2.讓您的公司或機構檢查電子設備中是否存在惡意軟體。

三種企業網站多國語言的設計方式分析

作者 : Fred F.M. 日期 : 2011/9/19

目前跨國性企業網站的多國語言設計方式主要分為三種 :

方式一 自動判斷使用者預設的語言直接進行重導或詢問
方式二 先進入官方主頁或語言選擇頁，使用者選擇語言後再進行重導
方式三 可由使用者設定未來要顯示的語言

方式一 自動判斷使用者瀏覽器的預設語言,直接進行重導或詢問

如Google,Yahoo,MSN等網路服務網站，由於服務對象為廣大的使用者，因此多採用此種方式，讓多數用戶能夠不需選擇或設定直接進入其慣用的語言(瀏覽器預設語言)。

功能說明 : 根據使用者瀏覽器預設的語言，自動導到該語言的主頁，或跳出詢問對話窗，詢問要進入官方英文主頁或導到使用者語言的主頁。例如進入Sony或MSN網站，會自動偵測到使用者的語言，如果不是英文，則會顯示如詢問對話窗的畫面。

技術說明 : 在預設首頁開頭放置一段Javascript程式，判斷使用者瀏覽器的預設語言，然後自動重導到該語言的主頁或產生詢問對話窗。

方式一又分 :
1.1 直接重導 : 如 Yahoo, Google, Facebook, hp, Philips, Samsung等
優點 : 直接進入使用者預設的語言，不需任何選擇語言的動作。
缺點 : 若使用者預設的語言與瀏覽網頁要使用的語言不同，則每次必須重選語言。

1.2 跳出詢問對話窗 : 如 MSN，Sony等
優點 : 立即詢問要進入官方預設主頁或使用者語言的主頁，不必花時間尋找語言選擇功能。
缺點 : 若網站官方預設語言與使用者預設語言都不是瀏覽網頁要使用的語言，則每次必須重選語言。

方式二 先進入官方主頁或語言選擇頁，使用者自行選擇語言後再進行重導

除上述網路服務網站外，跨國性企業多採取第二種方式，原因是考慮使用者瀏覽器預設語言可能與瀏覽網頁要使用的語言不同，因此將語言的選擇權利交給使用者。

功能說明 : 先進入企業官方預設的主頁(通常為英文)或語言選擇網頁後，由使用者自行選擇瀏覽網頁要使用的語言，然後再導到該語言的主頁。

技術說明 : 在官方預設主頁或語言選擇頁提供的語言或國別清單選擇，使用者選擇語言後，再由網頁中的Javascript程式進行重導。

方式二又分 :
2.1 先進入官方預設主頁 : 如 Microsoft, GE, Apple, Dell, Amazon, Oracle等
優點 : 將選擇瀏覽網頁要使用的語言的主導權交給使用者。
缺點 : 若瀏覽網頁要使用的語言不是網站官方預設語言，則每次必須選擇語言。

2.2 先進入語言選擇網頁 : 如 Coca-Cola , Nokia , BMW , SAP, UPS, VISA
優點 : 可立即選擇瀏覽網頁要使用的語言，不必花時間尋找語言選擇功能。
缺點 : 每次進入都必須選擇語言。

方式三 可由使用者設定未來要顯示的語言 : 如 IBM, Intel, Nvidia

第二種方式的缺點在於如果使用者選擇的不是該網站官方預設語言(通常為英語)，則每次進入主頁都必須做一次語言的選擇；因此，IBM, Intel，Nvidia等公司採取第三種方式，提供語言設定與儲存功能，設定後就記錄在用戶端，不需要每次進行語言選擇。

功能說明 : 進入企業官方主頁(通常為英文)後，提供使用者設定並儲存瀏覽網頁要使用的語言，設定後會記錄在用戶端，未來再進入時，就會自動導到該語言的主頁。

技術說明 : 首頁中提供語言選擇與儲存的功能或連結到設定語言的網頁，選擇後透過Javascript程式將選擇的語言儲存在用戶端瀏覽器的cookie(註)中。未來每次進入該公司主頁會先透過Javascript程式判斷，如果用戶端(Cookie)已經有選擇的語言，就會重導到該語言的主頁。

註:Cookie是網站用來將使用者瀏覽狀態儲存在用戶端的方式， 再次瀏覽該網站就會回復到原來的狀態。

優點 : 只要設定一次，未來都會自動重導到目標語言的主頁。

由上述說明可以了解，第三種方法是最佳的設計方式，建議參考Nvidia的設計方式。在使用者第一次進入Nvidia網站時，就顯示語言選擇網頁。由使用者決定瀏覽網頁要使用的語言。使用者可以選擇是否要儲存選擇的語言。如果儲存選擇的語言，則未來進入Nvidia網站就會以自動進入該語言的主頁。Nvidia在主頁中也提供變更原設定語言的功能。

iPhone追蹤與監視應用軟體(Apps)整理

作者 : Fred F.M. Wang 日期 : 2011/10/21

目前市面上有許多的iPhone 安全防護軟體多放在資料保護, 遺失尋找與遠端資料移除的功能，較少有iPhone使用者行為紀錄的應用程式。僅找到三個具備此功能的iPhone Apps

什麼是追蹤與監視應用軟體(iPhone Tracking and Monitoring Apps)?

可以用來追蹤與監控所擁有的iPhone手機，功能包含文字訊息擷取，電話內容擷取，遠端監控，GPS追蹤等。

iPhone Tracking and Monitoring Apps如何運作?

第一類 : iPhone Tracking 軟體必需實體連線安裝，無法遠程安裝。安裝完畢後立即開始紀錄iPhone上特定的行為(activity)，然後將所有的資料，如文字訊息，電話紀錄與GPS位置等秘密地上傳到廠商提供的網站；安裝軟體者可以用廠商提供的帳號登入該網站檢視手機上所有的活動。

第二類 : 軟體安裝於PC，透過PC與iPhone連線，抓取iPhone中的歷史紀錄。

有哪些功能?

1. 檢視相片與影片 : 可以下載並檢視該手機相片與影片的快照。

2. GPS追蹤 : 可以GPS秘密地追蹤iPhone，根據GPS座標可以知道iPhone持有者所在地點。

3. 找到與閱讀文字訊息 : 秘密地紀錄送出與接收的文字訊息。每個文字訊息的複本都被傳送的遠端，因此即使被刪除，複本仍然存在。

4. 檢視郵件 : 秘密地紀錄所有送出的郵件。

5. 電話歷史紀錄 : 秘密地紀錄所有通話紀錄，包含相關電話號碼在通訊錄中的姓名。

等

使用目的 : 目前iPhone Tracking and Monitoring Tools用在三個目的

1.配偶iPhone監控

2.子女iPhone監控

3.員工iPhone監控 : 用在公司提供的iPhone使用記錄。在一些訴訟案中如果沒有與特定客戶的溝通紀錄可能會讓公司處於不利的風險。

產品介紹

1. Flexspy : 為技術最先進的iPhone tracking and monitoring app。功能最強大，也最貴。

功能 : 電話攔截(Live call interception)，遠端監控，簡訊/文字訊息攔截，電話紀錄檢視與隱藏的GPS追蹤。

• 100%無法被察覺
• 價格 : $149~$349 USD
• URL : http://www.flexispysoftware.com/
• 條件 : iPhone必須越獄，必須有網路連線(3G, EDGE, GPRS) 

2. Mobile Spy : 世界第一家隱藏式iPhone追蹤與監控軟體公司。

功能 : 隱藏的GPS追蹤，檢視相片，讀取郵件，讀取簡訊，檢視電話紀錄，檢視聯絡清單。

• 透過SSL安全連線檢視紀錄 
• 價格 : $49.97~$99.97 USD 
• URL : http://www.mobile-spy.net/ 
• 條件 : iPhone必須越獄，必須有網路連線(3G, EDGE, GPRS) 

3. iPhone Spy Stick : 與前兩種安裝與運作方式不同，是一種不需要越獄的iPhone Tracking Tool

功能 : 檢視已刪除之文字訊息，檢視已刪除的電話紀錄，檢視已刪除的相片，擷取GPS座標(含歷史紀錄)，檢視網頁瀏覽歷史與行事曆紀錄等

• 安裝方式 : 透過iPhone cable一端連iPhone一端連安裝iPhone Spy Stick軟體的PC。 
• 價格 : $169.95 USD 
• URL : http://www.iphonespystick.com/

結論 :

1. Flexspy與Mobile Spy 都具備紀錄iPhone傳送接收的簡訊，送出的郵件，通話紀錄，GPS定位追蹤等功能，可以不影響iPhone的使用情況下，監看這些紀錄，但是，只能安裝在越獄手機。

2. iPhone Spy Stick 不需要越獄，但是功能僅限於檢視已刪除的訊息與通話紀錄等，而且必須將iPhone連接PC才能檢視。

3.Verdasys的Digital Guardian，將於2012年將會有Android與iOS版本的DG，但是時程尚未確定。

4. 賽門鐵克發表 Data Loss Prevention for Tablets 預防 iPad 機密資訊外洩,但是不是iPhone

因此, 目前尚未發現企業可用的iPhone Data Leak Preventation Apps

Java程式審查清單(code review checklist)

譯者 : Fred F.M. Wang 日期 : 2011/11/14

以下是一些審查 Java程式碼需注意項目。以下清單有審查 Java程式碼要展開的活動列表。包含有11個不同類型的問題與審查的領域。譯者註 : 有許多也不限於Java程式，在多數語言都適用，有些部份也可以利用Code Review或inspection工具輔助檢查，有些則需人工檢查。 

1. 程式設計風格與樣式相關問題

1.1 有遵循專案計劃中指定的標準？

1.2 有提供適合的內含文件，也就是程式內的註解? 以提供較佳的可維護性。 

1.3 程式檔案開頭是否包含下面項目

• 程式標頭 : 如程式名稱與描述
• 應用系統名稱 
• 依存關係 : 相關的程式，Tables等 
• 限制 : 執行環境與條件 
• 版權資訊 
• 修改日誌

1.4 是否遵守有意義的命名慣例？命名是否正確反映程序或參數層級？命名是否正確定義全域，共用與外部的功能函式？譯者註 :以提高程式的可讀性。

1.5 程式碼是否有做合適的縮排? 譯者註 :以提高程式的可讀性。

1.6 是否呼叫一套共用的副程式庫，而不是複製程式碼到不同的程式中？ 譯者註 :以提高程式的再用性，與可維護性。

1.7 有任何冗餘的程式碼? 譯者註 :應該撰寫乾淨的程式碼(Clean Code)。透過版本管理軟體保留舊版程式，而不要把舊程式碼mark成註解保留在程式中造成冗長且難以閱讀的程式。

2. 標籤和助譯碼相關問題

2.1 程式中有任何標籤(label)沒有被引用到？

2.2 是否使用有意義的助譯碼或巨集？ (助譯碼通常用於設定畫面選單或其他操作的快速鍵)

2.3 助譯碼或巨集是否正確地使用。

3. 陣列相關的問題

3.1 所有的陣列索引值是否會落在限定範圍(bounds)內? 譯者註 :程式中應該做陣列索引值檢查，避免在執行中超過限定範圍(bounds)，造成不可預期的錯誤。

3.2 是否正確地初始化所有陣列的索引?

4. 迴圈/分支相關的問題

4.1 所有分支條件是否正確?

4.2 迴圈是否可被終止? 譯者註 :除了極少數的情況，程式迴圈都應該可以被終止。

4.3 終止一個迴圈的條件是否正確?

4.4 程式中除法運算式前，是否有檢查除數為零的狀況?

4.5 放在迴圈內的敘述是否可以移到迴圈外? (譯者註 :避免效能問題)

5. 結構相關的問題

5.1 某些部分的程式碼，在程式各種執行的線程中，是否永遠不會被執行到?  譯者註 :不會被執行到的程式碼就是冗餘的程式碼，也有可能是程式的條件式設計錯誤。

5.2 是否使用了過多的IF敘述? 譯者註 :是否可以用Switch.. Case語法取代多重的IF敘述? 以提高程式的可讀性。

6. 功能相關的問題

6.1 程式中對匯入的資料是否有做正確性檢查?

6.2 呼叫程式碼(Caller)實際參數與被呼叫的副程式中的正規參數是否匹配?

6.3 所有變數是否都有被使用到? 所有輸出的變數是否都有指定值? 譯者註 :這種情況容易造成程式維護者的困擾，因此程式開發時就應該去除沒有被使用到的變數，以提高可維護性。

7. 資料庫相關的問題

7.1 是否對Table的query有使用索引? (譯者註 :Select * Where.. 的query中如果沒有對應的索引，將造成全表搜尋，影響執行效能)

7.2 新增/修改模式的畫面屬性是否正確的設定與重設?

7.3 每個SQL敘述後是否有做錯誤狀態的檢查?

7.4 在更新資料庫data record前是否有先進行data record的鎖定(lock)

7.5 運算式中下面兩個條件是否有檢查?

• Rounding off (if required) 四捨五入(如果需要)
• Possibility of division by zero 除以零的可能性

8. 效能相關的問題

8.1 是否滿足執行時間的需求? 要做效能測試!

8.2 是否有更有效率的寫法? 譯者註 :例如相同結果採不同SQL寫法效率差異很大，因此有些SQL最佳化工具用來改善SQL Code。

9. 可用性相關的問題

        程式處理需要花較長的時間，是否提供通知訊息(optional)? 譯者註 :例如提供進度列(progress bar)，讓使用者需要花多少時間? 還有多久才會執行完? 避免讓使用者有系統當掉的不安感。

10. 檔案相關的問題

     檔案處理是否有做下面的檢查?

• 開啟檔案時先檢查檔案是否是空的?  
• 檢查是否產生輸出入的錯誤?

11. 錯誤處理的問題

11.1 使用者對錯誤訊息容易理解嗎? 錯誤訊息合適嗎?

11.2 所有的錯誤有被捕捉與控制嗎? (譯者註 :避免當掉的情況)

參考原文 : http://technotes.towardsjob.com/java/code-review-checklist-for-java/

八大類提升網頁效能的免費輔助設計與測試工具

作者 : Fred F.M. Wang (F.W.知識瑣記) 日期: 2011/11/04

第一類 網頁元件下載效率分析工具

1.1  HttpWatch 顯示網頁元件下載效率,目前有IE與Firefox的Plug-ins(Free)

1.2 Firebug 顯示每一網頁元件的大小與下載效率,目前僅有Firefox的Plug-ins(Free)

1.3 WebPageTest.org 網頁效能與最佳化分析工具,限外部網站(Free)

第二類 網頁設計最佳化分析工具
2.1 WebPageTest.org 網頁效能與最佳化分析工具,限外部網站(Free)

2.2 Google Page Speed (Free)
   a."根據Google網頁最佳化設計原則,進行網頁的分析,評分與建議
   b.外部網站可以直接使用Online Service
   c.內部網站則可下載使用Plug-in(只有Firefox與Chrome plug-ins)"

2.3 Yahoo Yslow 根據Yahoo網頁最佳化設計原則,進行網頁的分析,評分與建議,提供Firefox, Chrome,Opera, Safari等Plug-ins(Free)

第三類 圖檔壓縮與最佳化工具

3,1 Imagemagick 各類型圖檔轉換,壓縮,調整與特效工具(Open Source)

3.2 PNGCrush PNG檔最佳化工具(Open Source)

3.3 Jpegtran,gifsicle JPEG, GIF檔最佳化工具(Free)

3.4 YahooSmush.it Yahoo提供的圖檔最佳化工具(Free)

3.5 GIMP 影像處理工具(Open Source)

3.6 Paint.NET 影像與數位相片編輯工具(Open Source)

第四類 CSS Sprites產生器

CSS sprites技巧可以有效降低圖片文件的 HTTP連接請求數。將多個圖片以一定間距合併為一個圖片文件。頁面中使用這些圖片的元素將利用 background-position 這一 CSS 屬性來顯示合併圖片中的指定位置。

4.1 CSS 圖片合併產生器 : 這個工具可為您自動產生 CSS 圖片合併。 只需傳送一個內含2個以上圖片文件 (GIF, PNG or JPG) 的 ZIP 壓縮檔，就會為您自動產生合併後的圖片與 CSS 程式碼。 Open Source

4.2 Online CSS Sprites Generator 同上(Free)

4.3 SpriteGen 同上(Free)

第五類 Inline Image產生工具

使用data: URI scheme 把圖片數據嵌入頁面，雖然會增加Html檔的大小，但是若將內聯圖片合併到被緩存的樣式表檔案中則能既減少HTTP請求數又不會增加頁面大小。

5.1 DataURL.net DataURL Maker 只要把圖檔上傳，就會產生Inline image的資料檔(Free)

5.2 WebSemantics DataURL Convertor 同上(Free)

第六類 網頁縮小化工具(Minify)
從代碼中刪除不必要的字母，減少文件體積從而提高下載速度。

6.1 YUI Compression CSS, Javascript壓縮工具 Free

6.2 Alentum Absolute HTML Compressor 免費下載的HTML壓縮軟體(Free)

6.3 Dean Edwards' Packer 一個簡單的線上 Javascript 壓縮工具(Free)

6.4 Text Fixer HTML Compressor 一個簡單的線上HTML壓縮工具(Free)

6.5 HTMLCompressor.com 一個線上HTML,Javascript,CSS壓縮工具(Free)

6.6 "Javascript Compressor.com,

6.7 JSCompress.com" 一個線上Javascript壓縮工具(Free)

6.8 CSSCompressor.com 一個線上CSS壓縮工具(Free)

第七類 網頁程式模糊處理(obfuscation)工具

透過程式縮小化,變數無意義化,字串16進制化等方式進行網頁程式的糢糊化，美國的前十大網站，縮減獲得了21%的體積減小而程式碼模糊處理達到了25%。除了減量外還具有保護程式碼的功效

7.1 SearchBliss HTML Scrambler 線上HTML模糊處理工具(Free)

7.2 Jasob Obfuscation Tool 保護與最佳化Javascript,CSS,Javascript碼 Pay(有Fee trial)

7.3 javascriptobfuscator.com 線上Javascript模糊處理工具(Free)

第八類 Javascript Framework(Utilities)

透過Javascript Framework提供的Utilities提升Javascript程式效率

8.1 YUI Lazy Load工具，如YUI image loader(Free)

8.2 jQuery Lazy Load工具，如jQuery Lazy loader(Free)

8.3 Mootools Lazy Load工具，如Mootools LazyLoad(Free)

8.4 Prototype.js Lazy Load工具，如Prototype.js lazierLoad(Free)

相關文章
1. 免費的網站效能分析與測試工具與網頁效能最佳化分析工具介紹
2. 如何提升網站與網頁效能參考資訊整理

免費的網站效能分析與測試工具與網頁效能最佳化分析工具介紹

作者 : Fred F.M. Wang 日期: 2011/10/28
網站伺服器流量檢視工具
1 MRTG 用來偵測伺服器與網路的資料流量,能即時地繪出網路流量的統計圖。(Open Source)
2 RRDTool 同上(Open Source)
3 Cacti 同上,但功能更為強大(Open Source)

連線路徑與效率檢視工具
1 TraceRoute 可顯示封包在IP網路經過的路由器的IP位址與速率。(可以在DOS下執行tracert IP address)(Free)
2 SpeedTest.net 跨國兩點連線上傳與下載速率(Free)

網頁元件下載效率分析工具
1 HttpWatch 顯示網頁元件下載效率,目前有IE與Firefox的Plug-ins(Free)
2 Firebug 顯示每一網頁元件的大小與下載效率,目前僅有Firefox的Plug-ins(Free)
3 WebPageTest.org 網頁效能與最佳化分析工具,限外部網站(Free)

網頁效能最佳化分析工具
1 WebPageTest.org 網頁效能與最佳化分析工具,限外部網站(Free)
2 Google Page Speed (Free)
    a."根據Google網頁最佳化設計原則,進行網頁的分析,評分與建議
    b.外部網站可以直接使用Online Service
    c.內部網站則可下載使用Plug-in(只有Firefox與Chrome plug-ins)"
3 Yahoo Yslow 根據Yahoo網頁最佳化設計原則,進行網頁的分析,評分與建議,提供Firefox, Chrome,Opera, Safari等Plug-ins(Free)

網站壓力測試工具
1 Apache Jmeter 可錄製script，進行網頁壓力測試(Open Source)
2 OpenSTA 可錄製script，進行網頁壓力測試(Open Source)
3 Jcrawler 可錄製script，進行網頁壓力測試(Open Source)

網路頻寬模擬器
1 Aptivate Low Bandwidth Simulator 模擬低頻寬下你的網站執行/下載的情況，限外部網站(Free)
2 DummyNet 模擬頻寬限制,延遲下應用系統執行的結果(Open Source)

相關文章
1. 免費網頁效能提升的設計輔助工具介紹
2. 如何提升網站與網頁效能參考資訊整理

晉升的陷阱文章感想

 Fred F.M. Wang 原作日期 : 2010/9/9

“晉升的陷阱”原文 http://www.managertoday.com.tw/?p=2168:
這篇文章蠻好的，我的感想是
 
1. 馬謖失街亭的應負責任比較大的人，應該是孔明而非馬謖，省思三國演義的故事，可以發現天才如孔明，仍會一些犯錯誤。

2. 人事晉用不見得與能力有關，劉備用臥龍(孔明)而不用鳳雛(龐統)，因為龐統長的太醜。而曹操唯才是用造就魏國的強盛。因此，沒有被錄取或晉用，有時候也不用太責怪自己，也許沒有遇到明君，例如，姜子牙八十三歲如果沒有遇周文王，如何留名青史，蘇東坡才華過人卻一路被貶抑到海南島，一則幸，一則不幸。

3. 進入一個工作都會有適應與撞牆期，端賴主管有沒有心協助或自己有沒有毅力度過這些難關。主管用人除了要有智慧，還要有容忍屬下可能犯錯的雅量。如傑克威爾許年輕時因犯錯燒掉奇異公司的實驗室，因老闆寬容，傑克威爾許才有機會創造奇異公司A+成績。

當然，除了能力，自己的興趣或意願也很重要，如果有興趣就應即早培養準備做該職務的能力，如果沒有興趣硬接工作可能也做不久。


贊同文章中破解彼得原理魔咒的方法! 當然，最無法適應辦公室金字塔文化的人，可能就是創造大企業的人，如 Steve Jobs, Bill Gates, 郭台銘等。

Google免費提供的Java GUI開發工具,測試工具,程式品質與安全分析工具

2010/12/17 Google捐贈價值五百萬美金開發工具給Eclipse基金會
ZDNET新聞專區： Ed Burnette
2010/12/17
”前Instantiations產品開發副總裁現任Google軟體經理Eric Clayberg在Google Code
部落格上宣布，Google將捐贈WindowBuilder及CodePro Profiler這兩套開發工具的原
始碼及IP給予Eclipse基金會。
WindowBuilder是Google在今年8月併購Instantiations公司時所獲得的技術，是目前
最好的Java圖形介面設計工具；而CodePro Profiler則是可讓Java效能最佳化的工
具。估計這兩項工具的價值在5百萬美金左右。
Google也計畫將這兩項產品的支援轉由其他廠商來提供。在WindowBuilder支援部分預
計將由Genuitec提供，而CodePro Profiler將由OnPositive公司提供。從這些服務合
約獲得的營收將可用來支付部分人員的薪水。”

包含下面三項工具
1. WindowBuilder Pro
Develop Java graphical user interfaces in minutes for Swing, SWT, RCP, XWT and GWT with WindowBuilder Pro’s WYSIWYG, drag-and-drop interface. Use wizards, editors and intelligent layout assist to automatically generate clean Java code, with the visual design and source always in sync.
強大的GUI開發工具，可以讓Java開發者以所見即所得的介面，使用Swing, SWT, RCP, XWT, Google Web Toolkit（GWT）快速地建構用戶界面。
2. WindowTester Pro
Streamline testing of Java rich client applications with WindowTester Pro, including tools for automated recording, test generation, code coverage and playback of GUI interactions that can occur within an application. WindowTester Pro includes support for SWT and Swing.
在Java Rich Client應用中，針對SWT和SwingUI框架，測試GUI互動的工具，包含錄製 工具，測試產生器等。3. CodePro AnalytiX (CodePro Profiler)
Employ the comprehensive automated software code quality and security analysis toolkit CodePro AnalytiX to automatically improve software quality, reliability, and maintainability in developer applications. 綜合性 的自動化軟體程式品質和安全分析工具，以改善軟體品質、可靠性和可維護性。
下載點 http://code.google.com/javadevtools/download.html (這些是Eclipse plug-ins)

什麼叫"Content Aware" (內容感知)?

 

Fred F.M. Wang 原作日期 : 2011/3/15

IBM 持續強化content-aware等技術在Portal, WCM產品上…

什麼是"Content-aware"?
網路上有三種類型的技術都稱為是Content Aware (內容感知) :
1. Photoshop CS5 的「Content aware fill」功能，2. .IBM 儲存解決方案重複資料刪除(deduplication)技術，3. Princeton搜尋技術 Content-aware Searching

說明 :
1. Photoshop CS5 的「Content aware fill」功能，就是 CS5 會自動從畫面的各處，尋找合適的區塊、材質來填滿你選擇的部份。如下面圖片移掉佔左上角 1/9 的樹？沒問題，會自動用接近的材質，如天空填滿該區塊。

2.IBM 儲存解決方案中，因應資料大量成長所衍生的重複資料刪除(deduplication)技術，三種方法Hash based deduplication, Content Aware, HyperFactor，其中Content Aware就是假設需要進行重複資料刪除的文件是那些具有相同屬性（例如，相同名稱與檔案大小等）的對象。

3. Princeton搜尋技術 Content-aware Searching
http://www.cs.princeton.edu/cass/ 主要用於rich text or non-text資料型態的搜尋，分類與管理

IT組織規劃-不同組織工作劃分的優缺點與改善方法

Fred F.M. Wang 原作日期 : 2008/10/3

當企業IT須要服務許多單位開發不同的應用系統，又需使用多種平台與技術的情況，可能有哪些組織工作劃分的方式，優缺點與改善的方法?

1. 客戶導向式組織工作劃分

• 優點

– 有利深入客戶領域知識, 提供整體解決方案

– 可以提供客戶更專業的顧問服務

• 缺點

– 多項技術使用時學習曲線較長

– 同仁不容易專注於單一技術的深入

改善方式

• 強化技術訓練與技術知識傳承

• 開發標準化以提高生產力

2. 技術別組織工作劃分

根據不同的開發技術進行組織劃分，如Java, ABAP, VB...。

優點

– 同仁可以專精並深入於單一技術, 降低錯誤率, 程式生產力較佳

– 單一技術訓練與傳承容易

• 缺點

– 許多平台結合多種技術不易以技術劃分, 例如SAP R/3將可結合ABAP, Java開發

– 不利使用多項技術的應用, 例如 : B2B同時需有ABAP, Java; 網站同時有Java, HTML, Java script…

– 不利提供使用者整體性的解決方案, 例如 : 生產計畫則跨SAP , MES，Workflow，BI的Solution

– 技術應用無法平均劃分工作, 仍會有應用多技術的單位

改善方式

• 定期輪調以培養不同技術能力的同仁

• 強化組織間的溝通協調以提供使用者較佳的整體解決方案



4. 平台別組織工作劃分

根據不同的應用平台工作進行組織劃分，如ERP，Workflow，BI，B2B。
• 優點

– 熟悉平台使用與特性, 提供平台最佳的解決方案

– 單一平台訓練與知識分享傳承容易

• 缺點

– 不利提供使用者整體性的解決方案, 例如 : 生產計畫則跨SAP , MES，Workflow，BI的Solution

– 平台應用無法平均劃分工作, 仍會有應用多平台的單位

改善方式

強化組織間的溝通協調以提供使用者較佳的整體解決方案



5. 垂直分工式的工作劃分

根據專案管理，系統分析設計，開發(Coding)工作進行組織劃分。

• 優點

– 專業系統分析團隊深入客戶領域知識, 提供整體解決方案

– 可以提供客戶更專業的顧問服務

– 開發團隊專注於技術的提升，提高生產力。

– 可透過外包開發，提高開發人力資源的彈性。

• 缺點

- 增加不同團隊間溝通的時間，延長專案時間。

- 系統分析與設計人員離開技術太久可能，無法了解新技術的能力與可行性，設計出產生不洽當的設計。

改善方式

• 系統分析與設計規格標準化，並透過訓練，減少團隊間溝通的問題。

• 系統分析與設計人員需要對技術有所了解，可以由較資深的同仁擔任。

什麼是專業? 專家+敬業

Fred F.M. Wang  原作 2007/10/5

你喜歡喝咖啡，這叫興趣。


你通常比一般人更能輕鬆沖泡出美味的咖啡，這是專長。

你能夠對咖啡的色、味、形、溫、分辨咖啡出品種、產地，並對咖啡生成到製程的原理通透融會，自成一套學理，這是專家。

敬業呢？就是敬重業態、看重自己、 尊重別人。

專業呢？就是專家＋敬業=專業 (專家指能力,敬業指態度)

你是專業人士嗎?

下面是台積DNA與大前研一的闡述 :

"嚴謹務實、追求精確、承諾後必定全力以赴的工作態度 " -- 台積DNA：年輕工作者的40堂修練課

"能控制感情，以理性行動； 擁有比以往更高超的專業知識、技能和道德觀念；秉持顧客第一的信念；好奇心和向上心永不匱乏，加上嚴格的紀律，這樣的人才可稱為專業。" -- 專業：你的唯一生存之道 - 大前研一