你才知道啊。老大，我早說不要去了吧。呵呵。

哇賽！這你都知道，真了不起，好，再來！～

再給你三句話，分別猜一個藥品/保健品的名字：
1。烏龜蓋了一所房子，然后住進去。
2。烏龜把剛才那所房子拆了，然后又蓋了一所房子，然后住進去。
3。烏龜又把剛才那所房子拆了，然后又蓋了一所房子，然后又住進去！

答案見下期。
^_^

現在，Eclipse基本上已經完成了所有大型軟件開發產品的天下歸一。。。。。。。等等，還有兩個公司——也只有這兩個公司不愿意接受Eclipse，他們是～～～～SUN～～～和～～～～Microsoft！！

^_^

陳敘遠？你是人機工程部的嗎？我在南京，不能上公司的內部網，你能跟我用郵件聯系嗎？

泡泡

是的，三種說法各有各的道理，所以他們是三個不同的學科，或者三個不同的環節，但是總有些人把他們混淆，或者不承認存在其中的一種UI，本文是想給這些人多一種選擇吧。

好，現在餓補大眾文化：給你三句話，分別猜一個歌星的名字：
1。豬從豬圈里跑出來了，怎么辦？
2。豬又從豬圈里跑出來了，怎么辦？
3。豬再次從豬圈里跑出來了，怎么辦？

^_^

P.S. 然后他們還會取一個特別吸引人的標題！

一流的公司做標準，二流的公司做服務，三流的公司賣產品，四流的公司寫軟件！

我們公司界與三流和四流之間，不過比KD好，他們只是四流公司。

您好，我是BlogJava的管理員，歡迎來到BlogJava！

我很喜歡您的Blog，而且我越來越發覺我們有著某些相似的愛好，Aspect，Tiger，Persistence等等，如果您有時間，歡迎來我的Blog看看，謝謝。

Brian Sun

支持你，現在只是精神上支持你，有時間的話可以幫你寫點代碼（物質上支持）。

目前博客園、BlogJava和博客生活的團隊功能還不太好玩，只是可以相當于一個多人的Blog，每個注冊上去的人都可以發文章跟隨筆，以后會向Wiki方向發展。謝謝大家的支持。

順便說一句，本人已經被提升為BlogJava的管理員，慶祝一下，^_^。

哦，這說明俺不怎么上那些無聊的網站羅，呵呵。

例子：面向方面語言

A: 面向對象語言
B: AspectJ 1
B1: AspectJ 2
B2: AspectWerkz
C: AspectJ 5

例子：Java的持久化問題

A: 二進制序列化
B: Entity Bean
B1: EJB 2.x/容器托管
B2: Hibernate
B3: JDO
C: 還不敢肯定，可能會是EJB 3.0
D: 可能會是JDO 2.0

吉安人，這你都知道。。。。

所以這就是Plato的洞穴寓言所要說的事。

哇賽，知音啊，我也是一直在用3.0.1版，覺得這個版本比較成熟，比較穩定，比現在最近版3.1M4或者3.1M5a好多了！

自我批評一下，由于沒有經過認真仔細的調查，犯了巨大的錯誤，其實上面所謂的第五條BlogJava目前已經做的很好了。真是“不調查就沒有發言權”！老毛講的一點都不錯！

目前的BlogJava不僅可以被Google很好的搜到（新文章大約要等3～4天才可以），而且還可以反向搜索！：）比如我的首頁用Google反向搜索可以搜到Blog里面的具體文章，用Yahoo的反向搜索還可以搜到我的幾個好友的Blog！（包括dudu）。這也是Yahoo在我心目中首次超過Google！

唉，俺們都是程序員，哪有那么多搞笑細胞，好不容易搞兩個笑話，還是從別人那里拷來的，你還笑俺，太沒人性了！真是地道的吉安人！

據說JDO2.0已經獲得了通過，下面是第二次投票的結果:

JSR #243
Java^TM Data Objects 2.0 - An Extension to the JDO specification
Public Review Reconsideration Ballot

These are the final results of the Public Review Reconsideration Ballot for JSR #243. The Executive Committee for SE/EE has approved this ballot.

Votes

SE/EE Apache Software Foundation Apple Computer, Inc. BEA Systems Borland Software Corporation Fujitsu Limited Google Inc. Hewlett-Packard IBM IONA Technologies PLC Intel Corp. JBoss, Inc. Lea, Doug Nortel Networks Oracle SAP AG Sun Microsystems, Inc.

Icon Legend Yes No Abstain Not voted

---

View Vote Log

SE/EE
On 2005-02-22 Sun Microsystems, Inc. voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-28 Intel Corp. voted Yes with the following comment: An agreement between the Spec Leads of 2 Expert Groups is not binding on the Executive Committee. That said, the extra time for review has demonstrated that the JSR 243 Public Draft is consistent with the "letter" from the Spec Leads so there is no problem there in any case. In similar situations in the future, it would be better to use the usual process of initiating a new JSR rather than a letter from Spec Leads. That would provide more transparency and involvement of the community. ------------------------------------------------------------------------------ On 2005-02-22 Google Inc. voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-22 Apache Software Foundation voted Yes with the following comment: Let a thousand flowers bloom :) ------------------------------------------------------------------------------ On 2005-02-23 Lea, Doug voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-23 Nortel Networks voted Yes with the following comment: Nortel supports the JDO Technology and its ongoing use. ------------------------------------------------------------------------------ On 2005-02-25 IONA Technologies PLC voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-27 JBoss, Inc. voted Abstain with the following comment: Since this newly proposed specification is essentially identical to the one proposed during the Public Review Ballot vote, we would see no reason to change our vote, hence our previous comment remains. However, while this vote is fundamentally a NO vote, we cast it as an ABSTAIN to acknowledge Sun's role in trying to clarify the situation through their FAQ, and most specifically the central role of persistence in the JSR-220 specification and in the Java platform as a whole: "The new persistence API as defined by JSR 220 will be the standard Java persistence API going forward.". This JSR-243/JSR-220 discussion, initiated by some JSR-243 proponents, has only brought disruption on the JSR-220 side and no sign of flexibility on the JSR-243 side. This could give the feeling of a coup to slow down the JSR-220 EG. The J2EE/EJB specification set represents the significant part of today?s Java ecosystem. Hence, in order to remain competitive, it is critical to make sure these specifications don?t get disrupted. ------------------------------------------------------------------------------ On 2005-02-28 Hewlett-Packard voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-28 BEA Systems voted Yes with the following comment: After further review, BEA has concluded that there is a vibrant JDO community which needs this specification, regardless of whether we are successful in achieving an overarching persistence strategy. As a result, I see no reason to hold this community hostage to a goal that may or may not be achieved. ------------------------------------------------------------------------------ On 2005-02-28 Oracle voted Abstain with the following comment: Oracle's primary concern has been partially addressed with the FAQ published by Sun reiterating that JSR 220 is the intended standard Java persistence API moving forward. Given the clear direction set by Sun on this issue, we will not object to the evolution of the specification to serve the existing JDO community. It is vital that the persistence work in JSR 220/EJB 3.0 for the mainstream J2EE community not be disrupted. EGB 3.0 is making excellent progress as part of the umbrella J2EE 5.0 specification and has been well received. ------------------------------------------------------------------------------ On 2005-02-28 IBM voted Abstain with no comment. ------------------------------------------------------------------------------ On 2005-02-28 SAP AG voted Yes with the following comment: SAP thanks the JSR 220 and JSR 243 Spec Leads for the additional clarifications that were provided for this reconsideration ballot. We are satisfied with the clarifications regarding the future roadmap of EJB 3, JDO 2 and the new J2SE persistence model that is being developed as part of JSR 220 and therefore do not see an impediment for JDO 2 to proceed. Given that JSR 220 has the challenging goal to deliver an overarching persistence strategy for Java, it is important that the interests of all existing persistence communities, including JDO, are equally represented in this Expert Group. ------------------------------------------------------------------------------ On 2005-02-28 Borland Software Corporation voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-28 Fujitsu Limited voted Yes with no comment. ------------------------------------------------------------------------------

最近用了一下wiki，感覺不是很好用，即使是最權威的MediaWiki也不太好用，但愿dudu能開發出一個讓我們大家收益非潛的wiki系統來。
呵呵。

發到我的郵箱里來吧，挺有意思的。Gmail的郵箱。

你指的是哪個廣告？有什么意思？

辯論出現在軟件開發中的幾個場景：

1。偷換概念。“你說的這不是xx，我說的那個才是xx”

2。將概念外延一味擴大。“我所說的xx包括yy和zz，所以你還沒理解我的意思”

3。主題轉移。“對于用戶來說是xx，但是對于開發人員來說卻不是xx，而是yy”

4。打比方。（這在辯論場上是很有力的一招，但是太流氓）

5。旁征博引。“既然微軟認為xx，那我們也不會比微軟好到哪去，也xx吧”

。。。。。。

未完待續

這是一個好現象，因為會C只是會一種實現方法，而實現有many人去做，CORBA既是一種廣泛的實現方法，也是一種高層設計手段，還對重用遺產系統有很大的好處，所以應該有更多的人去用。

中國人學習計算機（其實所有理科都是這樣）最喜歡從底層做起，我見過一個程序員花一年的時間自己寫了一個Java虛擬機，實在是沒必要。大部分中國程序員覺得不懂CORBA可以，不懂C就不是程序員！這種現象叫眼低手高，比眼高手低還可怕。

但我相信會有很多人愿意選擇第三個，只是因為他們（或她們）上我的blog的機會很小，所有沒有看到這篇文章。我猜想很多搞藝術設計或者網頁制作的人會喜歡第三個方向，有點CG的味道。

呵呵，你說“佩服佩服”，我是不是應該說“失禮失禮”就像古代人，或者“過獎過獎”就像現代人啊。：）

產品的最終設計就是工程設計。簡單的解釋一下二者的區別，比如鍵盤，工程設計就是指設計一個附和人體工學的鍵盤布局，例如把打字區一分為二，或者采用更縝密的彈簧增加擊鍵時獲得的舒適感，抑或加入鍵底薄膜可以防水。而工業設計就涉及其生產制造的過程，例如采用什么塑料可以降低生產成本，采用什么形狀的彈簧可以減少生產環節，降低次品率等等。

那你所謂的設計師是什么含義呢？是我前面提到的UP中的一個環節？還是搞產品最終設計的？或者說，你的設計是專注于工業設計還是專注于工程設計？

呵呵，這說明dudu是一個典型的程序員，如果是我，我愿意選擇第一個，稍帶一些研究性質。

呵呵，沒想到還有高手前來討論，其實利潤分離在人類社會經濟進化的歷程中處處都有，關鍵在于是不是所有人都從中受利。比如給NIKE做OEM的工廠如果生產自有品牌，可能就面臨更多的風險和開拓市場所需的成本，其銷量也不會有NIKE那么好，但是如果給NIKE生產商品，利潤率就會有所提高。至于NIKE，如果它自行生產所有商品，必然陷于資金的不足，融資又有成本，利潤率也不夠，但是如果專注于設計和品牌營銷，把這兩樣做好了，利潤自然滾滾而來。既然對而者都有好處，他們就會這樣去做。

但是在國內就不同了，因為市場競爭不充分，專注于設計和品牌的企業可能面臨巨大的風險，又由于消費者的維權意識很差，消息又閉塞，導致很多工廠自己做銷售會賺的更多，所以就有自己的貿易公司了。

這樣做導致的結果很不好，因為銷售公司是為生產部門服務的，所以經常出現生產多少銷售部門就有多少銷售任務的情況。銷售部門也不承擔質量問題，生產部門也不會自己跟自己過不去，于是消費者的權益就無人理睬了。

如果讓你選擇上面提到的三個方面中的一個去研究，你會選擇哪一個？

據說是“不愛紅妝愛武裝”的意思，因為powder的解釋很多。

這本書提及的軟件設計和我所理解的軟件設計是同一回事，但是和現在很多人理解的軟件設計不是同一回事。

現在的人們理解軟件設計好像是UP中的一個環節，所以方方面面都要到位，但又不能超格，就好像是生產線的一個流程一樣，失去了設計的本意。而這本書喚醒了人們心中對設計的美好理想，設計表達的應該是軟件最終的樣子，包括界面和交互式設計，當然還有載體等等其它因素，設計應該是對設計者和開發者整體思路的構造，而不是一個面面俱到的東西。

但話又說回來，現在的軟件功能性往往多于交互性，比如一個系統，80％的程序員可能根本就遇不到系統的界面和交互，設計對于他們來說多少就有點架構的意思了。

泡泡

看到他們回的帖了，實在無聊，和我想象中他們會回的帖子一樣，所以我不會再回，因為再回帖就意味著吵架或者是他們所謂的“辯論”，我的“辯論”不是這樣，在我的辯論世界里我只談自己的看法，不回擊別人對我的指責，直到有人真正看懂了我的理論體系并對此提出致命性打擊時，我才會出手。而我出手的時候，也就意味著我知道自己之前的言論錯了，或在某個層面錯了，并且我已發現了改進的方法。 當然，也不排除這種可能，那就是有人從根本上駁倒了我，讓我覺得自己之前的立場如一堆廢紙般毫無意義，那我會帖出我全新的認識，毫不猶豫的！總而言之，我的原則就是——我只參與見解的分享，不參與見解的評論！

感覺如何？

呵呵，MSN Space慢主要是因為它的圖片和廣告，還有花里胡梢的外觀，建議Microsoft可以考慮提供一種簡單設計的blog，功能恰到好處，采用單獨的服務器運行。

我的郵箱是
briansun.vip@gmail.com

我的MSN上班時間都開著
javaboy2010@hotmail.com

我是這樣考慮的。我們先來看一個簡單的比喻。我們都知道圖有兩種基本的表示法——鄰接表和鄰接矩陣，兩種方法都可以全面的反映圖的信息，這意味著前一種表示法能做到的事情，后一種表示法也都能做到，同樣后一種表示法所做到的事情，前一種也不會做不到。所以圖只要以其中的一種表示法表示就可以了，（由于兩種表示法對不同操作有不同的反應性能，所以）除非有特殊的性能需求，否則不需要使某個圖同時具備這兩種實現方法。

現狀也很類似，既然“Facade＋懶加載”與“容器＋Service”同時為解決問題的兩種方案，或者可以說是兩種實現方法，我們的系統又相對穩定，不會出現一會要加載5個服務，一會又變成50個的情況，所以我認為兩種方案不需要同時具備。此外，如果同時采用這兩種實現方法的話，很可能會在設計時出現這樣的尷尬局面：當程序員需要get一個對象時，他將面臨一個選擇，是將這個get方法放在容器里呢，還是放在門面上，或者，干脆，他兩個方法都提供，“既然后期需要大量重構，不如現在來點冗余代碼”的想法真的很深入人心。。。。。。

做平臺的泡泡

＃……×※◎……＃×※◎！￥％◎！……￥◎……￥×◎！
熱烈祝賀樹懶同學進入復試！
等全部確定下來后我去與你匯合，
并親赴你不得不請的飯局！
無論你在合肥、青島、北京、南京……
＃……×※◎……＃×※◎！￥％◎！……￥◎……￥×◎！

說得對，MacOS X確實對MacOS支持的不是很好，前者是蘋果公司在徹底拋棄了原來的操作系統架構之后完全重做的，采用了類Unix內核。后者是原來的產品，從八十年代末就開發了，使用的是Windows第三版以前的內核（Windows95是第四版。。。。。），兩者不能很好兼容是很正常的事，但是身為硅谷和好萊塢都著名的雙料大腕，蘋果公司顯示出了一個業界領導人應有的風采，給予了合作伙伴不少的支持。要知道，每個新版的圖形工作產品或媒體產品如Photoshop都是先發布蘋果版再發布PC版的，可見蘋果對軟件供應商的支持遠多于某些廠商。
（這又給了我們一個啟事，既然像蘋果這么大的公司都可以選擇如此大規模的變革——誰說大象不能跳舞？！）

呵呵，哪里哪里，一般一般。。。。呵呵。。。這個嘛。。。其實。。。。我也不懂的很多啦。。。。嘻嘻。。。我懂的也不是很多啦。。。哦。。常來看看喔。。。

ERPII與ECM之戰
摘自ZDChina [http://www.zdnet.com.cn/biztech/e-business/story/0,1000001984,20029349,00.htm]

Thursday, September 20 2001 1:40 PM

從商業界為了產品的商標而煞費苦心這一點上可以看出IT業現在的發展趨向。各大公司都在利用內部保密的新策略努力為自己的產品定名，這一行為好象自然界的動物為了生存空間而相互競爭一樣。
Click here to find out more!

Gartner 公司正在進行ERP II的升級，AMR Research也在致力于ECM的工作。ERP II和ECM都是縮寫詞語，它反映了互聯網技術正在使得各公司不用自己公司的名稱來定義它們軟件產品的趨勢。ECM（enterprise commerce management）即企業商務管理，在當今也許就是一種超前的概念，它更準確地描述了它的用途，也就是讓人們一目了然知道它是用來做什么的。這兩個術語也只是剛剛脫離傳統走向新型定名概念的開始，現在說它們能夠準確地描繪出未來電子商務的發展趨勢還為時過早。

ERP II其實是相當于在原有的建筑上添磚加瓦。Gartner早在十年以前就創造出了這個詞——ERP (enterprise resource planning) 即企業資源計劃，是為了描述一種新型的軟件，這種軟件是集中了多種工作任務于一身的集合體，這些任務包括金融方面、人力資源方面、命令和單獨運行共享數據庫等。ERP銷售商，如：Oracle, PeopleSoft, 和 SAP 一直銷售情況良好，直到一年多以前業內不景氣之時情況才發生變化。原因也很顯而易見，就是新興起的SCM（supply-chain management）即供應鏈管理；CRM（customer relations management）客戶關系管理；電子購物；電子市場；以及其它一些商業對商業應用搶占了市場，奪取了ERP原有的光彩。

關于ERP II的構想的確有它自己的道理，很有可能再次刮起一陣ERP旋風。因為，盡管現在很多公司在使用新的應用產品，但是過去的ERP系統還沒被各公司拋棄。原來的ERP銷售商也期待著有一天能夠重新拾起老本行的工作，把新的B2B（business to business ）應用功能添加到原來的ERP上使得ERP重新煥發青春。比如：Oracle, PeopleSoft, 和SAP這幾個原來青睞于ERP的公司，現在正提供它們自己的CRM產品。然而在ERP II一路走來的時候，頗具諷刺的是，除了以前曾經經營過ERP的幾家公司之外Gartner還沒有確認新的公司作為ERP II的經營者。這使得Ariba, i2,和 Siebel Systems等一些銷售公司大為失望，因為這些公司為ERP 重新殺回市場做了不小的貢獻，它們通過開發新的B2B應用程序從而提供更好的合成應用，為ERP 的東山再起奠定了實力的基礎。與此同時，老的ERP銷售商打算放棄原有的ERP商標，作為重鑄自我形象——建立新型電子商務供應商形象的關鍵一步。

ECM已經把諸多因素都考慮進來。AMR Research的觀點是ECM要比Gartner的ERP II更高級，因為ECM已經認識到了B2B軟件銷售商家的重要作用。正如July AMR 的報告所說的那樣，ECM的其中一個規則就是把多個銷售商的共同系統作為一項現實目標去實現。ECM還為應用合成提供了更廣闊更具實用性的步驟。ERP II希望各個公司能夠把外向型應用（如：CRM和SCM）與原來的ERP系統聯合起來。ECM升級了一個合成框架結構，可以提供一個介于個別的ECM 模板和B2B應用模式之間的新型應用。現在ECM不再期望完全的合成功能，而是接受了秘密的貿易交流，這作為一種途徑為公司在降低成本和復雜性的同時與用戶加強了聯系。

盡管ECM的構想很不錯，但無論是它還是ERP還都缺乏前瞻性。兩個概念只為IT提供了一個中介模式，那就是適應電子商務的需要。這一步邁出的方向是正確的，但是力度還遠遠不夠。

ERP II和ECM都認為單個的企業仍然將是電子商務市場的骨干力量。它們都以企業為主要依靠，直到電子商務的核心轉移到互聯網上來。公司們也都認識到她們必須配置軟件和程序以滿足眾多客戶公司的需要。有的公司也將不得不放棄一部分它們曾經所追求的獨立性，因為這樣做使得它們可以獲得協作帶來的利益。同時，他們也將更加地開放，以便能夠與它們的客戶和供應商建立更密切的聯系和分享信息。

我是有興趣的，但我沒翻譯過書，只翻譯過一篇文章（在非程序員第37期，署名也是briansun），不知道難度如何，你有樣章可以給我看看嗎？

briansun
email:briansun.vip@gmail.com
blog:http:/www.briansun.com

兼容性分三個方向講，一個是自兼容，即兼容本體系的產品，比如Office組件間相互兼容，Windows XP和Windows 2K明明是采用不同的內核，確幾乎相互兼容90％以上的應用。

另一個是橫向兼容，是講本產品與其它同類產品的兼容性，這種兼容性多數是根據大企業或第三方機構所發布的標準來定的。比如StarOffice聲稱自己和Office兼容的很好。

第三種兼容性就是縱向兼容，意思是本產品能兼容多種平臺，或兼容很多下游軟件商的產品。比如StarOffice兼容很多操作系統，Linux、Solaris、Win32，但是Office卻只兼容Windows。

蘋果的Mac體系產品和MacOS X操作系統確實是值得崇拜和研究的對象。我們都知道它不兼容IBM PC體系，但并不是說它缺乏兼容性，相反，它的自兼容和橫向兼容都做的很好了，現在在MacOS X上已經可以運行多款微軟產品Microsoft Office、Microsoft Internet Explorer、Microsoft Media Player、Microsoft MSN Messenger等等，加上以前就對它支持的Adobe，Coral，Java，Mozilla，Macromedia，EA，暴雪等品牌，蘋果產品已經對PC兼容的很好了。他們唯一不放棄的就是縱向兼容性，也就是說MacOSX不能在PC上跑（盡管它用的是類Unix內核），而Mac系列個人電腦也不能用Windows/Linux。這樣做的好處是

a.幾乎沒有蘋果電腦能感染的病毒。

b.由于沒有其它廠商可以生產蘋果的個人電腦，保證了它的質量、售后服務和市場形象。

c.由于沒有消耗資源的Windows，蘋果機的性能非常好，使其可以勝任高性能圖形工作站的角色。

d.有限的應用杜絕了很多橫向兼容性問題，使其bug的數量呈幾何級數遞減。并可以專注于設備的外形設計。

e.有限的硬件供應商使升級頻率減少，耐用性大大加強，一般的蘋果電腦使用十年以上是沒有問題的。

f.獨特的定位使得IBM、HP、Dell等“黑手”無法撼動蘋果“個人電腦之王”的稱號，蘋果也是據我所知的唯一一個在某領域各方面都擊敗Sony的企業。

想買蘋果產品的泡泡

呵呵，謝謝Yuko的回復，你是我最好的朋友之一。你的信我已經幫你寄出了，而且保證沒有看。。。。

在HR的招聘環節中，招聘方式的選擇往往存在一個成本性指標的問題。簡單的說，就是如果兩個同等效力的方案之中的某一個更便宜，企業就會選擇，無論是企業的規模與行業的差別。

具體的說，應該遵循下面這個過程。

1。如果存在一種方法，正確的衡量某個人的能力與企業對這個人的愿景，那么企業就會選擇。

2。遺憾的是腦經正常的人都知道這種方法是不存在的，那么企業必然會選擇層層考核加試用來衡量一個人的能力。這對大企業來說是很應該的，因為他們有的是錢，而需要合格的人來花這些錢。素質高的員工是利潤的來源，客戶信賴的對象，企業的門面，也是減少內部溝通成本的最佳選擇。比如P&G在很多大學都只招一個人，Intel和麥肯錫都只要碩士以上學歷的人。

3。現在我們有了一種衡量能力的合理方法，可是對于中型企業來說，這種方法成本太高了，大多數中型企業面臨人才的極度需求狀態，但是他們確實沒有什么地方能夠留住人才的，因此中型企業往往是薪水最高的，一般都會比大型企業要高。這時中型企業無法忍受應聘者的慢熱情況，他們需要立即能上手的人才，所以這些企業往往不看重應聘者的學歷，而重視能力，園長就是這樣進入國內最大的獨立軟件供應商的。

4。小企業又是完全另外的一回事，因為小企業愿意花更少的成本來衡量一個人的能力，他們既不愿花錢來判斷誰最有能力（這個需要有伯樂，而請伯樂需要花錢），也不愿意花錢給人做大量的培訓，更不愿意讓人隨隨便便實習。這些企業能找到的最省錢的判別人能力的方法就是請學歷和社會經驗代勞。這也就是說到這樣的企業找工作，做一份好簡歷是個非常重要的秘訣。

想知道如何成生這些圖片嗎？寫信給園長就告訴你！

這個bug也臭了點吧。。。。

買個本本怎么會有這么好的配置呢。。。再說買個8000塊錢的本本肯定是國產貨中的劣等貨，呵呵，不值得一買。。。。

樓上這句話說得還有點道理，我頂你。。。呵呵。。。。