分类: News

IT資訊新聞

  • 微軟Windows Server 2003認證介紹

    Windows Server 2003作為微軟有史以來最強大的操作系統平台,已於2003年5月23日在中國正式發布。
    Windows Server 2003是一個全面的、完整的、可靠的服務器操作系統,他減少了成本,提高了計算操作的效率,幫助IT人員做到事半功倍。
    Windows Server 2003相關課程,將對學員在Windows Server 2003環境下系統管理和維護的技術熟練程度及專業水平進行有效的、可靠的測試。同時這些考試認證也將對解決方案設計和實現方面的技術精通程度和專長進行有效和可靠的衡量。
     
    一、適用對象
    凡具有Windows和一定英語水平的在職人員﹑各大專院校在校學生及要求獲得網絡技術知識的人員均可報名參加微軟認證類在線培訓。學習本專業者需有一定計算機基礎和英文基礎,計算機方面應有Dos和Windows基礎,要求會編制批處理文件,對系統配置文件的部分參數有一定的了解。在英文方面應能讀懂基本的計算機方面的專業詞彙或相當於高中畢業的英文水平。

    二、認證體系

    MCSAMCSE作為微軟的兩項高端IT資格認證,微軟公司已出台其針對於Windows Server 2003的認證體系,並在國內已能申請參加所有相應科目的考試。
    1、MCSA 2003——MCSA2003微軟認證系統管理員證書證明您有能力勝任網絡及系統管理員職位,獲得業界承認的對微軟部分產品的技術的精通和所需的專業技能。
    2、MCSA:Security on Windows Server 2003——該認證著重考察學員在管理和維護一個安全的企業網絡方面的技術和能力。
    3、MCSA:Messaging on Windows Server 2003——該認證表明獲得者能夠實現,管理和維護一個基於Exchange Server的消息基礎結構平台。要求認證的參加者需要至少一年的Exchange和Windows 2003的運行環境的管理經驗。需要通過4門考試。包括3門核心考試和1門選修考試。
    4、MCSE 2003——MCSE 2003微軟認證系統工程師證書是行業中承認範圍最廣的一項高級技術證書。獲得MCSE證書,證明自己具備使用高級的Microsoft Windows平台和Microsoft服務器產品,為企業提供成功的設計、實施和管理商業解決方案的能力。
    5、MCSE: Security on Windows Server 2003——該認證著重考察學員在管理和維護一個安全的企業網絡方面的技術和能力。
    6、MCSE: Messaging on Windows Server 2003——該認證表明獲得者能夠完成設計,規劃和實現一個基於Microsoft Exchange Server的消息基礎平台結構。要求參加該認證的系統工程師至少擁有一年以上的部署Exchange Server和Windows 2003系統環境的部署經驗。需要通過6門核心考試和2門消息平台方面特定考試。

    三、認證途徑

    在學習或考試時,你可以選擇先學習MCSA 2003的課程,然後再繼續學習剩下的MCSE 2003的課程,循序漸進!

    四、業界評論

    一位業內人士說,微軟認證在國外IT認證中知名度是最高的,參加考試和通過認證的人數也是最多的,因為在計算機操作系統中微軟所佔的市場份額是最大的,所以,通過微軟認證相對而言更具有普遍意義。中國科學院軟件研究所博士生導師仲萃豪研究員說,一些跨國企業、外資企業對它的員工要求比較高,特別是從事IT行業的工作,微軟證書幾乎成了應聘的通行證,沒有它的證書就做不好它的產品。所以要想從事微軟公司的工作,必須獲得微軟的證書。
    六、 MCSA 2003/MCSE 2003主要課程介紹
    70-290: 《管理Windows Server 2003環境》(MS2274)《維護Windows Server 2003環境》(MS2275)
    1.管理用戶和計算機帳號、組、資源的訪問
    2.實現打印,管理打印和組織單元中的對象訪問
    3.實現組策略使用組策略管理用戶環境
    4.介紹Windows2003中的安全性
    5.管理服務器與監視服務器性能
    6.維護設備驅動,管理磁盤、數據存儲、容錯
    7.使用軟件更新服務維護軟件
    70-291:《建置Windows Server 2003網絡基礎架構:網絡主機》(MS2276) 《建置、管理與維護Windows Server 2003網絡基礎架構:網絡服務》(MS2277)

    1.在多個子網中分配IP地址
    2.配置客戶端IP地址及客戶端配置名稱解析
    3.Isolating Common Connectivity Issues
    4.使用RRAS配置路由
    5.使用DHCP分配IP地址管理和監視DHCP
    6.名稱解析使用DNS解析主機名
    7.管理和監視DNS
    8.使用WINS解析NetBIOS名稱
    9.使用IPSec和證書增加網絡通信的安全性
    10.配置網絡訪問管理和監視遠程訪問

    70-293:《規劃與維護Windows Server 2003網絡基礎架構》(MS2278)

    1.規劃TCP/IP物理和邏輯網絡與路由和交換的規劃和排錯
    2.Planning,Optimizing,and Troubleshooting DHCP
    3.DNS的規劃策略、優化和排錯
    4.Planning and Optimizing WINS
    5.IPSec的規劃和排錯,規劃遠程訪問,網絡訪問排錯
    6.規劃Windows2003的網絡架構

    70-294:《規劃、建置與維護Windows Server 2003Active Directory基礎架構》(MS2279)
    1.介紹AD的架構實現AD森林和域的架構
    2.實現組織單元架構實現用戶,組和計算機帳號實現組策略
    3.使用組策略分發和管理軟件實現Sites管理AD複製
    4.佈置域控制器管理操作主控
    5.維護AD可用性規劃和實現AD架構

    70-298:《規劃與設計安全的網絡環境》(MS2830)
    1.網絡安全分析
    2.設計物理資源訪問的安全
    3.規劃主機安全、規劃帳號安全、規劃驗證安全
    4.規劃數據安全、規劃數據傳輸安全、規劃用戶策略
    5.設計管理網絡的策略

    70-227:《部署與管理Microsoft Internet Security and Acceleration Server 2000》(MS2159)
    70-270:《建置與支援Windows XP Professional》(MS2272)

    五、 MCSA 2003/MCSE 2003培訓目標

    網絡管理員
    網絡工程師
    系統管理員
    信息技術專業人員
    信息系統管理員
    網絡操作分析員
    網絡技術員
    技術支持專業人員
    系統工程師
    技術支持工程師
    系統分析師
    網絡分析師
    技術諮詢人員

  • 好用的 MS SQL 2005 字串加密應用 ( MD5 & SHA1 )

    部門最近決議,要將早期舊系統中使用者密碼的部分轉為加密字串,當然隨之而來的技術討論會議就開始了。
    有人質疑為什麼密碼一定要加密呢??這個問題牽扯到資訊安全的環節了。請想想以下情況:

     

     

     

     

    • 駭客入侵資料庫竊取資料
    • 公司內部有心人士將資料庫內容偷偷竊取
    • 網管人員偷偷使用主管級的帳密登入系統

    當一個公開的系統帳密完全外洩時,輕則系統下架不使用;重則公司或部門將面臨結束營業的情形 (TigerLin 朋友的公司曾經發生過,想當然爾…結束營業)。這就是一直強調密碼要編碼過的原因所在了。

    在找了 MSDN 相關文件之後發現…其實 SQL 2005 就有內建的函式可直接應用了,而且很方便的呢。不過…中間也是發生了一點插曲,折騰了一下才試出來 ^~^a …

    MS SQL 2005 字串加密函式 — HashBytes

    HashBytes提供的加密法有幾種 (MD2、MD4、MD5、SHA、SHA1 ),但最常使用的還是 MD5 與 SHA1。而整個使用過程的感覺來說,基本上還算簡單~只是有一些”眉角”要注意。首先先測試 HashBytes 運作是否合乎需求: 

     
    1 select hashbytes(‘MD5’,‘12345’as MD5,hashbytes(‘SHA1’,‘12345’as SHA1; 
       


      

     產生以下的結果

    MD5 SHA1
    0x827CCB0EEA8A706C4C34A16891F84E7B 0x8CB2237D0679CA88DB6464EAC60DA96345513964

    針對 HashBytes 的應用測試過程

    接下來開一個測試用的 Table 來試試轉換的結果如何:

     

     
    1 CREATE TABLE [dbo].[HashTest](  
    2 [INDEX_NO] [int] IDENTITY(1,1) NOT NULL,  
    3 [PassWD] [varchar](50) COLLATE Chinese_Taiwan_Stroke_CI_AS NOT NULL,  
    4 [HashedPW] [varchar](50) COLLATE Chinese_Taiwan_Stroke_CI_AS NULL,  
    5 CONSTRAINT [PK_HashTest] PRIMARY KEY CLUSTERED  
    6 (  
    7 [INDEX_NO] ASC 
    8 )WITH (IGNORE_DUP_KEY = OFFON [PRIMARY]  
    9 ON [PRIMARY]  
    10 GO 
       

     

    在 PassWD 欄位中輸入一些字串, HashedPW 保持空白,等等要看加密的結果是否正確

    INDEX_NO PassWD HashedPW
    1 test  
    2 test2  
    3 test3  

     然後將以 SHA1 加密過的字串更新到 HashedPW 看看 —

     
    1 update hashtest set hashedPW = HashBytes(‘SHA1’, PassWD) 
       

     咦??怎麼都變成亂碼了啊 O_o…這樣子根本不能用啊…再看了 MSDN 之後發現該函數的回傳值型態為 varbinary,並不是字串形態,所以要再使用 sys.fn_VarBinToHexStr() 進行轉換的動作 — 
      

    INDEX_NO PassWD HashedPW
    1 test 咐戔 L s???閨
    2 test2
    3 test3 >縛 鄀 o Y

     

     
    1 update hashtest set hashedPW = sys.fn_VarBinToHexStr(HashBytes(‘SHA1’, PassWD)); 
       

     

    輸出的結果就正確了 🙂

    INDEX_NO PassWD HashedPW
    1 test 0xa94a8fe5ccb19ba61c4c0873d391e987982fbbd3
    2 test2 0x109f4b3c50d7b0df729d299bc6f8e9ef9066971f
    3 test3 0x3ebfa301dc59196f18593c45e519287a23297589

     

    最後…改一下登入機制的驗證方式,修改比對的欄位後…原本明碼的密碼就可以隨風而逝了,需求達成~

  • SQL Server 2005 檢視表的不思議現象

     春天到了~俗話說「春天後母臉 — 說變就變」,那系統可以說是女人心 — 永遠都有可愛又難以捉模的時刻~ 咳咳咳…扯遠了…回到正題 ^^”。由於最近公司的 DB Server 進行升級,系統也將原本的 SQL 2000 升級至 2005,步驟在一般不過了:
    安裝 => 設定 => 升級 SP2 => 完成把原本的 MDF 掛載上去後,修改連線密碼,一切正常!!上線~隔天不思議的情形就發生了…網頁上顯示的資料居然都是最舊的!! What’s up !?!?

    將頁面上使用的 view 表以 SSMS 開啟,發現排序的指令沒有生效
    程式內使用的 SQL String 為 “Select * from vwTest”
    而 vwTest 內則有下 order by [dtDate] 的語法,恩恩~怎麼看都沒錯啊~
    切到檢視表設計下看…排序以及資料都是正常的!!好…看來是檢視表內的 order 語法無法在讀取檢視表 vwTest 的第一時間生效了…馬上進行 Troble Shooting!!

    在 Google 了一下之後,首先看到了微軟的 KB,裡面說到其症頭為 —

    The SELECT statement uses the TOP (100) PERCENT expression.
    ==> vwTest裡面的確有用到 TOP (100) PERCENT 的選取方式


    The SELECT statement uses the ORDER BY clause.
    ==> 也有使用 order 排序

    解決方式 —
    936305 Cumulative update package 2 for SQL Server 2005 Service Pack 2 is available

    安裝時明明有升級到 SQL 2005 SP2 … 現象卻依然持續的發生,只好繼續找了 T_T
    最後在國外的 SQL SERVER 為主題的 BLOG 中找到了一篇文章說明了因應的對策

    • 在Select語法的部分,將原本的 Select TOP (100) PERCENT 改為 Select TOP 2147483647
    • 有找到另外一種解法,將 Select 語法改為 Select TOP (99.999999999999)也是可行的,注意~小數點後面是 12 個 9 唷!

    我採用的方法是 12 個 9 的方法,將 vwTest 的語法修改之後並儲存,在開啟的同時…一切又回到美好的正常狀態了!這裡也有一個看起來頗奇怪的地方呢,不知道各位有沒有注意到,既然都選取 TOP 100 PERCENT 了,不就是選取全部了嗎?為什麼還要特別加上以百分比選取的語法呢?後來跟程式設計師討論了一下,可能是早期的程式產生器所產生的 VIEW 特有的現象,由於程式已經是 N 年前寫的,現在已經不可考了。但為了安全…輕易的把 TOP 100 PERCENT 拿掉又怕會有更不可思議的意外,因此暫且先用 14個 9 的選取方式代替。

    小插曲 — 針對 SQL 2005 SP2 的重大更新
    這一個更新是在找資料中看到的,標題很有趣的寫著 “A Service Pack for a Service Pack
    這個 hotfix 修正的可是一個大問題呢…”清除工作未在排定的時間間隔執行
    什麼 O_o…排定的工作不會執行,這可是大事,當然馬上把它下載到 SERVER 進行安裝
    有先發現總比到後面問題發生在處理好多了,這雖然是一個小插曲,卻是一個很大的意外收穫呢 ^^b

    參考資料:
    http://support.microsoft.com/kb/926292/en-us
    http://support.microsoft.com/kb/933508
    http://support.microsoft.com/kb/933508
    http://www.themssforum.com/SQLServer/Order-views/
    http://sqlblog.com/blogs/tibor_karaszi/archive/2007/11/28/sorted-views.aspx
    http://www.sqlmag.com/Article/ArticleID/95449/sql_server_95449.html

     

    來源:www.51-pass.com

  • IT & Program 那一方有優勢?

    某一天上班的時間,我正在規劃新的網路架構與DNS安全性的議題報告時,突然有一種很深的感慨…
    在近十年的工作資歷當中,IT相關的部份一直佔得很重,當然台灣企業來說不太像國外一樣分的那麼清楚,所以當IT的同時也兼著開發ERP系統,可以說是「IT為主 程式為輔」的界定吧^^b!之前在鈊象電子任職軟體設計師的時候,就一直覺得很吃力,雖然說寫程式是我的興趣,也算是專長之一,但跟極專業的軟體設計師比我當然還是差多了。有鑑於此在感觸的當下我把 MSN 的暱稱改為「當 IT 比當程式設計師有成就感多了!」~
    後來 Maduka 敲我的 MSN 時看到我的暱稱,只發出了一陣陰險的笑聲(XD),莫約十秒後他的暱稱變成「當程式設計師 比當 IT 有成就感多了!」。好吧~我被嗆了~哇哈~由於當下我沒想太多,看了笑一下之後我就繼續我的工作了。
    下班騎機車回來途中,腦袋一直運轉著下午的話題,分析到底是 IT 好還是 Program 好,後來發現…
    現在是網際網路發達的年代,如果今天程式寫的再好,那沒有好的 IT 架構也沒有用啊!舉個例子:
    ================================================
     今天公司有發送大量電子報的需求,RD部門已經將程式的效能、執行續、網路 I/O 相關的部份寫的非常好了!測試 1000 封發送速度極快,已經可以上線了!但正式運作時則經常發生以下情形 —
    01.退信率高
    02.發信時部門網路幾乎癱瘓
    03.發送到某個數量時 SMTP Server 主機會產生死當
    04.超過 10000 封以後寄信速度會只剩下 1 / 6
     
    從以上的情形看來是程式設計的問題嗎?為什麼在測試的時候很ok,一上線就變成這個樣子呢?
    會以電子報作為例子是因為這是個很典型的 程式 + IT 一起運作的例子 (我在某機公司就遇到這樣的情況),問題其實是出在 —
    01.DNS 無 MX 紀錄或是反解不正確
    02.網路架構層級太深,電子報的 Server 位於網路底層,但 SMTP Server 在網路的上層
    03.沒有調整 SMTP 工作階段的數量,大量發送的情況下 MTA 程式更是一個關鍵點
     
    讓我們來針對每一個問題作處理 (以下為 IT 部門的負責範圍) —

    1. DNS 的 MX 紀錄設定好,PTR紀錄設反解,如果要成功機率更高則加入 SPF Record 與 CallerID Record
    2. 可將 SMTP 放置到 DMZ 中,減少封包經由 NAT 轉換的損失,並將電子報主機移至跟 SMTP Server 同一個 Switch ( 視情況是否加入 DMZ)
    3. MTA來說,可以使用 Linux Base 的 Postfix,並參閱官方的設定說明 (建議發送 eDM 不要使用 IIS 的 SMTP)。

    ================================================
     
    由以上的例子可以看得出來,程式寫的好但是 IT 架構設計不良,程式的好無法顯現出來
    IT 架構設計優良,但是沒有好的程式來執行測試,那其價值也無法發揮
     
    最後,我的 MSN 參照「食神」中的撒尿牛丸改成「IT 與 Program 有什麼好爭的!混在一起搞個 ERP 不就得了!
    最後我的朋友也很欣然同意了我的說法了 ^^
     
    現在是團隊合作的時候,單兵作戰的時代已經過去了,唯有多方面的配合才能讓企業更加快速的成長
    願我的朋友們每一位都可以擔任團隊中的關鍵角色,你們一定可以的!GO~
  • 新時代新觀念 — DNS 與 Mail是密不可分的 (含Caller ID與SPF說明)

     由於現在的頻寬日益提昇,Mail Server軟體安裝的過程也可以說是點滑鼠即可完成
    很多朋友近期一直問我:「我家裏已經是光纖了!又是固定IP,那我申請一個Domain就可以架設Mail Server了吧~應該跟Web Server一樣簡單」
    其實…這樣的觀念是錯誤的!Web Server本身只需要A紀錄或是CNAME別名解析,指向到對的IP就可以了

    但Mail Server之間的交談要比Web的複雜,小弟在這裡列出幾項Mail Server必備的紀錄型態:
    MX紀錄:郵件交換紀錄,在2000以前SAPM不會太多的年代,如果沒有MX紀錄的話Server會去尋找A紀錄作查詢;但在2000年以後SPAM大量散發的年代,Mail Server沒有MX紀錄的話大多都是會被Block掉。
     
    SPF紀錄:全名為Sender Policy Framework,這算是一個比較新潮的紀錄型態,2003年SPAM最氾濫的年代由openspf組織制定,加入SPF紀錄的Mail Server可以降低被當成SAPM的風險。如要查詢或是產生SPF紀錄可以到 http://old.openspf.org/wizard.html?mydomain=microsoft.com 或是 微軟的CallerID小工具 會有精靈模式的工具幫助產生。
     
    CallerID紀錄:微軟推行的anti-spam的紀錄型態,原生格式為 XML,以microsoft.com為例
    ====================== 紀錄開始 ======================
    <ep testing=”true” xmlns=”http://ms.net/1“>
        <out>
            <m>
                <mx />
                <a>213.199.128.160</a>
                <a>213.199.128.145</a>
                <a>207.46.71.29</a>
                <a>194.121.59.20</a>
                <a>157.60.216.10</a>
                <a>131.107.3.116</a>
                <a>131.107.3.117</a>
                <a>131.107.3.100</a>
            </m>
        </out>
    </ep>
    ====================== 紀錄結束 ======================
    是不是感覺像在寫程式呢?其實這就是微軟所推行的CallerID紀錄的格式,不要懷疑~
    要產生相當簡單,可以到 微軟的CallerID小工具 ,除了可以產生SPF以外也可以產生CallerID紀錄。
     
     
    以上三個是針對Mail Server (無論是Exchange、Postfix等,都通用)重要的DNS紀錄
    下一篇文章將會寫出如何加入諸如SPF與CallerID特殊紀錄的方式。

  • 計算主機虛擬化後節省的電費

    因為工作上的需要,必須將 Server 整理並將占用空間減少,便開始著手進行虛擬化工程。公司有 18 台 伺服器,其中 7 台都是屬於「骨董」的 PC 了,規格大約是介於 P-II 233 ~ P-III 800 之間,記憶體最大也不超過 256M 的「PC Server」。這些主機除了效能不彰、硬碟會嘎嘎叫以外,重點還是…很熱,尤其是幾台 K7 的更是火熱的很,冷氣開放也壓不過那 CPU 熱情散發的氣息啊 Orz…

    咳咳…虛擬化不是該文的重點所以不詳述,切入主題!花了一些時間將低階的主機虛擬化到高階主機裡面後,主管便提出「變更後報告書」的需求,What??又是報告啊~好吧~沒寫過虛擬化變更的報告,就當練習好了~首先虛擬化第一個直覺想到的優點就是「省電」,恩恩~好~看看節省了多少電費,馬上到台電的網站查詢電費的計算方式!~

    查到的公式在設計到 EXCEL 裡面,填入一些必需的數字,恩…每一台主機的電費就出來了,加加總總後,再加上冷卻成本 (BTU) 節省的費用,乗上 12 個月就是這一次虛擬化所節省的費用~就這樣~算出來的數字就可以當作一個指標了 ^^b

    零件的耗電要怎麼查詢??經過 Google 一番,找到一個好站:http://www.journeysystems.com/?power_supply_calculator
    使用很簡單,點選下方那個大大的「Start the Calculator」後即會跳出一個 POPUP 視窗
    TigerLin 以 SERVER 為範例,這裡點選「SERVERS」 的 Botton計算電費-選擇平台類型

     

    選擇相關的配備,並按下「Find My Wattage!」系統就會建議使用至少幾瓦的 POWER,但 TigerLin 還是最自己稍微加總一下以取得較準確的耗電量。這裡要強調,新的零件大多都沒有內建在裡面,但是其標示的耗電量還是可以當作參考用,至少寫報告交差有個依據,個人 PC 誤差不會超過 100 元就不要太計較了啦 ^~^a計算電費-選擇零件

     

    最後再將所得的數字填入 EXCEL 中紅色欄位的地方,並參照裡面的用電度數範圍填入每度單價,即可大略算出每台主機的電費,報告有數字後也可安心交出去了 ^^b

    image

     

    因為 TigerLin 對 EXCEL 不是很熟…所以介面醜醜的也不太人性化…但至少還可以計算啦 XD
    按這裏從 SkyDrive 下載「計算電費小工具」

  • 初學者,你應當如何學習C++以及編程

    Javascript是世界上最受誤解的語言,其實C++何嘗不是。坊間流傳的錯誤的C++學習方法一抓就是一大把。我自己在學習C++的過程中也走了許多彎路,浪費了不少時間。

    為什麼會存在這麼多錯誤認識?原因主要有三個,一是C++語言的細節太多。二是一些著名的C++書籍總在(不管有意還是無意)暗示語言細節的重要性和有趣。三是現代C++庫的開發哲學必須用到一些犄角旮旯的語言細節(但注意,是庫設計,不是日常編程)。這些共同塑造了C++社群的整體心態和哲學。

    單是第一條還未必能夠成氣候,其它語言的細節也不少(儘管比起C++起來還是小巫見大巫),就拿javascript來說,作用域規則,名字查找,closure,for/in,這些都是細節,而且其中還有違反直覺的。但許多動態語言的程序員的理念我猜大約是學到哪用到哪罷。但C++就不一樣了,學C++之人有一種類似於被暗示的潛在心態,就是一定要先把語言核心基本上吃透了才能下手寫出漂亮的程序。這首先就錯了。

    這個意識形成的原因在第二點,C++書籍。市面上的C++書籍不計其數,但有一個共同的缺點,就是講語言細節的書太多——《C++ gotchas》,《Effective C++》,《More Effective C++》,但無可厚非的是,C++是這樣一門語言:要拿它滿足現代編程理念的需求,尤其是C++庫開發的需求,還必須得關注語言細節,乃至於在C++中利用語言細節已經成了一門學問。比如C++模板在設計之初根本沒有想到模板元編程這回事,更沒想到C++模板系統是圖靈完備的,這也就導致了《Modern C++ Design》和《C++ Template Metaprogramming》的驚世駭俗。
    這些技術的出現為什麼驚世駭俗,打個比方,就好比是一塊大家都認為已經熟悉無比,再無秘密可言的土地上,突然某天有人挖到原來地下還蘊藏著最豐富的石油。在這之前的C++雖然也有一些細節,但也還算容易掌握,那可是C++程序員們的happy old times,因為C++的一切都一覽無餘,everything is figured out。然而《Modern C++ Design》的出世告訴人們,“瞧,還有多少細節你們沒有掌握啊。”於是C++程序員們久違的激情被重燃起來,奮不顧身的踏入細節的沼澤中。尤其是,模板編程將C++的細節進一步挖掘到了極致——我們幹嘛關心涉及類對象的隱式轉換的優先級高低?看看boost::is_base_of就可以知道有多詭異了。
    但最大的問題還在於,對於這些細節的關注還真有它合適的理由:我們要開發現代模板庫,要開發active library,就必須動用模板編程技術,要動用模板編程技術,就必須利用語言的犄角旮旯,enable_if,type_traits,甚至連早就古井無波的C宏也在亂世中重生,看看

    boost::preprocessor有多詭異就知道了,連C宏的圖靈完備性(預編譯期的)都被挖掘出來了。為什麼要做這些?好玩?標榜?都不是,開發庫的實際需求。但這也正是最大的悲哀了。在boost裡面因實際需求而動用語言細節最終居然能神奇的完成任務的最好教材就是
    boost::foreach,這個小設施對語言細節的發掘達到了驚天地泣鬼神的地步,不信你先試著自己去看看它的源代碼,再看看作者介紹它的文
    章吧。而boost::typeof也不甘其後——C++語言裡面有太多被“發現”而不是被“發明”的技術。難道最初無意設置這些語言規則的傢伙們都是oracles?

    因為沒有variadic templates,人們用宏加上缺省模板參數來實現類似效果。因為沒有concepts,人們用模板加上析構函數的細節來完成類似工作。因為沒有typeof,人們用模板元編程和宏加上無盡的細節來實現目標… C++開發者們的DIY精神不可謂不強。然而,如果僅僅是因為要開發優秀的庫,那麼涉及這些細節都還是情有可原的,至少在C++09出現並且編譯器廠商跟上之前,這些都還能說是不得已而為之。但我們廣大的C++程序員呢?大眾是容易被誤導的,我也曾經是。以為掌握了更多的語言細節就更牛,但實際卻是那些語言細節十有八九是平時編程用都用不到的。 C++中眾多的細節雖然在庫設計者手裡面有其用武之地,但普通程序員則根本無需過多關注,尤其是沒有實際動機的關注。一般性的編碼實踐準則,以及基本的編程能力和基本功,乃至基本的程序設計理論以及算法設計。才是真正需要花時間掌握的東西。學習最佳編碼實踐比學習C++更重要。看優秀的代碼也比埋頭用差勁的編碼方式寫垃圾代碼要有效。直接、清晰、了、KISS地表達意圖比玩編碼花招要重要…

    避免去過問任何語言細節,除非必要。這個必要是指在實際編程當中遇到問題,這樣就算需要過問細節,也是最省事的,懶惰者原則嘛。一個掌握了基本的編程理念並有較強學習能力的程序員在用一門陌生的語言編程時就算拿著那本語言的聖經從索引翻起也可以編出合格的程序來。十年學會編程不是指對每門語言都得十年,那一輩子才能學幾門語言哪,如果按字母順序學的話一輩子都別指望學到Ruby了;十年學習編程更不是指先把語言特性從粗到細全都吃透才敢下手編程,在實踐中提高才是最重要的。

    至於這種摳語言細節的哲學為何能在社群裡面呈野火燎原之勢,就是一個心理學的問題了。想像人們在論壇上討論問題時,一個對語言把握很細緻的人肯定能夠得到更多的佩服,而由於論壇上的問題大多是小問題,所以解決實際問題的真正能力並不能得到顯現,也就是說,知識型的人能夠得到更多佩服,後者便成為動力和仿效的砝碼。然而真正的編程能力是與語言細節沒關係的,熟練運用一門語言能夠幫你最佳表達你的意圖,但熟練運用一門語言絕不意味著要把它的邊邊角角全都記住。懂得一些常識,有了編程的基本直覺,遇到一些細節錯誤的時候再去查書,是最節省時間的辦法。

    C++的書,Bjarne的聖經《The C++ Programming Language》是高屋建瓴的。 《大規模C++程序設計》是挺務實的。 《Accelerated C++》是最佳入門的。 《C++ Templates》是僅作參考的。 《C++ Template Metaprogramming》是精力過剩者可以玩一玩的,普通程序員碰都別碰的。 《ISO.IEC C++ Standard 14882》不是拿來讀的。 Bjarne最近在做C++的教育,新書是絕對可以期待的。

    PS關於如何學習編程,g9的blog上有許多精彩的文章:這裡,這裡,這裡,這裡…實際上,我建議你去把g9老大的blog翻個底朝天:P

    再PS書單?我是遑於給出一個類似《C++初學者必讀》這種書單的。 C++的書不計其數,被公認的好書也不勝枚舉。只不過有些書容易給初學者造成一種錯覺,就是“學習C++就應該是這個樣子的”。比如有朋友提到的《高質量C/C++編程》,這本書有價值,但不適合初學者,初學者讀這樣的書容易一葉障目不見泰山。實際上,正確的態度是,細節是必要的。但細節是次要的。其實學習編程我覺得應該最先學習如何用偽碼表達思想呢,君不見《Introduction to Algorithm》裡面的代碼?《TAOCP》中的代碼?哦,對了它們是自己建立的語言,但這種僅教學目的的語言的目的就是為了避免讓寫程序的人一開始就忘了寫程序是為了完成功能,以為寫程序就是和語言細節作鬥爭了。 Bjarne說程序的正確性最重要,boost的編碼標準裡面也將正確性列在性能前面。此外,一旦建立了正確的學習編程的理念,其實什麼書(只要不是太垃圾的)都有些用處。都當成參考書,用的時候從目錄或索引翻,基本就對了。

    再再PS myan老大和g9老大都給出了許多精彩的見解。我不得不再加上一個P.S。具體我就不摘錄了,如果你讀到這裡,請務必往下看他們的評論。轉載者別忘了轉載他們的評論:-)許多朋友都問我同一個問題,到底要不要學習C++。其實這個問題問得很沒有意義。 “學C++”和“不學C++”這個二分法是沒意義的,為什麼?因為這個問題很表面,甚至很浮躁。重要的不是你掌握的語言,而是你掌握的能力,借用myan老大的話,“重要的是這個磨練過程,而不是結果,要的是你粗壯的腿,而不是你身上背的那袋鹽巴。 ”。此外學習C++的意義其實真的是醉翁之意不在酒,像C/C++這種系統級語言,在學習的過程中必須要涉及到一些底層知識,如內存管理、編譯連接系統、彙編語言、硬件體系結構等等等等知識(注意,這不包括過分犄角旮旯的語言枝節)。這些東西也就是所謂的內功了(其實最最重要的內功還是長期學習所磨練出來的自學能力)。對此大嘴Joel在《Joel On Software》裡面提到的漏洞抽象定律闡述得就非常漂亮。

    所以,答案是,讓你成為高手的並不是你掌握什麼語言,精通C++未必就能讓你成為高手,不精通C++也未必就能讓你成為低手。我想大家都不會懷疑g9老大如果要抄起C++做一個項目的話會比大多數自認熟練C++的人要做得漂亮。所以關鍵的不是語言這個表層的東西,而是底下的本質矛盾。當然,不是說那就什麼語言都不要學了,按照一種曹操的邏輯,“天下語言,唯imperative與declarative耳”。 C++是前者裡面最複雜的一種,支持最廣泛的編程範式。借用當初數學系入學大會上一個老師的話,“你數學都學了,還有什麼不能學的呢?”。學語言是一個途徑,如果你把它用來磨練自己,可以。如果你把它用來作為學習系統底層知識的鑰匙,可以。如果你把它用來作為學習如何編寫優秀的代碼,如何組織大型的程序,如何進行抽象設計,可以。如果掉書袋,光啃細節,我認為不可以(除非你必須要用到細節,像boost庫的coder們)。

  • 虛擬化項目實施前需考慮的十大問題

    利用虛擬化技術,把軟件從硬件當中抽取出來,創建靈活、動態的環境,這樣的好處很吸引人。不過能否成功實施該項技術則取決於所需技能、安全和管理工具以及業務驅動因素是否到位。因為,在有些情況下,虛擬化技術還沒有準備好,或者回報不夠明顯,因而不能立刻開始實施。虛擬化項目不應該倉促上馬。這是一個長期機會,如果企業把虛擬化當成是一項戰略,而不僅僅是一個項目,那樣更有可能獲得長遠效益。

    以下是啟動全企業虛擬化項目之前要問自己的幾個重要問題。

    1、你擁有支持虛擬化技術的技能嗎?

    EMA把缺少“相應技能”列為成功部署虛擬化技術面臨的最大障礙。這家研究公司聲稱,虛擬化技術還沒有到位的企業約有四分之三不具備支持這項技術的技能。 EMA建議:在採用這項技術之前,對員工進行培訓、確定需求、記下預期出現的變化,並且在小的試點環境裡對虛擬化技術進行試用。

    2、你對虛擬化技術可能帶來的人事紛爭做好準備了嗎?

    第二個隱藏困難也與人這個因素有關。 EMA認為,因為IT部門多年來存在於各自獨立的環境,IT主管試圖讓公司的主流用戶接受虛擬化技術時可能會面臨阻力。譬如說,有些部門可能不想共享服務器資源,正因為如此,EMA建議公司部署報告工具,顯示虛擬化技術如何有助於提升性能,或者因為可共享彼此的資源而至少不會損害各部門的利益。

    3、你有沒有考慮過相關風險?能不能承受?

    雖然虛擬化技術減少了支持多個系統及應用所需的物理資源的數量,但同時把更多的用戶和應用集中到了數量更少、更複雜的共享虛擬化環境下。正因為如此,硬件故障、人為錯誤、安全漏洞、規劃問題、支持問題及其他因素帶來的影響在虛擬化環境下會得到極大地放大。 EMA給出的建議就是:在虛擬化項目的每個階段,企業應當制訂詳細的業務連續性和災難恢復計劃。

    4、你的安全系統承受得了嗎?

    虛擬化技術會帶來更多的安全漏洞、惡意軟件及薄弱環節,數量之多超出了許多公司原先準備的應對能力——這主要是因為如今的技術還無法處理新的威脅。 EMA認為,借助現有工具,幾乎發現不了像虛擬機管理程序感染、rootkIT病毒以及惡意虛擬機這類安全問題。 IT主管必須像保護物理機器那樣來保護虛擬機,還要採取其他步驟來確保虛擬化環境得到保護。 EMA認為,發現、配置、變革管理及其他方面的技術和製度對發現針對虛擬化環境的惡意軟件變得更為關鍵。

    5、你的系統和應用與虛擬化技術兼容嗎?

    有些應用和系統與虛擬化技術之間缺乏良好的兼容性。譬如說,EMA提到的“具有對各種資源的高效利用、極大的需求峰值或者持續高利用率等特點”的應用。這家研究公司認為,直接與硬件進行聯繫的應用也會妨礙虛擬化項目的實施。

    6、你有沒有容量規劃措施?

    虛擬服務器散亂現像是部署的虛擬化技術超過現有容量所帶來的一個常見結果。 EMA建議,IT部門應當利用詳細的容量規劃措施,確保自己有足夠的軟硬件資源來支持所實施的虛擬化技術,並確保虛擬化技術不會失去控制。

    7、你的環境得到支持嗎?

    EMA認為,雖然許多流行的套裝應用軟件支持虛擬化技術,但還是有許多應用軟件不支持。這家研究機構建議,IT部門在部署虛擬化技術之前,應當調查哪些軟硬件平台得到支持、哪些需要升級。

    8、你的網絡支持虛擬化技術嗎?

    網絡和存儲可能會給數據中心的虛擬化技術帶來瓶頸。譬如說,專注於用戶的虛擬化技術(如應用虛擬化、桌面虛擬化或者應用流)在低帶寬連接上就無法使用。企業的IT管理人員可以試著利用廣域網優化技術或者限制系統映像數量過多,克服網絡和存儲帶來的局限性。

    9、你的管理系統能夠處理虛擬化環境嗎?

    雖然虛擬化技術減少了要管理的物理資源的數量,但也加大了整個環境的複雜性,還帶來了讓某些IT管理人員為之頭痛的管理問題。譬如,易於部署可能會帶來虛擬機數量過多,或者虛擬服務器散亂現象,這可能會導致管理難度大大提高。

    另外,添加的一層軟件加大了管理整個環境的複雜性。 EMA認為,在管理工具跟上虛擬化技術的步伐之前,成功的關鍵在於不但要有相應工具,還要有發現、性能管理、配置管理、補丁管理、服務級別管理、自動配置、災難恢復等其他方面嚴格的流程製度。

    10、虛擬化技術可以幫助你滿足業務目標嗎?

    也許在倉促實施虛擬化技術過程中最容易被忽視的因素就是,沒有把技術實施與具體的業務目標聯繫起來。為了評估虛擬化技術部署項目的成功,企業的IT部門必須在部署這項技術之前,先要知道所需要的結果。 EMA建議,IT管理人員應當為長遠的戰略成果做好規劃,不要使用虛擬化技術作為解決緊迫的棘手問題的權宜之計。譬如說,雖然許多公司認為節省成本是虛擬化技術的一個成果,但EMA認為情況往往並非如此。

    EMA認為: “總的來說,節省成本並非是總能得到的結果,實際上,減少成本(軟件、硬件和場地等方面的成本)是最不能指望的結果。譬如說,儘管服務器合併帶來的成本效益經常被吹噓,但它帶來的只是一次性的成本節省,而額外成本(特別是對軟件而言)往往相當大。”