<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    GHawk

    2006年1月19日 #

    建議方正要是勝訴的話,為開源事業(yè)做點貢獻

    中國人民可以說是被盜版和Windows慣壞了。在Linux默認環(huán)境下的中文顯示至今慘不忍睹。
    看看現(xiàn)在一些主要的發(fā)行版本,默認設置下的日語的顯示已經(jīng)相當不錯了。
    作為漢字發(fā)祥地且擁有眾多人口的中國,實在是有些悲哀。
    文泉驛計劃正在為實現(xiàn)這個目標努力。作為一個非盈利性組織,他們的貢獻的確值得贊賞。
    最近方正正在為字體的事情打官司,并提出了高額賠償?shù)囊蟆=ㄗh方正要是能夠勝訴的話,貢獻一些字體給開源組織,為弘揚漢語言文化多做點貢獻。

    posted @ 2007-08-23 15:01 GHawk 閱讀(651) | 評論 (1)編輯 收藏

    Maven2 用于度量和品質(zhì)保證的插件


    以上是一些常用的用于品質(zhì)管理的插件。默認情況下都不用配置,相當方便。如果需要手動配置的話,根據(jù)網(wǎng)上的文檔也相當容易配置。
    apache的maven plugin頁面: http://maven.apache.org/plugins/
    codehaus mojo 頁面: http://mojo.codehaus.org

    posted @ 2007-05-28 14:32 GHawk 閱讀(1557) | 評論 (1)編輯 收藏

    Scripting in Mustang 的一點啟發(fā)

    2006 Sun Techdays Shanghai 的第2天下午有一個名為《Java Scripting: One VM, Many Languages》的Session。

    Rags為大家展示了Mustang的一個新特性,Scripting in Java——腳本語言支持。

    通過加入腳本引擎的支持,就能夠在Java中解釋Javascript,python,ruby等諸多腳本語言。

    對于這個特性,想到的一個可能的應用就是在annotation中寫腳本語言,然后在代碼中用相應的腳本語言引擎解釋執(zhí)行。
    保留到運行時的annotation可以用實現(xiàn)aop的功能,使用非inline的腳本就可以更靈活地控制aspect的行為。

    比如:
    //inline scripting
    @ScriptBefore(script
    ="",language="javascript"?)
    public?void?foo()?{
    ???
    }

    //non-inline scripting
    @ScriptBefore(file
    ="scripts/logging.js",language="javascript")
    public?void?bar()?{

    }

    posted @ 2006-09-26 10:04 GHawk 閱讀(1326) | 評論 (3)編輯 收藏

    一個XPer提供的一些經(jīng)驗

    前些天,和一位XPer進行了一次愉快的談話。他向我講述了一些感覺很有效的實踐。

    關(guān)于過程和迭代
    他曾經(jīng)參與過的項目的迭代是以月為迭代單位的,但事實上每周都會重復一個簡單的過程。
    在迭代過程中,他非常推崇Burn-Down Charts。這是一個Scrum的工具。通過Burn-Down Charts,能夠把過程中間的變化記錄下來,使過程高度可視化。等到一次迭代完成,回顧一下所有的Burn-Down Charts就能作為改進的判斷依據(jù)。
    KPT Meeting。所謂KPT Meeting就是 Keep-Prevent-Try metting。小組定期舉行KPT會議(基本上是每周一次)。在KTP會議上,通過頭腦風暴的方式每個人(不是某幾個人)把各自認為前一階段里做得好的方面寫在Keep一欄里;做得不好的方面寫在Prevent一欄里;希望嘗試的寫在Try一欄里。然后大家對這些項目進行評估和篩選。下一階段中,Keep的項目繼續(xù)保持,Prevent的項目應該杜絕,Try的項目進行嘗試。

    工具
    在開展這些實踐的時候,交流比較頻繁。首推的工具是Mini white boardDC
    選擇Mini white board的原因并不是因為帶有"mini"聽上去會像 Mini Cooper 或者 iPod mini 那么cool。因為一塊A3左右大小的白板非常適合個人或者結(jié)對使用,而且環(huán)保(省去了草稿紙)。雖然整個團隊也有用于大規(guī)模交流的更大的白板,但那屬于“競爭資源”,各自使用自己的白板更為方便。
    交流結(jié)果產(chǎn)生后,為了不花不必要的時間去做精美的文檔,一臺輕便的DC往往是最合適的選擇。當然,如果足夠,手機上的照相功能也可以完成同樣的任務。相比偷拍街上的MM,這些電子產(chǎn)品能夠?qū)崿F(xiàn)更大的價值。

    關(guān)于結(jié)對
    每天進行6小時的結(jié)對編程,分3次,每次2小時。每次和不同的成員組隊。在結(jié)隊的時候充分利用了上面提到的工具進行交流。如果出現(xiàn)兩個人不能解決的問題的時候,會立即向整個團隊提出,這樣可能導致一次stand-up meeting。即使問題不能馬上解決,至少也能確保每個人都知道這個問題。

    posted @ 2006-08-24 15:45 GHawk 閱讀(1445) | 評論 (0)編輯 收藏

    關(guān)于locale的設定 (轉(zhuǎn))

    轉(zhuǎn)自:http://www.syxin.com/2006/03/localelocale.html

    關(guān)于locale的設定
    ?
    locale是國際化與本土化過程中的一個非常重要的概念,個人認為,對于中文用戶來說,通常會涉及到的國際化或者本土化,大致包含三個方面:看中文,寫中文,與window中文系統(tǒng)的兼容和通信。從實際經(jīng)驗上看來,locale的設定與看中文關(guān)系不大,但是與寫中文,及window分區(qū)的掛載方式有很密切的關(guān)系。本人認為就像一個純英文的Windows能夠瀏覽中文,日文或者意大利文網(wǎng)頁一樣,你不需要設定locale就可以看中文。那么,為什么要設定locale呢?什么時候會用到locale呢?

    一、為什么要設定locale
    正如前面我所講的,設定locale與你能否瀏覽中文的網(wǎng)頁沒有直接的關(guān)系,即便你把locale設置成en_US.ISO-8859-1這樣一個標準的英文locale你照樣可以瀏覽中文的網(wǎng)頁,只要你的系統(tǒng)里面有相應的字符集(這個都不一定需要)和合適的字體(如simsun),瀏覽器就可以把網(wǎng)頁翻譯成中文給你看。具體的過程是網(wǎng)絡把網(wǎng)頁傳送到你的機器上之后,瀏覽器會判斷相應的編碼的字符集,根據(jù)網(wǎng)頁采用的字符集,去字體庫里面找合適的字體,然后由文字渲染工具把相應的文字在屏幕上顯示出來。

    ?
    在下文本人會偶爾把字符集比喻成密碼本,個人覺得對于一些東西比較容易理解,假如你不習慣的話,把全文copy到任何文本編輯器,用字符集替換密碼本即可。
    ?
    那有時候網(wǎng)頁顯示亂碼或者都是方框是怎么回事呢?個人認為,顯示亂碼是因為設定的字符集不對(或者沒有相應的字符集),例如網(wǎng)頁是用UTF-8編碼的,你非要用GB2312去看,而系統(tǒng)根據(jù)GB2312去找字體,然后在屏幕上顯示,當然是一堆的亂碼,也就是說你用一個錯誤的密碼本去翻譯發(fā)給你的電報,當然內(nèi)容那叫一個亂;至于有些時候瀏覽的網(wǎng)頁能顯示一部分漢字,但有很多的地方是方框,能夠顯示漢字說明瀏覽器已經(jīng)正確的判斷出了網(wǎng)頁的編碼,并在字體庫里面找到了相應的文字,但是并不是每個字體庫都包含某個字符集全部的字體的緣故,有些時候會顯示不完全,找一個比較全的支持較多字符集的字體就可以了。
    ?

    既然我能夠瀏覽中文網(wǎng)頁,那為什么我還要設定locale呢?
    ?
    其實你有沒有想過這么一個問題,為什么gentoo官方論壇上中文論壇的網(wǎng)頁是用UTF-8編碼的(雖然大家一直強烈建議用GB2312編碼),但是新浪網(wǎng)就是用GB2312編碼的呢?而Xorg的官方網(wǎng)頁竟然是ISO-8859-15編碼的,我沒有設定這個locale怎么一樣的能瀏覽呢?這個問題就像是你有所有的密碼本,不論某個網(wǎng)站是用什么字符集編碼的,你都可以用你手里的密碼本把他們翻譯過來,但問題是雖然你能瀏覽中文網(wǎng)頁,但是在整個操作系統(tǒng)里面流動的還是英文字符。所以,就像你能聽懂英語,也能聽懂中文。
    最根本的問題是:你不可以寫中文。
    ?
    當你決定要寫什么東西的時候,首先要決定的一件事情是用那種語言,對于計算機來說就是你要是用哪一種字符集,你就必須告訴你的linux系統(tǒng),你想用那一本密碼本去寫你想要寫的東西。知道為什么需要用GB2312字符集去瀏覽新浪了吧,因為新浪的網(wǎng)頁是用GB2312寫的。
    ?
    為了讓你的Linux能夠輸入中文,就需要把系統(tǒng)的locale設定成中文的(嚴格說來是locale中的語言類別LC_CTYPE ),例如zh_CN.GB2312、zh_CN.GB18030或者zh_CN.UTF-8。很多人都不明白這些古里古怪的表達方式。這個外星表達式規(guī)定了什么東西呢?這個問題稍后詳述,現(xiàn)在只需要知道,這是locale的表達方式就可以了。
    ?
    二、到底什么是locale?
    locale這個單詞中文翻譯成地區(qū)或者地域,其實這個單詞包含的意義要寬泛很多。Locale是根據(jù)計算機用戶所使用的語言,所在國家或者地區(qū),以及當?shù)氐奈幕瘋鹘y(tǒng)所定義的一個軟件運行時的語言環(huán)境。
    ?
    這個用戶環(huán)境可以按照所涉及到的文化傳統(tǒng)的各個方面分成幾個大類,通常包括用戶所使用的語言符號及其分類(LC_CTYPE),數(shù)字(LC_NUMERIC),比較和排序習慣(LC_COLLATE),時間顯示格式(LC_TIME),貨幣單位(LC_MONETARY),信息主要是提示信息,錯誤信息, 狀態(tài)信息, 標題, 標簽, 按鈕和菜單等(LC_MESSAGES),姓名書寫方式(LC_NAME),地址書寫方式(LC_ADDRESS),電話號碼書寫方式(LC_TELEPHONE),度量衡表達方式(LC_MEASUREMENT),默認紙張尺寸大小(LC_PAPER)和locale對自身包含信息的概述(LC_IDENTIFICATION)。
    ?
    所以說,locale就是某一個地域內(nèi)的人們的語言習慣和文化傳統(tǒng)和生活習慣。一個地區(qū)的locale就是根據(jù)這幾大類的習慣定義的,這些locale定義文件放在/usr/share/i18n/locales目錄下面,例如en_US, zh_CN and de_DE@euro都是locale的定義文件,這些文件都是用文本格式書寫的,你可以用寫字板打開,看看里邊的內(nèi)容,當然出了有限的注釋以外,大部分東西可能你都看不懂,因為是用的Unicode的字符索引方式。
    ?
    對于de_DE@euro的一點說明,@后邊是修正項,也就是說你可以看到兩個德國的locale:
    /usr/share/i18n/locales/de_DE@euro
    /usr/share/i18n/locales/de_DE
    打開這兩個locale定義,你就會知道它們的差別在于de_DE@euro使用的是歐洲的排序、比較和縮進習慣,而de_DE用的是德國的標準習慣。
    ?
    上面我們說到了zh_CN.GB18030的前半部分,后半部分是什么呢?大部分Linux用戶都知道是系統(tǒng)采用的字符集。
    ?
    三、什么是字符集?
    字符集就是字符,尤其是非英語字符在系統(tǒng)內(nèi)的編碼方式,也就是通常所說的內(nèi)碼,所有的字符集都放在/usr/share/i18n/charmaps,所有的字符集也都是用Unicode編號索引的。Unicode用統(tǒng)一的編號來索引目前已知的全部的符號。而字符集則是這些符號的編碼方式,或者說是在網(wǎng)絡傳輸,計算機內(nèi)部通信的時候,對于不同字符的表達方式,Unicode是一個靜態(tài)的概念,字符集是一個動態(tài)的概念,是每一個字符傳遞或傳輸?shù)木唧w形式。就像Unicode編號U59D0是代表姐姐的“姐”字,但是具體的這個字是用兩個字節(jié)表示,三個字節(jié),還是四個字節(jié)表示,是字符集的問題。例如:UTF-8字符集就是目前流行的對字符的編碼方式,UTF-8用一個字節(jié)表示常用的拉丁字母,用兩個字節(jié)表示常用的符號,包括常用的中文字符,用三個表示不常用的字符,用四個字節(jié)表示其他的古靈精怪的字符。而GB2312字符集就是用兩個字節(jié)表示所有的字符。需要提到一點的是Unicode除了用編號索引全部字符以外,本身是用四個字節(jié)存儲全部字符,這一點在談到掛載windows分區(qū)的時候是非常重要的一個概念。所以說你也可以把Unicode看作是一種字符集(我不知道它和UTF-32的關(guān)系,反正UTF-32就是用四個字節(jié)表示所有的字符的),但是這樣表述符號是非常浪費資源的,因為在計算機世界絕大部分時候用到的是一個字節(jié)就可以搞定的26個字母而已。所以才會有UTF-8,UTF-16等等,要不然大同世界多好,省了這許多麻煩。
    ?

    四、zh_CN.GB2312到底是在說什么?
    Locale 是軟件在運行時的語言環(huán)境, 它包括語言(Language), 地域 (Territory) 和字符集(Codeset)。一個locale的書寫格式為: 語言[_地域[.字符集]]. 所以說呢,locale總是和一定的字符集相聯(lián)系的。下面舉幾個例子:
    ?
    1、我說中文,身處中華人民共和國,使用國標2312字符集來表達字符。
    zh_CN.GB2312=中文_中華人民共和國+國標2312字符集。
    ?
    2、我說中文,身處中華人民共和國,使用國標18030字符集來表達字符。
    zh_CN.GB18030=中文_中華人民共和國+國標18030字符集。
    ?
    3、我說中文,身處中華人民共和國臺灣省,使用國標Big5字符集來表達字符。
    zh_TW.BIG5=中文_臺灣.大五碼字符集
    ?
    4、我說英文,身處大不列顛,使用ISO-8859-1字符集來表達字符。
    en_GB.ISO-8859-1=英文_大不列顛.ISO-8859-1字符集
    ?
    5、我說德語,身處德國,使用UTF-8字符集,習慣了歐洲風格。
    de_DE.UTF-8@euro=德語_德國.UTF-8字符集@按照歐洲習慣加以修正
    ?
    注意不是de_DE@euro.UTF-8,所以完全的locale表達方式是
    [語言[_地域][.字符集] [@修正值]
    ?
    生成的locale放在/usr/lib/locale/目錄中,并且每個locale都對應一個文件夾,也就是說創(chuàng)建了de_DE@euro.UTF-8 locale之后,就生成/usr/lib/locale/de_DE@euro.UTF-8/目錄,里面是具體的每個locale的內(nèi)容。
    ?
    五、怎樣去自定義locale
    在gentoo生成locale還是很容易的,首先要在USE里面加入userlocales支持,然后編輯locales.build文件,這個文件用來指示glibc生成locale文件。
    很多人不明白每一個條目是什么意思。 其實根據(jù)上面的說明現(xiàn)在應該很明確了。
    ?
    File: /etc/locales.build
    en_US/ISO-8859-1
    en_US.UTF-8/UTF-8
    ?
    zh_CN/GB18030
    zh_CN.GBK/GBK
    zh_CN.GB2312/GB2312
    zh_CN.UTF-8/UTF-8
    ?
    上面是我的locales.build文件,依次的說明是這樣的:
    ?
    en_US/ISO-8859-1:生成名為en_US的locale,采用ISO-8859-1字符集,并且把這個locale作為英文_美國locale類的默認值,其實它和en_US.ISO-8859-1/ISO-8859-1沒有任何區(qū)別。
    ?
    en_US.UTF-8/UTF-8:生成名為en_US.UTF-8的locale,采用UTF-8字符集。
    ?
    zh_CN/GB18030:生成名為zh_CN的locale,采用GB18030字符集,并且把這個locale作為中文_中國locale類的默認值,其實它和zh_CN.GB18030/GB18030沒有任何區(qū)別。
    ?
    zh_CN.GBK/GBK:生成名為zh_CN.GBK的locale,采用GBK字符集。
    zh_CN.GB2312/GB2312:生成名為zh_CN.GB2312的locale,采用GB2312字符集。
    zh_CN.UTF-8/UTF-8:生成名為zh_CN.UTF-8的locale,采用UTF-8字符集。
    ?
    關(guān)于默認locale,默認locale可以簡寫成en_US或者zh_CN的形式,只是為了表達簡單而已沒有特別的意義。
    ?
    Gentoo在locale定義的時候掩蓋了一些東西,也就是locale的生成工具:localedef。
    在編譯完glibc之后你可以用這個localedef 再補充一些locale,就會更加理解locale了。具體的可以看 localedef 的manpage。
    ?
    $localedef -f 字符集 -i locale定義文件 生成的locale的名稱
    例如
    $localedef -f UTF-8 -i zh_CN zh_CN.UTF-8
    ?
    上面的定義方法和在locales.build中設定zh_CN.UTF-8/UTF-8的結(jié)果是一樣一樣的。
    ?

    六、locale的五臟六腑
    ?
    剛剛生成了幾個locale,但是為了讓它們生效,必須告訴Linux系統(tǒng)使用那(幾)個locale。這就需要對locale的內(nèi)部機制有一點點的了解。在前面我已經(jīng)提到過,locale把按照所涉及到的文化傳統(tǒng)的各個方面分成12個大類,這12個大類分別是:
    1、語言符號及其分類(LC_CTYPE)
    2、數(shù)字(LC_NUMERIC)
    3、比較和排序習慣(LC_COLLATE)
    4、時間顯示格式(LC_TIME)
    5、貨幣單位(LC_MONETARY)
    6、信息主要是提示信息,錯誤信息, 狀態(tài)信息, 標題, 標簽, 按鈕和菜單等(LC_MESSAGES)
    7、姓名書寫方式(LC_NAME)
    8、地址書寫方式(LC_ADDRESS)
    9、電話號碼書寫方式(LC_TELEPHONE)
    10、度量衡表達方式(LC_MEASUREMENT)
    11、默認紙張尺寸大小(LC_PAPER)
    12、對locale自身包含信息的概述(LC_IDENTIFICATION)。
    ?
    其中,與中文輸入關(guān)系最密切的就是 LC_CTYPE, LC_CTYPE 規(guī)定了系統(tǒng)內(nèi)有效的字符以及這些字符的分類,諸如什么是大寫字母,小寫字母,大小寫轉(zhuǎn)換,標點符號、可打印字符和其他的字符屬性等方面。而locale定義zh_CN中最最重要的一項就是定義了漢字(Class “hanzi”)這一個大類,當然也是用Unicode描述的,這就讓中文字符在Linux系統(tǒng)中成為合法的有效字符,而且不論它們是用什么字符集編碼的。
    ?
    LC_CTYPE
    % This is a copy of the "i18n" LC_CTYPE with the following modifications: - Additional classes: hanzi
    ?
    copy "i18n"
    ?
    class "hanzi"; /
    % <U3400>..<U4DBF>;/
    <U4E00>..<U9FA5>;/
    <UF92C>;<UF979>;<UF995>;<UF9E7>;<UF9F1>;<UFA0C>;<UFA0D>;<UFA0E>;/
    <UFA0F>;<UFA11>;<UFA13>;<UFA14>;<UFA18>;<UFA1F>;<UFA20>;<UFA21>;/
    <UFA23>;<UFA24>;<UFA27>;<UFA28>;<UFA29>
    END LC_CTYPE
    ?
    在en_US的locale定義中,并沒有定義漢字,所以漢字不是有效字符。所以如果要輸入中文必須使用支持中文的locale,也就是zh_XX,如zh_CN,zh_TW,zh_HK等等。
    ?
    另外非常重要的一點就是這些分類是彼此獨立的,也就是說LC_CTYPE,LC_COLLATE和 LC_MESSAGES等等分類彼此之間是獨立的,可以根據(jù)用戶的需要設定成不同的值。這一點對很多用戶是有利的,甚至是必須的。例如,我就需要一個能夠輸入中文的英文環(huán)境,所以我可以把LC_CTYPE設定成zh_CN.GB18030,而其他所有的項都是en_US.UTF-8。
    ?

    七、怎樣設定locale呢?
    ?
    設定locale就是設定12大類的locale分類屬性,即 12個LC_*。除了這12個變量可以設定以外,為了簡便起見,還有兩個變量:LC_ALL和LANG。它們之間有一個優(yōu)先級的關(guān)系:
    LC_ALL>LC_*>LANG
    可以這么說,LC_ALL是最上級設定或者強制設定,而LANG是默認設定值。
    1、如果你設定了LC_ALL=zh_CN.UTF-8,那么不管LC_*和LANG設定成什么值,它們都會被強制服從LC_ALL的設定,成為 zh_CN.UTF-8。
    2、假如你設定了LANG=zh_CN.UTF-8,而其他的LC_*=en_US.UTF-8,并且沒有設定LC_ALL的話,那么系統(tǒng)的locale設定以LC_*=en_US.UTF-8。
    3、假如你設定了LANG=zh_CN.UTF-8,而其他的LC_*,和LC_ALL均未設定的話,系統(tǒng)會將LC_*設定成默認值,也就是LANG的值 zh_CN.UTF-8 。
    4、假如你設定了LANG=zh_CN.UTF-8,而其他的LC_CTYPE=en_US.UTF-8,其他的LC_*,和LC_ALL均未設定的話,那么系統(tǒng)的locale設定將是:LC_CTYPE=en_US.UTF-8,其余的 LC_COLLATE,LC_MESSAGES等等均會采用默認值,也就是LANG的值,也就是LC_COLLATE=LC_MESSAGES=……= LC_PAPER=LANG=zh_CN.UTF-8。
    ?
    所以,locale是這樣設定的:
    1、如果你需要一個純中文的系統(tǒng)的話,設定LC_ALL= zh_CN.XXXX,或者LANG= zh_CN.XXXX都可以,當然你可以兩個都設定,但正如上面所講,LC_ALL的值將覆蓋所有其他的locale設定,不要作無用功。
    2、如果你只想要一個可以輸入中文的環(huán)境,而保持菜單、標題,系統(tǒng)信息等等為英文界面,那么只需要設定LC_CTYPE=zh_CN.XXXX,LANG=en_US.XXXX就可以了。這樣LC_CTYPE=zh_CN.XXXX,而LC_COLLATE=LC_MESSAGES=……= LC_PAPER=LANG=en_US.XXXX。
    3、假如你高興的話,可以把12個LC_*一一設定成你需要的值,打造一個古靈精怪的系統(tǒng):
    LC_CTYPE=zh_CN.GBK/GBK(使用中文編碼內(nèi)碼GBK字符集);
    LC_NUMERIC=en_GB.ISO-8859-1(使用大不列顛的數(shù)字系統(tǒng))
    LC_MEASUREMEN=de_DE@euro.ISO-8859-15(德國的度量衡使用ISO-8859-15字符集)
    羅馬的地址書寫方式,美國的紙張設定……。估計沒人這么干吧。
    4、假如你什么也不做的話,也就是LC_ALL,LANG和LC_*均不指定特定值的話,系統(tǒng)將采用POSIX作為lcoale,也就是C locale。

    posted @ 2006-08-16 10:45 GHawk 閱讀(756) | 評論 (0)編輯 收藏

    PostgreSQL的主機認證配置

    轉(zhuǎn)自 http://www.linuxsir.org/bbs/showthread.php?t=32116

    pg_hba.conf 文件
    客戶端認證是由 $PGDATA 目錄里的文件pg_hba.conf 控制的,也就是說, /usr/local/pgsql/data/pg_hba.conf. (HBA 的意思是 host-based authentication:基于主機的認證.) 在initdb初始化數(shù)據(jù)區(qū)的時候,它會 安裝一個缺省的文件.

    文件 pg_hba.conf 的常用格式是一套記錄, 每行一條。空白行或者井號(“#”)開頭的行被忽略。一條記錄 是由若干用空格和/或 tab 分隔的字段組成。

    每條記錄可以下面三種格式之一

    local database authentication-method [ authentication-option ]
    host database IP-address IP-mask authentication-method [ authentication-option ]
    hostssl database IP-address IP-mask authentication-method [ authentication-option ]

    各個字段的含義如下:

    local
    這條記錄適用于通過 Unix 域套接字的聯(lián)接.

    host
    這條記錄適用于通過 TCP/IP 網(wǎng)絡的聯(lián)接.請注意,除非服務器是 帶著 -i 選項或者等效的配置參數(shù)集啟動的,否則 TCP/IP 聯(lián)接將完全被禁止掉.

    hostssl
    這條記錄適用于試圖建立在 TCP/IP 上的 SSL 之上的聯(lián)接. 要使用這個選項,服務器必須帶著 SSL 支持編譯.而且在服務器啟動的時候, 必須用 -l 選項 或等效的配置設置打開 SSL.

    database
    聲明記錄所適用的數(shù)據(jù)庫。值 all 表明該記錄應用于所有數(shù)據(jù)庫, 值 sameuser 表示于正在聯(lián)接的用戶同名的數(shù)據(jù)庫。 否則它就是某個具體的 Postgres 數(shù)據(jù)庫名字.

    IP address, IP mask
    這兩個字段以各主機的 IP 地址為基礎, 控制一條 host 記錄應用于哪個主機. (當然,IP 地址可能會被欺騙(spoofed),但是這個考慮 超過了 Postgres 的考慮范圍.) 準確的邏輯是,對于匹配的記錄

    (actual-IP-address xor IP-address-field) and IP-mask-field
    必需為零.

    authentication method(認證方法)
    聲明一個用戶在與該數(shù)據(jù)庫聯(lián)接的時候必須使用的認證方法. 可能的選擇如下,詳細情況在 Section 4.2.


    trust
    無條件地允許聯(lián)接.這個方法允許任何有登錄客戶機權(quán)限的用戶以任意 Postgres 數(shù)據(jù)庫用戶身份進行聯(lián)接.

    reject
    聯(lián)接無條件拒絕.常用于從組中“過濾”某些主機.

    password
    要求客戶端在嘗試聯(lián)接的時候提供一個口令, 這個口令與為該用戶設置的口令必須匹配.

    在 password 關(guān)鍵字后面可以聲明一個可選的文件名. 這個文件包含一個用戶列表,列表記錄的是那些適用口令認證記錄的用戶, 以及可選的候選口令.

    口令是以明文的方式在線路上傳輸?shù)模绻玫谋Wo,請使用 crypt 方法.

    crypt
    類似 password 方法,但是口令是用一種簡單的 口令對應協(xié)議加密后在線路上傳送的.這么做在密碼學理論上是不安全的, 但可以防止偶然的線路偵聽.在 crypt 關(guān)鍵字后面 可以有一個文件,文件里包含適用口令認證記錄的用戶列表.

    krb4
    用 Kerberos V4 認證用戶.只有在進行 TCP/IP 聯(lián)接的時候才能用. (譯注:Kerberos,"克爾波洛斯",故希臘神話冥王哈得斯的多頭看門狗. Kerberos 是 MIT 開發(fā)出來的基與對稱加密算法的認證協(xié)議和/或密鑰 交換方法.其特點是需要兩個不同用途的服務器,一個用于認證身份, 一個用于通道兩端用戶的密鑰交換.同時 Kerberos 對網(wǎng)絡時間同步 要求比較高,以防止回放攻擊,因此通常伴隨 NTP 服務.)

    krb5
    用 Kerberos V5 認證用戶.只有在進行 TCP/IP 聯(lián)接的時候才能用. (譯注:Kerberos V5 是上面 V4 的改良,主要是不再依賴 DES 算法, 同時增加了一些新特性.)

    ident
    服務器將詢問客戶機上的 ident 服務器以核實正在聯(lián)接的用戶身份. 然后 Postgres 核實該操作系統(tǒng)用戶是否被允許以其請求的數(shù)據(jù)庫用戶身份與數(shù)據(jù)庫聯(lián)接. 只有在使用 TCP/IP 聯(lián)接的時候才能用這個選項. 跟在 ident 關(guān)鍵字后面的 authentication option 聲明一個 ident map(身份映射), 該文件聲明那些操作系統(tǒng)用戶等效于數(shù)據(jù)庫用戶.見下文獲取詳細信息.


    authentication option(認證選項)
    這個字段根據(jù)不同的認證方法(authentication method)有不同的 解釋.

    認證時使用與聯(lián)接請求的客戶端 IP 地址和所要求的 數(shù)據(jù)庫名字匹配的第一條記錄. 請注意這里沒有 “fall-through(越過)” 或者 “backup(備份)”:如果選定了一條記錄但認證失敗, 那么將不會繼續(xù)考慮下面的記錄.如果沒有匹配的記錄,則拒絕訪問.

    在每次聯(lián)接的請求時,文件 pg_hba.conf 都會被重新讀取.因此很容易就能在服務器運行的時候修改訪問權(quán)限.

    在 Example 4-1 里是 pg_hba.conf 的一個例子. 閱讀下文理解不同認證方法的細節(jié).

    Example 4-1. 一個 pg_hba.conf 文件的例子

    # TYPE DATABASE IP_ADDRESS MASK AUTHTYPE MAP

    # 允許在本機上的任何用戶以任何身份聯(lián)接任何數(shù)據(jù)庫
    # 但必須是通過 IP 進行聯(lián)接

    host all 127.0.0.1 255.255.255.255 trust

    # 同樣,但用的是 Unix-套接字聯(lián)接

    local all trust

    # 允許 IP 地址為 192.168.93.x 的任何主機與數(shù)據(jù)庫
    # "template1" 相連,用與他們在自己的主機上相同 ident 的用戶名標識他自己
    # (通常是他的 Unix 用戶名)

    host template1 192.168.93.0 255.255.255.0 ident sameuser

    # 允許來自主機 192.168.12.10 的用戶與 "template1" 數(shù)據(jù)庫聯(lián)接,
    # 只要該用戶提供了在 pg_shadow 里正確的口令.

    host template1 192.168.12.10 255.255.255.255 crypt

    # 如果前面沒有其它 "host" 行,那么下面兩行將拒絕所有來自
    # 192.168.54.1 的聯(lián)接請求 (因為前面的記錄先匹配
    # 但是允許來自互聯(lián)網(wǎng)上其它任何地方有效的 Kerberos V5 認證的聯(lián)接
    # 零掩碼表示不考慮主機 IP 的任何位.因此它匹配任何主機:

    host all 192.168.54.1 255.255.255.255 reject
    host all 0.0.0.0 0.0.0.0 krb5

    # 允許來自 192.168.x.x 的任何用戶與任意數(shù)據(jù)庫聯(lián)接,只要他們通過 ident 檢查
    # 但如果 ident 說該用戶是 "bryanh" 而他要求以 PostgreSQL 用戶 "guest1" 聯(lián)接,
    # 那么只有在 `pg_ident.conf' 里有 "omicron" 的映射,說 "bryanh" 允許以
    # "guest1" 進行聯(lián)接時才真正可以進行聯(lián)接.

    host all 192.168.0.0 255.255.0.0 ident omicron

    posted @ 2006-06-07 10:42 GHawk 閱讀(1213) | 評論 (0)編輯 收藏

    UP & XP之爭,意義何在?(續(xù))

    雖然我沒能去參加BEA的活動,但是相關(guān)的資料已經(jīng)下載并且瀏覽過了,確實收獲不少。所以,對于莊兄的這些想法我很理解。

    相信不只你我,大部分的人都比較認同敏捷化的過程,希望使過程變得敏捷。的確,這是個好東西,之前我也說過“敏捷過程是三贏的”這樣的話。

    我所關(guān)心的問題是“如何能夠用好XP?”。

    莊兄認為“湯的味道,不需要什么過程控制”,我也會認同。為什么?因為你我都是中國人。大部分中國人不會認為湯的味道需要什么過程控制。但是想想看,如果你在不同地方買到的肯德基炸雞味道各異;同一批次生產(chǎn)的同型號的汽車形狀各異;銀行里取出來的一疊百元大鈔大小不一,你不會覺得奇怪么或是有那么一點點憤怒么?

    西方人(甚至學習西方的日本人)對品質(zhì)的重視程度卻完全不同。他們不允許肯德基炸雞的味道有很大偏差(即便你覺得無所謂);“2毫米工程”不允許整車的總裝長度發(fā)生2毫米以上的偏差(即便你覺得無所謂);百元大鈔……(我想誰都不會無所謂)。

    所以,一切質(zhì)量都有標準,一切標準都應該被度量!這就是工程學的目標之一,為了實現(xiàn)更嚴格的質(zhì)量標準,就需要過程控制和度量。

    莊兄所說,用測試用例保證代碼的質(zhì)量其實還是采用了“測試用例”作為度量的標準。唯一的問題是:“如何確保測試用例的質(zhì)量”。顯然,我們不能把一把不直的尺子度量出來的結(jié)果作為可靠的參考依據(jù)。怎么解決呢?“結(jié)對編程”么?嗯,這是一個不錯的方式,那么最終該信賴誰呢?是Pair中的A還是B呢?或者,是Leader么?那么又是誰提出的要求呢?是老板么?還是客戶?政府?法規(guī)?市場?……問題沒有終結(jié)了。

    不要學習哲學家的方法,提出一層又一層無法解決的問題。我們是工程師,應該試圖解決問題才對!解決問題的關(guān)鍵在于,XP同樣需要標準!為了制定標準,必要的文檔是不可以少的。而且,標準本身的質(zhì)量是嚴苛的。因為,作為標準,他不可以含糊其辭、模棱兩可。在標準的基礎之上,我們才可以談什么TDD、Pair Programming之類的實踐。

    回到爭論的開端。我引用了林先生的話“UP是正楷;XP是草書。要先學好UP才能學好XP,先學XP會亂套。”我對這句話的理解如下:這句話并沒有批判UP或是XP,只是指出了一個學習的順序。我認為這句話是有實踐依據(jù)的,因為UP強調(diào)的是一種經(jīng)典的工程方法。軟件工程本來就源于其他行業(yè)的工程實踐經(jīng)驗。UP利用大量的文檔對開發(fā)活動進行約束和記錄。正是這種重量級的過程規(guī)范了規(guī)范了從PM到Coder的所有活動,有問題可以參照文檔,看看自己應該怎么做。文檔也可以作為日后評估這個過程的依據(jù)。隨著整個團隊和每個個人的經(jīng)驗不斷積累,開發(fā)活動中的日常行為漸漸形成了一種職業(yè)習慣。然后可以通過對UP的配置,逐漸減少文檔的使用量,一些沒有必要的文檔就可以省去,更具團隊的實際能力調(diào)整過程。UP是可配置的,不必要的文檔沒有存在的理由,這一點UP和XP沒有什么兩樣。當然,隨著大家的職業(yè)習慣越來越好,經(jīng)驗越來越豐富,個人和團隊就可以采用更敏捷更輕便的過程,逐漸過渡到XP上去。

    反過來,如果一開始就沒有詳盡的文檔,很多活動(比如設計、版本控制)往往會脫離控制,進入一種無序的、混亂的狀態(tài)。沒有文檔可參考,就意味著很多問題只能問人,而不同人的回答可能各異,同一個人對同一個問題的兩次回答也可能不同!當然,如果整個團隊的工程素養(yǎng)和個體的職業(yè)習慣都比較好的情況下可能不會發(fā)生類似的情況。但是這種工程素養(yǎng)和職業(yè)習慣從哪里來,可能單靠的XP是不足以培養(yǎng)出來的。

    “UP是正楷;XP是草書。要先學好UP才能學好XP,先學XP會亂套。”這句話表明了UP和XP在一定程度上是存在沖突的,并且提出了一條路線去降低和避免這個沖突。

    再次需要強調(diào)的是莊兄所提到的“XP是一種思想”,這點我認同。但是我認為這個除了思想之外,還是一種“文化”。這種思想和文化也是出于軟件工程多年來的實踐,其中也不免有UP等其他過程。不能簡單地認為“我們只要吸取歷史的教訓,提出新的思想和文化就不會再犯同樣的錯誤了。”很多時候歷史總是一次又一次地重演著。新的思想和文化如果不能被準確地理解和運用,它所帶來的可能仍然是它原本想解決的問題。只有我們具備了引入這種文化的基礎,才能把它變成自己的文化,否則這仍然是掛在嘴邊行于表面的一種不求精髓只求模仿的偽文化、偽思想。這一點對于UP和XP的實踐者來說沒有什么兩樣。

    posted @ 2006-04-25 15:03 GHawk 閱讀(2049) | 評論 (4)編輯 收藏

    UP & XP之爭,意義何在?

    不光是做軟件,凡是做產(chǎn)品,最后關(guān)注的總是產(chǎn)品的質(zhì)量

    舉個例子,比如你做一鍋湯:
    今天你狀態(tài)很好,做完后嘗了嘗,感覺很美味,你的家人嘗了以后也有同感,喝完后感覺心情舒暢、意猶未盡。
    隔了一個禮拜,你做同樣的湯給家里人喝。做完后你嘗了嘗,感覺依然美味,盼望著得到家人的賞識,然而他們卻說味道咸了點。你很奇怪,為什么同樣自己嘗過了,家里人卻感覺不一樣呢?是不是最近加班多了,休息不好,味覺不準了?
    一個月過后,你要去國外出差,給家里請了個臨時保姆。一天,他也做了這么個湯,做完后,他也嘗了嘗,感覺口味很不錯,可是端上桌,家里人說這湯太辣了。原來這保姆才從湖南老家出來不久……

    因此,只把焦點放在最后的產(chǎn)品上往往是不夠的。需要對“做湯的過程”加以控制。所以工程界會比較關(guān)注過程的管理,在軟件領(lǐng)域也稱作“軟件生命周期管理”。

    再來看看UP和XP。它們都屬于軟件過程,只不過各有特色。

    再拿剛才那個做湯的例子:
    大家都聽說過德國人的廚房像化學實驗室,天平、計時器、量杯……裝備齊全,再配上精確的菜譜,嚴謹?shù)牡聡四軌虼_保不用嘗那最后一口都做出口味基本一致的湯。
    換了中國人,大部分人都不會模仿德國人做菜的方式。解決方案很簡單,讓你的太太和孩子都嘗那最后一口,再根據(jù)反饋調(diào)整幾次,同樣能做出全家人滿意的湯。

    這個例子也許不太貼切,但是可以聯(lián)想一下:德國人做湯傾向于UP;中國人做湯傾向于XP

    UP和XP最終目的都是為了保證產(chǎn)品的質(zhì)量,不同的是,兩個過程所強調(diào)的方法不同。我想,沒有人會說“UP的目的在于變態(tài)地追求文檔的完美”、“UP是為了要程序員學會寫各種各樣文檔”……之類的話。同時,也沒人會說“XP就是不要文檔只要代碼”、“XP就是要變態(tài)地追求完美的代碼”……這樣的話。

    這些不正確的看法,只是人們對于這兩種過程的誤解。或許是來自于開發(fā)人員和項目經(jīng)理的那些“不堪回首的經(jīng)歷”。

    “UP害慘了整個軟件行業(yè),讓開發(fā)人員沒完沒了地寫文檔而忽略了代碼,XP才是王道”這樣的話,我不敢茍同,仍然有很多企業(yè)使用著UP這樣的重型軟件工程,就好比德國人依然喜歡把廚房弄得像個實驗室。

    XP固然是個好東西。但是,不知道大多數(shù)人對于XP的熱衷是出于對XP文化的理解,還是國人慣有的“一窩蜂”似的行為。不曉得一個“能夠熟練閱讀代碼的Leader”是不是能夠真正運用好XP,確保他的團隊能夠盡可能少地出現(xiàn)"Over engineering"這種違背Agile精神的東西,或是能夠讓他的團隊保證“每周只工作40小時”這樣的基本實踐?

    對于不同的技術(shù)和過程,應該給予冷靜的分析和慎重的選擇。每個過程和技術(shù)都不能以“正確”或“不正確”來定性,只能以“合適”和“不合適”來定性。因為正確或不正確是要嚴格證明的,而合適不合適是來源于工程實踐的結(jié)果。所以,COBOL依然在金融領(lǐng)域起著舉足輕重的作用,科學家們?nèi)圆煌麱ortran,匯編和C仍然健在……

    另外不得不提的是文化上的差異。為什么很多時候,我們學習國外的先進技術(shù),購買了整套生產(chǎn)線,引進了全套圖紙,請國外專家做了詳細的全程化培訓,國人生產(chǎn)出的產(chǎn)品品質(zhì)依然不如國外原產(chǎn)的?這是每個中國人都應該思考的問題……

    ?

    posted @ 2006-04-23 18:28 GHawk 閱讀(1899) | 評論 (4)編輯 收藏

    對"UP是正楷,XP是草書"的反思

    “UP是正楷,XP是草書。先學好了UP,才能學好XP;先學XP再學UP就會亂套。?”

    老師曾這么說。最近,對這句話有了深刻的體會。

    軟件過程是一個以人為中心的活動。人是項目中最難確定和控制的因素。休息的質(zhì)量、情緒的起伏都會影響整個活動。為了盡可能地約束這種個體的不確定行為和減少開發(fā)過程中不必要的誤會。"UP"采用了大量的文檔來對整個開發(fā)過程進行控制。這些文檔主要分為以下幾類:

    • 計劃文檔——項目的開發(fā)計劃、迭代計劃、測試計劃等。
    • 技術(shù)文檔——項目的設計文檔、某個操作的說明文檔等。
    • 記錄文檔——日常的會議紀要、每日進度反饋、評估報告等。

    文檔成了UP活動的主要部分。在UP中,往往大量的資源用于文檔的制作。這些文檔的目的是為了盡可能減少不必要的溝通成本和誤會,也為了在發(fā)生問題的時候能夠盡快確定原因找到解決方法。

    而正是因為如此繁重的資源消耗,導致真正的設計和代碼只占到了總開銷的很少部分。這對很多人來說不可理解,甚至覺得本末倒置。于是很多敏捷方法誕生了,最具代表性也是對UP思想最具顛覆性的就屬XP了。

    對外,XP以快速的反應速度來響應客戶的需求;對內(nèi),XP以高質(zhì)量的代碼和設計來確保盡可能不產(chǎn)生不必要的文檔和資源開銷。

    從表面上看,在當今,XP確實是一種非常理想的開發(fā)過程。

    但是,從沒有過程到XP往往會非常失敗。這是為什么?問題的關(guān)鍵還在于人。

    • 無過程-->UP -->XP

    UP利用文檔來約束和規(guī)范人們的開發(fā)活動。當一個沒有經(jīng)驗的團隊經(jīng)歷UP后,就等于把性格各異、習慣差別不同的人統(tǒng)一成了“相對較一致的開發(fā)人員”。

    他們有一致的編碼習慣,有共同的用語,有嚴格的規(guī)則。隨著經(jīng)驗的積累,這個團隊間的默契越來越高。此時,如果過程由UP向XP切換,付出的代價就會相對較低。

    • 無過程-->XP-->UP

    XP主張快速反應。如果一個沒有經(jīng)驗的團隊在一開始就嘗試XP,那么后果可能是慘痛的。因為一個沒有經(jīng)驗的團隊其成員間的相互了解頗少,對于一件事,往往十個人有十種想法。當缺少文檔約束時,在以代碼和設計為中心的活動中,成員之間往往因為水平的參差不齊導致無休止的討論甚至爭論,代碼被不必要地頻繁改動。這是因為,在團隊建設早期,成員之間往往連最基本的尊重和信任都不存在。 這種無意義的活動往往會嚴重影響項目的正常進行。

    所以,學習和應用過程不僅僅是個體的事,而是整個團隊的事。只有當團隊采用嚴格文檔化的過程并且經(jīng)過磨合后,才能漸漸向輕量級的過程遷移,逐漸將不必要的文檔刪減掉,采用更靈活的過程。但是,此時并不是“沒有文檔”而是“心中有文檔”。

    posted @ 2006-03-01 16:25 GHawk 閱讀(1655) | 評論 (4)編輯 收藏

    加載Classpath中的文件(轉(zhuǎn))

       URL url = this.getClass().getResource("EJBConfig.xml");
            
    try {
                File xmlFile 
    = new File(URLDecoder.decode(url.getFile(),"UTF-8"));
                
    if(xmlFile.exists())
                    System.out.println(
    "OK");
            } 
    catch (UnsupportedEncodingException e) {
                e.printStackTrace();  
    //To change body of catch statement use File | Settings | File Templates.
            }

    posted @ 2006-01-19 22:07 GHawk 閱讀(763) | 評論 (0)編輯 收藏

    主站蜘蛛池模板: eeuss免费天堂影院| 国产亚洲一区二区三区在线不卡 | 国内精品99亚洲免费高清| 亚洲欧洲日产国码久在线| 0588影视手机免费看片| 国产亚洲成av人片在线观看| 九九九国产精品成人免费视频| 永久免费bbbbbb视频| 一本色道久久综合亚洲精品蜜桃冫| a拍拍男女免费看全片| 91亚洲一区二区在线观看不卡 | 鲁大师在线影院免费观看 | 亚洲天堂中文字幕在线观看| 国产精品免费无遮挡无码永久视频| 亚洲色成人中文字幕网站| 一级毛片大全免费播放下载| mm1313亚洲精品国产| 边摸边吃奶边做爽免费视频99 | 亚洲国产综合精品中文字幕| 老湿机一区午夜精品免费福利 | 亚洲国产精品99久久久久久 | 亚洲乱码卡三乱码新区| 国产免费不卡视频| 亚洲国产中文在线二区三区免| 亚洲免费视频播放| 亚洲啪啪免费视频| 国产人在线成免费视频| 亚洲中文字幕人成乱码| 野花高清在线观看免费完整版中文| 99热亚洲色精品国产88| 思思99re66在线精品免费观看| 亚洲色偷偷色噜噜狠狠99| 午夜两性色视频免费网站| 亚洲AV成人精品日韩一区| 成在线人永久免费视频播放| 风间由美在线亚洲一区| 亚洲高清视频一视频二视频三| 国产免费福利体检区久久| 亚洲精品无码乱码成人| 久久九九AV免费精品| 亚洲网址在线观看|