freesky

     摘要: Make utilities such as GNU make, System V make, and Berkeley make, are fundamental tools for streamlining the application build process, but each one is just a little different from the others. Learn the structure of the makefile and how to avoid common mistakes in its creation, discover how to fix or work around portability issues, and pick up hints for solving other problems as they crop up.  閱讀全文

     摘要: 什么是makefile？或許很多Winodws的程序員都不知道這個東西，因為那些Windows的IDE都為你做了這個工作，但我覺得要作一個好的和professional的程序員，makefile還是要懂。這就好像現在有這么多的HTML的編輯器，但如果你想成為一個專業人士，你還是要了解HTML的標識的含義。特別在Unix下的軟件編譯，你就不能不自己寫makefile了，會不會寫makefile，從一個側面說明了一個人是否具備完成大型工程的能力。

因為，makefile關系到了整個工程的編譯規則。一個工程中的源文件不計數，其按類型、功能、模塊分別放在若干個目錄中，makefile定義了一系列的規則來指定，哪些文件需要先編譯，哪些文件需要后編譯，哪些文件需要重新編譯，甚至于進行更復雜的功能操作，因為makefile就像一個Shell腳本一樣，其中也可以執行操作系統的命令。

makefile帶來的好處就是——“自動化編譯”，一旦寫好，只需要一個make命令，整個工程完全自動編譯，極大的提高了軟件開發的效率。make是一個命令工具，是一個解釋makefil  閱讀全文

     摘要: GOF給模板方法（Template Method）模式定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。這里的算 法的結構，可以理解為你根據需求設計出來的業務流程。特定的步驟就是指那些可能在內容上存在變數的環節。  閱讀全文

     摘要: 策略模式（Strategy Pattern）中體現了兩個非常基本的面向對象設計的基本原則：封裝變化的概念；編程中使用接口，而不是對接口實現。策略模式的定義如下：

定義一組算法，將每個算法都封裝起來，并且使它們之間可以互換。策略模式使這些算法在客戶端調用它們的時候能夠互不影響地變化。

策略模式使開發人員能夠開發出由許多可替換的部分組成的軟件，并且各個部分之間是弱連接的關系。弱連接的特性使軟件具有更強的可擴展性，易于維護；更重要的是，它大大提高了軟件的可重用性。
  閱讀全文

     摘要: "其實中國程序員，現在最需要的是一張安靜的書桌。"，的確，中國架構師大多缺乏系統的基礎知識，與其自欺欺人的宣揚"讀書無用，重在實踐變通，修身立命哲學書更重要"，把大好時間用來追逐互聯網上的片言只語，不如直面缺陷，系統的學習一次。  閱讀全文

     摘要: 知道了成為一個成功的 IT 架構師需要投入多少工作后，我們就想知道哪些因素對成為一個不錯的架構師起決定性作用。因此，我們向專家組提出了這樣的問題：“什么技能對 IT 架構師最有價值，架構師如何學習這些技能？”

可以在很多地方找到成為好的架構師所需的技能列表——書上、培訓課程、大學、有關體系結構的其他網站上等等。例如，IBM 的內部專業提高網站就提出以下幾點 IT 架構師的理想特征：

設計體系結構的技能和經驗
有序的以方法為驅動源的任務執行
完整生命周期經驗
行業部門經驗
領導能力
很強的溝通和專業技能

和可能看到的很多其他列表類似，這個列表相當泛泛，可能并不如您所期望的那樣有可操作性。而這正是我們詢問前面的問題的原因所在：幫助您確定一個明確的方向。

  閱讀全文

     摘要: 作為 IT 架構師，您可能經常會發現自己處于進退維谷的境地，前有您的業務目標，后有您的 IT 系統。這兩方面都具有規模大、不易改變和靈活性差的特點。制定業務目標的人員和開發系統的人員不一定了解彼此的工作內容和成果。似乎是這樣，業務人員使用一種語言來表達他們希望實現的業務目標，而開發人員則使用另一種語言來表述技術要求。

而這就是我們為了實現高效率而需要著手處理的問題：理解這兩種語言并執行必要的轉換，以便 IT 能反映業務的需求，并能在適當的時候對業務目標進行更改，使其與 IT 的能力相適應。這并不是一個容易完成的工作，但這正是您能夠獲得很大利益的原因。

由于這部分工作可能會非常困難而棘手，因此，我們向 IBM 體系結構專家隊伍尋求指導。本月我們邀請這些專家分享他們用來將業務需求表述為明晰簡潔的技術要求的方法，以便 IT 團隊能成功地實現。

  閱讀全文

     摘要: 面向服務的體系結構 (SOA) 已成為了一項事實標準，用于開發基于組件的應用程序，可使用標準接口通過網絡（Internet 或其他網絡）訪問這些應用程序。至少 IBM 高級管理人員和很多其他供應商、分析師、顧問和軟件開發人員都這么說。他們還將告訴您，整個行業都在逐步采用 SOA，如果您尚未開始 SOA 開發，將很快跟不上時代的步伐了。

贊譽之詞。但這些看法是否真的很有吸引力，能讓您開始著手您自己的 SOA 嗎？讓我們來看看一位參加 Open Group 主辦的 SOA 大會的架構師的問題。在 IBM Global Services 副總裁 Michael Liebow 的主題發言后的提問期間，這位架構師問道：“SOA 是不是我們需要知道的唯一體系結構？（順便提一下，Liebow 先生的回答是“是的”）在稍后，另一位架構師大聲問道：“SOA 和我們多年前就知道的組件體系結構很相似。如果我們采用了它，是否意味著我們又多添了一個技術豎井（另一個開發死胡同），從而需要進行更多的集成？”（而這次，會議參加者——包括平臺供應商、企業 IT 架構師、顧問、系統集成商和其他人員——回  閱讀全文