部落格精選－Mac的愛恨情仇之群雄四起

豬言豬語

Mac的愛恨情仇之群雄四起

事情變的愈來愈有趣了，自從去年中Jobs宣佈採用Intel CPU開始，江湖上一場腥風血雨戰爭就此展開。原本Mac跟Windows的戰爭自古以來就一直存在著，但因為這次的硬體平台轉換，讓整個戰爭進入了白熱化的階段，各方好手紛紛加入這場大混仗，我們來看看到底是怎麼個混亂法~~

參與這場戰爭的我粗分為四種人：
1. 堅持原汁原味的Mac基本教義派
2. 想把Mac OS X安裝在光華牌PC的靈魂派
3. 想在Mac Intel上灌Windows的肉體派
4. 比爾萬歲之Windows基本教義派

鋒芒乍現 ～ 瘋 IT

談 Data Warehousing下的 Table Merge (一）～資料庫系統在資料倉儲環境下所會面臨的問題

對於小資料表而言，或許如果一次的 Full Table Scan 是一秒鐘，那兩次也才兩秒而已。但對於大型的資料表而言，如果一次的 Full Table Scan 是十分鐘，那兩次則是以二十分鐘來估算了，當然這更不用說那些巨型的資料表了。因此，在資料倉儲的環境中，一個 SQL 語法所會造成的 Full Table Scan 次數會是系統效能的重要議題……

談 Data Warehousing下的 Table Merge (二）～TABLE MERGE–Oracle 所提出來的解決方案

MERGE是ORACLE資料庫在版本9i以後所提出來的SQL語法，讓使用者可以用利用該語法，在一次執行中，同時對資料庫進行修改用（Update）與新增（Insert），一方面，可以方便資料庫管理師（或程式設計師）在PL/SQL的撰寫（過去，如果要達到相同的果效，即要利用cursor宣告與控制），另一面就系統效能的考量而言，這樣的做法，減少Full Table Scan的次數……

談 Data Warehousing下的 Table Merge (三）～ MERGE 語法在資料庫版本10g上的New Feature


.Net Go2 OO

搞懂耦合力與內聚力，紮穩物件導向設計的馬步

在物件導向的設計的實務上，最困難的工作之一就是「如何決定物件的責任以及物件之間的關係」。

我們可以由兩個不同的觀點來解釋這句話：從抽象的觀點來看，物件的責任分配應該易於理解與合理，不讓人困惑，並且讓物件之間的運作盡量不會互相干擾；從實做的觀點來看，讓物件之間相依性降到最低，不會因為特定物件的變更而引起了整個架構的漣漪，確保設計擴充上的彈性。

系統設計的起點：如何將需求轉為物件導向的設計

初學物件導向程式設計的人員，不必過於將真實世界的所有事情都要以OO的觀點來看待他，因為此時你所學習到的只是如何去實踐OO系統開發的工具而已，你可能會一直停留在物件導向的reuse或extend等執著當中，所以你會遇到為什麼使用OO會這麼的礙手礙腳的問題，此時別灰心，因為只是你缺少了一些思考的觀點、原則及方法等經驗吧！

Kenming's 軟體設計思維

淺論架構的 POC (Proof of Concepts)

POC, Proof of Concepts, 從字面的意義來解釋的話，即為 "概念性的驗證"。

既然是需要驗證(Proof)，所以 POC 是一種 "解決方案(Solution)"，是針對 "概念" 所提出的解決方案，而架構的 POC，目的即在於擷取出最精要、核心的解決方案(Solution)，以作為解釋架構的概念依據。

我與 Ringle 聊到 POC，他原來對 POC 的認知是對客戶所提出的一種解決方案，所以主要滿足對象是 "客戶"。不過，對於架構的 POC，我不太認同對象是客戶，我會以為，會希望能透過某種概念性的解決方案，而對架構有整體、全貌性的認知者，那才會是架構 POC 的對象。

所以，誰負責撰寫架構 POC？ 我認為是 "架構師(Architect)"，誰想瞭解及驗證架構 POC？我以為是開發團隊所有成員與利益關係人(Stakeholder)。

架構 POC 的對象釐清後，再來是瞭解其呈現的具體樣貌是什麼樣子呢？底下是架構 POC 具化的幾個可能樣貌。