新寫了一個Java并發(fā)程序設(shè)計(jì)教程， 用于公司內(nèi)部培訓(xùn)的，和2007年寫的那個相比，內(nèi)容更翔實(shí)一些。

內(nèi)容列表

1、使用線程的經(jīng)驗(yàn)：設(shè)置名稱、響應(yīng)中斷、使用ThreadLocal
2、Executor ：ExecutorService和Future ☆ ☆ ☆
3、阻塞隊(duì)列 : put和take、offer和poll、drainTo
4、線程間的協(xié)調(diào)手段：lock、condition、wait、notify、notifyAll ☆ ☆ ☆
5、Lock-free: atomic、concurrentMap.putIfAbsent、CopyOnWriteArrayList ☆ ☆ ☆
6、關(guān)于鎖使用的經(jīng)驗(yàn)介紹
7、并發(fā)流程控制手段：CountDownlatch、Barrier
8、定時器: ScheduledExecutorService、大規(guī)模定時器TimerWheel
9、并發(fā)三大定律：Amdahl、Gustafson、Sun-Ni
10、神人和圖書
11、業(yè)界發(fā)展情況: GPGPU、OpenCL
12、復(fù)習(xí)題

下載地址：

 http://files.cnblogs.com/jobs/Java%e5%b9%b6%e5%8f%91%e7%a8%8b%e5%ba%8f%e8%ae%be%e8%ae%a1%e6%95%99%e7%a8%8b.pdf  

 歡迎看了之后寫反饋給我。
博客園的文章地址：

http://www.cnblogs.com/jobs/archive/2010/07/29/1788156.html

Google云計(jì)算AppEngine Java版剛剛推出來的時候，我就申請了該服務(wù)。該服務(wù)的申請需要提供手機(jī)號碼驗(yàn)證，GOOGLE很牛B，能夠發(fā)送全球的手機(jī)短信。申請的帳號放了很久， 前段時間學(xué)習(xí)OpenID，需要作一個范例，于是就在Google AppEngine上作，作的過程發(fā)現(xiàn)其不能使用線程，導(dǎo)致HttpClient組件無法工作，于是我修改了OpenID4Java的實(shí)現(xiàn)，全部使用 URLConnection來實(shí)現(xiàn)。最終程序部署成功了，網(wǎng)址 http://cogito-study.appspot.com，歡迎大家測試使用。

我來說一下我對Google AppEngine Java版本的使用感受吧。
1、 Google AppEngine Java版本，具備基本功能，但是由于缺乏一些重要的功能，例如線程，沒有線程，很多庫無法使用，例如我上面提到的HttpClient不能使用。 Google提供一個類的白名單http://code.google.com/intl/zh-CN/appengine/docs/java /jrewhitelist.html，大多數(shù)需要使用的類都有，javax.xml.crypto不再其中，使得我要部署一個SAML2的實(shí)現(xiàn)時玩不 轉(zhuǎn)。
2、Google AppEngine提供了一個DataStore，使用JDO訪問數(shù)據(jù)，其查詢語言支持GQL。基本功能是具備的，但是也是存在很大的局限性，最多返回 1000行數(shù)據(jù)，COUNT(*)也是最多返回1000行。這個限制使得很多應(yīng)用要跑在其上，會很麻煩。
3、部署很簡單，在Eclipse中使用Google提供的插件，輸入帳號密碼就可以部署了，太簡單了。但我使用的過程中，經(jīng)常出現(xiàn)某些時段無法部署的情況，通常遇到這種情況，多嘗試幾次或者過段時間再嘗試就好了。
4、管理界面簡潔方便，功能基本完備。包括性能監(jiān)控、數(shù)據(jù)管理、日志、計(jì)費(fèi)等都有。
總結(jié)
Google的AppEngine Java版本已經(jīng)具備了基本功能，可以部署簡單應(yīng)用了，但是由于其功能不夠完備，目前大多數(shù)應(yīng)用要部署在其上，都會要做相當(dāng)大的修改或者無法實(shí)現(xiàn)。

我在Google AppEngine上部署了一個Java應(yīng)用(OpenID測試)
http://cogito-study.appspot.com

Google Apps不支持線程，所用到的庫openid4java需要創(chuàng)建線程（因?yàn)镠ttpClient），我修改了openid4java的實(shí)現(xiàn)，使得其支持Google App Engine。

部署在Google App Engine上的應(yīng)用可以應(yīng)用任何OpenID Provider登陸，包括Google、Yahoo、MSN等。

你可以通過這個測試網(wǎng)站了解OpenID

最近花了較多時間學(xué)習(xí)單點(diǎn)登陸以及相關(guān)的安全技術(shù)，做一個簡單的總結(jié)，發(fā)表我的一些看法。拋磚引玉，希望各位朋友參與討論。

單點(diǎn)登陸，鳥語原文為Single Sign-On，縮寫為SSO。別以為單點(diǎn)登陸是很時髦高深的技術(shù)，相反單點(diǎn)登陸是很古老的技術(shù)，例如1980年kerberos v4發(fā)布，一直發(fā)展至今，被Windows、Mac OS X、Linux等流行的操作系統(tǒng)所采用，是為應(yīng)用最廣泛的單點(diǎn)登陸技術(shù)。

kerberos適用于局域網(wǎng)，十分成熟。互聯(lián)網(wǎng)發(fā)展之后，多個網(wǎng)站需要統(tǒng)一認(rèn)證，業(yè)界需要適合互聯(lián)網(wǎng)的單點(diǎn)登陸技術(shù)，也就是WEB SSO。2002年，微軟提出了passport服務(wù)，由微軟統(tǒng)一提供帳號和認(rèn)證服務(wù)，理所當(dāng)然，大家都不愿意受制于微軟，但是很認(rèn)同微軟提出WEB SSO理念，于是產(chǎn)生了Liberty Alliance，另外指定一套標(biāo)準(zhǔn)，這套標(biāo)準(zhǔn)發(fā)展起來就是SAML，目前SAML的版本是SAML V2，屬于OASIS的標(biāo)準(zhǔn)。

--------------
SAML

SAML，鳥語全名為Security Assertion Markup Language，彌漫著學(xué)院派的腐尸味道，縮寫十分怪異，令人望而生畏。計(jì)算機(jī)行業(yè)，向來崇尚時髦，SAML這一名稱使得其較少受到大眾程序員的關(guān)注。

SAML的標(biāo)準(zhǔn)制定者，來自SUN、BEA、IBM、RSA、AOL、Boeing等大公司，制定技術(shù)規(guī)范相當(dāng)專業(yè)有水準(zhǔn)，系統(tǒng)分層合理，抽象了幾個概念把整個系統(tǒng)描述得很清楚，使用流行技術(shù)XML Schema來描述協(xié)議，使用到了XML-Sign和XML Encrypt等較為前緣XML安全技術(shù)。

SAML的基本部分包括Protocol、Bingding、Profile、Metadata、AuthenticationContext。其中Protocol是交互消息的格式，例如AuthnRuequest/Response（認(rèn)證請求/響應(yīng)）的消息對。Bingding是指協(xié)議所采用的傳輸方式，例如使用HTTP Redirect或HTTP POST或SOAP的方式傳輸Protocol中所定義的消息。Profile是系統(tǒng)角色間交互消息的各種場景，例如Web Single Sign-ON是一種Profile、Single Sign-Out也是一種Profile、身份聯(lián)邦也是一種Profile。各個參與方所提供的服務(wù)的描述信息為metadata。系統(tǒng)的認(rèn)證方法通常是千差萬別的，AuthenticationContext是SAML中定義的認(rèn)證擴(kuò)展點(diǎn)，可以是最普通的User Password認(rèn)證，也可以是kerberos認(rèn)證，也可以是電信常用的RADIUS，或者是動態(tài)密碼卡。

SAML在Java企業(yè)應(yīng)用中，得到廣泛支持，IBM、BEA、ORACLE、SUN的Java應(yīng)用服務(wù)器都提供了SAML的支持，曾經(jīng)有人說，SAML就是如同JDBC一樣，將會是使系統(tǒng)集成的準(zhǔn)入證。SAML有很多開源實(shí)現(xiàn)，包括SUN公司的Open SSO，不幸的是，這些開源實(shí)現(xiàn)都不夠好，或者相當(dāng)糟糕，如果我們需要支持SAML協(xié)議，可能需要在開源的版本上裁剪或者另行開發(fā)。

SAML考慮了Web SSO，也考慮了傳統(tǒng)的SSO集成，包括Kerberos和LDAP的集成，其中Attributed擴(kuò)展機(jī)制以及相關(guān)規(guī)范，使得SAML擁有良好的擴(kuò)展性，很好集成傳統(tǒng)協(xié)議和支持新協(xié)議。

SAML是一個定義良好的規(guī)范，概念清晰，分層合理，擴(kuò)展性良好，一切都很棒，但是有一點(diǎn)不好，就是曲高和寡！

-------------
OpenID
有一些互聯(lián)網(wǎng)公司，擁有眾多很多帳號，很牛B，例如GOOGLE、YAHOO、Facebook，希望別人的系統(tǒng)使用它們的帳號登陸。他們希望一種足夠簡單的WEB SSO規(guī)范，于是選擇一種草根網(wǎng)絡(luò)協(xié)議OpenID。OpenID，名字取得好，顧名思義，一看就知道它是干嘛的。國內(nèi)也有它的Fans，例如豆瓣網(wǎng)。openID的確足夠簡單，但是協(xié)議本身是不完善，可能需要一些補(bǔ)充協(xié)議才能夠滿足業(yè)務(wù)需求。例如GOOGLE采用OpenID + OAuth。目前支持OpenID有Yahoo、Google、Windows Live，還有號稱要支持OpenID的Facebook。目前Yahoo和Google宣稱對OpenID的支持，但是其實(shí)是有限制的，Yahoo的OpenID只有少數(shù)合作伙伴才能獲得其屬性，Google也只有在其Google Apps中才能獲得賬號的Attribute。用戶賬號畢竟是一個互聯(lián)網(wǎng)公司的最寶貴資源，希望他們完全分享賬號是不可能的。

Open ID和SAML兩種規(guī)范，都將會減少系統(tǒng)間交互的成本，我們提供Open API時，應(yīng)該支持其中一種或者或兩種規(guī)范。

--------------
OAuth

oAuth涉及到3大塊的交互和通信。1. 用戶，2. 擁有用戶資料/資源的服務(wù)器A，3. 求資源的服務(wù)器B，。

oAuth的典型應(yīng)用場景（senario）
以前，用戶在 擁有資源 的的網(wǎng)站A有一大堆東西；現(xiàn)在用戶發(fā)現(xiàn)了一個新的網(wǎng)站B，比較好玩，但是這個新的網(wǎng)站B想調(diào)用 擁有資源的網(wǎng)站A的數(shù)據(jù)。

用戶在 求資源的網(wǎng)站B 上，點(diǎn)擊一個URL，跳轉(zhuǎn)到 擁有 資源的網(wǎng)站A。
擁有資源的網(wǎng)站A提示：你需要把資源分享給B網(wǎng)站嗎？Yes/No。
用戶點(diǎn)擊 Yes，擁有資源的網(wǎng)站A 給 求資源的網(wǎng)站B 臨時/永久 開一個通道，然后 求資源的網(wǎng)站 就可以來 擁有資源的網(wǎng)站 抓取所需的信息了。
(參考資料：http://initiative.yo2.cn/archives/633801）
（摘抄）
--------------

內(nèi)部系統(tǒng)間集成使用LDAP、Kerberos，外部系統(tǒng)集成使用SAML或者OpenID + OAuth，這是一種建議的模式。

------------
PAM

人們尋找一種方案：一方面，將鑒別功能從應(yīng)用中獨(dú)立出來，單獨(dú)進(jìn)行模塊化設(shè)計(jì)，實(shí)現(xiàn)和維護(hù)；另一方面，為這些鑒別模塊建立標(biāo)準(zhǔn) API，以便各應(yīng)用程序能方便的使用它們提供的各種功能；同時，鑒別機(jī)制對其上層用戶（包括應(yīng)用程序和最終用戶）是透明的。直到 1995 年，SUN 的研究人員提出了一種滿足以上需求的方案--插件式鑒別模塊（PAM）機(jī)制并首次在其操作系統(tǒng) Solaris 2.3 上部分實(shí)現(xiàn)。插件式鑒別模塊（PAM）機(jī)制采用模塊化設(shè)計(jì)和插件功能，使得我們可以輕易地在應(yīng)用程序中插入新的鑒別模塊或替換原先的組件,而不必對應(yīng)用程序做任何修改，從而使軟件的定制、維持和升級更加輕松--因?yàn)殍b別機(jī)制與應(yīng)用程序之間相對獨(dú)立。應(yīng)用程序可以通過 PAM API 方便的使用 PAM 提供的各種鑒別功能，而不必了解太多的底層細(xì)節(jié)。此外，PAM的易用性也較強(qiáng)，主要表現(xiàn)在它對上層屏蔽了鑒別的具體細(xì)節(jié)，所以用戶不必被迫學(xué)習(xí)各種各樣的鑒別方式，也不必記住多個口令；又由于它實(shí)現(xiàn)了多鑒別機(jī)制的集成問題，所以單個程序可以輕易集成多種鑒別機(jī)制如 Kerberos 鑒別機(jī)制和 Diffie - Hellman 鑒別機(jī)制等，但用戶仍可以用同一個口令登錄而感覺不到采取了各種不同鑒別方法。PAM 后來被標(biāo)準(zhǔn)化為 X/Open UNIX® 標(biāo)準(zhǔn)化流程（在 X/Open 單點(diǎn)登錄服務(wù)（XSSO）架構(gòu)中）的一部分。（摘抄）

如果我們設(shè)計(jì)一個認(rèn)證系統(tǒng)，PAM是應(yīng)該參考借鑒的。

-------------
JAAS
Java Authentication Authorization Service（JAAS，Java驗(yàn)證和授權(quán)API）提供了靈活和可伸縮的機(jī)制來保證客戶端或服務(wù)器端的Java程序。Java早期的安全框架強(qiáng)調(diào)的是通過驗(yàn)證代碼的來源和作者，保護(hù)用戶避免受到下載下來的代碼的攻擊。JAAS強(qiáng)調(diào)的是通過驗(yàn)證誰在運(yùn)行代碼以及他／她的權(quán)限來保護(hù)系統(tǒng)面受用戶的攻擊。它讓你能夠?qū)⒁恍?biāo)準(zhǔn)的安全機(jī)制，例如Solaris NIS（網(wǎng)絡(luò)信息服務(wù)）、Windows NT、LDAP（輕量目錄存取協(xié)議），Kerberos等通過一種通用的，可配置的方式集成到系統(tǒng)中。在客戶端使用JAAS很簡單。在服務(wù)器端使用JAAS時情況要復(fù)雜一些。（摘抄）

-------------
Spring Security，Spring框架大名鼎鼎，Spring Security屬于SpringFramework旗下的一個子項(xiàng)目，源自acegi 1.x發(fā)展起來。很多人項(xiàng)目應(yīng)用了spring security，但我個人看來，spring security絕對不算是一個設(shè)計(jì)良好的安全框架。其設(shè)計(jì)感覺就是一個小項(xiàng)目的安全認(rèn)證實(shí)踐罷了。

-------------
CAS
應(yīng)用最廣的開源單點(diǎn)登陸實(shí)現(xiàn)了，其實(shí)現(xiàn)模仿Kerberos的一些概念，例如KDC、TGS等等，都是來自于Kerberos。CAS對SAML和OpenID協(xié)議支持得不夠好。個人感覺類似Kerberos的機(jī)制在互聯(lián)網(wǎng)中可能過于復(fù)雜了。我感覺單純的ticket機(jī)制，過于局限于基于加密解密的安全了，感覺上SAML的Assertion概念更好，Assertion可以包括認(rèn)證、授權(quán)以及屬性信息。

-------------


--------------------------
09博客園紀(jì)念T恤
新聞：Wordpress發(fā)布實(shí)時RSS技術(shù) 推動實(shí)時網(wǎng)絡(luò)發(fā)展
網(wǎng)站導(dǎo)航: 博客園首頁  個人主頁  新聞  社區(qū)  博問  閃存  找找看

現(xiàn)在很多開源項(xiàng)目在使用LOG的時候做了不好的示范--在基類中實(shí)例化的方式使用LOG，而不是靜態(tài)變量。

例如：

class Base  {
     private final Log LOG = LogFactory.getLog(this.getClass());
}

class Derived  {
    public void foo() {
           if (LOG.isDebugEnabled()) LOG.debug("foo");
    }
}

這種用法，當(dāng)類被繼承的時候，LOG就完全亂了。spring、struts都有這樣的問題。

正確的使用方式應(yīng)該是直接靜態(tài)化聲明LOG。

例如：

class DerivedA  {
     private final static Log LOG = LogFactory.getLog(DerivedA.class);
}



--------------------------
盛大招聘.Net開發(fā)工程師
經(jīng)典好書：.NET框架程序設(shè)計(jì)（修訂版）
新聞：2008年最精彩科技圖片：電流運(yùn)動模擬圖居首
導(dǎo)航：博客園首頁  知識庫  新聞  招聘  社區(qū)  小組  博問  網(wǎng)摘  找找看
文章來源:http://www.cnblogs.com/jobs/archive/2009/01/05/1368894.html

Eclipse包含很多插件，插件之間有復(fù)雜的依賴關(guān)系，如果使用單獨(dú)下載安裝的方式，容易遺失部分需要依賴的插件。

在Ecliipse的Software Update功能中安裝插件，能夠解決插件依賴的問題，但是在Eclipse 3.4之前的版本，Software Update不能夠多線程同時下載，遇到網(wǎng)速較慢的更新站點(diǎn)時，需要漫長的等待，有時候安裝一個插件，需要數(shù)個小時，甚至更久。

在Eclipse 3.4之后，Software Update有了很大的改變，可以多線程下載了，但是不能手工選擇鏡像，它會笨笨的選擇一些很慢的站點(diǎn)，效果變得更差了，下載速度時快時慢，但是經(jīng)常都比以前手工選擇鏡像要慢。經(jīng)常選擇一些只有數(shù)百B速度的下載站點(diǎn)，令人抓狂！

所以說，Eclipse 3.4的Software Update功能依然令失望。

期待數(shù)年，終于盼來了新版的Software Update功能，但是新版的更差了，哎。。。

     摘要: 我們在開發(fā)中，經(jīng)常需要遍歷一個目錄下的所有文件，常用的辦法就是使用一個函數(shù)遞歸遍歷是常用的辦法。但是遞歸函數(shù)的缺點(diǎn)就是擴(kuò)展不方便，當(dāng)然你對這個函數(shù)加入一個參數(shù)FileHandler，這樣擴(kuò)展性稍好一些，但是仍然不夠好，比如說，不能根據(jù)遍歷的需要中途停止遍歷，加入Filter等等。我實(shí)現(xiàn)了一個FileIterator，使得遍歷一個目錄下的文件如何遍歷一個集合中的元素一般操作。  閱讀全文

http://openjdk.java.net/上的Announcements:

2008/04/28 New Project approved: More New I/O APIs for the Java Platform

包括內(nèi)容：

• 4313887 New I/O: Improved filesystem interface
• 4640544 New I/O: Complete socket-channel functionality
• 4607272 New I/O: Support asynchronous I/O

讓人期待太久太久了，終于來了，Java在大規(guī)模并發(fā)、高性能方面又進(jìn)一步，JSR 203應(yīng)該會在JDK 7中實(shí)現(xiàn)，屆時隨著JDK 7的發(fā)布，將會有更多的基礎(chǔ)軟件使用Java實(shí)現(xiàn)，而且有極好的性能。

在磁盤I/O和網(wǎng)絡(luò)大規(guī)模并發(fā)I/O方面都會得到更好的性能。

可以預(yù)見受益的程序：
1、WEB服務(wù)器 Tomcat、Jetty等，在Windows下，Java將可以使用IOCP，而不是現(xiàn)在nio所用的select，網(wǎng)絡(luò)并發(fā)性能將會得到大幅度提升。在Linux下則應(yīng)該改變不多，畢竟linux現(xiàn)在并發(fā)最好性能的網(wǎng)絡(luò)I/O EPOLL，JDK 6.0 nio的缺省實(shí)現(xiàn)就是epoll。
2、數(shù)據(jù)庫應(yīng)用程序。如Derby、Berkeley DB Java Edition等使用Java實(shí)現(xiàn)的數(shù)據(jù)庫，性能將會得到更好的提升，有望能夠誕生和Oracle、SQL Server一樣強(qiáng)大的100% Pure Java的數(shù)據(jù)庫系統(tǒng)。
3、其他網(wǎng)絡(luò)應(yīng)用程序。例如DNS、LDAP等，隨著MINA之類的框架更強(qiáng)大和JDK的原生支持，將會越來越多的服務(wù)器程序使用Java實(shí)現(xiàn)。

在新項(xiàng)目中，除了一些框架所依賴的配置文件使用XML外，基本沒有使用XML。JSON基本替代了原來XML在程序內(nèi)的位置。在以前，我們不愿意使用一種私有的格式，于是選擇了XML。選擇XML的理由，可能是大家都用它，所以我們也用它。

XML 是一種很好的技術(shù)，但是目前的情況來看，XML被濫用了，SOAP是XML被濫用的一種典型，程序內(nèi)部的表示使用XML也是濫用的一種典型。看到的一種情況，一個對象toString使用XML格式輸出，導(dǎo)致日志文件十分羅嗦，調(diào)試時，在watch窗口中看到一大堆<tag>。

在新項(xiàng)目中，認(rèn)真考慮這種情況，找到了另外一種選擇，那就是JSON。選擇JSON的理由很充分：
1、JSON的解釋性能要比XML要好，要簡潔緊湊。
2、可讀性要比XML好。JSON本身就是JavaScript的語法，和程序員的思維，而非文檔編寫的思維。
3、JavaScript原生支持，客戶端瀏覽器不需要為此使用額外的解釋器，在web環(huán)境中使用特別合適。

在java中使用json，目前需要注意一些情況：
1、目前開源的JSON-LIB代碼質(zhì)量不好，最好是在此基礎(chǔ)之上修改一個版本，或者自己重新開發(fā)一個版本。
2、使用new Date的方式替代JSON-LIB中的{year:2007, month:12, ....}之類的方式
3、JSON-LIB中，object的propertyName在輸出的時候，都帶上""，例如{"name": "溫少"}, 其中name是的雙引號是不必要的，在輸出時應(yīng)該判斷，不需要的就是就不加上""，減少網(wǎng)絡(luò)流量。
4、JSON的解釋器中，應(yīng)該支持簡單的表達(dá)式，例如new Date()、new Date(2939234723)之類的，這使得JSON的表達(dá)能力會更強(qiáng)一些。
5、JSON應(yīng)該分兩種，一種只支持簡單格式，類似開源的JSON-LIB，一種是通過JavaScript解釋器來實(shí)現(xiàn)的。后者在程序中傳輸數(shù)據(jù)時，能夠得到更強(qiáng)大的表達(dá)能力，但是也會導(dǎo)致安全問題，需要慎重使用。

1、 XP中的結(jié)對編程。XP編程中，有一些思想總結(jié)的很好，例如測試驅(qū)動，但又有極度的荒唐的就是結(jié)對編程。結(jié)對編程是我看到過的最荒唐最可笑的軟件工程方 法，兩倍的投入，一半的產(chǎn)出，可謂事倍功半。以前看結(jié)對編程只是覺得荒唐可笑，后來看了李安的電影《斷背山》，覺得以“斷背”來形容結(jié)對編程最適合了，結(jié) 對編程簡直就是專門為“男同志”們度身定做的軟件工程方法，你想一對“男同志”，每天手牽手背靠背進(jìn)行“結(jié)對編程”，是多么“浪漫有趣”的事情。不過這只 對“男同志”們的浪漫有趣，對工作本身一點(diǎn)也不有趣！
--------------

2、JDO投票鬧劇（2004-2005）。 一個通過黑客式靜態(tài)AOP方式旁門左道實(shí)現(xiàn)的持久化技術(shù)JDO，竟然會被一些人追捧，這本身就是一個很荒唐的事情了。在JCP的投票中，JDO被否決了， 這一點(diǎn)也不奇怪，奇怪的是投票結(jié)果出來之后的鬧劇。一些人以“政治陰謀論”來說事，說JDO不被通過，是因?yàn)檎卧颍羌夹g(shù)原因，這個荒唐的理由竟然 被社區(qū)的很多人相信了，一片聲討，JCP迫于壓力，重新投票，通過了JDO相關(guān)的JSR。但是JDO并沒有因此有一點(diǎn)點(diǎn)起色，一直沉淪至今。JDO通過靜 態(tài)AOP（enhance）的方式使得代碼無法調(diào)試，就單這一點(diǎn)，就足以使JDO永遠(yuǎn)無法流行。

這件事情很明確表明兩點(diǎn)：1)、不要相信一些技術(shù)作家的判斷力；2)、普通的大眾沒有判斷能力，會人云亦云。

當(dāng)年荒唐的文章選錄：
《程序員》2005年第2期 http://blog.csdn.net/gigix/archive/2005/01/21/262163.aspx
---------------